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:
[ol][li]Save the attached file on your computer.[/li]
[li]In the Vera web UI, go to Apps → Develop Apps → Luup files.[/li]
[li]Upload the attached I_Ecobee1.xml file, first checking the “Restart Luup after upload”.[/li][/ol]
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.
[quote=“watou, post:20, topic:174457”]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.)[/quote]
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.
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 [tt]LastUpdate[/tt] variable (from the service ID [tt]urn:micasaverde-com:serviceId:HaDevice1[/tt]) will not be updated. If the current time (seconds since the Epoch) is too different from [tt]LastUpdate[/tt] (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 [tt]CommFailure[/tt] 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!
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.
I think the [tt]CommFailure[/tt] 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 [tt]CommFailure[/tt] 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.
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.
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?
[quote=“saratankard, post:27, topic:174457”]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?
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.)
Question: On the Ecobee TStat when a message pops up there is a "“View details” option as well which you can navigate to with the arrows on the TStat. I didn’t see anything in the documentation, so just wanted to confirm that there currently does not exist a way to edit this text field (by choosing a different parameter for instance).
Observation: I noticed on my EcoBee TStat in Mios there is no ModeTarget service variable for the urn:upnp-org:serviceId:HVAC_UserOperatingMode1 service. This was causing a few errors in my LUUP code when I went to change the TStat from CoolOn to Off, etc because the service variable was reporting a nil value. I went ahead and added the service, variable, and value manually in Mios in the advanced settings and all works fine now, but might be nice to have this feature added.
Hi Sara,
I’m afraid I don’t understand what you are looking for regarding messages on the thermostat. Please elaborate and I will attempt to answer!
You are correct that there is no actual ModeTarget device variable, and after looking at the code I can see that a call to the GetModeTarget action will always return “AutoChangeOver” regardless of the actual setting (a definite bug).
But I wonder why you would query the ModeTarget variable or call the GetModeTarget action. ModeTarget is the variable that (should) hold the mode to which you are trying to set the actual thermostat, while ModeStatus is the variable which holds the actual, current mode. So normally you would want to be querying the ModeStatus variable (or calling GetModeStatus) to get the current HVAC mode. The UPnP spec separated the Target and Status concepts, knowing that an attempt to change the mode (with SetModeTarget) might be delayed from actually effecting the change, which is then finally reflected in GetModeStatus.
Also note that the above is a completely different subject from the current running state (ModeState) – whether the thermostat is currently calling for cooling, heating, is idle, etc. The ecobee API doesn’t report the current running state last I checked, so there is currently no way to know if the thermostat is currently calling for heating or cooling.
On the Ecobee thermostat when a message is received I see three things on the display screen: 1) Desired message displayed message in a large blue box and 2)“Ok” 3) “View Details”. As a user, you can either click “Ok” to accept the message or click “ViewDetails”. I am wondering if there is a way if there is a way to input text so when the user clicks “View Details” another sub-message appears. As of right now when you click View Details, the original message is just displayed. Let me know if this makes more sense.
So, I was using the SetModeTarget action to set the ModeTarget variable to Off or CoolOn and this is what caused the error as no such variable existed. I was not actually querying the ModeTarget variable or using the GetModeTarget action. So, what you are saying makes sense but I don’t believe it applies to what I am doing.
My guess is that the “View Details” button, in the case of text messages, would display the entire message if it were a really long message, while what is initially shown might be truncated if it’s too long for the blue box. I can’t test it at the moment but that would make sense. The ecobee API only lets me send one message, up to 500 characters long. No additional fields are offered.
Are you saying that you are seeing an error calling the SetModeTarget action? The UI5 and mobile apps can use that action without complaint (unless there is something in the logs I’ve missed. If you have any log output you would like me to look at, please send it along.)
To get the current HVAC mode, query the ModeStatus variable or call the GetModeStatus action.
[quote=“hadiesper, post:35, topic:174457”]Hi Everyone, I have a quick question before purchasing the Ecobee Smart Thermostat.
I am going to buy 12 of them. Will this plugin be able to support all at once?
Has anyone tried to control the thermostat through SQ Remote.[/quote]
During development of the plugin I saw it managing 15 thermostats from the one plugin instance. Each thermostat has a thermostat device, a humidity device and a home/away switch device, so in that case the one plugin instance created 45 devices. The large number of devices can be managed using rooms, categories, etc.
I only saw the plugin work with the Smart Si model but I have no reason to believe that it would not work with ecobee’s other thermostats.
All monitoring and control goes through ecobee’s web services, but I’ve not seen any performance or reliability issues as long as you have a solid Internet connection (and good wi-fi co-located with the thermostats).
I have managed my own Smart Si via the AutHomation Android app with no issues. I suspect SQ Remote will also work but I’ve not heard.
I have noticed a weirdness on the EcoBee plugin that seems to occur sometimes after a restart. It seems when the luup engine is overloaded (causing a restart) both the cool and the heat go to their respective temperature extremes (-400, +400). It does not occur after EVERY restart, so I am trying to re-create the error in order to solidify more specific events which will be more helpful for you in thinking about this problem. In the meantime, I was wondering if you had ever observed such behavior?
I also have noticed, rarely, but sometimes the plugin loses comms with the Ecobee server, requiring a re-entry of the PIN#. I know you have noted in your github notes that sometimes external events may cause this. Are there any events in particular you have noticed that we can be wary of in order to predict when a lost comm is more likely to occur? Or better yet, would it be possible to add a sent alert or notification when the ecobee loses comms?
Thanks again for all your hard work – it is not under-appreciated! 8)
I have not seen anything like you are describing, but when you say “go to their respective temperature extremes” do you mean that the UI is showing that the setpoints are at these extremes but checking at ecobee.com verifies that the UI is wrong, or that the plugin sets the setpoints as such to the thermostat, or what exactly? There is nothing in the plugin that will set these values to those extremes. Make sure you have debug logging (LogLevels must include 35 in the list) so if you are able to re-create this situation, we can have logs to examine. Sorry nothing comes to mind on this one, but maybe if you have more detail, it would help me think of something to try or inspect.
I too have noticed this rare occurrence, requiring me to press “Get PIN” and then enter the new PIN in the ecobee.com portal. It might be weeks and weeks before this happens, and I have no idea what is causing it. I have always assumed that it was the consequence of some required maintenance going on at Ecobee with their API, where existing tokens need to be flushed, but that is just a wild guess. I can’t think of anything in the plugin that would be falsely reporting the need for a new PIN. Look in your logs for “Encountered authorization error; forgetting tokens.” and look for messages immediately preceding it to see what is being reported as to the cause. The set of errors that would tell the plugin to forget its auth_token are:
invalid_request = "The request is malformed. Check parameters.",
invalid_client = "Authentication error, invalid authentication method, lack of credentials, etc.",
invalid_grant = "The authorization grant, token or credentails are expired or invalid.",
unauthorized_client = "The authenticated client is not authorized to use this authorization grant type.",
unsupported_grant_type = "The authorization grant type is not supported by the authorization server.",
invalid_scope = "The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner.",
not_supported = "HTTP method not supported for this request.",
account_locked = "Account is temporarely locked.",
account_disabled = "Account is disabled.",
authorization_pending = "Waiting for user to authorize application.",
authorization_expired = "The authorization has expired waiting for user to authorize.",
slow_down = "Slow down polling to the requested interval."
If the ecobee API returns any of these except “authorization_pending,” then the plugin will throw away its auth_token and require you to request a new PIN. Perhaps check with your contact at Ecobee to determine if this list of API error returns is too long, and that some of these returns would not suggest that the session needs to be discarded.
On the subject of knowing when this happens, it is relatively straightforward for one to set up an automated notification when the plugin enters the state where it needs the user to request a new PIN. It is also easy to use the GetPIN UPnP action to perform the request for a new PIN, but much trickier (and outside the scope of the plugin) to automate the entering of that PIN in the ecobee.com web portal. So the process of knowing when authorization has been lost and then re-establishing authorization is nearly fully automatable (but that last step would be pretty tricky unless you had a web page automated testing tool, for example).
My pleasure. Please report back here what you can so other plugin users can benefit, and thanks!
do you mean that the UI is showing that the setpoints are at these extremes but checking at ecobee.com verifies that the UI is wrong, or that the plugin sets the setpoints as such to the thermostat, or what exactly?
What I observed was the setpoints in the UI at these extremes. Perhaps a bit stupidly, I did not check in ecobee portal or the thermostat itself. I have not been able to re-create the error, but once I do I will post on here.
Look in your logs for "Encountered authorization error; forgetting tokens." and look for messages immediately preceding it to see what is being reported as to the cause.The set of errors that would tell the plugin to forget its auth_token are: (.....) If the ecobee API returns any of these except "authorization_pending," then the plugin will throw away its auth_token and require you to request a new PIN. Perhaps check with your contact at Ecobee to determine if this list of API error returns is too long, and that some of these returns would not suggest that the session needs to be discarded.
Thanks for all the valuable information on error codes for the logs. I should have enough to go on to investigate myself and report back. Also, I will follow-up with an ecobee rep to see if all really are necessary to discard the session.
On the subject of knowing when this happens, it is relatively straightforward for one to set up an automated notification when the plugin enters the state where it needs the user to request a new PIN.
It would be quite valuable for us to have a notification when the plugin enters this state. Is this something relatively straightforward that I could implement, or do you mean easy for you to add to the plugin? I would love to make that happen! If you could tell me a bit more about how to simply add alerts when the EcoBee has lost comms (but not re-enter a new pin like you discuss), that would be very helpful.
