Jump to content

290128050_ConstellationBanner.jpg.6eb5d1fe82e0853d4c3b80a745d12d74.jpg

DIY cloud and rain sensor with ascom support?


Corpze
 Share

Recommended Posts

Just an idea from my side( I am not at all sure workable it is), is to connect a anemometer for wind speed and use that as another safe or not safe condition. A way to sense moisture on the scope would also be very useful. At least in my mind there three issue that I want to be warned about, one is clouds two is excessive wind and three is when my dew control system failed(this rarely happens but it did on two occasions and everything was soaked)

Link to comment
Share on other sites

  • 2 weeks later...

So, i think it´s time for some "long-time" feedback.

It´s running 24/7 and have done so for almost a month now, without a glitch, at all.

There has been almost flood-like conditions in Sweden during September with almost 30-40mm of rain some days, and the sensor keeps on going.

The values seems very consistent and reliable, it reports back to the Sequence program as it should and it seems to be all good, there is some question marks left though;

The rain sensor (cheap china sensor) looks like it corrodes, I assume I have to just look and see how long it lasts. Maybe someone have a picture of a AAG or similar to compare with?

The setup dialog box Indicates "Overcast or fog" under the Cloud Sensor settings, even though it is clear weather, it doesn't really matter but is a nice feature.

After have been watching the setup dialog box then and now for nearly a month, i clearly see why the other makers have a program to look over the parameters etc. when i close down the setup dialog box and hit ok, the driver runs flawless, but i simply have to rely on the hardware to work as it should.

To sum it up -  :headbang:

/Daniel

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

