Here is another error for you to decipher. 
Here is the error:
I am not using temperature and here is my settings for temperature:
Got it, thanks. I added that fix to the next release too. 
1 Like
Great app! I'm having problems with the Rain Delay though. It appears that the child devices aren't actually delaying, or are checking the status of the RainHold after running a daily schedule. Here are the logs. It looks like the parent is setting rain hold, but the child doesn't check it until after running a schedule:
Here's the beginning:
The rest of the zones run, and then it reports that it's skipping the daily schedule:
Unable to duplicate.
app:1253 2025-04-29 08:27:29.140 AM info OutdoorRain update from Parent, rainNow: wet.
app:1253 2025-04-29 08:27:29.118 AM info DayGroup update from Parent.
app:1253 2025-04-29 08:27:29.097 AM info MonthIn update from Parent.
app:1253 2025-04-29 08:27:28.084 AM info Rain Hold - schedule skipped for Front Sprinkler Valve Timetable Today.
app:1253 2025-04-29 08:27:28.069 AM info Checking Front Sprinkler Valve Timetable Schedule.
dev:1087 2025-04-29 08:27:03.791 AM info pseudoRain ON/WET
app:1253 2025-04-29 07:55:10.338 AM info Front Sprinkler Valve Timetable scheduled today.
app:1253 2025-04-29 07:55:10.295 AM info Checking Front Sprinkler Valve Timetable Schedule.
app:1253 2025-04-29 07:54:20.221 AM info Valve pseudoValve2 closed.
app:1253 2025-04-29 07:53:20.180 AM info Valve pseudoValve2 opened.
app:1253 2025-04-29 07:53:00.156 AM info Valve pseudoValve1 closed.
app:1253 2025-04-29 07:52:00.099 AM info Valve pseudoValve1 opened.
app:1253 2025-04-29 07:52:00.065 AM info Running Sprinkler Valve Timetable Schedule.
app:1253 2025-04-29 07:50:39.722 AM info OutdoorRain update from Parent, rainNow: dry.
app:1253 2025-04-29 07:50:39.701 AM info DayGroup update from Parent.
app:1253 2025-04-29 07:50:39.676 AM info MonthIn update from Parent.
app:1253 2025-04-29 07:50:38.747 AM info Front Sprinkler Valve Timetable scheduled today.
app:1253 2025-04-29 07:50:38.699 AM info Checking Front Sprinkler Valve Timetable Schedule.
dev:1087 2025-04-29 07:50:17.758 AM info pseudoRain OFF/DRY
To my eyes, it shows that the schedule did run because the rain sensor reported dry. Then, after changing to wet, the schedule ran and skipped due to rain hold.
Let me try and better document my intention for handing rain. First, recognize I live in Southern California where rain is part myth, part reality. The kind of rain I'm about to describe might never have occurred in my lifetime here. 
Pretend we have three zones, one that runs in the morning, one mid-day, one runs late-afternoon. The rain hold option is on/true:
There's been no rain for days. But today, in this example it rains from 10am to 11:30am. Enough to cause the rain sensor to go from Dry to Wet, sometime around 11am., and go back to dry sometime around 3pm.
The morning run sees no rain hold and runs normally. The Mid-Day run is blocked because the rain sensor is saying Wet. The tricky part is the code is assuming that if it was wet once today, it remains wet and the late-afternoon run is also going to be blocked.
The rain sensor is "debounced" because the sensor probably should dry out quicker than the soil. The assumption is, if the sensor ever got wet, the soil did too, and would remain wet for the remainder of the day. At midnight the debounced sensor reading is reset, ready for tomorrow. In other words, the sensor is NOT a soil detector it's a predictor at best. It means that the "adjustment" the rain sensor has to detect wet, needs to be a good indicator of soil dampness and block rain only when it's a usable rain vs a mere sprinkle.
I've also assumed that the App, allowing for dozens, maybe hundreds of timelines, tricky (aka smart) schedules are easy to get exactly right. I can see, for example, that a daily schedule that provides MINIMUM water could run, rain or shine and then for no-rain, another schedule runs to move from minimum to IDEAL.
I think I found what's happening.
Here's my log from this morning. At 11pm, the child sprinkler schedule sets state.rainHold after being triggered by a change in the rain sensor (I'm using your hybrid virtual sensor and some Rule Machine logic to combine moisture sensors, a rain sensor and external delay).
At midnightish when rescheduler() runs, state.rainHold is reset to false, but the rain sensor is not checked again. So when the scheduler runs a few minutes later, it schedules the sprinklers, even though it shouldn't because the external 'rain sensor' is still set.
Is that the intended behavior?
1 Like
Ok, I'll refactor my "midnight" resched to account for it still raining at midnight.. probably a common occurrence.
Yes, the scheduling of a run is independent of if it dispenses water (turns on/off valve).
As described above, a 'morning run' before the rain hits for the day is going to run. When rain hits, the next valve open attempt will be blocked... and on and on through the rest of the day.
If the rain sensor is an accurate reflection of soil moisture, then having it reset at midnight wouldn't be needed. You're using advanced logic to set the virtual rain sensor and thus it's probable those rules will set the sensor back to dry when the soil is likely to need water.
The Precipitation and Weather Monitor for NWS Data from Gary is similarly smart by setting wet to indicate enough rain in the past 24 hours. Again, not needing the midnight reset.
Midnight reset is intended for those not-as-advanced rain sensors. I'll explore making it optional.
I think it makes sense to reset rainHold at midnight for general usage, but it should also probably do another check immediately, even for non "advanced" cases. What if it started raining at 11:59 and then kept raining for six hours? Since the external event that triggers setting rainHold happened right before the midnight reset, it would be lost. The first sprinkler schedule would then run, even though there had been a (potentially) downpour that morning.
Still, fantastic job with the app! It puts DIY sprinkler control easily within the grasp of the average Hubitat owner.
I've decided to remove the midnight reset of RainHold because the option of using the Hybrid Virtual Sensor to make any arbitrary Rain Sensor behave as needed for Sprinkler Schedule Manager is probably a better solution. Most people will probably use an Internet based rain detector, such as the already mentioned Precipitation and Weather Monitor for NWS Data and need no special handling.
Changes discussed have been Released:
v1.0.5 (Parent) and v1.0.5 (child) and v1.0.2 (child)
See the 2nd message at the top of this topic for notes.
I gave this a try but I needed to be able to use moisture sensors for two different beds to enable/disable watering for the individual valves. One is for a raised bed drip system and the other is for a garden sprinkler. The Hybrid raincheck would need to be per valve. I didn't think about setting up two separate instances of Scheduler which if possible would have probably worked.
I've tackled adding additional Rain sensors to the Package. Lots of testing remains but here's a hint of the design I'm implementing:
First, in the Parent App, you select sensors, plural, if desired:
Just as today, selecting a rain sensor doesn't force any Timetable to USE it.
Within each Timetable, you can select ONE rain sensor, or none.
In other words, the old binary switch:
has been replaced by a selector.
I'll give it a try when it's ready. Right now I'm using a couple of rule machine rules that work.
-- Currently disabled, that is the sensors last reading from last fall. It will be too wet to matter for several more weeks.
Changes discussed
Added multiple Rain Sensors to be integrated.
have been Released:
v1.0.6 (Parent) and v1.0.6 (child) and v1.0.2 (child)
See the 2nd message at the top of this topic for notes.
If you are upgrading, You will lose your Rain Sensor config. Just reselect in the parent and then in each child Timetable.
I think the latest release broke the rain delay.
I am using the rain check driver to manually hold the sprinklers. This was working yesterday. I updated to the latest version and now the rain hold is false even though the rain check driver is wet.
Take a look at your Logs.
This first screen shot shows the selected devices and values being pulled over by clicking Done in any of the child apps.
It received an OutdoorTemp and an OutdoorRain update. The Rain sensor was wet.
THEN, I set a time a couple minutes in the future in the child and clicked Done again.
A check occurred, discovering that a rain hold was a possibility.
Finally, the schedule ran and aborted ("schedule skipped") due to rain hold:
I created a new schedule and it recognizes the rain delay. It's only affecting the existing zones.
I think I'll just recreate the 4 zones. There is some other garbage in them from the rain delay programming change. The current zones are still showing the NWS driver as an option then through it's been long deleted. By recreating everything will be fresh.
1 Like
The change to add more Rain Sensors was more like a complete rewrite of that entire section. I didn't think it would be that disruptive but it was, in the end.
I hope you've recovered and found it useful once again.
1 Like
It only took 5 minutes to set the zones back up. I should have tried that before I posted.
The scheduler is incredibly versatile and easy to use. I appreciate that you shared it with us. Thank you.
1 Like
