Possible to add control of a 'slave' opensprinkler?

[brucep]

Hi,

Is it possible to add a feature where a slave opensprinkler can be controlled as a virtual expansion module? that way programming and timing can be controlled from a central unit. I was thinking along the lines of setting a static ip for a slave unit, and have the master unit send commands to the slave outputs when necessary. At the moment I run 3 units which, for geographical reasons are not able to be wired as simple expansion outputs from a central unit, but the locations are all covered by my outdoor wirless network. (I messed around with two 8 Channel RF systems, but reliability was not great).  It would be nice to be able to manage everything from one IP address.

Any advice, or help appreciated.

Thanks,

Bruce

[Ray]

I’ve actually thought about this before and it’s definitely possible. Because OpenSprinkler uses HTTP GET commands, to trigger a valve on another controller you just need to send a GET command to the other controller. The firmware always send GET commands to the opensprinkler cloud server to query weather, so in theory there is no technical barrier. Specially, you can define any station as a remote station (by giving it’s ip address and station index). Of course this will require changing the firmware code, and for the moment we can use the station name to provide the ip address and station index (just like how RF stations use the station name to encode the RF signal).

I don’t think we have time to fit this into the upcoming firmware 2.1.4, but it should definitely be considered for future updates.

By the way, you mentioned that the RF system is not very reliable. One thing I should mention is that I’ve found a few cases where you need to tweak the signal timing a little bit, especially if you have the more recent OS 2.2 or 2.3 (which uses 16MHz clock). Specifically, check the last 4 digits of the HEX code, and try to increase that to see if it improves reliability. Those 4 digits define the signal timing used for RF signals. It is scaled (75%) internally by the firmware to account for processing overhead. However, since 2.2 and 2.3 use faster mcu clock, the processing overhead is likely smaller so you need to increase the timing data to counter-act the scaling. In the future we really need to add a self-calibration procedure to measure the processing overhead more accurately.

[Author]

Posts