Ecobee App Ported to Openluup

To those who may be interested, I have successfully ported the Ecobee App to Openluup. It was a hobby on its own and was successful thanks to @Watou generosity in providing the encrypted API file. He originally wrote it for UI5 and I made some touch-ups to it last year to make it work on UI7 but making it work on Openluup was a whole different task. I will run a bit more test before calling it good and posting it here.

@akbooer : Since you are going to ask what I did, here are the major changes:

  1. I had to install luasec to my lua library to support https calls.
  2. A developer account needs to be create on the ecobee website in order to get an API key so that everyone’s data remains safe and is seen as an independent app. This only takes a few seconds.
  3. Merged the encrypted API lua file into the main one, refactored several functions and eliminated need of module calls which made passing variables more cumbersome.
  4. Use of the ubiquitous dkjson decoder instead of a compressed customized one on the original app. (I don’t really understand what the purpose was and struggled with it for some time). Related was the “Require” declaration of the json library which did not seem to work on the vera either so it has been a mystery as to how the app works on UI7.
  5. luup.task messages does not appear to show anywhere so I added a message field on the device to get status of the app and mostly debug…
  6. All the “<” and “>” operators were replaced with lua equivalent in the xml files.
  7. Localize all the icons since we should not have storage limitations on openluup and icons are small anyway.

Well done, but I’m a bit disappointed in myself, since a well-written plugin should run very nicely both on Vera and openLuup. Some of the more ‘sophisticated’ ones do pull some strange tricks, and maybe that’s what you ran into here.

If’ there’s anything I should be doing differently, then please let me know, but to comment specifically on your points:

1. I had to install luasec to my lua library to support https calls.

I do that on standard openLuup installs now, since more and more things need HTTPS. I’m just working on digest authentication to make this more universal.

2. A developer account needs to be create on the ecobee website in order to get an API key so that everyone's data remains safe and is seen as an independent app. This only takes a few seconds.

Yes, this is similar to other cloud-based items like Netatmo, etc.

3. Merged the encrypted API lua file into the main one, refactored several functions and eliminated need of module calls which made passing variables more cumbersome.

That one’s definitely not my fault!

