So, Ray, I don’t think you’ve understood the magnitude of the problem for me (and perhaps others) when the controller doesn’t fail-safely.
I live in a semiarid desert and most of my ground is essentially gravel with a thin layer of topsoil, but it’s orchard and vineyard country and we have pretty good water sources (Lake Okanagan, for one, plus reservoirs up in the mountains) so we try to grow things on it anyway.
As I said I have 32 zones currently and during average weather conditions I have a total run time of 21 hours. That means during dry months I have room for about 112% watering budget expansion — which would take me to a teeny bit over 24 hours. Last time it was over 40°C every day for a few days I did run 24×7.
I can’t run any zones simultaneously because most of them max out the capacity of my system for water delivery.
I can’t run zones for just a few minutes — no water would get into the ground to the roots, it would all evaporate first. During the day I need to run some zones for upwards of 10 minutes before the area cools off enough for any water to be soaking in. I already have a few zones that only run for about 20 minutes. It’s obviously “wasteful” in absolute terms, but then again if we in this region were sensible there wouldn’t be an agriculture here except in the very bottom flood-plain of the valley.
I might be able to split all the times in half and run the program repeating every 12 hours, but that would be the limit. However 12 hours lost watering is still not acceptable — it doesn’t leave room for maintenance and field/orchard/lawn work. It would also make it nearly impossible to avoid running some zones in high-traffic areas when there is activity in those areas (at least not without a lot more, and far more complex, programming features). Getting that kind of timing right is something you want the computer to do and not have to work it out manually — but OpenSprinkler doesn’t have enough programming features and controls to do it.
Asking someone with a complex system to run every zone multiple times a day just to work around the lack of fail-safe reboots is nearly as absurd as making a UPS a requirement for reliable fail-safe operation! Both are non-starters — entirely impractical.
When I say “fail safe”, I mean it in the sense of something like a life support system, which in fact it is, for plants. You don’t allow a life support system to sit inactive for up to 24 hours just because it rebooted at the most inopportune time. The system has to come back fully operational and running on schedule, no matter how long or short the downtime or when it occurs. The downtime is unavoidable, but what the system does on reboot is entirely within its ability to manage.
When I compared OpenSprinkler to the old controllers I was trying to convey the facts that: (a) this form of fail-safe operation is a very common long-standing feature that I would expect every modern controller to have; and (b) OpenSprinkler has a great deal more computing power and resources than those old junkers (I think – there is a microcontroller CPU in the Irritrol) so there’s no reason why it can’t _easily_ support this feature.
Furthermore, as I said, past dynamic events are irrelevant if they can’t trivially be accommodated. “fail safely” means simply do what the programming says to do as if the controller had been rebooted while nothing was running, say at midnight, and no dynamic events were received since then. If you’ve got room to store weather events or pause requests, etc. (with their arrival timestamps) such that they won’t be erased by a reboot, then, sure, take them into account when running the program forward to the current time of day, but otherwise they don’t matter as much as simply getting the program on track again. If I tell the system to pause while I do some maintenance and there’s a glitch causing a reboot before I finish that gets me all wet, well it’s not the end of the world. If I really don’t want to get wet at the wrong time, well I know where the power switch is, not to mention the master valve! And if it would come back alive when I rebooted it I wouldn’t worry about turning it off for maintenance work!
As for OpenSprinkler being open-source, well yes I know it is, but as you may recall what I said in the past: while I have considerable programming experience, including in low-level systems code, the OS firmware is written in a language I have little ability in, and absolutely zero interest in expending any effort in learning. So unless the feature is so trivial to implement that even an old C programmer could work it out in short order, I’m unlikely to be able to help with it. Also, if it’s that simple, well…. If I had been the designer of the system I wouldn’t think it would be a very difficult feature to implement, but there are aspects to the current design that I don’t fathom the reason for even from a user perspective, so my guess isn’t likely worth very much.
In any case, as I said, I’m still stunned and dismayed that OpenSprinkler didn’t have this long known feature from day one. The lack of this feature was certainly not obvious to me before I made the purchase and committed to changing my system over and I really didn’t expect it to be missing.