OpenSprinkler stations jumping straight back to OFF when ON command sent

[raaahbin (Robin Darroch)]

I was tearing my hair out for a while this afternoon, because I had coded something that should have been super-simple, and suddenly my OpenSprinkler binding was behaving super weirdly. However, I think I’ve figured out what was causing it - or at least how to cause it to misbehave and therefore how to avoid triggering the misbehaviour. However, in the hope of avoiding others having to follow in my footsteps, I hope posting this can be useful in fixing whatever is going on behind the scenes.

I have three active stations on my OpenSprinkler - one that does a lawn and veggie beds, and two that do all the garden beds. The lawn and veggie beds station runs on different logic to the other two, but the other two I always want to run in sequence. Therefore, I had coded the following rule:

rule "run front yard after running garden beds"
when
	Item waterGardenBeds changed from ON to OFF
then
	waterFrontYard.sendCommand(ON)
end

I have a separate rule to create a timer to turn the stations off a certain amount of time after they are turned on, but that was working fine. However, the behaviour I was seeing was:

• after starting the system from fresh (originally on 3.1.0, but updated in my frustration to 3.2.0.M5), using an individual toggle switch in the OH interface to turn on (for example) the lawn watering would work as expected, and appear in the log as:

15:32:04.554 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'waterVeggiesLawn' received command ON
15:32:04.554 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'waterVeggiesLawn' predicted to become ON
15:32:04.556 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'waterVeggiesLawn' changed from OFF to ON
15:32:04.556 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'gWateringStations' changed from OFF to ON through waterVeggiesLawn
15:32:04.557 [INFO ] [nhab.core.model.script.watering.rules] - Watering turned on - timer set for: 15 minutes.

• I could then manually turn off that station, and manually turn on the first of the other stations - again, responding as expected:

15:32:36.709 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'waterVeggiesLawn' received command OFF
15:32:36.710 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'waterVeggiesLawn' predicted to become OFF
15:32:36.710 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'waterVeggiesLawn' changed from ON to OFF
15:32:36.711 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'gWateringStations' changed from ON to OFF through waterVeggiesLawn
15:32:51.092 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'waterGardenBeds' received command ON
15:32:51.093 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'waterGardenBeds' predicted to become ON
15:32:51.094 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'waterGardenBeds' changed from OFF to ON
15:32:51.094 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'gWateringStations' changed from OFF to ON through waterGardenBeds
15:32:51.095 [INFO ] [nhab.core.model.script.watering.rules] - Watering turned on - timer set for: 15 minutes.

• However, here’s where it gets weird. If I turned off the waterGardenBeds item, it would trigger the rule given above, but not with the expected results:

15:33:12.852 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'waterGardenBeds' received command OFF
15:33:12.853 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'waterGardenBeds' predicted to become OFF
15:33:12.854 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'waterGardenBeds' changed from ON to OFF
15:33:12.854 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'gWateringStations' changed from ON to OFF through waterGardenBeds
15:33:12.855 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'waterFrontYard' received command ON
15:33:12.856 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'waterFrontYard' predicted to become ON
15:33:12.856 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'waterFrontYard' changed from OFF to ON
15:33:12.857 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'gWateringStations' changed from OFF to ON through waterFrontYard
15:33:12.858 [INFO ] [nhab.core.model.script.watering.rules] - Watering turned on - timer set for: 15 minutes.
15:33:16.360 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'waterFrontYard' changed from ON to OFF
15:33:16.361 [INFO ] [nhab.event.GroupItemStateChangedEvent] - Item 'gWateringStations' changed from ON to OFF through waterFrontYard

As you can see, the station that was meant to be turned on by the above rule did initially turn on, but then turned off again within a matter of seconds. Once this had happened, any attempt to turn on any station manually (through OH) would receive the same results - on, then back off again almost immediately.

