May 6, 2020 at 2:52 pm #65739
I have 2 OSPi running my system. I have a well pump set as a master valve on #1 controlling 3 zones and #2 connected to 8 zones around house. I have all zones for #2 set as remote zones on #1 with all control/programs running through #1. When i went to start system this spring, I found that #2 would not connect to internet. I found the sd card had failed and reinstalled everything on a new sd card and setup #2 again.
My problem is that #2 zones stop running after roughly 2 mins regardless of length of time set. For example, I set Sidewalk zone to run for 30 mins. On #1 it shows that it is set for 30 mins and zone starts. If i open up #2, it shows that sidewalk is on but scheduled for 2 mins. Time will end on #2 and the zone will typically turn off roughly 5-30 seconds later. If go back into #1, which is where the time was set, it will still show as running. Any ideas why this may be happening?May 6, 2020 at 2:56 pm #65781
If you set a controller as remote (in your case, #2), you should not be operating zones on that controller — instead, you should be operating those zones on the master controller. Basically, a remote controller should only passively listen to the master controller and you should not open zones on that remote controller directly.
The turning off is due to the master controller sending periodic signals to refresh the remote zones, to make sure they are in sync with what the master controller thinks their statuses are. If you don’t want that behavior, you can go to the master controller (#1 in your case), Settings -> Advanced -> and uncheck “Special Station Auto-Refresh”, so that the master controller will not send refreshing commands. However, I recommend you not do so because if you do that, the master controller and remote controller can be out of sync and it can be confusing.May 8, 2020 at 10:45 am #65816
Sorry if I wasn’t clear. I run all programs on the master controller. When i found that the zone was shutting off, I opened the remote controller to see if I had something set incorrectly and found that the station was set for 2 mins even though it was set for 30 mins on the master controller. Unchecking the “Special Station Auto-Refresh” appears to have solved the issue for now. As you mentioned, i would prefer to keep it checked if possible. Is it normal for the remote controller to show the zone set for only 2 mins? Now that “Special Station Auto-Refresh” is unchecked, the remote controller shows the zone is set for 18 hours. Is that normal?May 8, 2020 at 10:48 am #65833
Ok, I probably misunderstood the description in your first post. My guess is that it’s possible you have two remote zones which are pointing to the same zone on the remote controller. So if you set one of them to run, the other is not running, then the special station auto-refresh will cause the second one to turn off the remote zone after about 2 minutes. You should check through your remote zone settings and see if there might be a duplicate.
The 18 hours run time is normal: it’s the maximum run time allowed on any zone. The actual run time will be decided by the master controller — when the master controller sends a command to turn off that remote zone, it will be shut off. The reason to have a 18 hr maximum is such that in case master controller loses connection, it won’t leave the remote zone on indefinitely.May 9, 2020 at 8:15 am #65842
Just checked and all remotes zones on the master controller are pointing to different zone index on remote controller. I would think if that was the issue, the run time would still show as the time that was set on the master controller. In this case, its set for say 15 mins on the master and instantly shows as 2 mins on remote. I’m attaching a screenshot of the 2 side by side. The remote actually started for slightly less than 2 mins.
Attachments:May 9, 2020 at 8:16 am #65857
What’s the firmware version running on your master controller, and the remote controller respectively?May 11, 2020 at 10:02 am #65896
Both are running 2.17 (2)May 11, 2020 at 10:12 am #65914
OK, I checked the firmware code, and here is the logic:
– when special station auto refresh is turned on, the master controller sends a command to turn the remote zone on for 2*MAX_NUMBER_STATIONS seconds each time. As firmware 2.1.7 allows a maximum of 56 zones, this is about 2*56 = 112 seconds, so roughly 2 minutes. And every MAX_NUMBER_STATIONS seconds (56 in this case), the master controller send refreshing signals to renew the on time for another 112 seconds. This keeps the master controller and remote zone in sync as close as possible, so even if master controller loses connection to remote, the remote zone will remain on for no more than 112 seconds.
– when special station auto refresh is turned off, the master controller sends a one-time turn-on command to remote zone, to turn it on for the maximum number of time (about 18 hours), and will not send refreshing commands. It then sends turn-off command when the zone is scheduled to be turned off.
If you observe the remote zone turns off after 2 minutes, even if the corresponding zone on the master controller shows longer time, that means the master controller is not sending renew commands for some reason. I don’t know why, but my guess is that maybe it took master controller more than 112 seconds to cycle back and send renew commands — however, even in that case, I would expect it to again turn the remote zone on after some time. So basically I don’t know the reason, however, it sounds like keeping special station auto refresh option off resolves the issue.June 12, 2020 at 7:20 pm #66788
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.
- You must be logged in to reply to this topic.