Hydreon RG-15 rain sensor

Has anyone tried to write a custom component for ESPhome to connect the Hydreon RG-15 rain sensor via a serial? There is a code available for arduino here, but my C++ skills are not good enough to port it.

1 Like

It appears to be a tipping bucket sensor.

All you need is a pulse counter with a multiplication filter for the rainfall rate:

And an integration component for the accumulated rainfall:

Thanks! This is how I’ve done it actually. The original post was specifically about the TTL connection, since it provides additional functionality.

There’s this in the ESPHome cookbook:

It’s all Greek to me.

Just hooking up a RG-15 to an ESP8266 12F to explore the TTL data, so we’re on the same path. I’ll update as soon as I find something useful, but I’m more into electronics then coding.

Didn’t have much time, finally got to it. I went for a Tasmota integration, using a Huzzah32, and compiling esp32 Tasmota firmware. I had some troubles getting it to work reliably, noticed later on the I had to use a dev branch of the Tasmota firmware, but also noticed some bad wiring later on. Rewired the sensor, compiled the firmware on Gitpod.io using the dev version of the basic tasmota32 firmware, and seems to work ok. Now I have to make a waterproof setup for testing outside, before I replace the old RG-11 with the RG-15.
Instructions for the Tasmota RG-15 integration can be found here: Hydreon RG-15 Solid State Rain Sensor - Tasmota
Information about the instability/reboots of the tasmota32 firmware can be found here: Rainsensor Hydreon-RG-15 causes Restart Exception28 · Issue #14067 · arendst/Tasmota · GitHub
I’ll make a screenshot of the device entities later on, but I managed to get diagnostic sensors, and rainsensors “RG-15 active, RG-15 event, RG-15 FlowRate, RG-15 total” in Home Assistant, and trigger them with a few drops of water.

Maybe I will give porting it to ESPhome a try in a couple of weeks. For now it’s working and I want to do some field testing first. I learned a lot from the well documented Tasmota solution, great work, kudos to the Tasmota developers and community!

Today I noticed that the values from the sensors are passed from the sensor without the mm (or mm/h for the flow rate) unit, but the total rainfall value has the kWh unit. Since the sensors payload does not supply the unit of measurement, the HA integration seems to be the problem. I’m trying to figure this out, any suggestions on where to look are highly appreciated.
Tasmota RG15

well that was easily fixed: Unit of measurement - #2 by tom_l

This is how it looks after applying the fix for all sensor entities:
Tasmota RG15 fixed

Since 2022.4.0 the dedicated sensor is available in ESPHome

1 Like

I’m getting really frustrated with my RG-9… It’s reporting results that make absolutely no sense. See README.md for details… Not recommending it at this time.

Anyone else has better luck?

Hi Janick,
maybe I can help you with that, I was having similar problems with my RG-15 prototype (via Tasmota integration), while my old RG-11 was functioning perfectly alongside it (only on/off via wave). So I was able to compare results, and also doublecheck with multiple outdoor camera’s if it was raining at the moment of the spikes or not (or if it was a bird or similar). I noticed spikes in the flow rate and rain event graphs mostly during afternoons, not everyday and not exactly at the same time, but without any registration of a rain event from the RG-11, or visible on camera footage.

I reached out to Hydreon, and received a very detailed answer from them. Kudos to Hydreon for taking the effort! (Message below)

What I took from that answer is that I should look into the power supply I was using, feed the sensor with separate power (not from the voltage regulator on the ESP32), and check shielding of the cable (I’m pretty sure I did not connect that to ground yet since it was a prototype). I did not have time to check this, also since I learned that an ESPhome integration was on its way. I was planning to rebuild everything later this month using ESPhome, use a regular PCB instead of a breadboard :laughing:, and fix powersupply and shielding.
Let me know if this helps, below you will find the complete explanation from Hydreon. Good luck!

