Forum Replies Created
-
Posts
-
The high/low limit idea sounds interesting, but I agree that the tolerance issue would be my primary concern there. I’ve never experienced a blockage, but have experienced both a stuck open valve and a broken pipe, so my initial desire was simply for a functionality mention by Ryan (alert if zone(s) on but no flow, alert if no zone on and flow).
A few potential issues:
1. OS doesn’t currently appear to have any functionality for sending email. Not sure how much programming space adding this would consume.
2. How much potential system instability would be added by supporting email notifications? (i.e. what happens if email cannot be delivered immediately? What if remote email server is slow, or stops responding during some part of the email transaction? Sending email would require DNS lookups which may or may not work, may timeout, etc.). I would not want the stability of my irrigation controller to be adversely impacted by the addition of this functionality (although I definitely agree that it would be “nice to have”).
3. How much “leakage” do typical residential irrigation systems have (compared to the resolution of the flow meters)? I assume the systems aren’t 100% watertight, so may need a non-zero “all zones off” low flow threshold (similar to Comatose’s low pressure limit).
I don’t currently have a flow sensor (or the OS firmware supporting it), but it sounds like the flow data is only logged during zone operation, so there would be no information logged regarding item #3. Not sure if it would make any sense to add support for adding logging for some sort of min/max/avg value for this.
I’m not sure what else could be done to notify the user of a flow-related issue in the absence of email notification (if it were deemed too risky for whatever reason). The only thing I could think of with the current hardware would be to flash the backlight, but that is very likely to go unnoticed, as would a warning notice on the UI (as most people probably have the device mounted in some out-of-the-way location, and aren’t logging into the web interface every day).
Some sort of sounder/beeper/speaker could be added to the OS hardware which could perhaps alert the user to any sort of issue (flow-related, network connectivity, SD card full, etc.), and perhaps with the addition of “cloud” support, the email notification could be generated/handled from the “cloud” as opposed to the OS unit itself.
Great.
Will the “cloud” functionality (i.e. maintaining that persistent connection) be able to be disabled by the user?
I ran into this same situation (voltage read on all outputs even when off when system was not connected to valves), but luckily had previously read this thread so was not concerned. Might be something good to mention in the build directions, however, as it seems an “obvious” thing for people to try to test (and an unexpected result).
I’ve just finished building my OpenSprinkler system, but my previous controller provided per-minute granularity and (I think) 2-digit range (00-99). For my specific use, 6-80 minutes in one-minute increments would suffice, so options 1 or 3 would work, 2 would not.
Regarding the recently-discussed issue of units on the per-station times, what about setting the units at the zone level as opposed to the program level? (from what I can tell, the previous discussion has been centered on including this information at the program level).
That way, users have the flexibility of selecting hours/minutes/seconds for each zone, but you can represent the actual durations in the programs themselves in a single byte (0-255 of the selected unit). Note that the “units” could certainly follow the options mentioned in the first post (and not necessarily just H/M/S).
