Plug-in for ecobee thermostats in development

[watou]

I got my API!

Thank you WATOU, your plug-in works beautifully!

Thanks for the positive feedback!  Very glad to hear.

watou

[theal]

watou,

thanks for your plug-in!

a couple questions after playing with Smart tstat & plag-in:
- Home/Away buttons gives 'Invalid Service' error
- Resume button works, but forces Programming for 10-15 minutes, i.e. during this period a temperature can't be changed to Hold; it snaps back to Programming setting
- my Hold Action is set to "Ask Me". What is a Hold timing default in "Ask Me" mode and is it user settable? Any thoughts on implementing Hold timing options?
It would be great to have
 - QuickSave/Economy button state
 - Wattage reporting working
 - Heat/AC/Fan ON/OFF state reporting

PS I'm a bit confused about your instructions for scope/selectionType/selectionMatch settings to enter smartWrite/thermostats/list of thermostat identifiers.
During the setup smartWrite was automatically set to 'registered' and both my thermostats seem to work. I did not enter tstats IDs as I was not really clear if I had to do it anyway and how/where to enter them.

Thanks again for great work!

[watou]

thanks for your plug-in!

You're welcome!

- Home/Away buttons gives 'Invalid Service' error

What are the specific models of your ecobee thermostats?  I have a single EB-SMARTSi-01 here that I've done testing against, and I've only ever gotten "view only" access to a collection of other ecobee thermostats.  There is code for "EMS" thermostats in the plugin which I've not yet been able to test.  I would appreciate part of your /var/log/cmh/LuaUPnP.log file around the time of the 'Invalid Service' error to see if it leads me in the direction of finding the cause.

When I press the Away button, it sets an indefinite hold event that changes the heat and cool setpoints to the quick-save setback and set forward increments.  The Home button issues a ResumeProgram function to clear the hold.  This is for non-EMS thermostats.  For EMS thermostats, setting Away performs a setOccupied(false) function (a special hold type).

- Resume button works, but forces Programming for 10-15 minutes, i.e. during this period a temperature can't be changed to Hold; it snaps back to Programming setting

I will have to research what "forces Programming for 10-15 minutes" means.  Could you elaborate or send me a doc link?

- my Hold Action is set to "Ask Me". What is a Hold timing default in "Ask Me" mode and is it user settable? Any thoughts on implementing Hold timing options?
It would be great to have

Currently all holds are set indefinitely because I don't know how to semantically match other hold times to Vera/UPnP service types.  I could possibly add a variable on the Advanced tab that let you choose a different hold time from indefinite, but I will have to know more about potential use cases to get it right.

- QuickSave/Economy button state

I asked for a way to implement QuickSave from the plugin, just as the user can do from the web portal, and I don't think that is in the current API.  However, the "Away" button when used with non-EMS thermostats attempts to detect/set a setback/forward hold event like QuickSave does.  I think that if we can figure out the 'Invalid Service' error that you get (but that I can't reproduce here), this might help address this point.

- Wattage reporting working

Like in the Nest plugin, the UserSuppliedWattage device variable is just a placeholder in the code for wattage reporting.  Do you have any implementation ideas for how to make this meaningful?

- Heat/AC/Fan ON/OFF state reporting

This was not in the ecobee API last time I checked, but I will look again after the API is officially public and report back.

PS I'm a bit confused about your instructions for scope/selectionType/selectionMatch settings to enter smartWrite/thermostats/list of thermostat identifiers.
During the setup smartWrite was automatically set to 'registered' and both my thermostats seem to work. I did not enter tstats IDs as I was not really clear if I had to do it anyway and how/where to enter them.

If you are a non-commercial customer, you can typically skip the entire section of the README regarding setting selectionType and selectionMatch.  Only larger infrastructure users would typically be concerned with viewing/controlling specific subsets of their managed thermostats.  If you have any suggestion on how to make the documentation less confusing, please pass it along!

Thanks very much for the report.

watou