Message from Hydreon:
"Thank you for your support of our Hydreon rain sensors!
Glad that the RG-11 has been working well for you for some time. Not a surprise, but good to hear. Our classic design just keeps on.
The ESP32 platform is a good place to work.
It is great to see that you have been able to test out our new RG-15 rain sensor. We put a lot of time and effort to reduce the errors in the RG-11 rain sensing algorithm.
Let’s start with the model comparison. Hopefully, this will help minimize any confusion, then we can discuss the accuracy subject.
The RG-11 was designed more than a decade ago, as a Swiss Army Knife. This unique product can do many things. Rain detection, tipping bucket, condensation detector, wiper control, irrigation control, drop detector (input for a DIY algorithm), and a rain water harvester. It is easy to say that most of our customers use the RG-11 in the rain detection mode and use the input in an embedded system in an incredibly wide array of useful products, like what you are using on your awning.

This is where things get interesting. The RG-15 was designed to do 1 thing, rain detection. No Swiss Army Knife. Just rain detection. We also added a serial communication system that can reveal much more information. More on that later.

We utilize a proprietary lab rain generator for many of our measurements and was the foundation for the algorithm development. The rain sensor and tipping bucket are mounted axially so that all the rain that hits the rain sensor is caught by the tipping bucket. In this case we measure very close to the reference tipping bucket.
We also have many units and tipping buckets on our roof. This way we can do real world comparisons. In these cases, there are variations that we have noted.
For example, the RG-15 using the serial communication port measures 0.001” increments and the single rain drop “event” detection can be 1000x more sensitive. Many tipping buckets are 0.01” increments. The RG-15 will detect 0.01” minutes to hours faster than a tipping bucket (depending on rain intensity) due to the physics of tipping bucket rain collection. The RG-15 detection is essentially instantaneous, the tipping bucket rain will hit the side walls, then run down to the bottom of the collector, then drip into the tipping mechanism. This all takes time and we see it in the measurements. There are also issues with tipping buckets and wind. We have a researcher in Chile looking at the differences between tipping buckets and the RG-15 in high wind environments.
However, there are discrepancies that may or may not be due to rain localization. The bottom line, if you demand absolute tipping bucket accuracy, a very expensive stainless steel tipping bucket is where you should go. But remember that that will take maintenance. How many times have tipping buckets failed to detect properly because of junk clogging the collection mechanism? We always find out there are problems at the worst time.
That is why we state on the product page: The RG-15 is designed to replace tipping bucket rain gauges in many applications where their maintenance requirements make them impractical.

So now comes the fun part. From above, there is extra data that can be used. One of those is rain detection. From above, this detection is not dissimilar to the RG-11 on the most sensitive setting. The information from the serial port looks like this:
SW 1.000 2020.07.06

One tricky part. There is no announcement when the rain event is done. By careful examination of the data stream, it can be determined when. You watch for the EventAcc is reset to 0. Of course, that assumes that the Accumulator and EventAcc have been incremented, which is not always the case.
I am not aware of anyone actually using the system like this, but it certainly can be used that way, particularly in conjunction with the other rain data.

If there is enough precipitation to trigger the tipping bucket, that will also happen.
The internal registration is at high sensitivity, which is much more sensitive. You can use that information. Here is a bit more on the available commands as well as the output data.

Acc = Accumulation. The amount of accumulation detected since the last Acc message.
EventAcc = Event Accumulation. This is the amount of rain detected during the current rain event. This counter resets 60 minutes after the RG-15 has detected the last drop.
TotalAcc = Total Accumulation. This is the total amount of accumulation recorded since the device was last reset with the “o” command.
Rint = Rain Intensity. This is calculated over the past minute and extrapolated to the hour. This information is not always accurate. We will be updating this in an upcoming release.
See the RG-15 instruction guide for reference.

Also, for reference:
How to use a RG-15 with a standard RS232 system
Accessing the RG-15 with a JSON API
RG Arduino Guide

