Ecobee: update values when a command sent?

Is it possible to have the Ecobee binding pull an update from their servers when a command is sent?
For example could the manual temperature up and down value be populated after a resume event by requesting a status update from the server rather than waiting for the regular 4 minute polling interval?
Apologies if the binding has been already updated to do this - it’s all been working well so I’ve left it alone.

I’ve been thinking how to do this reliably and without too much disruption to the code. I will try a change and report back in a few days.

Thanks - happy to help with testing too

I have one attempt at this enhancement done. Please replace your current Ecobee binding JAR with this one, fully stop and restart openHAB runtime, and try to either send commands, update state or perform action calls in rules to Ecobee-bound items. Between about 6-11 seconds after a successful update, command or action call, the binding should poll for new updates, and then return to the configured (or default 3-minute) polling cycle.

This test binding supports a new optional configuration setting in openhab.cfg:

ecobee:quickpoll=6000

This defines how long to wait after any of the above update/command/action is performed. Note, however, that the granularity of checking is hardcoded to 5000ms, so the poll will happen more like around 10 seconds after the successful update/command/action.

Please give me your candid feedback on this approach, and thanks!

John

Update: The pull request for this change is here. I also added an optional ecobee:granularity config option to override the default 5-second rate at which the binding checks if it’s time to poll the API.

Testing time today is limited but initial thoughts are its way better in the usability stakes. Only tried a simple home hold from the ecobee app followed a couple of minutes later by an away hold from openhab. The hold status in openhab as well as the manual temperature override with the correct hold values appeared very quickly compared to before when using openhab to set the away hold. Will test more in the next 24 hours and let you know. This is without any extra settings in openhab.cfg which I will add later.
Thanks again for adding to this feature rich binding!

Please report back to this thread when you have any more feedback and thanks!

Tested again yesterday on cooling after doing a small hardware mod to make Ecobee play nicer with my Mitsubishi Electric Heatpump. Again the binding is a vast improvement in terms of usability. It took around 10 seconds for the change from “away hold” to “home” to be reflected back into the Openhab Mobile App so I might experiment with the additional settings to bring that down a little.

The reason it took about 10 seconds is because the binding now checks every 5 seconds if it’s time to poll again (default ecobee:granularity=5000), and it will wait no less than 6 seconds after sending a change (ecobee:quickpoll=6000). I made ecobee:granularity 5000ms because I don’t want the binding waking up constantly to check if it’s time to poll, but you could set it to a lower value to get closer to the ecobee:quickpoll value. You could also lower the ecobee:quickpoll value. Setting either value too low could result in either the binding waking up too often and affecting overall openHAB performance, or requesting a poll too soon after the change so it’s not reflected yet in the data that comes back from the poll. A busy API server or network slowness could result in the change not being reflected in the quick poll, and then it won’t be until the next normal poll (ecobee:refresh) which by default isn’t for another 3 minutes (180000ms).

Please let me know what values you settle into, thanks!

1 Like

So far down to
ecobee:granularity=3400
ecobee:quickpoll=2600
although it still seems to take around the same time for changes to show. No problems with missing updates or system slowness, will experiment further and actually time how long it takes the changes to show up.

Thank you for reporting your experiences, Kevin. It seems strange that setting a hold would not be reflected sooner with those settings. Did you get a more recent JAR than the first one I put at the link? (The most recent is still about a week old.) I look forward to more observations.