September 8, 2017 at 2:42 am #47619
I’m making use of some WiFi HTTP remote stations to switch various items around the plot where it is difficult to reach with a hardwired cable from the Opensprinkler master or expansion unit.
With the firmware feature repeating remote HTTP on and off commands the remote stations has been working very well.
However, I have had a few occasions lately where we experience power failures to the Opensprinkler master unit, but not at the remote station as they are fed from a different source of supply.
Losing power to the main unit when a remote station is active and due to be switched off, creates issues with station being active when they are suppose to be inactive.
Would it be possible to add to the Opensprinkler API a field for the remaining running time of a station.
By being able to send or read the remaining running time of a station, some additional safety features can be built into remote WiFi HTTP stations.
If the remote WiFi HTTP station where able to receive the remaining running time it would be able to switch the station off in the event of a loss of WiFi signal.September 17, 2017 at 1:24 pm #47716
Mike, I did the HTTP Station function as a fairly simple extension of existing code to provide basic support for off-the-shelf http devices. As you say there is no way to specify dynamic on/off commands. What you would need is some kind of meta_tag that could be specified in the on/off command fields but substituted live at time of sending (i.e. $time_remaining or $off_time). This would get tricky real quick as you would need to support multiple variables and formats based on whatever the remote device wanted (e.g. relative time in seconds vs minutes or perhaps an absolute time in a particular ISO format). A great feature but probably not high up on anyone’s list I suspect. Cheers, PeteSeptember 18, 2017 at 9:51 am #47779
I am not entirely sure if I understand the request. But let me first explain how the remote station feature is implemented, hopefully this will clarify some of the details. Basically the remote station (same as RF station) is implemented by sending HTTP commands to the remote stations. The question is what’s the duration that should be sent to the remote stations. Because the feature is implemented at a fairly low level (in the solenoid activation functions), it does not know the exact water time scheduled. This is done to make the remote station work just like a physically connected stations — when the master controller tells it to turn on, it turns on, and the ‘turn-on’ action should not need to provide a timer.
For reliability reasons, the firmware has a ‘special station auto-refresh’ flag. If checked, this turns on a remote station for only about 2 minutes at a time, and the master controller must renew the turn on command to keep the remote station running. This way, if the WiFi signal is lost, the remote station will not remain on for more than 2 minutes, to avoid it being left on indefinitely. As a result, if you try to read the remaining water time from the remote station, it won’t be more than 2 minutes.
The exception is when the ‘special station auto-refresh’ is turned off. In this case, the master controller won’t renew the turn-on command, and so each time it turns on the remote station, it will use the maximum water time (18 hours), and then the remote station will be turned-off whenever the master controller sends a turn-off command. This is useful sometimes if you don’t want the master controller to keep sending refreshing commands, but the danger of doing so would be to leave the remote station on for a long time (up to 18 hours) if the master controller loses connection to the remote station.
In short summary, the remote station doesn’t know the exact water time because the feature is implemented at very low level and does not know the water time; keeping the auto-refresh on will resolve the reliability issue.
- You must be logged in to reply to this topic.