I restarted OpenHAB, and I am no longer seeing the behavior that I saw earlier. Appreciate you taking a look at this so quickly. I will keep an eye out on it, and will reply back if I see anything unusual.
Thanks again!
Thanks. I had a feeling that a restart might resolve the issue.
OTOH, I found what might be the cause. I have lastModified defined as a channel type twice here and here. I’ll correct this next time I do a release. If the problem reoccurs for you, post back here and I’l push the fix more quickly.
Thanks, Mark.
On a different topic, I finished converting all of my items over from v1 to v2 last night. I am only using 20 or so items (mostly in “info”, “runtime”, and “settings”), and everything is working great. The items are all updating as expected and matching the API I manually curl. However, I have not been able to get the weather forecast group to work. I defined them exactly like the other items, but all of them are showing up as NULL. Below are a few examples of how I defined the items.
Number:Temperature Weather_Temperature "Temperature [%.0f %unit%]" { channel="ecobee:thermostat:account:xxxxxxxxxxxx:forecast0#temperature" }
Number:Dimensionless Weather_Humidity "Humidity [%d %unit%]" { channel="ecobee:thermostat:account:xxxxxxxxxxxx:forecast0#relativeHumidity" }
Number:Speed Weather_Wind_Speed "Windspeed [%.0f %unit%]" { channel="ecobee:thermostat:account:xxxxxxxxxxxx:forecast0#windSpeed" }
This appears fairly straightforward, so I am really not sure what I am doing wrong. I am also seeing no activities for items I defined in the forecast group in “events.log”. I also checked “openhab.log” and did not see anything unusual. I also did a curl and can confirm the API is returning weather forecast data (below). Any advice is appreciated. Thanks again.
{
"page": {
"page": 1,
"totalPages": 1,
"pageSize": 1,
"total": 1
},
"thermostatList": [{
"identifier": "xxxxxxxxxxxx",
"name": "My ecobee",
"thermostatRev": "200607030058",
"isRegistered": true,
"modelNumber": "nikeSmart",
"brand": "ecobee",
"features": "Home,HomeKit",
"lastModified": "2020-06-07 03:00:58",
"thermostatTime": "2020-06-07 14:49:53",
"utcTime": "2020-06-07 19:49:53",
"weather": {
"timestamp": "2020-06-07 19:33:36",
"weatherStation": "FI:KPIA",
"forecasts": [{
"weatherSymbol": 0,
"dateTime": "2020-06-07 14:33:36",
"condition": "Clear",
"temperature": 881,
"pressure": 1014,
"relativeHumidity": 34,
"dewpoint": 559,
"visibility": 15000,
"windSpeed": 8,
"windGust": -5002,
"windDirection": "ESE",
"windBearing": 111,
"pop": 0,
"tempHigh": 891,
"tempLow": 618,
"sky": 1
},
... (abridged)
]
}
}],
"status": {
"code": 0,
"message": ""
}
}Hmm. That’s strange. I was pretty sure this was working. Let me have a look.
@jakdock I just tested it here and it’s working fine for me. Isn’t that the way it always goes… 
Can you try putting the binding into TRACE mode? If at least one item is linked to a forecast channel, you should see a log entry that looks like this.
2020-06-07 17:57:01.539 [TRACE] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Thermostat thing 'ecobee:thermostat:server:XXXXXXXXXX' including object 'includeWeather' in selection
Also, in TRACE mode, you should see the request and response JSON.
Mark,
I think I have discovered the issue. After turning on trace, this is what it shows:
2020-06-07 20:00:39.227 [TRACE] [hab.binding.ecobee.internal.handler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Thermostat thing 'ecobee:thermostat:account:411977279982' including object 'includeEquipmentStatus' in selection
2020-06-07 20:00:39.227 [TRACE] [hab.binding.ecobee.internal.handler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Thermostat thing 'ecobee:thermostat:account:411977279982' including object 'includeProgram' in selection
2020-06-07 20:00:39.227 [TRACE] [hab.binding.ecobee.internal.handler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Thermostat thing 'ecobee:thermostat:account:411977279982' including object 'includeRuntime' in selection
2020-06-07 20:00:39.227 [TRACE] [hab.binding.ecobee.internal.handler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Thermostat thing 'ecobee:thermostat:account:411977279982' including object 'includeSettings' in selection
2020-06-07 20:00:39.227 [TRACE] [penhab.binding.ecobee.internal.handler.EcobeeAccountBridgeHandler] - AccountBridge: Thermostat ecobee:thermostat:account:411977279982 selection: selectionType=registered,selectionMatch=null,includeAlerts=null,includeAudio=null,includeDevice=null,includeElectricity=null,includeEnergy=null,includeEquipmentStatus=true,includeExtendedRuntime=null,includeHouseDetails=null,includeLocation=null,includeManagement=null,includeNotificationSettings=null,includeOemCfg=null,includePrivacy=null,includeProgram=true,includeReminders=null,includeRuntime=true,includeSecuritySettings=null,includeSensors=null,includeSettings=true,includeTechnician=null,includeUtility=null,includeVersion=null,includeWeather=null
2020-06-07 20:00:39.227 [TRACE] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: Get Request json is '{"selection":{"selectionType":"thermostats","selectionMatch":"411977279982","includeAlerts":true,"includeEquipmentStatus":true,"includeEvents":true,"includeProgram":true,"includeRuntime":true,"includeSensors":true,"includeSettings":true}}'`
The API request did not include: “includeWeather”:true. Accordingly, the API response does not include weather information. Is there something I need to pass onto the binding to turn on weather?
Thanks again.
You just need to have at least one item linked to a weather channel.
Mark,
It is working perfectly now. Thanks a lot !!
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
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!
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?
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!
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,
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.
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?
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)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.
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
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)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.