- This topic has 4 replies, 2 voices, and was last updated 9 months, 3 weeks ago by
.
-
Posts
-
I was pretty excited about the station grouping feature of the new 2.2.0 version. However, after watching the excellent(!)
Introduction to OpenSprinkler Firmware 2.2.0video on YouTube, I doubt it will fulfill my requirements:I have about 8 sprinkler zones plus 9 water dripping zones (patches and hedges). The water dripping zones only require about 1 bar water pressure. My water pump has 4.8 bar – and takes about 900 W and is noisy while running. I would be interested in running 2-3 of these water drip zones in parallel. This way it would only need to run 1/3 of the time. So I could have a parallel group P1, a parallel group P2 and a parallel group P3. All consisting of 2-3 stations that run in parallel with regards to each other, but still sequential with regards to the other sprinkler zones and water dripping zones/groups.
Now with the new grouping feature I see only one parallel group P (parallel to everything else) and sequential(!) groups A, B and C.
Any way/workaround to fulfill my “grouping” requirement? I am running OSPi 2.2.0 (2)
Well what you wanted would be a two-level grouping feature: parallel at the bottom level, and sequential at the top level. That is more complicated than what the firmware can do at the moment. The sequential groups are suitable in cases that different zones are on different water supply lines therefore each group has to run in sequence but different groups can run in parallel.
In your case, you can always set all zones to the parallel group and then just use multiple programs to schedule different zones to run at different times.
> Well what you wanted would be a two-level grouping feature: parallel at the bottom level, and sequential at the top level.
Yes, exactly. I would need to be able to define multiple parallel groups like P1, P2, P3 and these groups would need to be sequential to others.
> In your case, you can always set all zones to the parallel group and then just use multiple programs to schedule different zones to run at different times.
Quite often I (or some less technical family member) also run manual schedules. I think this would not work as sometimes you have sprinklers too. Say I schedule manually the water drip zones (then 9 would run in parallel, which is too many) – or it would run together with a sprinkler (which needs 100% water and cannot share).
Well the situation you described is exactly why it’s complicated to implement the two-level grouping feature. 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? 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? 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.
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.
- You must be logged in to reply to this topic.