OpenSprinkler stations jumping straight back to OFF when ON command sent

[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.