3. Use of the ubiquitous dkjson decoder instead of a compressed customized one on the original app. (I don't really understand what the purpose was and struggled with it for some time). Related was the "Require" declaration of the json library which did not seem to work on the vera either so it has been a mystery as to how the app works on UI7.

I think I know the answer to this one, but it doesn’t matter. Yes, I made dkjson available as part of the standard openLuup install, but openLuup itself doesn’t use it, having got its own.

4. luup.task messages does not appear to show anywhere so I added a message field on the device to get status of the app and mostly debug...

They should show in the log file, but not the user interface. In fact, I’ve recently had conversations with @amg0 about this and know how to make this work. It’s on the list, but not high priority.

5. All the "<" and ">" operators were replaced with lua equivalent in the xml files.

I am really, really surprised by this. The openLuup xml reader should make these substitutions. If not, then something is wrong. Without them, it’s actually invalid XML, although the openLuup reader should cope with that. Can I possibly get an example of a file which didn’t work?

6. Localize all the icons since we should not have storage limitations on openluup and icons are small anyway.

Yes, that certainly works, although, strangely, for my other plugins (like Netatmo) which have lots of icons, I switched to pulling them directly from GitHub. This vastly improved the ease of updating the plugins in the MiOS app store, although, TBH, I’ve really stopped using that.

Anyhow, thanks for putting in the effort and sharing, in due course, with other openLuup users.

Alright it is ready to go! I also added the instructions

Well done, but I’m a bit disappointed in myself, since a well-written plugin should run very nicely both on Vera and openLuup. Some of the more ‘sophisticated’ ones do pull some strange tricks, and maybe that’s what you ran into here.

If’ there’s anything I should be doing differently, then please let me know, but to comment specifically on your points:[/quote]

Don’t be! I am not a coder by training. I learned Lua from looking at what all other developers did. I am not very good at reading manuals so… From what I can see some apps are not working because they use some unusual structures or functions. Some I really fail to understand but I am sure there was a reason at the time (i.e why the need to use an compressed json interpreter? And why the strange declaration of the json=L_ecobee_dkjson which doesn’t seem to work?)

4. luup.task messages does not appear to show anywhere so I added a message field on the device to get status of the app and mostly debug...

They should show in the log file, but not the user interface. In fact, I’ve recently had conversations with @amg0 about this and know how to make this work. It’s on the list, but not high priority.

It would have saved me some time but not much. No biggie.

5. All the "<" and ">" operators were replaced with lua equivalent in the xml files.

I am really, really surprised by this. The openLuup xml reader should make these substitutions. If not, then something is wrong. Without them, it’s actually invalid XML, although the openLuup reader should cope with that. Can I possibly get an example of a file which didn’t work?

This I am not sure. It has been one of my most suspicious factor for the Plantlink app not to work so I assumed that it didn’t work here. In any case I needed to do it because I moved all the functions into a lua file. I am unfamiliar with xml and was very confused by the mix of both lua and xml in the xml file. I think it is cleaner when separated.

Now one question: I have a device with buttons I want to display on the ALTUI device screen and are already within tabs in the device. The buttons show on UI7 but not on ALTUI… Haven’t quite figured this one out.

I would expect this have been preceded by something like:

require "L_ecobee_dkjson"

which would have defined the global module name L_ecobee_dkjson which is then aliased to the usual json prefix.

I am unfamiliar with xml and was very confused by the mix of both lua and xml in the xml file. I think it is cleaner when separated.

You are absolutely correct. XML is a mess and the conflation with Lua is an unholy alliance. Use the minimum possible XML for the implementation file and move swiftly to a separate Lua file (which any IDE can parse and error check for you.)

Now one question: I have a device with buttons I want to display on the ALTUI device screen and are already within tabs in the device. The buttons show on UI7 but not on ALTUI... Haven't quite figured this one out.

That, I am afraid, is not my area of expertise. You’d have to poll @amg0 or one of the other JavaScript-fluent developer for a clue here.

Well done again for doing this. I am assuming that it will end up in the AltAppStore?

I would expect this have been preceded by something like:

require "L_ecobee_dkjson"

which would have defined the global module name L_ecobee_dkjson which is then aliased to the usual json prefix.[/quote]
Yes there was a dkjson = require("L_ecobee_dkjson") preceding but I could not understand how the two were connected together…

Well done again for doing this. I am assuming that it will end up in the AltAppStore?

I have not looked yet at how to publish it yet but I would like to. It needs to come with a heavy warning though that it is meant for Openluup only. For UI7 and UI5, it probably works also but adds the hassle of creating a dev account on ecobee.

I can help with the publishing, although it is documented at the start of the AltAppStore thread. It’s easy to enforce ‘only openLuup’ from the store by not enabling the Vera download button. That’s a standard part of the configuration.

Ok I published it but there are version duplicates as I made a mess trying out things…

I’ll fix it tomorrow.

Sorry for the mess. I meant to post only two versions: 1.8 for UI5/UI7 and 2.0 for UI7/Openluup

OK, think that’s done.

Thank you. Have now released version 2.01 with some bug fixes to retain API Key between Luup reloads and accidental API disconnects. Also improved house mode device appearance in ALTUI.

Edit: After one day of testing, I can report that the plugin is much more resilient on OpenLuup than on the Vera: I am seeing less frequent need to reset the API pin and the post Luup reload consistently use the correct temperature unit unlike the vera which would randomly display the thermostat in C or F after a Luup reload. This is likely due to what I have been reporting in various threads: The architecture of UI7 on the vera hardware is leading to instability related to execution speed of various functions in different threads being inconsistent.

Thanks for putting this together!

After installing on openLuup via the AppStore. I can?t figure out where to put the api key, there?s only a Get Pin button on the control panel, and nothing obvious in the Attributes list. I?m sure I?m missing something…

Thanks!

I followed the manual install process and copied the files from github and now see the api key field (I had previously installed the original ecobee plugin on my vera and think openLuup had downloaded those device files previously so the App Store install didn?t overwrite them).

I entered my dev api key and clicked Get Pin but am seeing this in the logs:

[tt]
2018-05-12 05:58:31.332 luup_log:25: ecobee: task: Trying to getPin 2018-05-12 05:58:31.332 luup.task:: status=2 ecobee : Trying to getPin 2018-05-12 05:58:31.332 luup.variable_set:: 25.urn:ecobee-com:serviceId:Ecobee1.TSK was: Not yet authorized. Press ‘Get PIN’ once; wait for PIN; enter at ecobee.com. now: Trying to getPin #hooks:0 2018-05-12 05:58:31.333 openLuup.context_switch:: ERROR: /usr/share/lua/5.1/socket/http.lua:212: bad argument #1 to ‘gsub’ (string expected, got nil) [/tt]

[quote=“bwillette, post:13, topic:199056”]I followed the manual install process and copied the files from github and now see the api key field (I had previously installed the original ecobee plugin on my vera and think openLuup had downloaded those device files previously so the App Store install didn?t overwrite them).

I entered my dev api key and clicked Get Pin but am seeing this in the logs:

[tt]
2018-05-12 05:58:31.332 luup_log:25: ecobee: task: Trying to getPin 2018-05-12 05:58:31.332 luup.task:: status=2 ecobee : Trying to getPin 2018-05-12 05:58:31.332 luup.variable_set:: 25.urn:ecobee-com:serviceId:Ecobee1.TSK was: Not yet authorized. Press ‘Get PIN’ once; wait for PIN; enter at ecobee.com. now: Trying to getPin #hooks:0 2018-05-12 05:58:31.333 openLuup.context_switch:: ERROR: /usr/share/lua/5.1/socket/http.lua:212: bad argument #1 to ‘gsub’ (string expected, got nil) [/tt][/quote]

Ok I changed the folder structure on Github which should fix the initial problem you had with overwriting files. Thanks for reporting this. I also released 2.02 which has a couple of bug fixes.
Regarding your last problem, it looks like you did not enter an API key. Can you try to download version 2.02 and after you entered the API key from ecobee dev and click on getpin, go to the variables and see if the API_key variable is populated?

Unfortunately my Ecobee device refuses to render in AltUI now. I cleaned out all the files, removed the plugin, deleted the old device and reinstalled from scratch. I see it showing up in the logs that it’s setup and waiting for the PIN to be entered, however it’s not showing up in AltUI at all now, its like the device is invisible for some reason :frowning:

In ALTUI try add a device (you probably deleted it) and use the D_Ecobee1.xml and I_Ecobee1.xml as your device files. Your device should come back up.
Alternatively, you could reinstall from the AltAppStore on version 2.02. Having old files should not be a problem anymore.

I tried both of those without any luck. I think the device is there, just not showing up in the device display for some reason…I?ll keep digging

Ok, looks like it was an issue with my browser oddly. I now see the device, and entered my API key in the control panel field and then clicked the ‘Get Pin’ button. The API Key field goes blank when I click the button. Same result as before, and I don’t see the Variable you mentioned in my list (see attachment).

Figured it out. Turns out the instructions to run the ‘luarocks’ command assumed you had the luarocks package installed and I didn’t! That’s why the https call was failing. Installed that package and now it’s all working as expected.

Thanks again for the plugin and the help (and openLuup!)

Glad you got it working! And thank you for the report! I think if you have a recent install of openLuup, https would be embedded. It was not at the beginning but I had installed luarock on mine a while ago and forgot about it.
I will update the instructions in a bit.