Charmed Quark Systems, Ltd. - Support Forums and Community
Class: Irrigation - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (
+-- Forum: General Discussion (
+--- Forum: Device Classification (
+--- Thread: Class: Irrigation (/showthread.php?tid=8308)

Class: Irrigation - Dean Roddey - 05-01-2013

This thread is for discussion of the Irrigation device class. This is probably not any sort of high level irrigation scheduling type device, but more low level for core irrigation control, such as would be under the control of some other scheduling entity.

[to be done]

Class: Irrigation - Dean Roddey - 05-01-2013

(reserved for expansion)

Class: Irrigation - Dean Roddey - 05-01-2013

(reserved for expansion 2)

Class: Irrigation - Dean Roddey - 05-04-2013

This is one where I'm fairly lost at sea. Any suggestions about what this one might include? Could it be sufficient to then allow something like the generic irrigation scheduler to work in terms of such an interface? I guess that wouldn't be the case, given that it probably has to control non-dedicated irrigation control hardware.

But, anyhoo, is there anything that could actually be generically said about irrigation controllers? Or could they effectively be covered by the Relay class for all intents and purposes?

Class: Irrigation - Dean Roddey - 01-27-2015

Once again, before I start on the Irrigation Caddy driver, is there any reasonable abstraction we can define for an irrigation controller? It can't just be that it's a set of zones that can be turned off and on, since in many cases that will be done via a device that isn't itself an irrigation controller but just a relay device.

But is there any functionality that would be useful to define in terms of an irrigation controller itself that would provide useful semantic information and which would be pretty much universally supported amongst such devices? If not, I'll just make the caddy outputs be relay fields and be done with it.

Class: Irrigation - dgage - 01-27-2015

I'm at a blank right now but I'll think about it. I would suggest looking at jkish's Generic Irrigation Driver for some thoughts as he put in some goodies like weather and evapotranspiration features. That may be a good place to start to get some ideas.

Class: Irrigation - Dean Roddey - 01-28-2015

That type of stuff would really still want to live at a higher level, at maybe a 'sprinkler manager' level, not really at the driver level probably, because it will have to necessarily pull in information from various places. Ultimately we'll get his sprinkler driver thingie converted over to the new Event Monitor system, where it will be much more efficient and better able to do its job.

Class: Irrigation - jaydonoghue - 01-28-2015

Not sure if this is the wrong abstraction level or not.. But some things that may make sense

-Current status (running, stopped, bypassed)
-System Bypassed Yes/No (from rain sensor or other)
-List of Sensors with some parameters
- - Current Status On/Off
- - Name
- - Next run time
-List of Schedules / Program
- - Running/NotRunning
- - Enabled/Disabled
- - Some details about the program (may vary wildly between vendors?)

Class: Irrigation - Dean Roddey - 01-28-2015

The gotcha with things like the individual zones is that all too often those will not be an actual irrigation controller, but just some relays. So any higher level manager won't ever be able to assume that, at the individual zone on/off type level that it's dealing with a formal irrigation controller.

Schedules make more sense if we are talking about something that really is specific to the irrigation controller, but as you say, I'm not too sure if we can find any commonality. And, I guess, from the perspective of trying to provide some sort of standardized interface for a higher level controller, the built in schedules may be of no interest since it would be providing the schedule itself (since it has to work with smart and non-smart irrigation systems.)