@Jared:
Yes, you can. Let me break this down for you. You can use the “desired heat/cool” channels. Those are read-only, but you can use them in your sitemap to display the values. When you want to change them, you need to set a hold, and a rule runs that submits the ecobee hold actions. I give you my examples for my master-bedroom thermostat. Obviously, replace xxxx and yyyy with the values for your thermostat channels.
items: Number:Temperature ecobee_mbr_setpoint_heat "MBR Thermostat Setpoint Heat [%.1f °F]" <temperature> { channel="ecobee:thermostat:xxxx:yyyy:runtime#desiredHeat" } Number:Temperature ecobee_mbr_setpoint_cool "MBR Thermostat Setpoint Cool [%.1f °F]" <temperature> { channel="ecobee:thermostat:xxxx:yyyy:runtime#desiredCool" }
Now you have the values in your sitemap, but pushing the buttons does not anything yet, as they are read-only. Now insert a rule:
rule "Set MBR Temperature" when Item ecobee_mbr_setpoint_heat received command or Item ecobee_mbr_setpoint_cool received command then val ecobeeActions = getActions("ecobee","ecobee:thermostat:xxxx:yyyy") Thread::sleep(1000) ecobeeActions.setHold(ecobee_mbr_setpoint_cool.state as QuantityType<Number>, ecobee_mbr_setpoint_heat.state as QuantityType<Number>, null, null, null, "nextTransition", null) end
Now what does that do? Whenever you change the heat or the cold setpoint, it initializes the thermostat, waits a second (yes, that is necessary), and then writes the new setpoints to the thermostat, in this case until the next Transition (such as a schedule) occurs. You could also hold indefinitively, or a set duration, or whatever. The syntax is in the ecobee binding documentation and here is more about holds, for example: https://www.ecobee.com/home/developer/api/documentation/v1/functions/SetHold.shtml
If you do choose to use an indefinite hold, you will need some kind of rule to resume the schedule when you want it to. That works the same way.
Rule 'Set Main Temperature': Could not cast NULL to org.eclipse.smarthome.core.library.types.QuantityType; line 9, column 23, length 55
rule “Set Main Temperature”
when
Item ecobee_main_setpoint_heat received command or
Item ecobee_main_setpoint_cool received command
then
val ecobeeActions = getActions(“ecobee”,“ecobee:thermostat:XXXX”)
Thread::sleep(1000)
ecobeeActions.setHold(ecobee_main_setpoint_cool.state as QuantityType, ecobee_main_setpoint_heat.state as QuantityType, null, null, null, “nextTransition”, null)
end
I tried replacing the XXX:YYY with thermostat and sensor ID that didnt seem to work so then I just put the thermostat in. Any help on that would be great, thanks for the help already though.
Look in PaperUI under your thermostat-thing. That will tell you exactly how it needs to be called.
It’s two numbers: xxxx is the “thing” ID and yyyy is the thermostat ID (not the sensor ID!) set by ecobee, which can also be found in your account on ecobee.com.
Thanks alot sir. That got me what I needed. I updated this a couple of times but eventually figured out what I had incorrect. Thanks for the time and effort
.
I just received the following email from ecobee. Will the binding be ready when these changes are enforced on December 1, 2020?
Upcoming API Changes Effective December 1, 2020
The following changes will go into effect on December 1, 2020. If you are unsure whether these changes will have an impact on your solution today, we encourage you to discuss it with your technology team, program manager, other stakeholders and ecobee partners. Access/Refresh Token Format Changes
Starting from December 1, 2020, ecobee access tokens will no longer be returned as opaque 32-character strings. Access tokens will now be JWTs, which are considerably longer and uses a wider character set. Our JWTs follow the RFC7575 standard for JSON Web Signature tokens.
To ensure your application will continue to work, you will need to ensure that your application supports the following changes:
Access tokens will be up to 7KB in length, and includes upper/lower case alphanumeric characters, hyphens, underscores, and periods.
Refresh tokens can be of varying lengths and can contain non-alphanumeric characters. Authorization Code Changes
The Redirect URI associated with your registered application should be a semi-colon separated list of absolute URLs that start with https://. We do not accept http:// protocol links. PIN Authorization Changes
PINs will become 10 character alphanumeric strings.
This flow is only recommended in situations where a user is interacting with a device that cannot easily use a web-based login form; we recommend migrating to the Authorization Code strategy for a better user experience. Click here for more ecobee developer documentation. Early Access Program
For developers who would like to switch over to the new authorization flows before the December 1st deadline, there is an Early Access Program (EAP) available immediately. To gain access to this program, please submit a ticket on our Help Center and our Developer Relations team will reach out to you with next steps. Next Steps
If you have any questions about these upcoming changes to the ecobee API, please submit a ticket on our Help Center and the Developer Relations team will get in touch with you.
Not a developer here, but it looks like that change may affect the ecobee binding and it would probably be a good idea to get into the Early Access Program to get a closer look before the binding may stop working on December 1st.
Quick update on the auth changes… Initial indications are that the binding might not need to change. As soon as Ecobee is ready for me to test, I’ll confirm that. It is possible, however, that the binding will need to be reauthorized even if there are no code changes. I also confirm that once they’re ready for me to test.
I was given access to the test environment a couple days ago. My testing so far indicates that the current 2.5.x and 3.0 bindings appear to run successfully against the new environment.
As I’m not sure how long they will support backwards compatibility, and because Ecobee recommends reauthorizing all apps to take advantage of the improved security of the new system, I’ll be submitting 2.5.x and 3.0 PRs containing some documentation on how to reauthorize, as well as a few small bug fixes.
The 3.0 PR is here. As soon as this is merged, I’ll submit the 2.5.x PR. I’m hopeful these both can be merged before Dec 1.
After December 1, please post any issues here rather than starting a new thread. It will be easier to manage if everything is in one thread, and the discussion will benefit all users. Thanks!
Good news!! Both PRs were merged, and the changes are now in 2.5.11 and 3.0.0 M4 and M5.
Of course, the updated version of the binding can be pulled from Jenkins at any time, then dropped in the addons directory (after uninstalling the one that’s currently installed).
I recommend you move to this version of the binding as soon as practical either by installing the new OH release (3.0.0 M4 or 2.5.11) or downloading the binding for your OH version and installing into the addons directory.
Using the 2.5.x binding linked to above, my system has been running against the new Ecobee back end test environment for quite a few days without needing to reauthorize. However, while it’s not a requirement to reauthorize the binding with Ecobee immediately, Ecobee recommends that you reauthorize at some point to take advantage of the better security features of the new system. The process for doing this is described in the README. Obviously, you should not attempt to do this until after Dec 1.
If you have questions, or run into any issues, please post here rather than starting a new thread. That way others will be able to see the discussion easily.
Update: Today, 29 Nov, I converted my production system over to the new Ecobee auth system following the steps outlined in the README. Worked without issue. Note I was able to do this before 1 Dec only because Ecobee manually converted my API key over to the new system.
Update: If you’re using the Ecobee consumer portal at https://www.ecobee.com/consumerportal/index.html, after you enter the 9-character PIN, you will see a series of dialogs that look like these.
I’m not sure if this is a byproduct of moving from M2 to M3/M4 or not, but I have completely lost all of the temperature info on my ecobees. In-fact, I get absolutely nothing under runtime. I’ve restarted several times and nada. I have ecobee pulled off to a separate log as trace and I get the following:
2020-11-29 14:55:59.614 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Updating channels for thermostat id 511866108145
2020-11-29 14:55:59.619 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Thermostat '511866108145' has 8 remote sensors
2020-11-29 14:55:59.619 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'rs:100(Master Bedroom)' of type 'ecobee3_remote_sensor'
2020-11-29 14:55:59.619 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'rs:100(Master Bedroom)'
2020-11-29 14:55:59.619 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '680'
2020-11-29 14:55:59.619 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.619 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'rs:101(Lily)' of type 'ecobee3_remote_sensor'
2020-11-29 14:55:59.619 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'rs:101(Lily)'
2020-11-29 14:55:59.619 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '669'
2020-11-29 14:55:59.619 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.619 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'rs:102(Living Room)' of type 'ecobee3_remote_sensor'
2020-11-29 14:55:59.619 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'rs:102(Living Room)'
2020-11-29 14:55:59.619 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '700'
2020-11-29 14:55:59.619 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.619 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'rs:103(Jacob)' of type 'ecobee3_remote_sensor'
2020-11-29 14:55:59.619 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'rs:103(Jacob)'
2020-11-29 14:55:59.619 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '669'
2020-11-29 14:55:59.619 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.619 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'rs:104(Emily)' of type 'ecobee3_remote_sensor'
2020-11-29 14:55:59.619 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'rs:104(Emily)'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '669'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.620 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'ei:0(Main Floor)' of type 'thermostat'
2020-11-29 14:55:59.620 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'ei:0(Main Floor)'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '691'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'humidity' with value '52'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '3' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.620 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'rs:105(Garage)' of type 'ecobee3_remote_sensor'
2020-11-29 14:55:59.620 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'rs:105(Garage)'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '572'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.620 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'rs:106(Master Bathroom)' of type 'ecobee3_remote_sensor'
2020-11-29 14:55:59.620 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'rs:106(Master Bathroom)'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '692'
2020-11-29 14:55:59.620 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.626 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Updating channels for thermostat id REMOVED
2020-11-29 14:55:59.628 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Thermostat 'REMOVED' has 2 remote sensors
2020-11-29 14:55:59.628 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'rs:100(Closet)' of type 'ecobee3_remote_sensor'
2020-11-29 14:55:59.628 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'rs:100(Closet)'
2020-11-29 14:55:59.628 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '665'
2020-11-29 14:55:59.628 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'occupancy' with value 'false'
2020-11-29 14:55:59.628 [DEBUG] [andler.EcobeeThermostatBridgeHandler] - ThermostatBridge: Sending data to sensor handler 'ei:0(Upstairs)' of type 'thermostat'
2020-11-29 14:55:59.628 [DEBUG] [nal.handler.EcobeeSensorThingHandler] - SensorThing: Updating channels for sensor 'ei:0(Upstairs)'
2020-11-29 14:55:59.628 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '1' has type 'temperature' with value '684'
2020-11-29 14:55:59.628 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '2' has type 'humidity' with value '52'
2020-11-29 14:55:59.628 [TRACE] [nal.handler.EcobeeSensorThingHandler] - Capability '3' has type 'occupancy' with value 'false'
EDIT: “You take the car to the shop and it stops happening”. I restarted OH after posting and now I am getting data. I went back to grafana to make sure I wasn’t nuts and I see this ~24 hour gap.