When checking the OpenSprinkler interface after this happened, I discovered a weird thing on the display: the stations weren’t all just on or off - they were in a “Scheduled” state (I’ve tried to attach a screenshot here, but it didn’t work - I might try in a reply).

After using the OpenSprinkler app to send a “stop all stations” command (returning them all to the normal “off” state), I could once again turn on individual stations through the OH interface, but as soon as I triggered the rule at the start of this post, I got the OFF->ON->OFF behaviour again, along with the “Scheduled” state in the OpenSprinkler interface.

In the end, I decided that a likely culprit was the rapid sequence of commands (possibly even overlapping?) through the OpenSprinkler API, so I added a 5 second delay to the rule as follows:

rule "run front yard after running garden beds"
when
	Item waterGardenBeds changed from ON to OFF
then
	Thread::sleep(5000)
	waterFrontYard.sendCommand(ON)
end

Having done that (and reset all the stations in OpenSprinkler), it now seems to work as expected, without creating any odd on-off behaviour. However, it seems to me that it could be worth adding something to the OpenSprinkler binding to prevent this behaviour occurring if anyone else tries to code it to turn one station off and another station on in immediate series.

[raaahbin (Robin Darroch)]

As you can see, the “scheduled” status is for a time roughly 36 hours in the future.

I should also point out that there are no “scheduled” programs at all in the OpenSprinkler, except for the daily reboot schedule (the current workaround for OpenSprinkler’s tendency to drop off the wifi network at random intervals)

[matt1 (Skinah)]

Couple of points and questions…

1. What hardware do you have, the PI or the latest V3.0 esp based version?
2. What firmware is loaded, have you tried a newer firmware?
3. Have you checked the OS forum and asked there?
4. You mention wifi dropouts, have you tried making sure the wifi has good signal and if it still occurs when the signal is strong?
5. Try looking at the logs after you change to TRACE level logs for the binding.
6. How low can you make the delay before the ‘fix’ no longer works?
7. The 18 hour delay makes me think this may be a timezone mismatch as it should queue up the station and start when the other one finally recognizes as being stopped.

@raaahbin

Thread::sleep(5000)

Be sure to search the forum about how you only have 2 threads and using sleep is a bad idea unless just for a quick test.

@raaahbin

After using the OpenSprinkler app to send a “stop all stations” command

The binding can send this same command, perhaps try using this in the rule instead of the sleep and see if that helps.

@raaahbin

The lawn and veggie beds station runs on different logic to the other two, but the other two I always want to run in sequence.

Then you can setup a PROGRAM and openhab can tell it to run the program, this is how I do mine as I dont bother setting up all the stations, just use the programs and stations channels. Consider what happens when your wifi has dropped out or openhab is rebooting in the middle of when the watering is meant to be switching from one station to the next. Easier to offload this to the OS hardware and let it handle it.

[rossko57]

@raaahbin

I got the OFF->ON->OFF behaviour

As you discovered, it’s not a true report of device state.
For background, to explain ‘predictions’ log -

Autoupdate - a primer

I’ve found myself having to investigate and/or explain some of the features of autoupdate over time, and thought an in-depth view would be helpful. These notes apply to openHAB version 2.5 Overview Autoupdate is primarily a “speed up” feature for openHAB Items. Mostly we can ignore it, but sometimes you may get an unwanted or unexpected effect, or you may wish to exercise more control. To fully understand autoupdate, we must understand the difference between command and state of Items. If w…

@matt1

Be sure to search the forum about how you only have 2 threads and using sleep is a bad idea unless just for a quick test.

This will be fine in OH3, rules management is different.

[raaahbin (Robin Darroch)]

@matt1

1. What hardware do you have, the PI or the latest V3.0 esp based version?

Hardware version 3.1 DC.

2. What firmware is loaded, have you tried a newer firmware?

Firmware 2.1.9 (9) - the latest version AFAIK

3. Have you checked the OS forum and asked there?

