Ecobee set program hold

I’m looking into using the Ecobee binding to change the comfort profile until the next timed setting and can’t see which command I need to use. Basically I want to change to profile “myprofile” until the next transition.
Can someone advise me which parameter I need to add to an item to do this?

Hi Kevin,

Setting a hold in Ecobee requires the use of the ecobeeSetHold action (and the Ecobee action and binding bundles that are in the nightly Cloudbees builds or ones I shared earlier).

I have an unfinished wiki page that has an example of how to do that. The remaining ingredient is to know the holdClimateRef for your custom comfort setting. Every comfort setting has a readable name (like “Sleep”) and also a unique reference name (like “sleep”). For your custom comfort settings, Ecobee generates a unique reference for it like “smart1”, “smart2”, etc. You can find your ref name by editing your “myprofile” at and looking in the URL address bar of the browser for its unique reference name.

Using my example in the wiki, your ecobeeSetHold action call would look something like this:

ecobeeSetHold(SomeEcobeeItem, null, null, "smart1", null, null, "nextTransition", null)

Thanks very much indeed, I’ll get into it over the weekend and let you know how I get on. It’s being used in a rule and the logic is getting forever complicated in my quest to get it to securely and reliably use my location to enhance comfort whilst saving power.
Sent from my iPhone

Good luck, and let me know if you hit any bumps I can help with. I am also trying to zero in on reliable location logic, and there are many angles of attack.

I’ve just added the rule and added the latest org.openhab.action.ecobee-1.8.0-SNAPSHOT and org.openhab.binding.ecobee-1.8.0-SNAPSHOT to the addons folder, as well as added the rule and updated the designer.
I can now control the thermostat however it does things that I wasn’t expecting.
1)Setting a hold item holds that setting indefinitely - can this be changed to hold until next transition which is what I would prefer?
2)The comfort setting retrieved from the thermostat doesn’t change when I change the comfort setting with the binding even if a schedule event from ecobee happens during the hold (I use this in rules to validate what I’m doing)

My idea is to use presence information to tweak what the schedule was doing. I can overlay a schedule in openhab of course but it adds an extra layer of complication.

