Thanks, actually, the humidity sensor is not in the pipe. Just a draft but not completed work.
1 Like
I’ve tried using tipping bucket and the summed method for rain and neither one is accurate. What am I missing? Reading 23mm when only 4 has fallen is way off. Is there a way to set the bucket size when using the bucket tip method?
Hi, are you talking about NeverDry? Could you be more specific? Thanks
Yes, I’m not sure where it’s getting that number. None of my rain values in HA are reporting that number. It’s the specific neverdry rain entitiy.
The key thing first: NeverDry never counts bucket tips, so there’s no “bucket size” setting on our side — it consumes millimetres, and the tip->mm conversion is the job of whatever integration produces your rain entity. A 23-vs-4 over-read is almost always a mismatch between the sensor you’re feeding and the “Rain sensor type” you selected — not a calibration you set in NeverDry.
What matters is how the sensor’s value behaves over time:
- Daily total — climbs during the day, resets to 0 at midnight → select Daily total.
- Per event — reports the amount of the last rain pulse → select Event.
- Rolling window (e.g. a “last 24 h rain” sensor) — climbs as rain falls and falls again as old rain ages out, with no midnight reset. This is the trap: fed in as a Daily total, NeverDry mis-credits it and the number inflates. Don’t use a rolling/last-24h sensor.
Quick way to tell which one you have (Developer Tools → States, sensor attributes):
- state_class: total_increasing + unit mm → proper accumulator → use Daily total.
- unit mm/h (or device_class precipitation_intensity) → that’s a rate, not an amount — don’t use it.
- no state_class / measurement + unit mm → likely a rolling window → avoid it, use your station’s daily rain entity instead.
So the fix: point NeverDry’s Rain sensor at your daily rain entity (the one that resets at midnight) or a per-event one, set the matching type, and watch it during real rain — after 4 mm actually falls the NeverDry figure should read ~4, not 23.
We’re reworking the rain intake so it’s robust to all of these automatically, but swapping to the right sensor fixes it today. If you tell me which integration your gauge uses and the exact entity name, I’ll point you at the right one.
NeverDry v0.11.0 — trust your water balance
Hi all 
NeverDry v0.11.0 is out — the first stable of the 0.11 line, and it’s all about trusting your water balance.
Highlights
Rain accuracy fixes — no more over-counted rain from accumulator/rolling sensors, and rain baselines that survive restarts
Per-zone deficit model — scheduled top-up + yearly rain/irrigation tracking
Full soil-moisture (VWC) mode
More reliable valve close
Zone-card polish + a fresh landing page
Update via HACS. Full notes: Release v0.11.0 — trust your water balance · drake69/NeverDry · GitHub
We’ve also just opened GitHub Discussions — a place for questions, sharing your setup, and proposing/voting on ideas: drake69/NeverDry · Discussions · GitHub
Thanks to everyone who reported the rain bugs 
Ok so I changed to my daily rain sensor, but when I did your latest update it changed the yearly rain to over 1500 L…which doesn’t make any sense. I can’t seem to reset this value no matter where I look to do so. Any idea where I can just reset the rain amount? I’ve tried re-installing the integration but it remembers the old value.
Thanks, have you updated to release 0.11.0 ? Would you mind sharing your configuration on a GitHub issue? Many thanks.
1 Like
My entire config? What specifically?
Hi @raenrfm — no need for the full config, I think I’ve already pinned down what’s happening. 
The yearly rain total isn’t stored on the “Rain Yearly [L]” sensor itself — that one is just a display, derived from a system-wide value (yearly_rain_mm) kept on the Dryness Index entity. That value is a restore attribute, so Home Assistant keeps it for about a week even across a reinstall. That’s why deleting and re-adding the integration didn’t clear it — the old figure gets restored right back.
Two things:
To reset it now: delete the integration → restart Home Assistant (this lets the saved state expire) → add it back. The restart is the key step the plain reinstall was missing. Otherwise the total resets on its own on January 1st.
Coming soon: I’m adding proper reset buttons so you never have to do this dance again — a global “reset all totals” (deficit + water delivered + yearly rain) plus a per-zone reset. Tracking it for the next release.
Thanks for the detailed report — that jump to 1500 L is exactly the kind of edge case that helps.
Good news @raenrfm — the reset buttons I mentioned are already live, no need to wait.
If you enable beta versions for NeverDry in HACS and update to 0.11.1-beta.1 (or newer), the NeverDry hub device gets a “Reset yearly rain” button. Press it and the stuck 1500 L clears instantly — no delete → restart → re-add dance needed. There’s a “Reset yearly water” button too, for the delivered-water total. (A per-zone reset is still on my list.)
That same beta also carries the imperial-units rounding fixes, so your in/mm figures should display correctly now.
These are on the beta channel for the moment and will roll into the next stable. If you’d rather stay on stable, the delete → restart Home Assistant → re-add sequence from my last message still clears the total — the restart is the step a plain reinstall was missing.
Hi drake69,
I just added the integration and am working on the configuration. My lawn is divided into three irrigation zones. Until now, I have irrigated the area in the south roughly twice as much as the zone in the north.
The northern section gets very little sunlight because it is shaded by the house. Does your formula take this into account somehow? If so, how would you suggest I configure it? Should I add it as a separate irrigation entry where I fine-tune the ET coefficient?
Or should I simply adjust the irrigation system efficiency for that zone? One thing that is quite important to me is that sequential watering of the zones continues to work, because my water pressure isn’t enough to water multiple zones at the same time. I am not sure whether that will remain intact if I split it into multiple entries with one zone each.
Update #1: I guess setting a custom Kc would be the best option, but then I’ll loose the seasonal adjustment of it.
Update #2: I spend some time with Claude and we came up with the following feature request: RFC: per-zone microclimate_factor (site exposure) for Kc calculation · Issue #146 · drake69/NeverDry · GitHub
1 Like