Ecobee binding v2

Add-ons Bindings
41

Glad that got it sorted out. Seems like a shortcoming that the binding only looks for a link to a weather channel. If you have items linked to the forecast channels but not any weather channels, then you won’t get the forecast. I’ll add that to my list of things to look into.

1 Like
42

Hi guys,

Just wanted to know if anything changed in the ecobee v2 binding at the latest update to 2.5.6.

The thing is, I use several items from the “settings” category for my thermostats, such as “HVAC mode” and “FanMinOnTime”. These are read/write, so I just write values to the items and they get reflected on the thermostat.
That has ceased to work since the last update two days ago. Whenever I write a value, it reverts back to the old one after a few minutes. The strange thing is that this affects only one of my two thermostats, the other one is working as expected. When changing the settings from the Ecobee website, both work, just not from Openhab. Settings requiring ecobee actions (like setting the temperature) still work on both.

I’ll get some debug logs tonight, hopefully those will give some insights.

Thanks!

43

It looks like ecobee is now encouraging 2FA for standard web logins.

Has anyone tried enabling 2FA yet to see if it will affect API permissions as well?

44

Hmm, trying to put the binding into debug mode made me realize that it does not show up in “log:list” in the console…should it?

Thanks!

45

No, it doesn’t show for me either. I remember reading somewhere log:list will only show manually installed add ons. Bindings installed through paper UI don’t show up there.

Best,

46

Well, it does show the (via PaperUI installed) bindings like zwave, zigbee & mqtt…

But even on Linux, some problems solve themselves by restarting the openhab daemon, strangely enough. I rebooted after the last update two days ago, but somehow openhab seems to need more than one restart after an update. Now it works and I get the following in the log:

20:24:24.899 [INFO ] [arthome.event.ItemStatePredictedEvent] - ecobee_mbr_fanminontime predicted to become 5
20:24:24.907 [INFO ] [smarthome.event.ItemStateChangedEvent] - ecobee_mbr_fanminontime changed from 10.0 to 5
20:24:24.909 [INFO ] [handler.EcobeeThermostatBridgeHandler] - Setting field 'settingsdto.fanMinOnTime' to value '5'

Which is more like what I expected, especially the last line from the Ecobee handler.

47

I’m having an issue setting the temperature on my thermostat in my rules. I have the following syntax in my rule:

    val ecobeeActions = getActions("ecobee","ecobee:thermostat:account:REDACTED")
    ecobeeActions.setHold(72|"°F",70|"°F")

The goal is simply to set the temperature. When I save the rules file I get the error of

    The method setHold(ThingActions, QuantityType<Object>, QuantityType<Object>) from the type EcobeeActions refers to the missing type Object

What is this the correct way to do this?

48

I did it with variables/items (which I set to the desired temperature), but my current rule works.
The sleep is necessary. The action sets the temperature until the next transition, which is a schedule change, for instance, but you can omit that.

I think you just need to publish the number without the unit.

     val ecobeeActions = getActions("ecobee","ecobee:thermostat:xxxxxxx:yyyyyyyyyyy")
    Thread::sleep(1000)
    ecobeeActions.setHold(setpoint_cool.state as QuantityType<Number>, setpoint_heat.state as QuantityType<Number>, null, null, null, "nextTransition", null)
49

Why is the sleep necessary? The only time I regularly use sleep is if I’m updating items and need to wait for the bus to update.

50

For some reason, the action seems to read back the old values and uses them when the “getActions” is called, which is why I need to wait a bit before setting the hold. That may be just the cause with my way of using an item to set the temperature (which I guess you’ll do later on, too).

See here: Ecobee binding v2

51

So I think the problem is because you are waiting on the bus. I’ve had similar issues with rules in the past. You could get around this by using receivedCommand and triggeringItem. This could work something like below. The concept is that (in theory) you are only waiting on one item to update on the bus which would be the triggeringItem for the rule. receivedCommand gives you that value without having to wait for the bus. To note, I am jamming this off a tablet so I’m sure the code isn’t 100% but the logic should make sense.