I wanted to stop by and let folks know that the CloudSensorEvoPlus -Alpha on my GitHub (https://github.com/hjd1964/CloudSensorEvoPlus/tree/alpha) now has support for the Arduino Ethernet Shield (W5100).  This displays a chart of the last half-hour (actually the time span is configurable) of cloud readings along with the sensor data and safety status.   It also has support for reporting on barometric pressure (BMP180) and humidity (HTU21D.)  This is in addition to the usual serial channel that's usually tied up with the ASCOM driver.  There's also a command channel on port 9999 of the ethernet adapter so "anyone" can stop by and pick-up a sensor reading.

Full function requires a Arduino Mega2560.  However, the cloud detection w/web-site will run on a Mega328 (UNO, etc.) if you leave the humidity and barometric pressure sensing turned off.

Howard

Link to comment
Share on other sites

  • 1 month later...

Wow, you really have put some nice work on evolving the sensor, will this program work without the ethernet shield?

I have now run mine the whole winter without any glitch, see the attached logfile.

The graphs you have made looks neat!

/Daniel

Safetymonitor.JPG

Link to comment
Share on other sites

  • 6 months later...

Thank you so much to all.

 

I built this cloud & rain sensor with CloudSensorEvoPlus code from GitHub and works like a charm!!!

thank you so much to provide me very cheap cloud sensor to my observatory, now I could sleep a little bit more... :D

Edited by carballada
Link to comment
Share on other sites

  • 1 year later...

Thanks for this piece of software!

I cannot get the graph to work. I'v format the sd card (FAT). Downloaded Chart.min.js and renamed to Chart.js in the root directory of the sd card.

changed: #define SD_CARD_ON

Uploaded to the arduino UNO and then no webage is showing anymore. Any ideas?

Link to comment
Share on other sites

It's been an age since I've touched this code.  Provided your configuration and hardware are good the only thing that comes to mind would be if Chart.min.js was updated and is no longer functioning as intended with my code.

Github can be used to download an older version (from any repository) or grab the fork I made from about two years ago and try that...

https://github.com/hjd1964/Chart.js

 

Link to comment
Share on other sites

Sorry to barge into this thread (have to admit I didn't read it all). I'm curious which actual sensors are you guys using that can talk to an Arduino? I'm interested in writing an INDI driver.

Link to comment
Share on other sites

Wow, the list of sensors really goes on forever.  Arduino is very popular so lots of library support. 

I like to stick with I2C since it travels some distance with little trouble and two pins take care of everything.  I use all of the following in one role or another:

BME280, SI7021, MLX90614, BMP180, DS18B20 (1-wire)

  • Like 1
Link to comment
Share on other sites

1 hour ago, hdutton said:

It's been an age since I've touched this code.  Provided your configuration and hardware are good the only thing that comes to mind would be if Chart.min.js was updated and is no longer functioning as intended with my code.

Github can be used to download an older version (from any repository) or grab the fork I made from about two years ago and try that...

https://github.com/hjd1964/Chart.js

 

Yes! That did the trick! Thanks...

Link to comment
Share on other sites

I'm still a bit confused.  Changing  the value SecondsBetweenLogEntries doesn't seems to change the graph and in the config.h  dataFile = SD.open("Chart.min.js", FILE_READ); (instead of Chart.js)?

Link to comment
Share on other sites

Two things, you don't need the sensor driver, you could call ascom directly from your sensor controller using the ascom rest api. I'm using node red to run a workflow that is called by Alexa, it receives data from sensors and can issue REST calls into Ascom to open and close the dome etc.

Second, average is easy and not that intensive, you just need to add the data as the buffer fills and then manage adding and deleting once full.

 

Link to comment
Share on other sites

7 hours ago, skybadger said:

Two things, you don't need the sensor driver, you could call ascom directly from your sensor controller using the ascom rest api. I'm using node red to run a workflow that is called by Alexa, it receives data from sensors and can issue REST calls into Ascom to open and close the dome etc.

Second, average is easy and not that intensive, you just need to add the data as the buffer fills and then manage adding and deleting once full.

 

First, let me say that this project was a quick and dirty exercise in how fast I could get it done.  I don't even use CSEP...

I'm not following point 1 though. 

  • What is a "sensor driver".  A driver in my mind is a library/code to access a given sensor device.  You need that (even if it is "client side".)
  • What is a "sensor controller".  Is this the Micro-controller (Mega2560 or UNO in this case)?
  • Sounds like you're saying that you don't need an ASCOM driver that the Micro-controller is sending data to ASCOM but my understanding of ASCOM says that's not how it works. 
  • An ASCOM driver talks to the Microcontroller that talks to the sensors.

I'm not really interested in working on CSEP again but rather just want to understand if this is something worth looking into for my other projects or not.

Edited by hdutton
Link to comment
Share on other sites

I didn't mean to be critical, I just wanted to point out an alternative. 

By point 1 I am assuming that whatever you build in Arduino or serial  land is IP enabled and is the interface to the sensors.

That is the thing that you can put your sensor logic in and use to drive ascom via the REST interface.

 

Mike

 

Link to comment
Share on other sites

On 26/07/2018 at 02:54, hdutton said:

Are the sensors attached... it doesn't obey that setting except...

#if defined(MLX90614_ON) && (defined(DS18B20_ON) || defined(DHT22_ON) || defined(HTU21D_ON))

 

I didn't as I was just testing before actual build. Now that I have the sensors attached, the graph changed. Thanks again. Now the housing can start :)

 

Link to comment
Share on other sites

  • 11 months later...

Hi guys,

 

Out of curiosity, those that have built this system, how is it going for you guys? Is it still working? How long has it been working for? I am looking at a Cloud/Rain sensor for a remotely operated observatory I am setting up. I am pretty much building everything with little commercial available items (cloud sensor etc.. ). It would be nice to continue to build the remaining items. 

Link to comment
Share on other sites

  • 1 year later...

Guys,

I followed this thread towards the end of last year and being intrigued I went ahead and built this as per spec -  only recently been able to test it for calibration (had cloud, rain, cloud, more rain, for what seems months!).  So far seems its operation may be a bit unpredictable, as described below, but I need to do more analysis to clarify that!

Not sure if anyone will still be following this thread after all this time, but this is my update so far for anyone who may still be interested ....

Basically, the system worked first time - brilliant.  What I have noticed, however, is how sensitive the MLX90614 sensor actually is!  I have it mounted on top of my 'cloud sensor' enclosure pointing vertically straight upwards as required, this enclosure is in turn is mounted on the side of a portable box I use to contain power supply, mini pc, router, etc. which I normally place adjacent to the 'scope + mount when I hook everything up.

This evening was clear (the first decent clear night for ages) so decided to set just the box up outside to assess the 'night time, clear sky' readings (no mount/'scope).  This was positioned about 3 metres from the rear of my house on patio, with the cloud sensor box located on the side facing towards the house - I tend to do it that way, so the mini-pc would also face the house in that orientation, ensuring good wi-fi reception to my router.

To start with, it seemed the sky reading was somewhat 'warmer' temperature (~ -13 degrees C or so) and, with the ambient reading ~ +8.9 degrees C or so, the Ave. Diff. was thereby wobbling around the cut-off value, causing periodic unsafe conditions to be registered even thought the sky was perfectly clear.  By chance, I then turned the box around by 90 degrees so that the sensor was on the 'away from house' side and immediately the sky temperature dropped dramatically to around ~ -20 degrees  or lower!  This allowed the Ave. Diff. to change quite soon to a higher value, meaning it was more above the 'safe' limit than before ....

In other words, I can only presume that the sensor must have been susceptible to the radiated heat coming from my house (?), and turning it away from the house has allowed it to read the sky more accurately?  I don't know, only presuming here ....

In any event, a daytime 'cloudy' measurement I managed to do last week resulted in about the same Ave. Diff. readings as I'm currently reading this evening after I turned the box around!  So, I'm not totally sure what this means - is the technology or the theory not as accurate or reliable as it could/should be?  Should we therefore expect to take these readings with a pinch of salt, not to be relied upon completely?  To be fair, I haven't yet had an opportunity to do some night time, cloudy (and dry!) readings for comparison yet, so I guess that might be the proper comparison test against this evening's results.

If anyone's interested, I'll try to report back here with more info if/when I get it!

Stay safe,

Richard

Link to comment
Share on other sites

Hmmm .... thanks for the info skybadger.  So in your experience when configured correctly looks like it does work as expected then.

My sensor is open to the elements, just inserted into a hole in the top of the enclosure.  So I wonder if that creates too much of a viewing angle (standard sensor is 90 degrees FOV I believe) in that case - compared to your approach anyway?  Maybe I also need to 'concentrate' the FOV?

I've also fitted a small piece of EeonTex High-Conductivity Heater Fabric around the sensor, to ward of any dew forming.  I simply cut a tight fitting hole in the centre of a 2cm square piece and feeding 3 volts across it, then placed sensor through the hole in this with an insulation layer (to stop any electrical shorting - small piece of baking paper!) and subsequently through the hole in the top of the enclosure, so the insulation layer and heater fabric is 'sandwiched' between the sensor pcb and the underside of the enclosure body - seems to work nicely as far as I can tell!

Difficult to measure accurately, but this  probably raises the temperature being recorded by the sensor a little, but then I should be able to compensate for that by adjusting the threshold value accordingly.

What I can't figure out yet is why I saw similar readings for 'daytime cloudy' last week compared to my 'night time clear' yesterday evening?  More testing necessary ....

Out of interest, skybadger, what sort of LED lens have you used on yours?

Richard

Link to comment
Share on other sites

  • 7 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.