We have found that if the power supply is not reasonably solid, that transients can get through the internal regulator and create anomalous data, including false positives. It does not appear that you are experiencing any of these issues, just wanted to make you aware. We recommend a stable power supply, a good solid grounding system and dedicated wiring to the rain sensor. Also, while there is a note in the instruction guide about powering it with 3v3 directly, this is a very difficult implementation in practice. This method bypasses the internal regulator, so any variations on the supply line directly affect the A/D measurements which are very sensitive. This can and does mess up the algorithm. 5V to the V+ is a better way to go. The 3V3 reference can be used by other equipment, as it is the internal regulated supply. Although from the above, caution when using it as a phantom supply for other sensors is recommended to ensure the sensor data remains clean.
Thank you for sharing your Tasmota work. I will digest it. See the above for the 3v3 reference. Not sure exactly how you have wired the power supply. Let me know how you have it wired."

Thank you for your reply, @erdek

I received a similar message from Hydreon about my initial setup (see below, Oct 14, 2021) but they have been silent on my follow ups. So far, not impressed with their technical support.

It stopped raining at around 4pm yesterday. But the R1 false-positives have continued, albeit at a lower density. At 7pm, I changed the DIP settings from “0000” to “0100” to decrease the sensitivity. Still some false positives but much fewer with no rain overnight. This is the Pacific Northwest so I should have more test data soon…

I also have an NPN anemometer attached to the same device. It is powered via the VCC (5V) pin from the ESP32 board and sensed via a pulled-up GPIO. There is no way there was a 40mph gust at 6:30pm – but I see no correlation with the density of false positives on the RG-9. I’m disconnecting it (7am, May 13) to minimize the number of variables.

To give more context, it rained all day May 12 from approx 8am to 4pm. Typical PNW rainfall: constant shower of small drops, not heavy east-coast type rain. Not a drop before or since.

Hourly rainfall data from nearby City of Portland rain gauge

I’m currently powered via a 120AC/15VDC wall-plugin transformer I salvaged from some dead appliance. The 15VDC is fed using approx 50ft of 18AWG pair to the sensor enclosure to a DC/DC USB car power converter with the microUSB connected directly to the ESP32 board. The ESP has been rock solid.

Next experiment will be to feed 120AC directly to the project box and put a small 5DC power supply in there.

Message from Hydreon:

Hi Janick-

I have used similar buck converters and have found them to be relatively noisy. Perhaps a linear regulator alone could do the trick, such as the TI LM340T-12? I was creating a high quality audio/video system in our car and used it as an isolator. Ended up using a string of inductor/capacitors to try to tame the injected noise from the internal circuitry. Finally ended up with a 12V - 24V DC/DC converter, followed by the LM230T-12 and things quieted down significantly.

We are finding that it does not take much noise to get through and cause problems. Even though it has a good internal 3.3V regulator, we are detecting microvolt level signals at times on the optical transmission path, those false positives can be created with variations in the power supply.

Many of our false positives have been due to power supply related fluctuations. We even had some on our extensive roof monitoring environment. We were using a 12VDC transformer on a UPS running many monitor boards, not unlike the ESP32. We noticed some false positives that were correlated across more than one unit.

I ended up rewiring the entire system using a 12V Lead Acid battery powered with a trickle charger. Also modified the grounding and power system to be more of a star ground, minimizing any crosstalk from other units. The result is that we have been running this for about 1 month and have yet to see a false positive.

We have also helped many of our customers through what ended up being power supply related issues.

It is best to create a star ground and power distribution system where everything goes directly to the power supply. This minimizes the possibility of crosstalk on the line or any current modulated voltage variations as well.

Hope this helps!

Hi @janick ,
I was surprised by the detailed information they sent me, but if there is no follow-up then that’s very disappointing.
I hope to find some time this weekend to rebuild the prototype into a more stable sensor, with all the shielding in place, and connected to a more stable and suitable for outdoor power supply.
One thing was holding me back, that’s the problem with the ESPhome integration
There is a workaround for it, but I can’t seem to connect to the ESPhome container, so I was hoping a fix would have been released by now. I’ll try again and see if it works out this time, it’s really frustrating I cannot ssh into my HA OS.
I’ll post an update if I get things working.

Reducing the sensitivity seems to have done the trick! Almost no false positives until 3pm PDT when it started to rain, and solid report of rain intensity correlating to measured rainfall until it stopped at 6am.