Ecobee binding v2

Isn’t officeActions set when the rule is loaded, which might be before the thing actions have been initialized? What happens if you declare and set officeActions inside the body of the rule?

1 Like

Interesting idea, and probably dead on.
I’ve put the variable declaration outside the rule because that rule file contains a good half dozen rules for changing the thermostat, so I did not want to repeat them in every rule.
It really might be that the rule engine is started and the rules (and global variables) are loaded at startup before the the ecobee thing is initialized. That would explain why it worked when I changed from a cron trigger to a switch trigger, because at that time the rule file is detected as changed and would be reloaded.

That would also explain why my “away” ecobee actions still work. Those are not on a time trigger but a presence trigger, but as it’s only one rule the variable declaration is right before the action on that one.

Thanks, I’ll try that. But I might go back to using the built-in schedule anyway, as the ecobee actions with the binding have to go through the ecobee cloud, and are thus dependent on an internet connection (and the availability of the ecobee API).

This logic of having to repeat the same action code across the code base is accurate - I have an email action line that I had to past 100+ times exactly what your encountering.

Best, Jay

1 Like

Speaking generally, to avoid something like that, you’d declare global variables that are accessible from anywhere in the code. Obviously, if they’re declared before the corresponding thing is initialized, one is out of luck. I would assume that this is the same with email actions.

I’m guessing it’s the same for any Thing action. The openHAB core actions probably are ok.

I’ve actually run into this issue when trying to use Thing actions inside a rule with a System started trigger.

1 Like

Waking up this thread, has anyone noticed that the Ecobee binding seems to go “offline” a lot lately? I noticed this a couple times last month, when Openhab didn’t show changed Ecobee parameters (temperatures, setpoints and such).
Each time, disabling and re-enabling the Ecobee account got it back online, but I’m curious if anybode else has encountered this.
It ran flawlessly for years until just recently. I wonder if Ecobee changed something and the account authorization expires or something like that…

I haven’t noticed any recent issues with my ecobee setup. I believe several months ago I had to recreate my developer api key which I guessed was due to perhaps a security change and/or expiry on ecobee side. But since then the binding has been stable for me.

Last night I saw about 200 failures like the one shown below to query the Ecobee service. I see a couple of these every so often, but I’ve ever seen a stretch of a couple hundred. Other than that I haven’t noticed anything recently.

API: Ecobee API returned unsuccessful status: code=3, message=Processing error. Error processing thermostats: [T1, T2]

I’m going to check the logs tonight to see if anything useful is in there.

So I got this in the logs, rather nondescriptive:

2022-11-12 23:22:27.966 [WARN ] [inding.ecobee.internal.api.EcobeeApi] - API: Got IOException trying to get access token from OAuth service: Exception in oauth communication, grant type refresh_token
2022-11-16 22:29:02.842 [WARN ] [inding.ecobee.internal.api.EcobeeApi] - API: Got IOException trying to get access token from OAuth service: Exception in oauth communication, grant type refresh_token

Happened twice in the last week and a couple times before that.

Yeah, I’ve also had issues recently, most specifically my thermostat temp and humidity readings had gone to UNDEF (I do have a 30 min Expire timer set), and the runtime#lastStatusModified channel was out of date by 5 days. Closest ecobee-containing log entry I can find from around that time is below:

2022-11-17 03:11:06.512 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.ecobee.internal.handler.EcobeeAccountBridgeHandler.refreshThermostats( ~[?:?]
	at org.openhab.binding.ecobee.internal.handler.EcobeeAccountBridgeHandler.refresh( ~[?:?]
	at java.util.concurrent.Executors$ ~[?:?]
	at java.util.concurrent.FutureTask.runAndReset( ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]
	at java.util.concurrent.ThreadPoolExecutor$ [?:?]
	at [?:?]

As was mentioned above by @Tron, my historical experience has been very similar, binding has been very solid for a long time.

I was able to get the thermostat values to refresh in OH3 by disabling and re-enabling the Ecobee Account Thing.
The Ecobee site itself where I have previously been able to view the thermostat status & modify setpoints, create Developer/App info, etc. is currently broken, just shows a black screen, although I think it may have been broken for me for a while since I had to remove an older thermostat for my account and I’m not sure the removal went smoothly. Is the website working as expected for others?

I’m on OH v3.3.0 on Windows 10, if it matters.

Yes, the Ecobee site works as expected for me.