- This topic has 15 replies, 2 voices, and was last updated 9 years, 1 month ago by
.
-
Posts
-
Hi Ray,
I’ve got what appears to be a fundamental problem in programming. My program repeats (that were working in 2.1.0) aren’t working in 2.1.2. I’ve simplified my programming to show the issue with only a single program enabled (other/old programs are disabled). I’m using HW v2.1 with FW v2.1.2.
I expect this program should run multiple times due to the repeat setting. But the preview shows it running only once:
Am I doing something wrong here? It’s possible I broke something, I suppose, but I initially noticed this on much more complex programming after I imported my old config (running fine on 2.1.0) into OpenSprinkler after the 2.1.2 update.
Let me know if you need more data.
Edit: attached configuration string.
This is a preview script bug, we’ve just found the source of the problem (which was introduced when fixing a previous bug). It’s only a preview issue, and doesn’t affect how the controller runs the programs.
The preview fix will be released as soon as possible, thanks for your patience.
Thanks Ray. Looks like the repeat issue has been fixed, but I’m still seeing other issues in preview. Have all the fixes been rolled in?
See below. “Back (bed)” gets skipped on the 2nd iteration, and “Right (AC)” gets skipped on the 3rd iteration.
One more question.
The old User Manual (http://rayshobby.net/opensprinkler/svc-use/svc-web/) said the following about preview:
How does the program preview feature work:
This feature is implemented using a Javascript that performs a full software simulation. It uses the same algorithm that the controller runs. Therefore what you see is what you get: the graph faithfully represents how the controller will the programs during that day. All relevant parameters, such as station delay time, master on/off time, and each station’s master operation flag are taken into account in the simulation. If you are unsure whether you have set the programs correctly, you can easily use the preview feature to find out.
Above, you stated:
It’s only a preview issue, and doesn’t affect how the controller runs the programs.
I must say that I prefer the former “what you see is what you get” behavior. With the recent bugs, it is becoming harder for me to trust the preview. Are there plans to restore it to “what you see is what you get”, or has there been a fundamental change in the way this is implemented?
Regarding your first question: the preview is showing the correct run sequence. The issue is that your program takes 47 minutes to run, but your repeat cycle is set to 45 minutes. That means it’s trying to schedule the program again while the first run is still running. Therefore some stations cannot be rescheduled because it conflicts with the first run. You should set the repeat cycle time to at least 47 minutes.
Regarding your second question: it has always been our intention to have preview accurately reflect what the controller does. However, since these are two different programs — the controller runs firmware, and the preview is written in Javascript, there are inevitably some differences. When bugs are introduced, that will cause the preview to have different prediction than what the controller actually does.
Hi Ray, I understand your explanation, but IMO this is a bug. Not only is it different than prior firmware behavior, but it is also different than the way most irrigation controllers work — i.e. they will never corrupt a program due to overlapping programs.
To illustrate the first point, here are two screenshots. This is my actual program from end of last summer. The first image is a preview from that program under FW2.1.0. The second image is the same program under FW2.1.2 (i.e. exported config under 2.1.0 and reimported same config under 2.1.2). This shows the change in behavior, notably that ‘Back (bed)’, ‘Back (swing)’, and ‘Back (swale)’ have missing runs. The new behavior places additional burden on user to tweak the repeat cycle time. For old FW, I deliberately programmed repeat cycle time < program time to ensure additional program iterations ran immediately after the first.
FW2.1.0:
)
FW2.1.2:
For the second point, consider the Hunter Pro-C controller as one example: http://www.hunterindustries.com/sites/default/files/OM_PROCC_dom.pdf
The Pro-C will automatically stack any programs that overlap
Please consider this as an OpenSprinkler feature request to queue-up any programs which overlap, whether they are separate programs, Repeats of the same program, or Additional Start Times of same program.
I am not sure what you mean by ‘Corrupt’ a program. The program is not being corrupted at all. Firmware 2.1.0 and 2.1.2 have use different implementations. Specifically, firmware 2.1.0 will ignore overlapping programs — if a program is still running when a new program is scheduled to start, the new program will be ignored. In firmware 2.1.2, it can stack programs except stations that are already in the queue to run. For example, if program 2 is trying to start while program 1 is running, all stations that have finished running program 1 will be scheduled. However, if a station is running or in the queue to run while the same station is being requested to run by program 2, that station cannot be scheduled.
I don’t know how Pro-C automatically stacks programs, but I consider this a non-trivial problem. The reason is that you can set the repeat cycle so small that it causes the program to stack forever. For example, if you request the program to repeat every 1 minute, for 100 times, and the program takes 60 minutes to run, what do you expect to happen? I don’t think Pro-C even supports such flexible repeating programs. Also, OpenSprinkler supports up to 14 different programs. With this level of capability, it needs to conserve resources.
If you set your program to repeat every 47 minutes, it WILL run immediately after the previous run finishes.
For the sake of comparison: here are some details from the Pro-C feature list:
http://www.hunterindustries.com/irrigation-product/controllers/pro-crIndependent irrigation programs: 3
Start times per program: 4So we are talking about 3 different programs on Pro-C vs. 14 on OpenSprinkler; 4 start times per program on Pro-C vs. unlimited (practically limited by the number of minutes per day) start times on OpenSprinkler.
I am not sure what you mean by ‘Corrupt’ a program. The program is not being corrupted at all.
OK, maybe I didn’t choose the best words. What I meant is that the program execution was incorrect. ‘Incorrect’ means:
- stations programmed to water 2x times are not watered 2x times
- multiple iterations of the same program don’t water the same set of stations
Specifically, firmware 2.1.0 will ignore overlapping programs — if a program is still running when a new program is scheduled to start, the new program will be ignored.
I don’t know how this can be the case, my FW2.1.0 screenshot shows otherwise. Notice there is zero gap between any of the station run times in the first screenshot, and I definitely did not take the time to match perfectly the repeat time to program time.
For example, if you request the program to repeat every 1 minute, for 100 times, and the program takes 60 minutes to run, what do you expect to happen?
Well first I think that is nonsensical programming, and hopefully the user would see their mistake using Program Preview and then correct it. 🙂 But for the sake of argument I would expect it to run for 100 times @ 60 minutes each, back-to-back with no pause between them. You could mitigate this sort of nonsensical program by limiting repeat times to something sensible (4 or 8 or whatever), or by limiting total (program run time x num repeats) run time.
I don’t think Pro-C even supports such flexible repeating programs
Fair point. But I can demonstrate exactly the same issue by programming overlapping Additional Start Times, which the Pro-C most certainly does support. I know, because I used to utilize this feature on my Pro-C, and indeed it would queue-up multiple runs when multiple start times of the same program resulted in program overlapping.
If you set your program to repeat every 47 minutes, it WILL run immediately after the previous run finishes.
I understand that. That’s not the issue. The issue is that changing weather conditions mean my station run times are constantly changing. Now I’ll to constantly need to tweak the repeat time in response to that, otherwise I have a bunch of dead (non-watering) time while my programs are running. I’m trying to minimize that since I can only water during certain hours. This is not a big deal, just an disappointment since FW2.1.0 used to do this the way I had expected it to.
And, isn’t this a bigger problem for your users who use the automated “Water Adjustment” feature to vary the % of watering? What happens when a dry-spell and high temperatures result in increased station run times to the point where the program length exceeds interval time? Maybe there was no overlapping at 80%, but there is at 90%. Does the user get notified that there is now an overlapping program caused as a result of automated station run time increase, or does their lawn go brown because the overlapping program means some stations didn’t run when they expected them to? [I don’t use this feature, so I don’t know..]
For the sake of comparison: here are some details from the Pro-C feature list:
Ray, listen, I think you get the wrong impression from my post. 🙂
I’m not trying to compare OpenSprinkler to anybody — indeed it is far more flexible than any off-the-shelf controller. I’m not questioning that. I was merely pointing out this behavior which is different than most of your new users will be accustomed to (migrating from Hunter/RainBird, etc), and also that it is a different (and IMO less desirable) than the way it used to work. Or at least different than the way FW2.1.0 Preview used to tell me it would work.
Specifically, firmware 2.1.0 will ignore overlapping programs — if a program is still running when a new program is scheduled to start, the new program will be ignored.I’ve attached my exported config file corresponding to the programs preview comparison screenshots shown above. I suppose you could load this into one of your own OpenSprinklers with FW2.1.0 and find out how/why it displayed the way it did (queueing up overlapping programs) if, as you say, it was supposed to ignore overlapping programs.
I understand what you want to achieve: run programs back to back, and also allow for varying program run times (due to weather adjustment). There is not a simple way to achieve this currently, due to the way the firmware handles station runs.
Fundamentally, this is due to the fact that the firmware is centered around ‘stations’ and not ‘programs’. Conceptually the OpenSprinkler does not treat a program as an entity, so the concept of ‘queuing’ a program does not apply here. Rather, it treats each station as an entity. The reason it’s done this way is to accommodate both sequential and parallel stations. The firmware gives each station one run-time slot. If the slot is non-empty, it does not allow additional schedule to overwrite that slot. That’s why if a station is already scheduled while it’s being requested to run again, it can’t achieve that.
The main point to compare with Pro-C’s features is to explain that the limitations come from prioritizing the limited resources towards different goals. Pro-C allows only up to 16 stations, 3 programs, and 4 start times; while OpenSprinkler allows up to 48 stations, 14 programs, unlimited start times. On top of that, OpenSprinkler allows both sequential and parallel stations, allows individually setting each station to ignore rain, to activate a master station. As a result, the concept of ‘queuing programs’ does not apply here. I chose to implement the scheduling algorithm and data structures in a different way to accommodate the capabilities.
Firmwware 2.1.0’s preview has a bug itself — I am pretty sure that overlapping programs will be ignored by the firmware. Firmware 2.1.2 is the first that can actually handle overlapping programs to some extent, albeit with the limitation that it can’t handle overlapping stations.
Regarding the extreme case I brought up “repeat every 1 minute, for 100 times, and the program takes 60 minutes to run” — I don’t expect the sprinkler controller to be able to handle unlimited cases like this — it has to cut off somewhere. There may be other programs that are scheduled while the 100 runs are going on, so if you think about having a stack, that is going to overflow at some point if you don’t have any limit of such repeating schedules. On the microcontroller the resources are very limited — it’s not like a Raspberry Pi that has fairly large amount of RAM and virtual memory system. It will have to set a cutoff point somewhere, and decide that it can’t accommodate additional runs until some existing ones complete.
My main point here is that different high-level goals impose different limitations. I will think about how to solve the issue — for example, by having a station queue that allows the same station to appear multiple times in the queue, as opposed to reserving one and only one slot for each station. I think this can absolutely solve the issue that you have encountered. Still, the queue will have a limited size, so if there are too many station runs being requested, it will have to still abandon additional station runs until some slots are freed up in the queue. It will always have to cut off somewhere.
I understand what you want to achieve: run programs back to back, and also allow for varying program run times (due to weather adjustment).
Yes!
Regarding the extreme case I brought up “repeat every 1 minute, for 100 times, and the program takes 60 minutes to run” — I don’t expect the sprinkler controller to be able to handle unlimited cases like this — it has to cut off somewhere.
Understood. Of course I wouldn’t actually expect OpenSprinkler or any other controller to actually execute a nonsensical program like that. That’s why I mentioned limiting number of repeats or total run times. Speaking only for myself, I’d be happy with a simple limit of 4 repeats (to support the standard turf irrigation practice of splitting long runtimes into a multiple shorter runtimes to help mitigate runoff). Hopefully that would provide a very reasonable upper bound on the number of stations that could possibly ever get queued up.
Thank you for taking the time to understand the issue I was trying to describe, the detailed explanation, and for thinking about a way to solve it.
Not to belabor the point, but I just wanted to make sure this additional point was not lost.
I understand what you want to achieve: run programs back to back, and also allow for varying program run times (due to weather adjustment).
Not only that — but even when programs aren’t necessarily scheduled to run back-to-back, there is still potential for watering of stations being silently dropped as a result of increased watering percentage.
Example:
Here’s a program preview with watering percentage set (manually) to 100%. Programs are not running directly back-to-back, i.e. (interval time > program run time) to avoid the issue we discussed at length, above.
Now, this image shows the exact same program at 150% (manually set), notice that some station waterings have been dropped due to the issue described above:
Now, had I been using the automated Zimmerman method, and if that method had resulted in 150% watering percentage on my watering day, then I would have had absolutely no warning ahead of time that my stations weren’t going to be watered as intended. This is particularly unfortunate because this means that the controller delivers less water on the specific days where we actually required more. The only way the user would know is by analyzing the log data, or by their lawn turning brown.
Seems the only way to ensure this can’t happen is to place sufficiently large space between all programs so that there is no overlapping even at max percentage (250%?), which doesn’t seem practical for end-user — it means there is burden on end-user to always preview programs at 250% watering percentage to ensure this behavior can never happen.
I do fully understand from our discussion above that this is not an easy thing to solve, but I think this is something your users (at least those using Zimmerman method) should be aware of.
To understand your request, can you explain why you want to water the same station again over a short period of time? Why not aggregate it so that you water a longer period of time for the same station, as opposed to water it twice over a short period of time?
Also, I made it pretty clear above that no matter how well the algorithm is designed, there always exist cases that some water cycles will have to be ignored. Because the water time can increase due to weather adjustment, and stations have to run sequentially, you are essentially relying on the fact that there is enough spare time between water cycles for it to catch up. Let’s look at one extreme case: say you have a program that runs stations 1 to 8, each for 1 hour, and the program repeats every 12 hours. Now let’s say the weather algorithm says each station has to run 2.5 hours instead of 1 hour, so suddenly the program takes 20 hours to finish, and there is no way it can satisfy the water time requirement, simply because there is not sufficient gap between each program repetition to catch up with the increased water time. So I think it’s reasonable to require the the repeat cycles to be sufficiently far apart.
My point is that the algorithm will try its best to satisfy the requests, but no matter what, there is always a limit. Even with the best algorithm, you can always come up with cases that it cannot handle, and argue that it has flaws.
One solution is to set the stations to run in parallel mode — that is, any station can turn on at any time, without serializing them. This can solve your immediate need. But again, there is no perfect solution.
To understand your request, can you explain why you want to water the same station again over a short period of time? Why not aggregate it so that you water a longer period of time for the same station, as opposed to water it twice over a short period of time?
To conserve water. When you’re using spray heads with high precipitation rate, irrigating over dense soils (and/or on sloped lawns) you cannot have long run times — you get runoff and the water ends up on the sidewalk, driveway, or street. The solution is to break long runtimes into multiple shorter run times, with breaks in watering long enough to let the soil soak up the water (30 minutes is sufficient). This is a common irrigation technique.
Also, I made it pretty clear above that no matter how well the algorithm is designed, there always exist cases that some water cycles will have to be ignored.
In my opinion, and indeed this is just my opinion, it is simply bad practice for an irrigation controller to silently ignore/drop watering cycles, under any circumstances, but especially at the precise time when the watering algorithm determines the lawn needs more water. That is the kind of thing that kills lawns and frustrates users.
I do completely understand there are practical limits to what OpenSprinkler can do. But I think I’ve shown above that this ignoring of watering cycles can happen on fairly typical programming (i.e. simple zone repeats when Zimmerman method enabled and there’s an automated watering % increase). That’s not an extreme case at all. I don’t know the solution. It would be great if the least the controller could give the user a warning at the time the water schedule is programmed by the user letting the user know this will happen if watering percentage exceeds <x>%, or at least a warning (mobile app notification?) when actual watering % is increased to the point where cycles will be ignored on currently enabled programs. Or maybe constraining run times / repeat times so that it gives you a much more reasonable “worst case” to program for.
So I think it’s reasonable to require the the repeat cycles to be sufficiently far apart.
The only way to do this (to ensure ignoring cycles can’t happen) is to design and preview the watering schedule for 250% watering percentage. That’s a kludge. Besides, designing the watering schedule for 250% watering will result in suboptimal schedule at 100% (or less).
One solution is to set the stations to run in parallel mode
I don’t think that’s a solution because that requires even more tedious care with programming, in order to ensure I don’t end up with multiple zones firing at the same time, thus exceeding the electrical capability of the power-supply (not to mention insufficient water pressure with multiple zones activated).
I’ve highlighted the issue as best I can. Perhaps I do not explain the issue well, or my expectations are unrealistic, maybe both. For me, I will just disable Zimmerman method, adjust manually, and always preview my programs. Thanks for your time.
)
- You must be logged in to reply to this topic.