It’s only a problem that arose with OH sending commands to the OS - if I ignore OH altogether and just use the functions of the OS, it behaves perfectly normally.

4. You mention wifi dropouts, have you tried making sure the wifi has good signal and if it still occurs when the signal is strong?

The signal is excellent where it is. This is a known problem where if left running for a long (but indeterminate) period of time, sometimes the unit will drop off wifi and not rejoin without a reboot regardless of the quality of signal. It is no longer a problem since the function to schedule a reboot was added to the firmware, which serves as an effective workaround. There’s a fairly extensive thread on the OS forum about it.

5. Try looking at the logs after you change to TRACE level logs for the binding.
6. How low can you make the delay before the ‘fix’ no longer works?

I haven’t tried either of these steps yet - I might give those a try, see if I can narrow it down. I figured 5 seconds was enough to be an eternity for an API and not long enough that I’d care about it one way or another.

7. The 18 hour delay makes me think this may be a timezone mismatch as it should queue up the station and start when the other one finally recognizes as being stopped.

OK - I suspect it’s an artefact rather than commanded behaviour being time-shifted (and both openhab and opensprinkler are set to the correct timezone). I use the OpenSprinkler binding in OH only to send station on and off commands - never any other command - so how a “openhab says turn off station 1” and “openhab says turn on station 2” gets turned into “schedule a run of station 2 arbitrary (maximum?) length in 36 hours time”

@raaahbin

Thread::sleep(5000)

Be sure to search the forum about how you only have 2 threads and using sleep is a bad idea unless just for a quick test.

I understand that sleep is to be avoided if you don’t want that particular rule to completely stop responding during the sleep, but in this case that’s not a problem - there’s no concurrency needed in the watering system, and I am very happy to avoid race conditions where (for example) the system ends up thinking a station is on when it isn’t, or vice versa.

@raaahbin

After using the OpenSprinkler app to send a “stop all stations” command

The binding can send this same command, perhaps try using this in the rule instead of the sleep and see if that helps.

@raaahbin

The lawn and veggie beds station runs on different logic to the other two, but the other two I always want to run in sequence.

Then you can setup a PROGRAM and openhab can tell it to run the program, this is how I do mine as I dont bother setting up all the stations, just use the programs and stations channels. Consider what happens when your wifi has dropped out or openhab is rebooting in the middle of when the watering is meant to be switching from one station to the next. Easier to offload this to the OS hardware and let it handle it.

That’s really good advice - thanks! I’ve just been looking over the documentation, and it seems like the binding might have moved along under me, because I don’t think those features were available before. I’ll check it out.

[raaahbin (Robin Darroch)]

@rossko57

@raaahbin

I got the OFF->ON->OFF behaviour

As you discovered, it’s not a true report of device state.
For background, to explain ‘predictions’ log -
Autoupdate - a primer

Thank you! I didn’t know that was a thing (or more specifically, that it was a thing over which I had direct control), and have now added “autoupdate=‘false’” to all of those items. Hopefully that will avoid the spurious messaging that something has turned on when it has not in fact done so. Using only the actual state of the station is very important here!

[raaahbin (Robin Darroch)]

@matt1

@raaahbin

After using the OpenSprinkler app to send a “stop all stations” command

The binding can send this same command, perhaps try using this in the rule instead of the sleep and see if that helps.

@raaahbin

The lawn and veggie beds station runs on different logic to the other two, but the other two I always want to run in sequence.

Then you can setup a PROGRAM and openhab can tell it to run the program, this is how I do mine as I dont bother setting up all the stations, just use the programs and stations channels. Consider what happens when your wifi has dropped out or openhab is rebooting in the middle of when the watering is meant to be switching from one station to the next. Easier to offload this to the OS hardware and let it handle it.

I’ve had something of a search through the documentation, and I can’t find anything about using the binding to send an instruction to the OpenSprinkler to run a program, nor a “stop all stations” command. As it is, if I want to stop everything, I send an “OFF” command to my group of station items. Can you point me to how the capabilities you describe can be accessed?

