- This topic has 6 replies, 3 voices, and was last updated 4 months, 1 week 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.
Hi,
I have a similar situation to @nachtigall (one pump and zones with large water requirements and several zones with rather small water requirements) and I believe that many users have similar problems with a somehow limited water supply.
My approach would be to give each group a total capacity (e.g. 1). Furthermore, each zone is given a water requirement (something between 0 and 1). Zones can now run in parallel until the total capacity is exhausted.
By default, the total capacity = 1 and all water requirements = 1, so the behavior would be the same as it currently is and there is no additional complexity for beginners. However, experienced users can adapt the water requirements of their zones to their circumstances and thus theoretically operate any number of zones in parallel.
In nachtigall’s example, the sprinkler zones would have a demand of 1 and the drip hoses would each have a demand of 0.1 or 0.2.
I’ve already had a first look at the code and think I’m beginning to have an idea of what to do. However, I still have no idea how to add fields in the GUI for a first test environment.
Therefore I would like to present my idea here and look forward to feedback.Hi @Meise86, fyi there was a related discussion on this topic recently in https://opensprinkler.com/forums/topic/ok-to-hardwire-7-zones-7-x-24v-ac-valves-in-parallel-with-ospi/#post-78733 (last paragraph about “virtual zones”).
FWIW regarding your idea of total capacity = 1 and 0.1 and 0.2 capacities: I think that I would have difficulties in practice to estimate whether a zone would be 0.1 or 0.2. Of course, I planned my setup but it is also a lot of rule of thumb and best guesses and not too fine-grained. That is, more in the range of these steps: 0.1; 0.25; 0.5; 0.75; 1 or so. Just to give some feedback on the idea… But virtual zone do sound a bit more easier to grasp imho.
- You must be logged in to reply to this topic.