[ramblinwreck]

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.

[ramblinwreck]

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.

[ramblinwreck]

Did you set your sprinkler programs to ‘Use Weather Adjustment’? This option is off by default.

No, I missed that. That solved the problem. Thanks!

[ramblinwreck]

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.

[ramblinwreck]

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.

Attachments:

1. old_config.rtf

[ramblinwreck]

 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.

[ramblinwreck]

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.

[ramblinwreck]

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?

[ramblinwreck]

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.

[ramblinwreck]

Just a final update to say problem solved. There is/was no problem with OpenSprinkler. Problem was in the long run of underground wire that connected my OpenSprinkler (inside garage) to where the rain sensor was mounted externally (sitting on an outside fence post).

I dismounted the rain sensor from fence post and connected it directly to the OpenSprinkler with a short 6″ wire and tested it and it worked perfectly. I also re-connected long underground wire (formerly connected to external rain sensor) to OpenSprinkler without the sensor on the other end so that it should present “open circuit” to OpenSprinkler, and when I did that I got the toggling on/off status problem. So I reckon there must be some kind of short in the underground wire that was root cause of issue.

I ran a new wire to the external sensor and now all seems to be working properly.

I should have thought to do this check earlier, but in any case, thanks for the support.

[ramblinwreck]

I just updated to 2.1.2 and was bitten by this. I had exported my config (including programs) under old firmware, and imported back in under new firmware. My programs are now “broken” in the preview. Are there still plans to fix this bug in the preview scripts? [I do see the warning about repeat time being too short, but I do deliberately desire to program it this way, so that the ‘repeat’ gets queued and runs immediately, with no gap after the first time through]

 

 

 

[ramblinwreck]

Hi Ray,

OK, something is definitely broken with the microSD card access, for me at least. You recommended I remove the card and reformat — and I did just that (see above). In short, I reformatted, and ran a couple of run-once programs and confirmed they were logged correctly. Over recent days, I would occasionally check “view logs” to ensure I could still see those run-once program logs, and I could.

Well, it rained here Tuesday/Wednesday so I manually disabled the controller. Today (Thursday) is my regular watering day. At 6AM, I opened up the app on my iPhone to double check that the system did NOT run since I had disabled it. Go to “view logs” and precisely the same behavior I got before:

• “No entries found in the selected date range” (i.e my prior logs have disappeared)
• the sluggish / waiting behavior where the waiting icon spins for longer than usual in middle of screen
• same behavior from iPhone app or web interface

Interesting to me that this failure was noticed during the regularly scheduled time to run the program (i.e. Thursday morning – same as last week), although the system was actually disabled and therefore did not actually run during this time. Not sure if that is relevant, or coincidence. Unfortunately I do not know if actual irrigation is affected, since I had manually disabled my system due to rain.

Any ideas what the problem might be?

Chris

[ramblinwreck]

Hi Ray, OK I pulled the card and reformatted to FAT using Disk Utility on my Mac. Reinstalled the card into the controller, ran a ‘run once’ test program and that seemed to be logged correctly (no longer getting the “no entries found”). Will report back after my next schedule program runs, which will be the upcoming Thursday unless it rains.

Just for clarification — there should be no problem with me viewing logs while a schedule program is currently executing, correct? I used to be able to do this with the 2.0.x firmware, but this seemed to be the beginning of my troubles with FW 2.1.0, but maybe that was a red herring.

PS – I did manually inspect the contents of the card, using Finder, before I reformatted. There were some TXT files at the top/root directory, and I was able to open these. I suppose these were from the previous Firmware. There was also the LOGS directory you mention, and a couple of log files there too. Didn’t see anything obviously corrupted.

[ramblinwreck]

Hi Ray, yes, sorry I was not clear. microSD card is installed. I have been using logging (with previous FW 2.0.x) for some time (months) with absolutely no problems. I did not remove/re-format SD card during upgrade to Firmware 2.1.0. The only “out of the ordinary” thing that I did was to use the “clear logs” function because I had run a bunch of manual testing (with “run once program”) after the firmware update and wanted those logs (corresponding to manual testing) erased. So logging did work at least once after FW update. But I  did not test that logging worked correctly after using “clear logs”.

Edit to add: The LCD screen _does_ show the microSD card icon, so I believe the controller recognizes that a card is installed.

[ramblinwreck]

Thanks Ray. Got it installed this morning. Appears to be working well.

[ramblinwreck]

Got the DMG, installed 1.2.0 (6). Still have the issue (have to re-scan for my OS device again…). This is not urgent (I use web/app interfaces mostly), but thought I’d mention it.

[ramblinwreck]

Hi!

That’s odd because I do have settings being saved to ~/Library/Sprinklers/LocalStorage. Does this folder exist on the system with the app installed?

No.

Also, which version of OS X are you using? By the way, Apple is terribly slow at updating the OS X app. They emailed me yesterday letting me know it will be a while before they review 1.1.8 (latest on store is 1.1.6).

10.9.4

Just for the sake of debug, I created that folder structure manually (i.e. added Sprinklers/LocalStorage to my ~/Library), but I still get the same result, and those new folders stay empty.

[ramblinwreck]

@ray wrote:

I re-checked several times, tested by connecting to the screws on the plug, as well as on the raw wires (green plug removed), and I was always getting 4-5MΩ reading.