[Michele]

Michele,

How did you get PIN code login working?

I just clicked the "Get PIN" button on the ecobee device in UI5.  Teen I logged in to Ecobee's own gateway, went to Settings -> My Apps, typed in the PIN in the gray box and clicked on "Install App".  I then added "Vera Home Controllers" and a few minutes later my thermostats appeared in UI5.

I am having a problem though of having to go through this process every three days or so.  I get a message in the Vera log that says

"ecobee : Not yet authorized. Press 'Get PIN' once; wait for PIN; enter at ecobee.com."

After going through the whole process again, it works - until the next time.  What's up with that?

[watou]

I am having a problem though of having to go through this process every three days or so.  I get a message in the Vera log that says

"ecobee : Not yet authorized. Press 'Get PIN' once; wait for PIN; enter at ecobee.com."

After going through the whole process again, it works - until the next time.  What's up with that?

Let's not forget that the API is still not officially available!

Edit: not to discourage you from reporting whatever oddities you see! 

(I just think the programmers at ecobee are probably busily readying for GA, might have to do cleaning out of old tokens or other pre-launch prep.)

[watou]

To anyone who has installed the 0.7 (app store) beta of the ecobee thermostat plugin:

Please install the attached file on your Vera as soon as possible.  I've discovered a strange bug in Vera (1.5.408 anyway) that can lead to over-polling of ecobee.com.  This file will close that potential.

To install the attached file:

• Save the attached file on your computer.
• In the Vera web UI, go to Apps -> Develop Apps -> Luup files.
• Upload the attached I_Ecobee1.xml file, first checking the "Restart Luup after upload".

If you want to verify that you correctly applied the fix, the plugin will now log that it is version 0.8 in your Vera's /var/log/cmh/LuaUPnP.log file.

Thanks,
watou

P.S. If you installed the ecobee thermostat plugin but you do not currently have access to "My Apps" in the ecobee web portal, please uninstall the plugin for the time being, until such time as you have My Apps access, and only install 0.8 of the plugin once it's available in the app store.

[Michele]

Let's not forget that the API is still not officially available!

Edit: not to discourage you from reporting whatever oddities you see! 

(I just think the programmers at ecobee are probably busily readying for GA, might have to do cleaning out of old tokens or other pre-launch prep.)

That's probably it - that problem has not happened again since then.  This app is actually better than Ecobee's official web interface.