[matt1 (Skinah)]

I added these abilities and more sometime after the last stable version was released. This means to find matching documentation you will need to push the button in the top left of the website to change from STABLE to LATEST. You mention you have the milestone, so please always read the docs that are LATEST so they match.

See link here and if the docs are missing or not clear, then please raise a PR fixing it (preferred) or PM me the changes and I am happy to add them.

OpenSprinkler - Bindings | openHAB

The abilities you ask about are in the link above and if you can not see the new channels, you will need to delete and re-add the things. If you keep the UID of the things the same, then it should be very quick and all items will work right away.

Now that I have had some sleep, my memory is working better. The reason for the 18 hour delay is because when you manually turn a station on it uses a default time of 18 hours. I suggest if you wish to keep using full manual control, that you change the 18 hour length in your rule to exactly the time you want with the channel nextDuration. Using STATE OPTIONS metadata, you can add any time lengths that you want to the drop down list. If openhab is rebooting when your rule to turn off should have happened the sprinklers will run for 18 hours

Also you don’t need to wait for 1 station to end before adding more if you have sequential ticked in the stations properties (firmware).

So there are probably many different approaches to running the opensprinkler hardware, and all are valid ways just some work better with bad wifi connections, common when the sprinkler controller is outside where wifi is not so great.

1. Run it as you are now using openHAB as the full brains that need to be online for every step of the way. The hardware is basically just a bunch of relays that your controlling manually.
2. OH builds a custom program from scratch everytime the rule runs, then OH can go offline as the data is all queued up in the hardware unit.
3. Build your programs inside the hardware unit and trigger them from OH.
4. Programs inside the hardware that are fully scheduled by the hardware and OH just interrupts and tweaks these using the rainDelay and watering% features. This is how I run mine.

This is why I love the hardware because you can choose what you prefer and personally I like hardware that can keep running in the event that OH blows up, I was updating when a rule should have run, gets stolen or I sell the house.

Back to your original question as to if a delay can be added into the binding, that really depends on how long a delay is needed, hence why I asked how low the delay needs to be and if this only happens in a particular firmware. See if you can narrow it down to say 50ms and it then is reliable. Even if you choose to work around it via a method above, please still take the time to test and improve the binding for others that follow.

@raaahbin

This is a known problem where if left running for a long (but indeterminate) period of time, sometimes the unit will drop off wifi and not rejoin without a reboot regardless of the quality of signal. It is no longer a problem since the function to schedule a reboot was added to the firmware, which serves as an effective workaround. There’s a fairly extensive thread on the OS forum about it.

Great news as that is the only problem mine has had in the past year of use. It locks up and even the direct webpage of the unit can not be reached until rebooted. That happens every 6 months only, so now they have a reboot feature I will have to check it out.

@rossko57 thanks for your reply and corrections.

[raaahbin (Robin Darroch)]

@matt1

I added these abilities and more sometime after the last stable version was released. This means to find matching documentation you will need to push the button in the top left of the website to change from STABLE to LATEST. You mention you have the milestone, so please always read the docs that are LATEST so they match.

Excellent - I’ve changed to that, and can now see the listing for other channels.

See link here and if the docs are missing or not clear, then please raise a PR fixing it (preferred) or PM me the changes and I am happy to add them.

Thank you! I will PM with the things that I haven’t been able to figure out from the latest version of the docs.

The abilities you ask about are in the link above and if you can not see the new channels, you will need to delete and re-add the things. If you keep the UID of the things the same, then it should be very quick and all items will work right away.

I did indeed have to delete and re-add the things, but it’s all back to working as expected… now I’m looking forward to trying the new approaches to things!

