Yeah, I agree that simplicity is also a key quality factor of software. While watching the youtube video I also noticed how many options the scheduler already has and wondered how attractive this might be to the “average” user.
So, I had have a clear opinion about the logic:
> What happens if a group is supposed to run but then a user also want to manually operate one zone in the group? It’s non-trivial to clearly define the logic. Say zones 1, 2, 3 are in parallel group P1, what if P1 is currently running (i.e. all of zones 1, 2, 3 must be running) while the user also wants to stop zone 1 individually? Should that be allowed? Which should take priority?
Yes, should be allowed. The recent action of stopping P1 would take priority.
> Also, if P1 is running and the user manually starts zone 1 again for a different period of time, what should zone 1’s duration be?
Again: The recent action wins. That is, Zone 1 gets another time slot than P1.
> Without a clearly defined logic, the firmware will not have predictable behavior. I don’t think any one implementation can meet all users’ need. I’ve seen a lot of different requests for scheduler features, some of them conflict with each other. So I am afraid one firmware can’t fit everyone’s need. But the project is open-source so you can always modify the firmware in any way you want to fit your need.
Fair enough. I can totally understand your argument. Still thanks for listening.
I guess I will workaround then by buying better (faster with more water throughput) water dripping lines. I have some “cheap” (poor) ones from Gardena, will change to Rain bird with 2.3l/min. This will mitigate my issue.