I do have a suggestion for a feature that might not be too hard to do (I haven't checked the API docs).  How about adding an alert if you lose communication with the thermostat?  That could give you an early warning of trouble.

[watou]

This app is actually better than Ecobee's official web interface.

Wow!  That's great to hear.

I do have a suggestion for a feature that might not be too hard to do (I haven't checked the API docs).  How about adding an alert if you lose communication with the thermostat?  That could give you an early warning of trouble.

I would be happy to implement whatever is considered the "standard" way for doing this in Vera, but it might be achievable already without putting anything specific in the plugin.

There are two points of connectivity that could fail -- (1) from your Vera to ecobee.com, and (2) from ecobee.com to the thermostat. 

If the first happens, then the thermostat's LastUpdate variable (from the service ID urn:micasaverde-com:serviceId:HaDevice1) will not be updated.  If the current time (seconds since the Epoch) is too different from LastUpdate (say, 600 seconds or pick a number), then that would indicate that the plugin has not learned the thermostat's status in about that long.  I imagine some kind of automation could be kicked off.  In the second case, where ecobee.com can't communicate with the thermostat (by its own measure), then the CommFailure variable will be set to 1, another case where automation could be triggered.

Now this isn't as "user-friendly" as it could be, but I would be interested in implementing an enhancement as long as it's consistent with how other plugins well address the same issue.  Any thoughts on this are very welcome!

Regards,
watou

[Michele]

Good question.  I have no experience with other "cloud" type devices.  All my devices talk directly to Vera. 

Case 1 - loss of communication between Vera and ecobee.com.  If Vera itself has gone down, then you're already done - doing anything will be impossible.

Case 2 - loss of communication between ecobee.com and the thermostat.  That can happen a bunch of different ways: ecobee.com itself goes down (and that seems to happen about once a year), your router, modem, or ISP goes down, your wi-fi gets wedged (neighbor installs new router on your channel), or the thermostat itself fails.

If ecobee.com is up and Vera is still alive, odds are the thermostat itself has failed - that's what we want to know.

And while we're at it, is there a way to get ecobee alerts via the plugin?  One of my thermostat's dry contact inputs is connected to the A/C float switch.  If that trips, I get an email form ecobee but it's something you really want to know about right away.  For example, using VeraAlerts, I could get a notification right on my phone.  That would be cool.

[watou]

If ecobee.com is up and Vera is still alive, odds are the thermostat itself has failed - that's what we want to know.

I *think* the CommFailure variable will be set to 1 in the above case, but I can't say for certain because the specific logic that's behind the ecobee API for determining if a thermostat is "connected" is not visible to the API user.  I tested it here by simply removing power from my thermostat, saw that CommFailure went to 1, plugged it back in, and shortly thereafter saw it go back to 0.  I imagine that a sufficiently "dead" thermostat, aside from power loss, would show up in the API the same way, but I can't say for sure.

And while we're at it, is there a way to get ecobee alerts via the plugin?  One of my thermostat's dry contact inputs is connected to the A/C float switch.  If that trips, I get an email form ecobee but it's something you really want to know about right away.  For example, using VeraAlerts, I could get a notification right on my phone.  That would be cool.

I would very much like to know the "clean" way that a Vera plugin generates textual message notifications.  I believe the ecobee API would give me the ability to push alerts out, but I haven't investigated the proper way to surface these in the plugin.  Any ideas where I should look?  I can post in the Plugins and Plugin Development area here, but maybe someone reading this has ideas?  If not, I will start digging.

watou

[watou]

Just a note that I've (finally) updated the README online to reflect the current ecobee thermostat plugin release 0.8:

http://cocu.la/vera/ecobee/README.md.

The source code for the plugin (minus the API library) is also now published at GitHub:

https://github.com/watou/vera-ecobee-thermostat

watou

[saratankard]

Really curious about the SendMessage action call.  I tried using the below code I *think* this is correct, but I didn't see a message pop up on the TStat. Am I using the syntax in the way you intended?

dev_num=237
service_id="urn:ecobee-com:serviceId:Ecobee1"
action = "SendMessage"
arguements = {Direction="In", Parameter="MessageText",Value="Door 5 Open"}

luup.call_action(service_id,action, arguements, dev_num)

[watou]

Really curious about the SendMessage action call.  I tried using the below code I *think* this is correct, but I didn't see a message pop up on the TStat. Am I using the syntax in the way you intended?

dev_num=237
service_id="urn:ecobee-com:serviceId:Ecobee1"
action = "SendMessage"
arguements = {Direction="In", Parameter="MessageText",Value="Door 5 Open"}

luup.call_action(service_id,action, arguements, dev_num)

I think the argument syntax in your call is incorrect (see http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_call_action).  Try something like this:

Code: [Select]

local service_id = "urn:ecobee-com:serviceId:Ecobee1"
local action = "SendMessage"
local args = { MessageText = "Door 5 Open" }
local dev_num = 237
luup.call_action(service_id, action, args, dev_num)

I can't test this myself at the moment, but I think if you change the args accordingly it should work.  Also note that 237 should be either the main "Ecobee" device, in which case the message text should appear on all controlled thermostats, or 237 should be a specific thermostat device.

Regards,
watou

Edit: I think I had quotes around "MessageText" above which would be incorrect syntax.  (I should always test my examples before sharing them.)

[watou]

Sara, my example had a syntax error in it -- sorry!  Please let us know if you get your code to send messages to the thermostat's display.  Thanks!

[saratankard]

Works! Thanks so much