1. Run it as you are now using openHAB as the full brains that need to be online for every step of the way. The hardware is basically just a bunch of relays that your controlling manually.
2. OH builds a custom program from scratch everytime the rule runs, then OH can go offline as the data is all queued up in the hardware unit.
3. Build your programs inside the hardware unit and trigger them from OH.
4. Programs inside the hardware that are fully scheduled by the hardware and OH just interrupts and tweaks these using the rainDelay and watering% features. This is how I run mine.

I do have it in approach #1 at the moment, but given the results of the driving logic in OH are not overly complex (just more complex than the OS is capable of doing on its own), I will probably move to approach #3. Which is what I’ll need to PM you about explaining/adding to the docs.

This is why I love the hardware because you can choose what you prefer and personally I like hardware that can keep running in the event that OH blows up, I was updating when a rule should have run, gets stolen or I sell the house.

Yes - I would really like to have some of that resilience in the system, which obviously I don’t have right now because the communications between OH and OS are a single point of failure which could lead to undesirable results (either watering not being started when it should, or watering being started but then not stopping when it should).

Back to your original question as to if a delay can be added into the binding, that really depends on how long a delay is needed, hence why I asked how low the delay needs to be and if this only happens in a particular firmware. See if you can narrow it down to say 50ms and it then is reliable. Even if you choose to work around it via a method above, please still take the time to test and improve the binding for others that follow.

Moving from the “dumb relay controller” to “smart programs with external triggering” approach, I probably won’t need that rule or workaround any more. However, I will run some tests while I do still have it to see if I can get a meaningful value for the minimum effective sleep time.

[raaahbin (Robin Darroch)]

@matt1

Back to your original question as to if a delay can be added into the binding, that really depends on how long a delay is needed, hence why I asked how low the delay needs to be and if this only happens in a particular firmware. See if you can narrow it down to say 50ms and it then is reliable. Even if you choose to work around it via a method above, please still take the time to test and improve the binding for others that follow.

So I have done the testing, and here’s the interesting thing: reducing the sleep time to 500ms, then to 50ms, then commenting that line out altogether… didn’t reintroduce the problematic behaviour. So the one thing that remains is that my items now have autoupdate = "false" in the definitions. Which I guess means that was the real solution all along.

Well that, and in the long term changing my approach to use OS programs rather than just treating the OS as a dumb remote relay.

[matt1 (Skinah)]

Did you change the nextDuration from 18 hours? my guess is you have changed that to a lower number and that worked around the issue. If the controller was busy processing directions from openHAB, it would have scheduled the next station to start in 18 hours time causing your issue. Since the station was not ON, the state updated back to OFF which is correct.

BTW if you want a nice drop down list of durations add METADATA and STATE OPTIONS

[raaahbin (Robin Darroch)]

No - the next duration is still 18 hours. That hasn’t been changed yet: I’ve added scripting to the normally run rules to send an amended next run duration prior to turning them on, but none of those rules have run yet.

But what is now happening is that instead of sending another command to the OpenSprinkler when it hadn’t in fact finished executing the first one, the state change that triggers the rule only happens when the OpenSprinkler has executed the OFF command for the “garden beds” station, so the command to turn on the “front yard” station happens only after the prior command is completed… which is also why my “sleep” workaround worked.

[matt1 (Skinah)]

I’ll reply to your PM here so others can read. Yes you use the event log (see developer sidebar and it’s filter feature) to see what the items change to when you select a program. The difference is that it is a STRING channel so the number is in quotes.

openSprinkler_Programs.sendCommand(“0”)

Beware since I am mobile I can’t remove the culy quotes in the above. Without quotes for number channels, but when it is a String channel you need the quotes.

[raaahbin (Robin Darroch)]

Thanks! If I understand correctly, the programs channel can currently only be sent commands by number, not by name, but the number needs to be sent as a string. Is that correct? Is the reason it is configured as a string channel, because the intention in the longer term is to allow it to be used to query the list of available programs, and to call on those programs by name?

[raaahbin (Robin Darroch)]

@matt1

