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(EcobeeAccountBridgeHandler.java:219) ~[?:?]
at org.openhab.binding.ecobee.internal.handler.EcobeeAccountBridgeHandler.refresh(EcobeeAccountBridgeHandler.java:210) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
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.
I can’t for the life of me get this going…
Created a new App at ecobee.com
tinkered between commands and updates
tried several script variations
here is where I am:
Number:Temperature Control_Xavier_Thermostat_HeatHold "Xavier Set Temperature Heat" <Input> (EcobeeXavierThermostat, gSet_Settings)
Number:Temperature Control_Xavier_Thermostat_CoolHold "Xavier Set Temperature Cold" <Input> (EcobeeXavierThermostat, gSet_Settings)
configuration: {}
triggers:
- id: "1"
configuration:
itemName: Control_Xavier_Thermostat_HeatHold
type: core.ItemCommandTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/vnd.openhab.dsl.rule
script: >-2
val ecobeeActions = getActions("ecobee","ecobee:thermostat:fe3e2fXXX:41194595XXX")
val mode = EcobeeXavierThermostat_HVACMode.state.toString
Thread::sleep(1000)
if (mode == "heat") {
ecobeeActions.setHold(Control_Xavier_Thermostat_CoolHold.state as QuantityType<Temperature>,new QuantityType<Temperature>(receivedCommand.toString+" °F"), null, null, null, 'nextTransition', null)
} else if (mode == "cool") {
ecobeeActions.setHold(new QuantityType<Temperature>(receivedCommand.toString+" °F"),Control_Xavier_Thermostat_HeatHold.state as QuantityType<Temperature>, null, null, null, 'nextTransition', null)
}
type: script.ScriptAction
- inputs: {}
id: "3"
configuration:
itemName: Output_PushNotification_Alarm
command: HEAT!
type: core.ItemCommandAction
Anyone see something obvious I am missing?
I’m more familiar with the DSL rules, but:
What’s that “Input” in your items file? Did you link the HeatHold/CoolHold items to the Ecobee thermostat channels?
Did you define EcobeeXavierThermostat_HVACMode somewhere? It should be a string item.
Were you able to correctly link the ecobee app to Openhab using the API key? Meaning, do the ecobee channels (like current temperature) populate correctly?
1 Like
@Tron thanks kindly for the reply…
The top two items I’ve shown are proxy items from the example at the bottom of the binding page here:
My understanding is this is where you trigger the control from and are not bound to a channel? Are they supposed to be?
EcobeeXavierThermostat_HVACMode is defined and linked to the proper channel returning ‘heat’
The ecobee binding has been working well for a while… returning values and forecasts… just can’t get this to go.
I have them linked to the ecobee channel (which is read-only, so you’ll still need to use actions to change them) so they update if anything else changes them (such as the thermostat schedule):
Number:Temperature ecobee_setpoint_heat "Heat Setpoint [%.1f °F]" <temperature> { channel="ecobee:thermostat:xxx:yyy:runtime#desiredHeat" }
Number:Temperature ecobee_setpoint_cool "Cool Setpoint [%.1f °F]" <temperature> { channel="ecobee:thermostat:xxx:yyy:runtime#desiredCool" }
So if you send a command to them, they are not updated on the ecobee but rather trigger the action to do so. Here’s mine (in DSL format). Maybe that helps.
rule "Ecobee Set Temperature"
when
Item ecobee_setpoint_heat received command or
Item ecobee_setpoint_cool received command
then
val ecobeeActions = getActions("ecobee","ecobee:thermostat:xxxxx:yyyyyyyyyy")
Thread::sleep(1000)
ecobeeActions.setHold(ecobee_setpoint_cool.state as QuantityType<Number>, ecobee_setpoint_heat.state as QuantityType<Number>, null, null, null, "nextTransition", null)
end
As you can see, I don’t distinguish between heat/cool mode but just write both to the thermostat. Even if I only changed one of them. Maybe that’s where your rule messes up.
But I think that you need to strip the temperature unit in any case. Mine are defined as Number:Temperature, and that’s why I push them as “QuantityType”.
1 Like
Welp… I don’t know if my item definitions through the GUI or the DSL rule definition also done with the GUI were the problem (displayState?), but using your definitions with .rules and .items files and my thermostat definition works just fine. Before that I spent 45 minutes trying different type conversions before giving up and trying it this way.
Maybe I’ll try to move them back into the GUI, but at this point I’ve had enough!
Thanks!
You’re welcome. You now owe me a beer 
(Most likely culprit is trying to push temperatures with units to the thermostat. You can do it that way in the GUI as well)
Awesome! Send me coordinates (local brewery, favorite bar, Venmo and location) and I’m happy to oblige! Long time but mostly-retired home brewer…
I was just kidding
Openhab is a community software, free to use by anyone who wants to, and to me that extends to support as well. So if I’m able to help someone out (happens rarely enough), I’m glad to do so.
But I’m happy it works for you now!
(I hate the fact that the Ecobee thermostats cannot be accessed locally, and that everything has to go through their servers, but it was the best option for me at the time. Google Nest is even worse)
1 Like