Ecobee binding - confusing to initially link up

Good afternoon, all.

Working on playing with OpenHABian - got things running and with some help from folks on here, got my first binding working (OmniPro). Next, I’m trying to link to Ecobee. I created the API key on Ecobee’s site, but have no idea how to actually get it linked to OpenHAB2.

Any help is greatly appreciated, as I can’t really find a “process document” anywhere.

Create an ecobee.cfg in the openhab conf/services directory with the following:

appkey=put key here from https://www.ecobee.com/home/secure/developer.jsf
scope=smartWrite

Then you’ll need to watch the log file and it will show a pin that you’ll need to go back to https://www.ecobee.com/home/secure/settings.jsf and enter the pin in My Apps ad press the Install App button. See https://www.openhab.org/addons/bindings/ecobee1/#authorization as well.

So here’s the weird part - I added the API key in the PaperUI interface, and it was there but it looks like all the entries were REM’d out with a “#”. I removed the “#” and restarted the OpenHAB service, but no change. The log (in both cases) shows this:

2019-08-14 11:16:40.551 [INFO ] [inding.ecobee.internal.EcobeeBinding] - No Ecobee in-bindings have been found for selection.

I know I’m supposed to see the EcobeePIN exchange in the logs, but I’m not seeing it. I’m assuming the logs I’d see this in would be the regular Log Viewer (which is set to display both the “openhab.log” and “events.log”. But I’m not seeing it happen.

I’m also seeing this occasionally in the logs (though it’s probably unrelated):

2019-08-14 11:21:41.714 [WARN ] [java.util.prefs                     ] - Could not lock User prefs.  Unix error code 2.
2019-08-14 11:21:41.720 [WARN ] [java.util.prefs                     ] - Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
2019-08-14 11:22:11.708 [WARN ] [java.util.prefs                     ] - Could not lock User prefs.  Unix error code 2.
2019-08-14 11:22:11.711 [WARN ] [java.util.prefs                     ] - Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.```

The Java preferences storage is corrupt. See: https://www.openhab.org/addons/bindings/ecobee1/#troubleshooting-authorization

I attempted this, but it had no impact. The log is still showing those errors - it “may” also be impacting homekit integration as well (can’t pair, and after all the different troubleshooting items on that, this might be impacting as well). :frowning:

So, for some other reasons, I’ve had to load the latest snapshot, which fixed my other issues as well as this weird Java error (fresh load then switched modes to snapshot).

Still can’t seem to get it to pair, and in the log (web-based display of log) I don’t even see it trying to link up so I can pair it with Ecobee’s API site.

When I put in the API key, the service restarts and all I see in the log is this:

2019-09-07 11:38:21.117 [INFO ] [b.core.service.AbstractActiveService] - Ecobee Refresh Service has been started
2019-09-07 11:38:21.123 [INFO ] [inding.ecobee.internal.EcobeeBinding] - No Ecobee in-bindings have been found for selection.

You’ve never really mentioned editing ecobee.cfg, or what tool you use to edit it.
PaperUI is not suitable for 1.x bindings.

The fact it had an editable interface, I thought it would work. Not sure on the path of the file to edit. I did at one point find an ecobee.cfg file that had been edited by paperUI, but it looked like the entries had been REM’d out. I removed the “#” but didn’t seem to help.

I think when I was looking around, I found 2 locations for ecobee files, but the one with data I entered in PaperUI, was at:
/etc/openhab2/services/ecobee.cfg

# the private API key issued be Ecobee to use the API (required, replace with your own)
#appkey=REMOVED FOR SECURITY REASONS
# the application scope used when authorizing the binding
# choices are smartWrite,smartRead, or ems, or multiple (required, comma-separated, no spaces)
#scope=smartWrite
# Rate at which to check if poll is to run, in ms (optional, defaults to 5000)
#granularity=5000
# Data refresh interval in ms (optional, defaults to 180000)
#refresh=180000
# Time in ms to wait after successful update, command or action before refresh (optional, defaults to 6000)
#quickpoll=6000
# Time in ms to allow an API request to complete (optional, defaults to 20000)
#timeout=20000
# the temperature scale to use when sending or receiving temperatures
# optional, defaults to Fahrenheit (F)
#tempscale=C

That’s actually all that’s been added. I think I’m lacking understanding on the “items” portion of the config.

I shouldn’t worry about Items until you have the key part sorted out. You need to do as @ranielsen advised three weeks ago, with the appkey and scope.

That’s the thing. I believe I did. When I used PaperUI, it generated the file in /etc/openhab2/services/ecobee.cfg. I don’t actually see a “conf” directory, so I’m assuming @ranielsen mean’t wherever the openhab2 config directory is (which, from what I can tell, is /etc/openhab2/), then /services/ and the file ecobee.cfg is there with the contents above.

Okay, well, it doesn’t work. That’s the end of that, unless you do something. The file you have shown us is effectively “empty”, because as you noted everything is # commented out.

When you install a 1.x binding it makes a skeleton .cfg file which includes guidance on parameters, in the form of comments.

The folder it goes in is system dependent, so it depends what you did at OH install. In my Windows install I have C:/openhab2/conf/services/xxx.cfg files, but that’s not much use to you.
You said you used openhabian to install, so far as I can make out you would expect to have a/etc/openhab2/services/ folder, just as you say.

I’ve un-rem’d the line items in the config file, and restarted the service, but still no luck with an API pin in the logs.

May we see what your ecobee.cfg file looks like now? What did you use to edit it? (some windows editors will mess it up)
What does the binding have to say for itself at startup in openhab.log?

It was edited from an SSH connection, using NANO.

# the private API key issued be Ecobee to use the API (required, replace with your own)
appkey=MASKED AGAIN FOR SECURITY REASONS

# the application scope used when authorizing the binding
# choices are smartWrite,smartRead, or ems, or multiple (required, comma-separated, no spaces)
scope=smartWrite

# Rate at which to check if poll is to run, in ms (optional, defaults to 5000)
granularity=5000

# Data refresh interval in ms (optional, defaults to 180000)
refresh=180000

# Time in ms to wait after successful update, command or action before refresh (optional, defaults to 6000)
quickpoll=6000

# Time in ms to allow an API request to complete (optional, defaults to 20000)
timeout=20000

# the temperature scale to use when sending or receiving temperatures
# optional, defaults to Fahrenheit (F)
tempscale=F

After the service restart, here’s what was in the logs again (like it’s not even looking at that file):

2019-09-07 20:19:06.211 [INFO ] [b.core.service.AbstractActiveService] - Ecobee Refresh Service has been started

2019-09-07 20:19:06.236 [INFO ] [inding.ecobee.internal.EcobeeBinding] - No Ecobee in-bindings have been found for selection.

Stop your OH system. Search for a file ecobee.config - careful with that suffix. This is a cached version, if you find it delete it. When you restart, it will be recreated from ecobee.cfg

Here’s a snippet from the ecobee instructions:

Authorization

After you have installed and configured the binding, added items to your .items file and started openHAB (if not previously started), when the binding performs its first poll, it will discover that is has not yet been authorized by the Ecobee servers, and will retrieve a four-character PIN from the Ecobee server. This PIN will appear prominently in your openhab.log file:

This seems to suggest you do need to have something for the thermostat in items for it to query before you’ll see the pin.

I don’t fully understand the instructions, but I created “ecobee.items” file and threw it in the THINGS directory, with a single line in it of:

ecobee="=[TSTAT's ID NUMGER#name]"

I found 2 of them, but they had matching data. I deleted anyway and started, they were recreated but had the same data.

I’m prepared to believe that :smiley:

Nope, myfile.items files go in the/items folder, it is a sibling of the /services folder where you found ecobee.cfg and of the /things folder.

No, you have to make a complete Item in the usual way for an xxx.items file definition, and you would bind it to ecobee in the usual way for 1.x binding

The example in the docs is

Number KitchenTemp "Kitchen temperature [%.1f °F]"   { ecobee="<[123456789#remoteSensors(Kitchen).capability(temperature).value]" }

the bit in curly braces is the binding link

So your example would become something like

String myecostat "some eco thingy [%s]" { ecobee="<[987654#name]" }

Watch in openhab.log for a successful load of your items file. I would imagine you’ll need to restart again for the binding to pick it up, 1.x bindings are not so good with in-flight reconfiguration.

I mistyped. The file I created was ecobee.things (in the things directory). However, I realize that’s contrary to the instructions so I renamed it and put it in the items directory. Still not even understanding what the “usual way” is, as I’m new to the platform. Oh, I wish there was a 2.x binding for ecobee. :slight_smile:

The good news is, now something new is happening, and the wording suggests my syntax is indeed wrong, so cool:

2019-09-07 21:20:45.540 [INFO ] [inding.ecobee.internal.EcobeeBinding] - No Ecobee in-bindings have been found for selection.

2019-09-07 21:22:13.619 [WARN ] [.core.internal.folder.FolderObserver] - Error while opening file during update: /etc/openhab2/items/ecobee.items

2019-09-07 21:22:17.940 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'ecobee.items' has errors, therefore ignoring it: [1,1]: missing EOF at 'ecobee'

My goal for this particular binding was to ultimately create some rules so if any windows were open for longer than x seconds, HVAC status were captured somewhere, then set to OFF until the windows were closed for x seconds, then restore previous status.

The example files seem to show only the ability to monitor occupancy and remote temp. I hope I’m reading that wrong, and that there is the ability to control HVAC status (Heat, Cool, Auto, Off).