2018 Jan 17, 07:13 PM
Well, thats almost the same I want to do.
In our region there is plenty of water but the requirement on one part of the garden can be totally different from another part of the garden. This all is due to the weather of the past days, the time of year (sun high in summer or low in spring/autum), wind and so on.
Ideally I want moisture measurement for every station and combined with other weather data make a descision if and how long the station must be turned on. Additionally some level of autolearning should also be possible. So the way SIP works now it isn't suitable to do this. Don't get me wrong, I'm still happy with SIP the way it is now. :-)
At the moment I'm optimising the MQTT plugins so that connectivity/availability of the broker is more failsafe. Within my test environment this is working fine now. I also implemented a hearbeat signal which can trigger every plugin once a minute so the plugin can do some houskeeping if nessecary.
The next step is to enhance the MQTT plugin so that additional (sensor)data or commands can be received. This is quite easy to incorporate but the biggest question is "what to do with this data?" There must be a kind of logic with some configurable rule engine so that the enduser of SIP can create the required if-then-else logic. I already experimented with some stuff like Node-red, Blockly and Domoticz that I already have running for other purposes.
Maybe we should start a feature request conversation to first get the functional requirements clear and after that think of a possible solution. Any thoughts on this are welcome of course.
To be continued...
--Gerard
In our region there is plenty of water but the requirement on one part of the garden can be totally different from another part of the garden. This all is due to the weather of the past days, the time of year (sun high in summer or low in spring/autum), wind and so on.
Ideally I want moisture measurement for every station and combined with other weather data make a descision if and how long the station must be turned on. Additionally some level of autolearning should also be possible. So the way SIP works now it isn't suitable to do this. Don't get me wrong, I'm still happy with SIP the way it is now. :-)
At the moment I'm optimising the MQTT plugins so that connectivity/availability of the broker is more failsafe. Within my test environment this is working fine now. I also implemented a hearbeat signal which can trigger every plugin once a minute so the plugin can do some houskeeping if nessecary.
The next step is to enhance the MQTT plugin so that additional (sensor)data or commands can be received. This is quite easy to incorporate but the biggest question is "what to do with this data?" There must be a kind of logic with some configurable rule engine so that the enduser of SIP can create the required if-then-else logic. I already experimented with some stuff like Node-red, Blockly and Domoticz that I already have running for other purposes.
Maybe we should start a feature request conversation to first get the functional requirements clear and after that think of a possible solution. Any thoughts on this are welcome of course.
To be continued...
--Gerard