I didn’t quite understand this: do you mean that when it’s connected to OS, it always appears as open circuit (i.e. 4-5Mohm reading), even when you don’t press the self-test button? Because it’s normally closed, it should be almost 0ohm when self-test button is released. I can’t imagine how connecting it to OS would affect this.

No, sorry I was not clear. In all cases the rain-sensor was disconnected (i.e. unplugged) from the OpenSprinkler controller itself when I measured with the meter.
What I’m saying is that I checked, when the self-test button was depressed:
(a) by leaving the green plug on the rain sensor wires and touching the meter probes to the two screws on the plug
(b) be removing the green plug from the rain sensor wires and touching the meter probes to the wires directly

I wanted to rule out that the possibility that the plug itself was defective and was somehow shorting the two rain-sensor wires making it appear closed (i.e. no rain) when it should have been open (i.e. rain detected). But that wasn’t the case — I got the 4-5MΩ reading both ways (i.e. using ‘a’ and ‘b’ methods). So I don’t think the plug is defective.

—

So I think we’re in agreement that the rain-sensor is operating correctly and that it should work with OpenSprinkler? In that case, does this suggest I might have a defective unit? Is there anything else I can check here?

[ramblinwreck]

Ray, just confirmed that my rain sensor is in fact the Hunter Mini-Clik (see previous post).

Tonight I re-tested the rain sensor wires (disconnected from OpenSprinkler) with my multimeter. As the external sensor itself was dry, I had to use the little “self test” button on top of the sensor to trigger the rain shut-off function (i.e. open circuit). What I found:

No rain (self-test button not depressed): closed circuit — almost 0Ω reading between the wires
Rain (self-test button depressed): reading between 4 to 5 MΩ between the wires

I re-checked several times, tested by connecting to the screws on the plug, as well as on the raw wires (green plug removed), and I was always getting 4-5MΩ reading.

Do you think this could be the problem? I wonder how I can tell if this is “in spec” for this particular sensor (in which case the sensor is just not compatible with OS), vs the sensor is truly defective. Is this outside what OpenSprinkler expects to see?

[ramblinwreck]

@ray wrote:

Which type of Hunter rain sensor do you have? Can you post the model number? I think it has to do with either the way this particular sensor works, or there may be a loose connection somewhere..

I am 99% sure it’s the Hutner Mini-Clik, but I will confirm when I get home. Here it is:
(product page) http://www.hunterindustries.com/irrigation-product/sensors/mini-clik
(manual) http://www.hunterindustries.com/sites/default/files/IC_MiniClik_dom.pdf

@ray wrote:

If it’s a simple normally closed sensor, when it detects rain the two wires on the rain sensor should remain open-circuit. You can use a multimeter to verify this. Normally open sensors are the reverse way. If the multimeter shows that it connects and disconnects and repeats like that, then the sensor will not work with OpenSprinkler.

Everything I read suggests that it is a simple normally closed sensor (there is a 3rd wire to provide support for normally open controllers, but this isn’t used in my installation). I confirmed with my multimeter that it showed “open circuit” when the sensor itself was wet. I did not measure the wires while they were attached to the controller, but rather disconnected them and then measured at the tips of the disconnected wires. It was not inconsistent — I had a solid/stable “open circuit” reading. I did not test the sensor with a meter when it was dry, but I will do that this evening (that said: the “no rain” status has been working correctly, the problem occurs only when the sensor gets wet).

[ramblinwreck]

OK, powered off the OpenSprinkler, unplugged the rain sensor wires. Powered unit back on. Observations:

* OS unit indicates a steady/stable “rain indicated” status (I suppose this is expected since OS configured for “normally closed” sensor, and unplugging opens the circuit?)

* DMM indicates steady/stable “open circuit” across the 2 rain sensor wire ends (I suppose this is also expected for a “normally closed” sensor that is currently wet). I checked on continuity setting (reading: no continuity), and on resistance/ohm setting (reading: overloaded).

* Power OS off. Re-attach plug to wires, and reinsert plug to OS. Power ON. Unstable rain sense status again. 🙁

Seems to me like the rain sensor is behaving as expected by providing an continuous/steady open circuit. What should I check next?

[ramblinwreck]

Thanks for the reply. Got the OS controller installed this weekend everything is working well with these options left as zero (default). I won’t mess with success. 🙂

[ramblinwreck]

Thanks!

[ramblinwreck]

This is just my opinion, but I really don’t like having sliders for program duration at all. Here’s why.

I’ve got a pretty typical residential irrigation system with a mixture of spray heads and rotor heads. For the spray heads, I’ve have multiple (short) run times to help prevent runoff. My run times in my programs are any where from 4 minutes to 20 minutes, and I occasionally make +1/-1 minute adjustments to fine tune those zones. There is simply not enough precision in the slider (which goes to 300) to make a +1 or even +2 adjustment. What inevitably happens is I try to bump the slider ever so slightly, and then it jumps by +6 or +13 (or whatever) minutes, then I give up on the slider and enter it manually in the text box.

I’d much rather see the little rolling wheel thingys (not sure what they are called) like are used for the start/end times. This would also support data entry in a MM:SS format…

[ramblinwreck]

Thanks for the quick reply, got it!

[Author]

Posts