Hi Kevin,

  1. Please see my example above (next to last null parameter should be "nextTransition".

  2. program.currentClimateRef will only show you what’s supposed to be now running on the weekly program guide at the moment, kind of like the TV program listings they print in the newspaper (if they still do that). When you set a hold, it’s an unplanned variation from the program, so it won’t show under program.currentClimateRef. But you might have luck looking at the events[0].holdClimateRef property.

Hi John?
Thanks very much for your help, that will give me great flexibility and I’ll take a look at it tomorrow. I thought there would be a way.

Hi John

I’ve added “nextTransition” which works, as does the holding climate ref, albeit it only displays anything when its on hold.

Do you think its possible to add a change to “heating / cooling /off” mode action as well as a temperature up / down button? This binding seems to be working better than the ecobee app for day to day use so far!

One other thing, using the windows designer I was using before the action bundle - V1.8 nightly build from 12/8/15 works well apart from it doesn’t understand the ecobee action commands, and now that I’ve edited a couple of them won’t open the rule file. Using the one I downloaded recently results in many errors showing up in the code at random, so I’ve reverted to the earlier one, using notepad++ to edit the rule file with the ecobee actions in it. Should I start a separate thread about this?

Thanks again for your help

Hi Kevin,

Glad you have things working. You can change the heat/cool/auto/off modes by sending the proper command or update to an item bound to settings.hvacMode.

You can use a sitemap Setpoint and a rule to send off ecobeeSetHold action calls for up/down temperature holds.

You have to have openHAB 1.7.1 runtime or nightly plus nightly binding/action bundles for Ecobee (or more recent than what you are using) for openHAB Designer to recognise the Ecobee actions. If updating all of these to after their merged PRs for showing actions in Designer doesn’t work for you, then yes please open a new topic.



Hi John,

settings.hvacmode added and working - thanks yet again! The sitemap Setpoint may take a little longer to develop so I’ll keep it at the back of my mind for now.

On a different subject, how does one get a binding developed? I have Sensibo devices controlling my other HeatPumps and when they open up their API I’d like to get them included. Currently I use IFTTT to connect to them but its limited in what it can do. Unfortunately I don’t have the programming knowledge to develop the binding myself.



It depends on what kind of API Sensibo exposes. Ideally, you could use the HTTP or other “generic” binding, but what they expose may not work that way. If a true binding is needed, if i were you I would post a new topic here and perhaps other places to see if there is interest from a Sensibo user to develop a binding. But if the API is not yet available, it’s still hypothetical about what’s needed and what’s possible.

I’ve requested an access code so will report back once I’ve got one.

Moving onto Ecobee, it failed this morning the first time I sent it a command, then when I discovered nothing had happened I sent it again and it went through. Is this likely just something it does and I need to put in a check for hold status change and add send again logic if it doesn’t? Looking at the log times I think the command either was ignored when it was sent and no error was given or it disappeared into a hole OR after a minutes timeout the binding returned an error? Presumably sending the same command twice won’t have any adverse effects if I only do it when I suspect it hasn’t worked?

2015-09-08 07:19:07.314 [INFO ] [hab.model.script.HouseHeatpump] - received command wakeup - I DON’T THINK THIS ONE DID ANYTHING
2015-09-08 07:20:01.037 [WARN ] [] - Method failed: HTTP/1.1 500 Internal Server Error
2015-09-08 07:20:01.041 [ERROR] [.ecobee.internal.EcobeeBinding] - Authentication failed. Unexpected error. Contact support.
2015-09-08 07:20:29.434 [INFO ] [hab.model.script.HouseHeatpump] - received command wakeup - THIS ONE WORKED

Very, very rarely I’ve seen “Authentication failed. Unexpected error. Contact support” on a regular poll and it recovers on the next poll. Maybe 2-3 times total. If you set the binding to DEBUG or (better yet TRACE) logging level and try again, there might be more context to see if there is anything in the binding or action bundle to address this. Hopefully this can be reproduced.

The message “Method failed: HTTP/1.1 500 Internal Server Error” occurs when tokens expire and need to be refreshed, so that’s usually normal.

You could also check to see if the ecobeeSetHold action returns true (success) or false (failed).

How can I turn on TRACE exactly for only the ecobee binding? Presumably something in logback, but what (newbie alert!)? I’ll then run it for a few hours and look to see what I can find.

Hi Kevin,

You can either send it all to an ecobee.log file like in the wiki, or just add

<logger name="org.openhab.binding.ecobee" level="TRACE" />

to logback.xml in order to send TRACE logging to openhab.log.

Hi John,
after seeing how much information it gives in the main log I’ve now given it one of its own. Will let you know what I find

I’ve taken a look at the trace log and discovered it was querying the ecobee servers every minute when I should have been every 3 minutes. Since changing that the communication error causing stack dumps have come down from 28 in 16 hours to 1 in 10 hours so that looks like one problem held over from V1.7 that I may have fixed, although the 10 hours have coincided with the middle of the night in the Northern Hemisphere, so I need a few more hours before I can be sure.
The automatic profile changing rules are now almost perfected too Further updates in a few hours.

Several hours on and sadly the stack dumps haven’t completely gone away. Part of the problem it seems is due to server load, and some happened when commands were issued. Would you like to take a look at the logfile post 3min polling?

What stack traces in which log file? Do you think that they may signal a bug in the binding, as opposed to network or API server issues? If the former, please share the stack traces that you are concerned about. Thanks!

The stack traces in the full logging I turned on for the binding recently.
I’ve just taken a look at the recent stack traces - 9 in 11 hours and think they may just be communication failures, most happened in the middle of the night here so they are likely nothing to do with the action bundle. The binding seems well behaved, and the action bundle seems to be working well controlling the stat.I guess I’ll have to live with the communication failures!