ok, noizzle_head vs. zone_head fixed, must be zone_noizzle_head - you found the first bug
Now, we need to device on the channels to implement. I mentioned the API properties in post no. 14 - see above. The API provides much more that I currently implemented, but I donāt see the need for tons of channels. Provide feedback on what you like to see.
The API provides the option to register a callback. This would be much more efficient that polling. However, the problem is that this link has to be configured in the binding and it must be rachable from the internet = it requires router config (some kind of port forwarding). Does that makes sense?
pro: Rachio informs actively, you get near-real time updates (e.g. when a zone is running, a schedule is started etc - like with the App)
contra: Setup is much more complicated
Your opinion?
If you want give it a try I could enable the control functions like on/off, stop watering. I havenāt tested them, so not sure what happens.
With regards to the API and providing updates I like itā¦I would want to see what is required to open up port wise but I think we all have come to expect near immediate updates in OpenHab and would feel lost without them.
I agree that there are currently too many channels that really donāt provide information that is needed within a home automation system. For example the nozzle type, nozzle image url etc.
In regards to control, what does the channel āZone Runā do? Itās listed as a switch so I assumed I could turn that zone on or off by engaging that switch?
To me a great feature would be to be able to control zones and specify a time. When my wife asks me to turn the Rosebed on for 5 minutesā¦thatās what Iād like to be able to do.
Iād also like to see notifications of when a SKIP has been scheduled.
To get those events I need to register a webhook to the API. Something like http://myopenhab.mydomain.com:10000/rachio. This would call the bindingās web service on port 10.000. a) you need a dynamic DNS service (supposing not everyone has a fixed IP) and the router has to to a port forwarding to your OH device. I stopped implementation, because of this. Maybe a combined approach makes sense: A poll every x min + event driven when configured. With this events are preferred, and polling would be the fallback for people who donāt want to struggle with the router setup. In fact I donāt like to open my router from the Internet, so?
Having the zones image url allows building nice dashboards including a pic of the zone (like the app does). Information on the head give some options on implementing your own logic (calculations).
Yes, I already plan to start a zone immediately. The switch would be something like ārun zone for xx sec fixā (configurable static value), the regular run channel triggers a zone when the value changes. So something like zone1_run.sendCommand(600) to start a 600sec watering. I included the Switch only, because this is accessible in the PaperUI->Control oder in a habPanel.
What do you think?
Create a list of channels you donāt need and those you want to see (based on whatās available in the API). Iāll continue to implement the status update, so we see moving numbers at least once per min or so (event would be an optimization to that).
I want to help this effort so thank you so far although my controller is currently turned off for the winter so need to turn that on again before I can start!
I implemented the dynamic update of the channels (currently based on polling), but have problems with the control functions. the http post fails and I donāt know why, but itās an upcoming weekend
enable/disable is the active switch; disabling the devi device means: hold all schedules, stop watering etc
the represents the standby switch in the appās devixe settung
the zone run switch uses the following logic
when runTime is > 0 the zone will be started for runTime secs
if runTime = 0 then the default is taken, you can set this in the bridge config (defaultRuntime), default is 120sec
when a zone is running it can only be stopped on tge device level. This stops all zones.
the app allows to start multiple zones at the same time, Iām not sure if it provides a value by supporting that
Hi @KidSquid, I uploaded a new jar to dropbox. This version does not contain your apikey, but that should be fine, because you already discovered the things.
This build fixes the control functions and updates channel properties on a polling basis. Polling interval can be configured in the bridge thing definition (pollingInterval=n). So when turning active to off you should see the controller becoming standby mode in the app etc.
Could you please verify the functions with you controller. Thx
you should have
1 thing for the bridge
1 thing for the controller (with its own channels)
8 zone things
the bridge supports more than 1 controller (in my case 2). The final version might support multiple bridges (one per apikey), but thatās currentl out of scope
