I’ve been reading this thread with interest and I have a quick question for Tron. After you’ve set a hold, do you have any provision for cancelling the hold and going back to the scheduled setpoints? Or do you just let the ecobee do this automatically when it hits it’s next scheduled setpoint?
Cheers
There are multiple options in the setHold action API. You can set an indefinite hold, or you can set the hold so that it cancels using a variety of events (next transition, number of hours, start/end date, etc.).
Alternatively, you could cancel the hold using a rule that invokes the resumeProgram action API based on whatever you want to trigger the rule.
Hi Joe,
The latter. That is what the "nextTransition" is for. That only keeps the hold active until the next scheduled change occurs.
I actually rather rarely change my setpoints at all, but when I do, I want them not to interfere with the schedule. For instance, if I do feel cold, I may raise the temperature a bit, but still want the thermostat to go into low-temperature night mode when I go to bed.
But there is a resumeProgram action you can use to clear all holds. (Edit: Mark already answered that while I was typing)
Hello,
I noticed on the datetime channels (such as “runtime#lastModified”), the datetime returned to an item is in UTC, but the time zone offset is incorrectly set to my local time zone.
For example, it is now 08:00:00 at my local time (UTC -6). The lastModified channel has just received an update, and it returned a time of 14:00:00. However, the item linked to this channel has a time of 14:00:00-0600, when it should be either 14:00:00-0000 or 08:00:00-0600. Is there a setting I need to change to have this corrected?
Thanks in advance!
I’ll need to take a look at this.
Is this happening consistently on all the datetime channels? It might be a bug in how the binding is handling the date/time returned from Ecobee.
Thanks, Mark!
I have not checked this on all datetime channels, but I do use the following 2 channels for my project. I can confirm the datetime returned to an item is in UTC, and offset to my local time zone.
info#lastModified
runtime#lastModified
You can see from the screenshot below that my current local time is Dec 25 at 11:25 AM with a -0600 time zone offset. My runtime_lastModified channel returned Dec 25 at 5:23 pm, but also with a -0600 time zone offset.
I actually have noticed this behavior quite some time ago (may be a year?), but got distracted and didn’t have a chance to mention it on the post.
Thanks again!!
Thanks.
Yeah, I definitely think it’s a bug in the binding. I’ll take a look at what I might be doing wrong.
I should have some more time to devote to development after the start of the new year. 2022 was unusually busy with a bunch of other stuff.
Thanks for reporting.
Thank you Mark!
@jakdock FYI today I submitted a PR that should fix this. When merged, it will become part of 4.0.
Hi everyone!
I have a small issue with ecobee that I’m hoping someone can help. I’m using OH3 and EB binding 3.1.
In the openhab ui, I’ve discovered ecobee, and it is reporting the temperatures in celsius.
However, when I create the following in my items file (based on posts above)
Number MF_runtime_actualTemperature “Actual Temperature [%.1f °C]” (gMFRuntime, Group_HabPanel_Dashboard) { channel=“ecobee:thermostat:XXXXX:runtime#actualTemperature” }
MF_runtime_actualTemperature show 93 degrees whereas
ecobee:thermostat:XXXXX:runtime#actualTemperature shows 22.77777777777778 °C degrees.
Why is the C being converted to F? The when I try to use the habpanel widget it either shows 93 degree celsius (due to the use celsius flag) or if I select the value that is in celsius than the widget shows in very large font:
{{%.1f’ | sprintf:itemValue(config.temperature)}}
I’m guessing that is because there are too many decimals, but could be mistaken. Any help would be appreciated.
one thing to add, I’ve just noticeed the variable ecobee:thermostat:XXXXX:runtime#actualTemperature is holding not just the number, but also the text °C. So 22.77777777777778 °C.
I’ll need to see tonight at home how I configured it, but I’m in the Fahrenheit realm, and I think you want it to be in Celsius.
Have you tried to use “Number:Temperature” instead of “Number”?
That should choose the unit depending on what your OH installation is set to.
Yes, this.
The Ecobee API returns temperature values in Imperial units. So when the binding updates the runtime#actualTemperature channel, it does so in degrees F. If your system is set to Metric, and you define the item as Number:Temperature as @Tron suggests, OH should do the conversion to degrees C automatically.
Thank you both for the quick response!
That switched things over to Celsius for me 
One more questions if you don’t mind. If the widget’s option for “Use Celsius?” is populated it produces:
{{%.1f’ | sprintf:itemValue(config.temperature)}}
If the value is not populated, then where the current temperature should be, it is just not displayed. Any thoughts on why this may be? (The degree and holding box is also missing the temp)
I’m currently not sure which widget you mean.
Are you talking about a sitemap?
sorry, should have mentioned, HABPanel, Ecobee widget as well as the fork by Singal11, both have the same result.
Sorry, can’t help you there, the basic sitemaps are all I need.
But have you tried to build one and see what that shows?
I think there’s a default one you can modify.
No, not really.
