Ecobee binding v2

Very strange. I’ve not seen anything like this before. Was it just the runtime channels that weren’t being updated?

Other things like occupancy and equipment status were updating. It was just the temperatures oddly. I’ll keep an eye on it and see if it keeps doing this.

There’s only one condition I can think of that could cause the runtime data to not update, and that’s if the binding didn’t request the runtime data from the Ecobee API. The only way that can happen is if the binding thinks there are no items linked to any of the runtime channels. Given your item definitions above, the likelihood of that happening seems to be nil. I’m officially stumped on this one.

BTW, what version of OH are you running?

Yeah I didn’t post it, but I can see the gigantic json come back with all the temperature data periodically. I’d say it is getting there.

In this moment, I have M2 with M4 addons running because of https://github.com/openhab/openhab-core/issues/1852 but I’ve been bouncing around over the past week or so to do traces.

Hmm. If the runtime object is coming back in the json (and yes it is gigantic lol), then this test would fail and the runtime channels would be updated.

Curious to know if anyone has reauthorized yet. If so, how was the experience?

I just did it this morning. It went very well and almost directly according to the README you linked earlier. The biggest challenge I had was that as I’m still on 2.5.10, I had to download your jar and put it into the proper add-ons directory. Once I did that, I had to go into the Karaf console and bundle:uninstall the old one and restart. In doing so, it added back the included ecobee bundle from 2.5.10 and the new one from add-ons. I had to go into the console and remove the original again, restart again, and then I was able to pick the proper pin code from the logs (otherwise I was getting two and I couldn’t differentiate which one was for the new version). Thanks again for staying ahead of this and your hard work, it’s appreciated!

Thanks for the feedback @liko.

Yeah, since 2.5.11 isn’t out yet, the new binding needs to be pulled from Jenkins. So, as a reminder to others on 2.5.x, it’s important to make sure the old binding is uninstalled before dropping the new jar into addons. I don’t think I made this step as clear as necessary in the README.

@mhilbush appreciate your hard work on this.

Just migrated my very old OH 1.x binding to your latest update (a pain in the neck since I had to refactor all the rules and bring them up to date, but that’s not related to the security update)

Worked like a charm! Thanks!!!

I’m having a hard time with the re-authorization process. The other day I noticed that I was getting an “invalid grant” fail at token refresh. Assuming this was something to do with the API change, I uninstalled the 2.5.10 addon via paperUI, and manually added the new 2.5.11 file and restarted openHAB.

I removed the app from the “MyApps” section of the ecobee portal, but when I went to add it back in, I realized that I can’t find the PIN anywhere. It’s not in the logs, nor is it in the “thing” for my ecobee account.

The logs now contain the same token refresh error. plus a line that says “API: Received invalid_grant error response. User needs to reauthorize with Ecobee”.

The “thing” for my ecobee account says “Status: OFFLINE - CONFIGURATION_PENDING Checking authorization”, but there’s no PIN.

I’m probably missing something simple. How do get it to generate a new PIN?

Sorry you’re running into trouble.

Here are a couple suggestions:

  • restart openHAB and hopefully it will go through the PIN process

If that doesn’t work, try this (note if you use OAuth for another binding, you’ll need to reauthorize that binding too):

  • stop openHAB
  • in the userdata/jsondb directory delete StorageHandler.For.OAuthClientService.json as well as the NNNNNNNNNNNN--StorageHandler.For.OAuthClientService.json files in the userdata/jsondb/backup directory
  • start openHAB

Just for some feedback. I’m pretty sure ecobee forced me to reauth today when I restarted OH. I saw the message in the events of “Enter Pin (ABCD-EFGH)…”. The original key it gave me didn’t work. I had to destroy my old app, restart OH, get a new PIN, and enter it on the site. The StorageHandler file was totally non-existant so I didn’t have to delete it. That said, it’s all working now so no complaints here!

Interesting. They said existing authorizations would continue to work, but they didn’t say for how long? I wonder if anyone else has run into this.

Not really. I did a manual re-authentication according to the README, to be sure. That worked flawlessly.

1 Like

Wanted to share my experience. Woke up this morning to the invalid_grant error. So I did the following as suggested:

  1. Downloaded the 2.5.11 jar file from Jenkins
  2. Uninstalled the Ecobee binding using PaperUI
  3. Dropped the new jar file into the OH2 addons folder
  4. I immediately checked the logs and saw the new PIN
  5. Went over to Ecobee.com and Removed the existing OH2 app
  6. Created a new app, entering the new PIN.
  7. Back in business. No issues whatsoever.

Thank you!

1 Like

I had the same problem with my Ecobee. I just logged on to the Ecobee website. It sent a code to my phone that I entered on the Ecobee web page. Then it let me into my account. I then looked at my Openhab log and saw that all my ecobee data was updating. I believe the web site indicated that it was only good for a month.

Actually using V2.5.11

Thanks to much reading on OpenHAB community, I am quite happy with the new V2 binding after porting all my existing ecobee stuff from V1.9 but I am struggling with a simple action to change the Hold value of my thermostat.

I want to compute a new setpoint based on the actual runtime desired heat.

Items:

Number:Temperature runtime_desiredHeat "Température désirée  [%.1f °C]"  <temperature> (Thermo) { channel="ecobee:thermostat:account:xxxxxxxxxxxxx:runtime#desiredHeat" }
Number:Temperature Laurent_setpoint_heat

Note that I also have some similar items for runtime_desiredCool …

I simply want to substract 0.5 from the actual setpoint value before setting back a thermostat hold during a high rate period from my utility provider.

I have many coding try and here is my last one:

Laurent_setpoint_heat.state = runtime_desiredHeat.state - 0.5[°C]
val ecobeeActions = getActions("ecobee","ecobee:thermostat:account:xxxxxxxxx")
ecobeeActions.setHold(Laurent_setpoint_cool.state as QuantityType<Number>, Laurent_setpoint_heat.state as QuantityType<Number>)

That did not work and VS code complains about missing type Object as someone posted before …

@Denis_Lambert Are there any errors in the log file when the rule is loaded, or when it executes?

I’m pretty sure something like this will work. Sorry for using my items and units instead of yours, but I wanted to make sure it worked on my system before posting.

val actionsThermostat1 = getActions("ecobee","ecobee:thermostat:server:XXXXXXXXXX")
val newCool = (E1_Runtime_DesiredCool.state as QuantityType<Number>) + 4.5|"°F"
actionsThermostat1.setHold(newCool, E1_Runtime_DesiredHeat.state as QuantityType<Number>)

If you want to save newCool in an item, you always can do.

AnotherCoolItem.postUpdate(newCool)
1 Like