Author Topic: Plug-in for ecobee thermostats in development  (Read 81892 times)

Offline saratankard

  • Newbie
  • *
  • Posts: 19
  • Karma: +0/-1
Re: Plug-in for ecobee thermostats in development
« Reply #30 on: August 22, 2013, 11:04:53 am »
One follow-up question and one observation:

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.

Thanks again for a great plugin!!

« Last Edit: August 22, 2013, 12:00:34 pm by saratankard »

Offline watou

  • Hero Member
  • *****
  • Posts: 866
  • Karma: +43/-12
Re: Plug-in for ecobee thermostats in development
« Reply #31 on: August 22, 2013, 01:30:20 pm »
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).

Edit: I opened an issue to keep track of this bug here: https://github.com/watou/vera-ecobee-thermostat/issues/4

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.

Please let me know if this makes sense.

Thanks again for a great plugin!!

You're very welcome!

watou
« Last Edit: August 22, 2013, 01:33:56 pm by watou »

Offline saratankard

  • Newbie
  • *
  • Posts: 19
  • Karma: +0/-1
Re: Plug-in for ecobee thermostats in development
« Reply #32 on: August 22, 2013, 04:49:50 pm »
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.


Offline watou

  • Hero Member
  • *****
  • Posts: 866
  • Karma: +43/-12
Re: Plug-in for ecobee thermostats in development
« Reply #33 on: August 23, 2013, 04:21:21 am »
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.

I hope this helps!

Regards,
watou

Offline hadiesper

  • Full Member
  • ***
  • Posts: 111
  • Karma: +1/-14
    • Shifra Smart Homes
Re: Plug-in for ecobee thermostats in development
« Reply #34 on: September 11, 2013, 08:27:07 am »
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.
HadiEsper
http://www.shifrasmarthomes.com - 20 Fibaro Dimmers, 3 Thermostats, 1 Energy Meter, 2 Motion Sensors, 1 Temp/Hum Sensor, 2 VERAs, 5 Sonos Play:3 Zones, 2 TVs on GC iTach IR Control, 1 Apple TV on GC iTach, 2 Satellite Receivers on GC iTach, 1 XMBC MediaCenter, 10TB Synology

Offline watou

  • Hero Member
  • *****
  • Posts: 866
  • Karma: +43/-12
Re: Plug-in for ecobee thermostats in development
« Reply #35 on: September 11, 2013, 08:41:17 am »
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.

Regards,
watou

Offline hadiesper

  • Full Member
  • ***
  • Posts: 111
  • Karma: +1/-14
    • Shifra Smart Homes
Re: Plug-in for ecobee thermostats in development
« Reply #36 on: September 15, 2013, 04:34:11 am »
Thanks Watou. Your response was very helpful :)

HadiEsper
http://www.shifrasmarthomes.com - 20 Fibaro Dimmers, 3 Thermostats, 1 Energy Meter, 2 Motion Sensors, 1 Temp/Hum Sensor, 2 VERAs, 5 Sonos Play:3 Zones, 2 TVs on GC iTach IR Control, 1 Apple TV on GC iTach, 2 Satellite Receivers on GC iTach, 1 XMBC MediaCenter, 10TB Synology

Offline saratankard

  • Newbie
  • *
  • Posts: 19
  • Karma: +0/-1
Re: Plug-in for ecobee thermostats in development
« Reply #37 on: November 13, 2013, 09:55:21 am »
2 questions :)

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?

Thanks again for all your hard work -- it is not under-appreciated! 8)

Offline watou

  • Hero Member
  • *****
  • Posts: 866
  • Karma: +43/-12
Re: Plug-in for ecobee thermostats in development
« Reply #38 on: November 13, 2013, 10:27:13 am »
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:

Code: [Select]
  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).

Thanks again for all your hard work -- it is not under-appreciated! 8)

My pleasure.  Please report back here what you can so other plugin users can benefit, and thanks!

Regards,
watou

Offline saratankard

  • Newbie
  • *
  • Posts: 19
  • Karma: +0/-1
Re: Plug-in for ecobee thermostats in development
« Reply #39 on: November 21, 2013, 10:19:07 am »
Quote
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.

Thanks again, as usual, for everything!

Offline theal

  • Sr. Newbie
  • *
  • Posts: 49
  • Karma: +0/-3
Re: Plug-in for ecobee thermostats in development
« Reply #40 on: December 05, 2013, 02:18:43 pm »
Watou,

I have been using your plug-in for few month and it works great!
Thank you!

Any plans to implement Energy (Watts) reporting?

It would be very helpful to monitor as HVAC is the biggest energy hog  :'(

Thanks

Offline watou

  • Hero Member
  • *****
  • Posts: 866
  • Karma: +43/-12
Re: Plug-in for ecobee thermostats in development
« Reply #41 on: December 05, 2013, 03:05:21 pm »
I have been using your plug-in for few month and it works great!
Thank you!

You're very welcome, and thanks for speaking up.  I was really wondering who out there was using it.  I've gotten very little feedback, which is either good or bad. :)

Any plans to implement Energy (Watts) reporting?

It would be very helpful to monitor as HVAC is the biggest energy hog  :'(

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.

Regards,
watou

Offline theal

  • Sr. Newbie
  • *
  • Posts: 49
  • Karma: +0/-3
Re: Plug-in for ecobee thermostats in development
« Reply #42 on: December 05, 2013, 05:28:21 pm »
I think low feedback is a good thing - its working!
(btw, I don't see ecobee plug-in in Vera's Apps interface)

I have a very little experience with luup programming.
From what I read, it should be UserSuppliedWattage as described in http://wiki.micasaverde.com/index.php/Luup_UPnP_Variables_and_Actions#EnergyMetering1.
I'm not sure why Vera does not report energy consumption since dashboard displays correct wattage.
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?

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.

Thanks again for great plug-in

Offline watou

  • Hero Member
  • *****
  • Posts: 866
  • Karma: +43/-12
Re: Plug-in for ecobee thermostats in development
« Reply #43 on: December 05, 2013, 11:35:03 pm »
I think low feedback is a good thing - its working!
(btw, I don't see ecobee plug-in in Vera's Apps interface)

I hope that's it!  I do see the entry here: http://apps.mios.com/plugin.php?id=3586  or do you mean something else?

I have a very little experience with luup programming.
From what I read, it should be UserSuppliedWattage as described in http://wiki.micasaverde.com/index.php/Luup_UPnP_Variables_and_Actions#EnergyMetering1.
I'm not sure why Vera does not report energy consumption since dashboard displays correct wattage.

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.

Thanks again for great plug-in

You are very welcome, and thank you for the feedback!

watou

Offline theal

  • Sr. Newbie
  • *
  • Posts: 49
  • Karma: +0/-3
Re: Plug-in for ecobee thermostats in development
« Reply #44 on: December 06, 2013, 02:12:40 am »
Quote
I do see the entry here: http://apps.mios.com/plugin.php?id=3586  or do you mean something else?
I meant in Vera's interface Apps->Install Apps.

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

I will send Ecobee a request to to add running status in API.
Btw, I did see API documentation on Runtime stage reporting for heat and cooling https://www.ecobee.com/home/developer/api/documentation/v1/objects/ExtendedRuntime.shtml
Is it usable?

Thanks again