I've created a parent/child app that schedules and turns sprinkler valves on and off. It is at the point where others can use and find bugs I didn't find.
Find it in HPM by searching for "sprinkler". There's a Quick Reference as well.
Released as v1.0.6 (Parent) and v1.0.6 (child) and v1.0.3 (child)
csteele: v1.0.6 Added multiple Rain Sensors to be integrated.
Previous
csteele: v1.0.5 Don't tell the children about rain or temperature devices that don't exist.
* csteele: v1.0.5 corrected schEnable, so that enaDis is correct initially.
* null safe currentValve?.label/name.
* refactor rainHold to be by timetable,
* don't offer rain hold if no rain sensor device is selected.
* remove rainHold reset at midnight.
* csteele: v1.0.2 corrected schEnable, so that enaDis is correct initially.
* null safe currentValve?.label/name
* refactor rainHold to be by timetable,
* don't offer rain hold if no rain sensor device is selected.
* remove rainHold reset at midnight.
* csteele: v1.0.4 Make collection of outdoorRainDevice attributes to remove duplicates
* Added child switch option
*
* csteele: v1.0.0 Converted to capability.switch from valve
I created several Virtual Valves to test out the app and I think it's a great way to explore without wasting water.
Here's my Log from this morning:
The schedule was started at 6:04am and ran for a minute, then there's a 20 second delay for the valve to actually shut. The second valve starts at 6:05:20, and the third at 6:06:40 ending at 6:07:40 for exactly a minute per valve.
The most recent update adds Hot Day schedules and a Rain Hold. Both of these options require devices in your hub to provide Outside Temperature and a Water Sensor.
Hubitat has a built-in driver for OpenWeatherMap, which provides a temperature Attribute.
For rain, I have been using: Precipitation and Weather Monitor for NWS Data by GaryJMilne. It acquires NWS (National Weather Service - USA only) data from airport observations. It includes a WaterSensor attribute that provides Wet/Dry values.
You tell Sprinkler Schedule Manager what you consider the maximum temperature and if ANY temperature report is above that value, OverTemp is set (reset at midnight). Rain results are probably more interpretive than high temperatures. Rain is, to many, more than simple "wet in the past 24 hours" or "dry". For those people, Sprinkler Schedule Manager has an optional virtual hybrid driver allowing you to create Rules and turn on or off, the Water Sensor attribute of the driver.
I'm gathering parts and will be setting up the first part of my system next month. This controller looks interesting and probably exactly what I need. Thanks
I've thought of so many ways to use it ... from simple to extreme.
I have an 8 valve system and I can imagine just putting all 8 valves into one Child and having one or two Timelines... one for Mon, Wed, Fri, Another for Tue, Thu, Sat & Sun. No need for master timelines, no need for the optional temp sensor, no need for the optional Rain. That makes the schedule work alot like the controller on the wall that's too hard to setup, and is rather a lot like a blinking VCR, back in the day.
I have just a few Child schedules, one for the Front, one for Back, one for Drippers. Each has a weekday timeline, a weekend timeline and a Hot Day timeline. I've also got the Monthly % setup plus a weather app to feed into the rain option. I already had an outdoor temp sensor (Zooz ZSE44 800LR) to feed into the optional Hot Day timeline.
At the extreme is perhaps more than one Child and Timeline PER Valve. I built that once during testing but it was so much clicking just to find out "yep, works"
We are always under water restrictions in this part of Florida so I am limited to Wed and Saturday watering so not much to think about there. I'll have 4 zones when done, the drippers, front and each side. Screw the backyard. I rarely go back there anywhere. I'll most likely set-up the monthly percentages and the rain delay. I'm not sure I really need to worry about the heat. It's always hot and humid in the summer but we generally don't need to water during the summer anyway.
The drippers have been in awhile (they are run off of a B-hyve so I turned off the B-hyve app and moved those to your app. Maybe next week I'll get the front done and add that too if I can find the time before go with the grandkids over to Disney for a few days.
The app looks like it will do everything I need it to do.
Now that I'm alone, and under no restrictions, I bought four fake petunia hanging baskets to be deployed on the local tradition of Mother's Day (last frost). Those were the only things I irrigated (well concerns). Now: no automation, or water, required.
I was originally going to use switches(relays) until I went above ground (and spigot valves) to bypass the condo association. So I can see the need for having access to the switch capability.
Can you allow the selection of switches and valves in the same selection menu? It's been a long time since I messed with groovy so can't remember if that is possible.
Another question.... Have you ever considered adjusting the watering time based on the amount of precipitation that was previously received. I'm not sure if it's even worth considering but was curious.
First, fantastic app! I was in the middle of sketching out a sprinkler app when I found yours and abandoned what I was writing. With adding switches you've managed to get just about everything I was planning on putting in mine.
I've got a 9-zone system, and my only problem right now is that some of my zones (rotors) have a much lower inches/min discharge rate than most of the rest of the zones, so they need to run longer. I can create separate groups for them, but then I have to make sure I get the group duration timing right so there aren't overlaps. Separate children is an option too, but that's even more complicated, since the schedules aren't all on a single screen.
Eventually I'll measure the actual in/min output of each zone, and I'm sure every one of them will be different (the smallest zone has 5 spray heads, the largest 20).
Would it be feasible to add per-valve(switch) timing, rather than setting all the valves in a group to the same duration?
