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.

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).

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!

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.

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.

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.

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.

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.

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.

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.

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.

1) 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?

2) 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?

1) 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 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.

2) 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?

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).

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.

Quote

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.

Quote

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.

I would love to get ideas on what would be desired and any ideas on approaches. All I know is a UserSuppliedWattage device variable, but what code does with it is still a mystery to me. There might be other standard approaches for tracking HVAC energy consumption in Vera that I just don't know about. Thoughts?

Also, have you ever had the plugin prompt you to request a new PIN seemingly out of the blue? If so, did that event seem to correlate to anything else? I don't have much user feedback about the plugin, and it would really help track down this oddity.

Related to energy, I was planing to implement a work around for my HVAC split system to correctly report wattage as suggested in this post http://forum.micasaverde.com/index.php?topic=13301.0.However, I noticed that HVAC actual State ('HVAC_OperatingState1' and 'FanStatus') are missing in thermostat Notification setup. Would it be possible to add them?

Since July I think I had to reset PIN three times.I don't think it correlated with local setup; most likely something on Ecobee server.

Perhaps you can test with luup.variable_get("urn:micasaverde-com:serviceId:EnergyMetering1", "KWH", <deviceID>).

Related to energy, I was planing to implement a work around for my HVAC split system to correctly report wattage as suggested in this post http://forum.micasaverde.com/index.php?topic=13301.0.However, I noticed that HVAC actual State ('HVAC_OperatingState1' and 'FanStatus') are missing in thermostat Notification setup. Would it be possible to add them?

I suspect that the issue is that the Ecobee API, last I checked, has no way to report the current operating state, such as Heating, Cooling or Idle, or the current FanStatus (which is always reported as Off). And so the plugin can't either. Lacking that information, there would be no way to count energy consumption based on the UserSuppliedWattage setting, even though you may have supplied the values. I suppose my adding UserSuppliedWattage was misleading if there is no way with the present Ecobee API to know when the system was heating or cooling or if the fan was currently running.

If you could lobby Ecobee to add the current running HVAC and fan states to their API, then maybe enough customers asking for this API feature could tip the scales. Then I would update the plugin to make use of it and UserSuppliedWattage settings would most likely start being of value (plus there would be new automation trigger possibilities).

Since July I think I had to reset PIN three times.I don't think it correlated with local setup; most likely something on Ecobee server.

I believe that the next plugin release will remove this rare need to request and register a new PIN. 0.8 of the plugin is overly aggressive in throwing away authentication information on certain errors, and I was recently informed that this isn't needed.

I suspect that the issue is that the Ecobee API, last I checked, has no way to report the current operating state, such as Heating, Cooling or Idle, or the current FanStatus (which is always reported as Off). And so the plugin can't either. Lacking that information, there would be no way to count energy consumption based on the UserSuppliedWattage setting, even though you may have supplied the values. I suppose my adding UserSuppliedWattage was misleading if there is no way with the present Ecobee API to know when the system was heating or cooling or if the fan was currently running.

If you could lobby Ecobee to add the current running HVAC and fan states to their API, then maybe enough customers asking for this API feature could tip the scales. Then I would update the plugin to make use of it and UserSuppliedWattage settings would most likely start being of value (plus there would be new automation trigger possibilities).

I do see Wattage reported when the Heat is On (first number from UserSuppliedWattage variable).What triggers this Wattage display? Is there any way to see/used this trigger/status?

From your post I understand that Ecobee's API does not report weather On status is Heating or Cooling, however you can derive that if thermostat is in non-Auto mode state.Alternately, one can adjust wattage seasonally.