This is a follow-up about this issue based on my recent experiences.
I’ve just recently acquired a second OpenSprinkler and have configured it as an extender and defined remote zones on the master OpenSprinkler. Both are HW Version 3.2 – AC and running 2.1.9 (3) firmware. I should add that the extender isn’t currently wired up to the valves and flow meter, but I doubt that makes any difference to the behaviour. I’ll find out in a few weeks when I get it installed and running.
I’ve observed the following behaviours with special station auto refresh ON:
1. The master OS indeed issues a command to run the remote station for MAX_NUMBER_STATIONS (which for 2.1.9 (3) is 144 seconds).
2. After half that time is elapsed (in this case 72 seconds) the master issues another run command of the same duration. This repeats until the programmed time for the remote station on the master has elapsed, at which point it issues a stop command.
The issues I’ve encountered are as follows:
1. If the extender has a master valve and if there are On/Off Adjustments (which is true in my case), every time the master issues a run command, the master valve turns off and then back on in accordance with the On/Off Adjustments. This is clearly undesirable behaviour.
2. Whether or not there’s a master valve defined, the log for the remote zone on the extender only captures the time between when the master issues the last run command before the master issues the stop command. The Timeline Log view shows flow meter data appears to be captured for the whole time the master is issuing commands.
3. At one point I encountered exactly the same behaviour that itty2011 described – namely that the remote zone on the extender timed out after 144 seconds (112 in his/her case) and never restarted. However, I found that when I reset “All Options” and “All Station Data” on the extender the problem disappeared (note that I did not reset or restart the master). So I think the issue isn’t that the master is no longer issuing run commands, but that the extender is ignoring them for some reason. If I encounter this behaviour again I’ll try and investigate more thoroughly and won’t be so quick to “reset” things as that stopped the behaviour but eliminated the possibility of investigating further.
I’m assuming these remote run and stop commands are done using the /cm (Manual Station Run) API commands. The OS API documentation for 2.1.9 appears to be incorrect in that it states “An error code will return if you try to open a station that’s already running,” since I think no error code is issued but rather the station is restarted (including the master valve) if you issue it to a station that’s already running. I’ve been able to reproduce exactly the same behaviour I outlined in points 1 and 2 above using the /cm command.
With special station auto refresh OFF, everything is fine in that the master issues a run command (for the maximum of 64800 seconds or 18 hours) and then issues a stop command at the end of the programmed run time. However what’s not good is that if anything happens to prevent the extender from receiving the stop command, it’ll run the zone for the full 18 hours. I know that it isn’t likely, but if for example the master where to reboot (or lose the network connection, etc.) before issuing the stop command then that will result in a lot of water wastage (I live in Australia and this is a really dry country – water is very precious here). I’ve simulated that behaviour by restarting the master manually while a remote zone was running. Wouldn’t it be possible for the master to issue the run command for the programmed run time, as it’s a know quantity at the time the command is issued? For my own situation, this would be the perfect solution (I realise this may not be true for others).
Just for completeness I’ve appended a screenshot of the Timeline Log view on the extender showing two manual runs of a remote zone started from the master controller. The first instance shows a run with special station auto refresh ON, the second with it off, both for five minutes. As you can see, the flow sensor data looks like it’s captured the whole time, but the zone run time is truncated in the first instance.
I just wanted to say I think that OpenSprinkler is a fantastic product, much more capable than anything commercial I found. The flexibility it has (especially with the API, which I use to capture and analyse log data to track consumption and check for leaks, but which is capable of so much more) is really incredible.