openSprinkler_Programs.sendCommand(“0”)

With a bit of tweaking, I’ve now got a set of programs all set up and ready to run, as well as logic to select them, rather than sending the start and timing commands directly. I think that means transition to approach #3 is complete!

For anyone else looking into implementing OS programs via OH, it appears that the numbering in the programs channel directly corresponds to the current order of programs as listed in the OS interface, starting from 0 (so you can re-order programs after creating them: the number doesn’t stay with the particular program - it stays with the list position).

I have made a list of programs now ordered as follows:

• veggies & lawn only
• veggies & lawn only - long run (an extra soak for especially hot & dry conditions)
• garden beds only
• garden beds only - long run
• all stations
• all stations - long run

I then create a variable as a bitmask for program selection: if I want the veggies/lawn station to run, I add 2. If I want the garden beds to run, I add 4. If I want long runs, I add 1. So (for example) garden beds and a long run = 4 + 1 = 5

If the result is less than 2, that means no stations need to run. If the result is 2 or more, I subtract 2 and send the result as a command to the Programs channel as follows:

	if (programBitmask > 1) {
		programBitmask -= 2
		openSprinkler_Programs.sendCommand(programBitmask.toString)
	}

This is clearly much, much cleaner than coding a whole bunch of timers within OH and commanding each station on and off directly, and now the worst problem is that if the OH system goes completely offline, the sprinkler system won’t run. There’s probably a way to fix that by enabling a backup schedule of programs that is deferred every day by OH sending a rain delay signal or some such (in a way that becomes a “dead man’s switch” if OH were to go offline)… but that’s a problem for another day.

As frustrating as it was to deal with the unexpected behaviour yesterday, I’m now really glad it happened because of how much better the system is now. Thanks so much for your help!

[raaahbin (Robin Darroch)]

@raaahbin

but that’s a problem for another day

It wasn’t, as it turns out. I’ve done that too

openSprinkler_RainDelay.sendCommand(24) 

Added the above to the rules that run morning and evening, and enabled a basic schedule for programs (that are covered by the rain delay adjustment) to run if openhab stops resetting the rain delay value (and provided the system isn’t otherwise triggering a rain delay from its built-in weather service).

Redundancy FTW!

[matt1 (Skinah)]

Instead of creating multiple programs that are LONG versions, you can use the watering% to make the program 50% or 150% or whatever value suits. I believe this requires the weather forecasts to be setup have not used it.

I use my weather station to measure actual rain and then ignore the watering based on the amount of rain. Forecasts are often wrong here.

Back to the original question, yes I think it would be best to look into turning off the auto update at the binding level of that fixes it. If you can raise it on GitHub then next time I am making changes it won’t be forgotten or someone else can do it.

[raaahbin (Robin Darroch)]

@matt1

Instead of creating multiple programs that are LONG versions, you can use the watering% to make the program 50% or 150% or whatever value suits. I believe this requires the weather forecasts to be setup have not used it.

Not a bad idea - however, I would ideally like auto rain delay to inhibit the running of the scheduled programs in the event that openhab goes offline for an extended period (e.g. if it fails while we’re away on holiday)… and it doesn’t look like watering% can be used when auto rain delay is selected as the weather adjustment option. Perhaps that is just a limitation of the opensprinkler app interface? Either way, I’m pretty happy with the existing logic, but I might investigate watering% too.

Back to the original question, yes I think it would be best to look into turning off the auto update at the binding level of that fixes it. If you can raise it on GitHub then next time I am making changes it won’t be forgotten or someone else can do it.

I’ve just created a new issue in GitHub - hopefully I’ve done that correctly!

[raaahbin (Robin Darroch)]

Checking the documentation, it looks like the waterlevel channel is read-only… so I’m not sure I could use openhab to control the watering% as you suggest. As I say, it’s no problem at all as the setup I’ve got now should work perfectly and maintain a good level of redundancy in the case of partial system failure.