Sorry, but it seems like you’re not paying attention to the full set of concerns I have and their implications.
I did already consider creating one program per zone (indeed I researched doing it that way back before you added the ability to sort the run order by zone name because you did already allow easy re-ordering of programs — I posted about doing this in these forums), but that doesn’t allow for easily managing total run time when the system is nearly maxed out at 21 hours. It would also be extremely tedious to configure and then make changes with 32 zones — the UI is already heavy on requiring many clicks per operation. And so until you added the sorting feature I was still looking for alternative systems. The sorting feature was the key one that brought me back to looking at OpenSprinkler.
I’m already maxed out in time restrictions — as-is I can only run each zone once per day and just long enough for that zone. I’m not currently running any zones more than once per day, yet my program requires a full 21 hours, and during the hottest times of the year it will require a full 24 hours. I’d go for even more time if I could increase the % watering budget beyond that limit, but, well, there are only so many hours in the day.
I cannot run zones for just a few minutes multiple times per day — I need to run zones for enough time to overcome evaporation and to deliver water that will soak in; and I need to run zones in high-traffic areas _only_ at times when nobody can be expected to be there. There are not enough features in the current OpenSprinkler zone programming to build in such scheduling with those kinds of restrictions. It’s not unimaginable, but now you are talking serious amounts of additional code, not to mention storage for the additional values representing such restrictions.
I’m also concerned about reboots when the system is unattended — it is critical that it not sit idle for any significant portion of the day no matter whether there’s a power failure or a crash.
As for your imaginary miniature UPS, well there are obviously no existing separate power supply connections for the controller CPU alone, and as far as I’m aware there’s no battery charge controller already in the OpenSprinkler, and while I’m not opposed to a little bit more hardware hacking, that’s not something that was advertised as necessary. But even a UPS doesn’t solve the problem of reboots, either from crashes, or from necessary maintenance downtime.
If you don’t understand how a life support system needs to work in order to fail safely, then I guess that explains why you didn’t take this essential feature from all other sprinkler controllers into account in the original design of OpenSprinkler. I thought I explained it in a clear and obvious way, but perhaps you don’t have the background engineering experience with working on critical systems that have such requirements. One more try: Pretend you’re on the moon and you’re using OpenSprinkler to control your CO₂ scrubbers and they have a similar cycling requirement as my watering system — the program is maxed out to 24×7 operation and there’s no room for any unscheduled downtime. If the controller reboots just after midnight and then remains idle without restarting the program that should be active for the next 24 hours, well, then you’ll die. Such a controller _must_ restart the running program at the point it should be at for the current time of day after any reboot for any reason. Obviously my trees and garden won’t die from one day’s less watering, but it will start to impact their health, and if the failure went on for a week during the hot season, well some plants would die and trees would be highly stressed.
You ask why I think you haven’t added this feature already. Well, beyond it now being clear that you don’t understand how critical control systems must behave in order to fail safely, I think you’re also over-thinking the problem. You kept referring to how dynamic events impact the schedule generated from a program, but you don’t seem to realize that such things are entirely unimportant in the bigger picture of just getting the machine back on track and working again automatically.
Why not choose another product? Well, I do like to support open source projects — if you look me up on GitHub you’ll find I already maintain a number of them. I have already looked at most other products that have the capacity we need, but they all lack the one feature you were actually easily able to add to OpenSprinkler — the ability to control the order of zone operation without having to re-wire things. OpenSprinkler has the capacity to handle all the zones I have and more with just the one controller (I’m replacing two independent controllers), and the price is quite reasonable. All these factors, plus the fact I couldn’t imagine anyone designing a system that wouldn’t restart a program after a reboot, made OpenSprinkler a very attractive looking solution. I didn’t realize this problem until I was testing my primary zone control program and I couldn’t even find a way to manually start it after a reboot.
So as a supporter of open source projects I’d rather help you understand how this issue impacts users of your product and help you figure out how to change it so that it can support this obvious feature. Being able to say that OpenSprinkler can fully support all of the features of traditional controllers and then some would help you, me, and everyone else better promote it as an easy no-brainer upgrade for existing systems. I alone could easily sell five or more people on buying it, and without any need for convincing if it had this feature. However without it being able to do this most simple but necessary thing as all existing controllers can do I wouldn’t expect very many people to want to use it when they have an existing controller that already runs reliably and unattended even with flaky power.
Let me ask you: Why are you so reluctant to add a feature that you’ve clearly already figured out the algorithms for? What exactly in the controller code makes you think this is going to be so difficult to do? Are you still hung up on trying to support previous dynamic events that might have arrived between program start and the reboot, and if so, why? Where would you start in looking at the code to add such a feature in the simplest way possible without taking into account dynamic events?