elionce Posted September 24, 2018 Posted September 24, 2018 I'm using my ISY as a controller for my sprinklers (via EZFlora/EZRain). I've been having some issues where sometimes (but very rarely) the EZFlora doesn't receive an on/off command, which may leave one of the sprinkler lines running (if it was a missed OFF), or skip one of the lines (if it was a missed ON). I've tried replacing the EZRain itself, as well as installing more dual-band devices as close to the EZRain as possible in hopes of "boosting" signal redundancy - but presumably due to its distance in the back yard, I can't seem to get it totally 100% reliable. For instance, if I just try to toggle one of the lines off & on repeatedly, it may work 30 times in a row, but then the 31st it won't, and if I have the ISY java panel up, it'll show an "error communicating" dialog. Then if I try once more, it works & the java panel shows that it's again connected. Currently, my sprinkler programs are just: Send on command wait x minutes Send off command I'd thought about adding some redundancy by doing something simple like Send on command Wait 5 seconds Send on command again Wait x minutes Send off command Wait 5 seconds Send off command again ...So that each on or off command would be sent twice, in case there's a communication error - but before I do so, was wondering if there might be a more elegant or suggested way to i.e. have the program actually check if the command worked, and retry if it didn't (rather than just brute-force doubling up each command). Or would this simple double-command approach be a good way to hopefully resolve those few 'missed command' situations? Thanks in advance!
oberkc Posted September 24, 2018 Posted September 24, 2018 I would probably stick with the redundant approach. Oftentimes during communication difficulties, status is assumed and can be incorrect. Perhaps you could query each, then resend an ON command for those not responding, but I think your approach seems simpler to me.
elionce Posted September 24, 2018 Author Posted September 24, 2018 Cool, thanks for the feedback. That's pretty much what I thought, but just wanted to make sure I wasn't overlooking something obvious (i.e. maybe an actual built-in way to have it confirm status before proceeding, etc) :)
Recommended Posts