Version 2 of the Ecobee binding was recently merged. You’ll find it in 2.5.4 and later versions. You can find the documentation here.
While the v2 binding is very similar to the v1 binding, it’s not 100% compatible. Some items and actions are a little different, so it’s not a drop in replacement if you’re running the v1 version.
Setup is similar in that you need to register your thermostat(s) with Ecobee, as well as set yourself up as an Ecobee developer in order to get an API key.
If you run into any issues with the binding, please post here and I’ll do my best to help you out.
Thank you … I’m a new OpenHAB user so please bear with me :). I just installed 2.5.4 this morning and enjoying it so far. I’m a previous user of Vera, SmartThings, HomeSeer, and Control4 at one time or another.
First off, I found the API key a strange requirement. On other platforms I’ve simply been given the code and added it via “My Apps” on Ecobee website. I never had to sign up for a developer. In my opinion, with lack of understanding as to why this plugin was implemented this way, it seems like extra work involved that could potentially be much simpler.
Once I added the “things” to OpenHAB I had a massive number of channels added. Again, I’m new and using the Paper UI at this point … but I had to manually remove a huge number of channels to get to the stuff I actually care about. It would have been nicer to have all channels off and just turn on the interesting ones in my opinion.
The main thermostat is basically “read only” information with no ability to change the temperature, the program etc … am I doing something wrong?
Lastly, the sensors all starting to come through … but I only see the channels that are related to motion detection it looks like - nothing that tells me that actual temperature in each room, which is my main interest.
Thank you - hope this feedback and questions are helpful …
Paul
The original v1 binding was done this way. In my experience with API keys used in open source projects, and with other bindings I’ve worked on that also use API keys, there’s no (easy or reliable) way to administer the distribution of the key, nor is it advisable to embed the key in the app, as the key will be publicly visible to anyone.
Yes, there are a LOT of channels. But, I’m not sure what you mean when you say you had to remove the channels. Channels cannot be removed. But items can be removed. By any chance, do you have simple mode enabled? Simple mode, which is not recommended and is being removed in openHAB 3.0, creates items for all channels. This can be overwhelming, and is unnecessary in almost all circumstances.
Heating and cooling setpoints are changed by using the thing actions.
The climateref (e.g. home, away, etc.) also is set using thing actions.
Thing actions can be used to set more complex holds.
The sensor channels are created dynamically based on the capabilities of the sensor. When you look at a sensor thing in Paper UI, you should see something like this.
That’s super interesting … and makes a lot of sense. Thank you for explanation - the old analogy of “well others do it that way so it must be right” that is often a wrong assumption (on my part).
Bingo! yes, I have simple mode enabled … turning that off now And yes, apologies for confusion, I was referring to “items” - still learning the terminology here …
Thank you - I have some reading to do obviously …
Thank you - I “spoke” too soon at that one … they took a while to come through but about 10 minutes after I posted they now show up.
So, I have to follow up on “thing actions” and will do that … in meantime I’ve been organizing the sensors into “locations”, which I’m using “locations” to reference rooms in my house at this point. While trying to re-organize the location of various things I’m getting an Internal Server Error 500. I have done this with other things outside of this plugin so wondering if it’s a bug somewhere - what log information can I send you to (hopefully) help identify this issue?
Ok. If you run into any roadblocks, post back here and I’ll give a few examples. I’d also suggest you read up on QuantityTypes (e.g. an item of type Number:Temperature).
What do you mean when you say you’re using “Locations”? Do you mean the “Location” field of a thing? If not, something else? Can you give me an example of what you’re trying to do?
Speaking of QuantityTypes, make sure you set the Configuration->System->Regional Settings so that the system can do the proper unit of measure conversions.
Appreciate your patience :). Yes, in the actual thing I’m setting locations (which for now I’m using to represent the room the device is located in). When I set the location inside the thing it doesn’t accept it and I see an “INTERNAL: Error 500” pop up in the bottom right corner.
I’ve attached a couple of screenshots - wasn’t able to capture the 500 error in the screenshot. In the second example, I’m putting “Living Room” as the location and when I save it that’s when the error pops. I’ve checked the logs so far and found nothing - probably looking in the wrong place though.
Before you go too far down the road using Paper UI… Paper UI was designed primarily as an administrative interface. There are much better and flexible choices for a UI to view and control your setup – such as Basic UI and HABpanel, as well as the Android and iOS apps. Besides, Paper UI is going away in 3.0. It’s being replaced by a new admin interface.
Also, you should take a look at using groups. They give you a much greater degree of flexibility in organizing your items.
I’m not trying to blow off the issue you’re having. I’ll take a look at it.
Is it only the sensors where you see this problem? I can set the Location on my Thermostat things, but not on the sensor things. When I try to set the Location on a sensor thing, I get the same error as you. Looking in the browser at the response from openHAB, it complains about a NullPointerException. Unfortunately, it doesn’t give any more clues, and I don’t see a full stack trace in the log file. It may have something to do with the fact that the sensor things are dynamically creating some of their channels.
This is exactly the problem. Once the dynamic channels (e.g. temperature, occupancy, etc) are created, I believe the thing is no longer considered managed by openHAB core. Only managed things can be updated. So-called unmanaged things can’t be updated.
Updating the Location worked when I did it before the dynamic channels were created (there’s a brief delay between when a sensor thing is added and the dynamic channels are created). Updating the Location failed after the dynamic channels were created.
Sorry, but I don’t think there’s anything the binding can do about this.
Thanks very much for confirming this and explaining it further.
As someone new to OpenHAB is there something else that I should be doing to get this fixed? It sounds like this may be a core issue of some kind? Again, apologies if these seem like basic questions … I’m just trying to figure out if there’s somewhere else I can follow up etc
I was going to look at the issues list for openhab-core to see if there’s already an issue. I’m actually a little surprised this hasn’t come up before. I suspect the check for managed versus unmanaged is binary, which leaves no wiggle room for an edge case like this.
@pstewart19 The problem has been fixed in openHAB core, but the fix is in version 3.0. I also pushed a change to the Ecobee binding that will prevent the problem from happening in 2.5. My change will be in the 2.5.5 release.
Mark,
So far it’s been working for me. It took a few attempts to get the setHold to work. I wanted to pass in constants, but had to define items like your example before it could compile. So I have this:
rule "Initialize constants"
when
System started
then
UserCool_constant_ecobee.postUpdate(26)
UserHeat_constant_ecobee.postUpdate(16)
end
To set the constants. Everything else has been Fahrenheit so don’t know why I needed Celsius for this.
Then I had this:
val ecobeeActions = getActions("ecobee","ecobee:thermostat:ecobee:ecobee-basement")
ecobeeActions.setHold(UserCool_constant_ecobee.state as QuantityType<Temperature>,UserHeat_constant_ecobee.state as QuantityType<Temperature>)
And it works OK, but I get the following in the log:
2020-05-04 22:17:43.847 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'ecobee.rules', using it anyway:
The method setHold(ThingActions, QuantityType<Object>, QuantityType<Object>) from the type EcobeeActions refers to the missing type Object
2020-05-04 22:17:43.848 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'ecobee.rules'
2020-05-04 22:17:45.016 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'ecobee.rules', using it anyway:
The method setHold(ThingActions, QuantityType<Object>, QuantityType<Object>) from the type EcobeeActions refers to the missing type Object
2020-05-04 22:17:45.027 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'ecobee.rules'
Am I doing something wrong? And better yet, is there a better way to do constants here?
The rules DSL complains about QuantityTypes, but they work. I don’t have a solution for that. As someone who doesn’t like to see errors when my rules are parsed, I’m not happy about this either…
I didn’t have regional settings set. I updated it with the country and time zone, and it still did Celsius for the constant. But the setHold with constants you show (I changed it to F) also works (still gets that message). So I can get rid of the constant items. Thanks.
BTW, the binding internally does everything in Fahrenheit because that’s the way the Ecobee API works. Any conversions to C are done by openHAB based on the Regional settings.
I copied from your example in the doc, except took off the formatting stuff in quotes (thinking it didn’t matter). Putting country as US didn’t seem to make it do Fahrenheit. No matter now–I have it working passing in the constants (with the F notation) you showed above. Thanks for the help.
And yes, apologies for confusion, I was referring to “items” - still learning the terminology here …
