Rain sensor
-
It is fall season, time to move inside and build sensors. So far a wind/temp/humidity and a rain gauge have been added to the collection and this post describes the latter.
This first edition is based on the Misol type and I decided to write a simple piece of code to support that. Because it had to be a battery powered node which sleeps most of the time the natural choice was to base the code around the MySensors sleep function. The combined functionality of event triggered and time triggered interrupt is ideal for the purpose.
To simplify things I am only interested in the daily amount of rain why I reset to zero mm rain at midnight. I prefer to keep the code as simple as possible at the sensor level because other values are much easier to calculate at the controller level, at least when using OpenHab and its rule engine. I have no idea about the capabilities of other controllers.
Unfortunately I also wanted to receive messages from the controller. Those are for remaining runtime to midnight as well as being able to send zero or last known reading at any start/restart. This of course is a complication because of a mainly sleeping sensor.
So the sensor has to function without the normal timer functions. The first approach is instead to use the wake up events from sleep as a timer and keep track of time for remaining cycles to midnight. Also at any sending of amount of rain to the controller there is a short wait to enable incoming messages before going to sleep again.
The challenge (at least for me :-)) was to establish when midnight occurs without using any standard timer functions and without asking the controller at every end of the cycle. Because of how the rrd4j persistance works in Openhab the cycle time need to be max 60 seconds so there are quite a few cycles each day.
After several versions the approach became kind of an iteration where the sensor checks the remaining time at half the estimated runtime, then asks again at half of the newly found remaining time and so on. Most likely there are much more elegant ways to accomplish this but it is working.
The sensor itself is "homemade" based on the 328P-PU which runs at 1 Mhz. The only hardware complication was that I found the signal from the Miso unit to be very bouncing why I added an inverted Schmitt trigger to get a nice signal, simply because I had a few lying around and the use of capacitors only still gave a peculiar reading.
The sensor box is a standard "waterproof" IP65 junction box and the mounting console was made with my 3D printer. A few pictures can be found below.
One peculiarity with this sensor was that when using the MySensors library v2 it runs fine at 1MHz but, with everything else identical, modifying the chip to 8 MHz causes the radio connect process to fail. When going back to 1 MHz all runs well again. I have not digged any further into why this is happening.
PS. I have also printed the stl's designed by BulldogLowell as well (@BulldogLowell - Thank's a lot for sharing) but not yet finished that assembly. There are a few modifications I wish to make and not yet had time to finish but this is an issue for another thread.
-
It is fall season, time to move inside and build sensors. So far a wind/temp/humidity and a rain gauge have been added to the collection and this post describes the latter.
This first edition is based on the Misol type and I decided to write a simple piece of code to support that. Because it had to be a battery powered node which sleeps most of the time the natural choice was to base the code around the MySensors sleep function. The combined functionality of event triggered and time triggered interrupt is ideal for the purpose.
To simplify things I am only interested in the daily amount of rain why I reset to zero mm rain at midnight. I prefer to keep the code as simple as possible at the sensor level because other values are much easier to calculate at the controller level, at least when using OpenHab and its rule engine. I have no idea about the capabilities of other controllers.
Unfortunately I also wanted to receive messages from the controller. Those are for remaining runtime to midnight as well as being able to send zero or last known reading at any start/restart. This of course is a complication because of a mainly sleeping sensor.
So the sensor has to function without the normal timer functions. The first approach is instead to use the wake up events from sleep as a timer and keep track of time for remaining cycles to midnight. Also at any sending of amount of rain to the controller there is a short wait to enable incoming messages before going to sleep again.
The challenge (at least for me :-)) was to establish when midnight occurs without using any standard timer functions and without asking the controller at every end of the cycle. Because of how the rrd4j persistance works in Openhab the cycle time need to be max 60 seconds so there are quite a few cycles each day.
After several versions the approach became kind of an iteration where the sensor checks the remaining time at half the estimated runtime, then asks again at half of the newly found remaining time and so on. Most likely there are much more elegant ways to accomplish this but it is working.
The sensor itself is "homemade" based on the 328P-PU which runs at 1 Mhz. The only hardware complication was that I found the signal from the Miso unit to be very bouncing why I added an inverted Schmitt trigger to get a nice signal, simply because I had a few lying around and the use of capacitors only still gave a peculiar reading.
The sensor box is a standard "waterproof" IP65 junction box and the mounting console was made with my 3D printer. A few pictures can be found below.
One peculiarity with this sensor was that when using the MySensors library v2 it runs fine at 1MHz but, with everything else identical, modifying the chip to 8 MHz causes the radio connect process to fail. When going back to 1 MHz all runs well again. I have not digged any further into why this is happening.
PS. I have also printed the stl's designed by BulldogLowell as well (@BulldogLowell - Thank's a lot for sharing) but not yet finished that assembly. There are a few modifications I wish to make and not yet had time to finish but this is an issue for another thread.
@mbj - Great work and thanks for sharing!
What is the IC beside the atmega? Ftdi? -
@mbj - Great work and thanks for sharing!
What is the IC beside the atmega? Ftdi?@sundberg84 Thanks. The item is an inverted Schmitt trigger used to get a clean signal. What came from the reed relay was awfully bouncy so readings were not consistent.
-
Is there a chance you can post the code? I'd be interested to see the time to midnight function.
-
Interesting design, but I'm wondering why you don't just send a message every time the bucket tips, and then do all the tallying and midnight rollover stuff on the controller?
@Carywin
That is an alternative way of doing it, and also much simpler to code and also good enough for a rain sensor. It seems I always tend to complicate things :-) so I have tried to design this type of functionality (with counters and alike) to be inside the sensors because if the controller (here OpenHab) is down for any reason the sensor lives its own life and once everything is up again the sensor can report a correct value. I have the same type of functionality for the energy meter sensor which is based on the MySensors Energy Meter.If the sensor has been down it can receive last known value from OpenHab with an incoming message but any readings while down are of course lost. Also a manual set value can be received.
Does it make any sense?
-
Is there a chance you can post the code? I'd be interested to see the time to midnight function.
@Mark-Swift
I have not looked at the code for nearly a year so have no idea if it is usable or not for anybody else. Right now I have no time to take a look at it but will dig it out as soon as I get a chance, hopefully within the coming week. -
@Carywin
That is an alternative way of doing it, and also much simpler to code and also good enough for a rain sensor. It seems I always tend to complicate things :-) so I have tried to design this type of functionality (with counters and alike) to be inside the sensors because if the controller (here OpenHab) is down for any reason the sensor lives its own life and once everything is up again the sensor can report a correct value. I have the same type of functionality for the energy meter sensor which is based on the MySensors Energy Meter.If the sensor has been down it can receive last known value from OpenHab with an incoming message but any readings while down are of course lost. Also a manual set value can be received.
Does it make any sense?
@mbj Yes I see what you're trying to achieve.
I would keep a 16 or 32 bit counter in the rain sensor, and increment it on each bucket tip and send the new value when it changes. Then in the controller take care of tallys and midnight resets, but with some extra logic to handle when the counter value rolls over (that will take a very long time :D) or the sensor restarts. This would also mean you don't miss any pulses when the controller is down because the sensor is still counting, but a sensor restart won't reset your daily tally.
Another idea would be to have a reset command sent by the controller around midnight. There would need to be some logic where the controller waited until the sensor was awake again before sending it commands, but that seems simple enough.
Or just put a RTC on there XDHaving said all that I will look forward to reading your code and seeing the timing solution!
-
@jumping Unfortunately I had no time to look at anything last week and i will not be able to do it the next cople of weeks because of travelling but I promise it will come. I assume that you also have seen the code for a rain sensor at the Mysensors forum but if not take a look there in the meantime. I know this is a different solution but might be of interest anyhow.
-
-
@jumping Unfortunately I had no time to look at anything last week and i will not be able to do it the next cople of weeks because of travelling but I promise it will come. I assume that you also have seen the code for a rain sensor at the Mysensors forum but if not take a look there in the meantime. I know this is a different solution but might be of interest anyhow.
@mbj said in Rain sensor:
@jumping Unfortunately I had no time to look at anything last week and i will not be able to do it the next cople of weeks because of travelling but I promise it will come. I assume that you also have seen the code for a rain sensor at the Mysensors forum but if not take a look there in the meantime. I know this is a different solution but might be of interest anyhow.
No problem :-) thanks