when
Item ecobee_mbr_setpoint_heat received command or
Item ecobee_mbr_setpoint_cool received command
then
val ecobeeActions = getActions("ecobee","ecobee:thermostat:account:number")
var setpoint_heat = ecobee_mbr_setpoint_cool.state
var setpoint_cool = ecobee_mbr_setpoint_heat.state
if ( triggeringItem.name.toString == "ecobee_mbr_setpoint_heat" ) { setpoint_heat = receivedCommand }
else if ( triggeringItem.name.toString == "ecobee_mbr_setpoint_cool" ) { setpoint_cool = receivedCommand }
ecobeeActions.setHold(setpoint_cool as QuantityType<Number>, setpoint_heat as QuantityType<Number>, null, null, null, "nextTransition", null)
52

I’m currently using “received command” in my rules, and the wait is still necessary.
I don’t see the harm in it, though, that delay is insignificant to me.

I see that you need to define variables to use in the action line. I use the setpoint items and it works. Even better, that setpoint item is linked to the (read-only) setpoint of the ecobee, so it updates accordingly if something else (like a schedule) changes the setpoint.

Your example is a litte bit more elegant than mine, though, as you only write the setpoint (heat or cool) that actually changed. I suppose that’s why you need to define the variables.
I always write both directly from the state of the items, no matter which one triggered. Don’t think that makes a huge difference, though. More elegant, but more code, too.

If I omit the sleep line, the value changes within openhab, but not the thermostat and thus changes right back when it’s read again.

53

I’m having a similar issue that I need some help with. Rather than setting a hold for a temperature until the next transition I am looking to set a comfort setting until next transition. Currently I have the following:

val ecobeeActions = getActions(“ecobee”,“ecobee:thermostat:ecobeeaccount:111111111111111”)
ecobeeActions.setHold(null,null ,“sleep”,null ,null, “nextTransition”, null)

This gives me the following error:>

The method setHold(ThingActions, QuantityType, QuantityType, String, Date, Date, String, Number) from the type EcobeeActions refers to the missing type Object(org.eclipse.xtext.xbase.validation.IssueCodes.refer_invalid_types)

Do I need an include at the top of the rules file or something?

Thank you!

54

Hmm, I only can help you partially here because I don’t change the mode with the “nextTransition” option, and use that only with integer values (Temperature changes).

However, I am not sure how important the placement of spaces is. I notice that you either have none, or the space is after “null” and before the comma.

Can you try this?

ecobeeActions.setHold(null, null, “sleep”, null, null, “nextTransition”, null)

(so a comma and then a space)

55

@jfrank1845 What you have above should work, and I don’t understand why it doesn’t .

I’m able to reproduce it, so I don’t think it’s something you’re doing wrong. I’ll look into it more closely.

1 Like
56

When I put this in a rules file, VS Code complains about it with the same message you get above.

    val ecobeeActions = getActions("ecobee","ecobee:thermostat:account:XXXXXXXXXXXX")
    ecobeeActions.setHold(null, null, "sleep", null ,null, "nextTransition", null)

Oddly, however, when the rule executes, it doesn’t log an error, and it actually works as desired. :confused:

57

well look at that - you are correct! I guess I should have just tried it anyway - it does work! Thank you so much!

58

FTR, this also throws the same error in VS Code (but it executes successfully).

    val ecobeeActions = getActions("ecobee","ecobee:thermostat:account:XXXXXXXXXXXX")
    ecobeeActions.setHold(28|"°C", 12|"°C")

I’m pretty sure that QuantityType parameters are not handled well by the DSL rule validator, even though the code runs successfully at execution time.

The fact that the two examples I posted above both include QuantityType parameters (even though they are null in one case) would seem to support this.

59

Maybe, but you really would’ve had no reason to expect it to work. LOL

60

Hi all,

This binding is pretty good, way easier for me than the v1. Can someone break this down so I can understand it. Can I change temp on a site map from the app? I see the proxy items and rules for setting temps but I do not know what to do with those. Any help would be greatly appreciated.

Thanks
Jared