actionControlThermostat

[sjmn]

Thanks for writing this plugin. Should I expect to be able to change thermostat modes? Here's what I see when I try:
Ecobee Error plugin does not define method actionControlThermostat

[rapamatic]

I forked the code and am working on the ability to control the thermostat. So far I've added the ability to change modes and set points. You can download the two-way_control branch in my fork of the code if you want to check it out. Its working for me, but not quite ready to pull back here to the main code.

[sjmn]

I figured it was early yet. I'll wait till it's in the main code, thanks.

[rapamatic]

It just depends on how adventurous you want to be. I'm running it fine on my setup, with both ecobee3 and the older ecobee smart. The control functionality is a bit basic now, mostly because the indigo control paradigm is a bit different than ecobee's, so its a bit tough to map functions 1 to 1.... Any feedback or ideas on how you'd like to control your ecobees from Indigo would be greatly appreciated.

[trinchet]

I have 3 Ecobee3 thermostats - I'm happy to help test this plugin as needed. I am also learning python and can contribute there too. I would suggest starting simple by communicating a set point adjustment to the device in it's current mode. Let me know how I can help

[rapamatic]

trinchet - we can adjust setpoints and HVAC mode in the current copy in my fork - I'm going to put in a pull request tonight on those changes, but you can grab it from my account if you want. That stuff is fairly easy.... although I had to set an arbitrary amount of time on the setpoint hold - I choose 4 hours... The indigo thermostat model doesn't have a mechanism to adjust how long the hold should be set for, nor do I see an ability to resume the HVAC schedule from within Indigo - so I think we may need custom functions to do a lot of that...

It seems the Indigo paradigm is more for non-programmable thermostats, or they assume you'll do all the HVAC scheduling in Indigo... I tend to like to rely on the standalone lighting/HVAC/etc. systems to control as much functionality as possible, leaving Indigo to just be the "icing on the cake" or tie the systems together - that way if my indigo server or the ecobee server or my internet connection (the plugin talks to ecobee's API, NOT direct to the t-stats) flakes out, my HVAC schedules still run... but happy to hear other opinions on that matter too!

[trinchet]

Sounds Good rapamatic - 

I will check tonight and let you know if I have any trouble.  I agree with having the vendor manage it's system and Indigo act as a secondary control.  I am planning a trigger that checks for an excessive heat threshold.  If Indigo senses and fires this trigger the set points get updated on the ecobee.  4 hours seems like a perfect window as the trigger will fire again if it needs to.

I'll send you my comments after I get it running and testing.

RT

From: rapamatic [email protected]
To: jdhorne/indigo-ecobee-plugin [email protected]
Cc: trinchet [email protected], Comment [email protected]
Sent: 5/24/2016 5:51 PM
Subject: Re: [jdhorne/indigo-ecobee-plugin] actionControlThermostat (#4)

trinchet - we can adjust setpoints and HVAC mode in the current copy in my fork - I'm going to put in a pull request tonight on those changes, but you can grab it from my account if you want. That stuff is fairly easy.... although I had to set an arbitrary amount of time on the setpoint hold - I choose 4 hours... The indigo thermostat model doesn't have a mechanism to adjust how long the hold should be set for, nor do I see an ability to resume the HVAC schedule from within Indigo - so I think we may need custom functions to do a lot of that...
It seems the Indigo paradigm is more for non-programmable thermostats, or they assume you'll do all the HVAC scheduling in Indigo... I tend to like to rely on the standalone lighting/HVAC/etc. systems to control as much functionality as possible, leaving Indigo to just be the "icing on the cake" or tie the systems together - that way if my indigo server or the ecobee server or my internet connection (the plugin talks to ecobee's API, NOT direct to the t-stats) flakes out, my HVAC schedules still run... but happy to hear other opinions on that matter too!
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[jdhorne]

I've merged the changes from @rapamatic into my develop branch. If we're cool with it after a bit of poking, I can build an official release.

[rapamatic]

I'll keep testing it on my end, but since all setups are different, @sjmn and @trinchet , could you guys take a look also?

I think the next thing to work on is adding custom functions to the plugin to allow users to specify how long to have the setpoint hold for - as opposed to the 4 hour assumption in place now...

[trinchet]

I've done some preliminary testing:

3 thermostats tested -

• set point cool change - PASSED
• set heat point change - PASSED
• set mode to OFF - PASSED
• set mode to COOL - PASSED
• set mode to HEAT - PASSED
• reloaded plugin multiple times to verify tokens retained - PASSED

I know this is expected, but just documenting -

• I created a test action to set the mode to away and got an error
  "Plugin does not define the method setAwayStatus"
• I created a test action to set the mode to home (Away unchecked) and got an error
  "Plugin does not define the method setAwayStatus"

Seems to be working repeatedly with the above use cases.

• Trinchet

On May 25, 2016, at 12:19 PM, Jason Horne [email protected] wrote:

I've merged the changes from @rapamatic into my develop branch. If we're cool with it after a bit of poking, I can build an official release.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[rapamatic]

I don't personally use home/away status, but I think that is something I can easily add - I'll fork/pull request tonight, unless Jason gets to it first

[trinchet]

One additional finding:

If a thermostat is configured so that its hold action is set to "Until the next scheduled activity", it ignores the 4 hour hold assumption. This is a good thing, since it mimics how you would expect it to function if you just walk up manually and change the set point.

A Home/Away action may be useful to some, but I think a specific set point would be the most common used action. (for example, set to COOL, 78 degrees for "x hours" or "until next scheduled activity" - would be perfect)

-trinchet

[trinchet]

Earlier I wrote "A Home/Away action may be useful to some, but I think a specific set point would be the most common used action. (for example, set to COOL, 78 degrees for "x hours" or "until next scheduled activity" - would be perfect)"

Ignore that - I didn't realize this can be accomplished with out of the box thermostat actions. Works like a charm!

-trinchet

[trinchet]

Additional Testing feedback - 

• Temperature Sensors reporting in accurate temps - PASSED (compared to thermostat values all check)
• Repeated tests of incremental set point adjustments - PASSED
• Set triggers and actions to automatically adjust set points given events - PASSED

Defects discovered:

• Rebooting Mac running indigo loses authentication settings.
• Ecobee Action - Set Away Status reports "plugin does not define method setAwayStatus"

Other than those 2 defects I can't find any issues.  Looks good!

RT

From: rapamatic [email protected]
To: jdhorne/indigo-ecobee-plugin [email protected]
Cc: trinchet [email protected], Mention [email protected]
Sent: 5/25/2016 12:36 PM
Subject: Re: [jdhorne/indigo-ecobee-plugin] actionControlThermostat (#4)

I'll keep testing it on my end, but since all setups are different, @sjmn and @trinchet , could you guys take a look also?
I think the next thing to work on is adding custom functions to the plugin to allow users to specify how long to have the setpoint hold for - as opposed to the 4 hour assumption in place now...
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[trinchet]

Testing looks good on my end. 3 thermostats and 7 sensors all report and can be managed.

I set a trigger to send an email alert and activate an exhaust fan if temperatures in a computer room exceed a certain threshold on an ecobee sensor (the sensor is not participating in ecobee thermostat activities or schedules so it acts as a standalone device). To test I have a dumb thermometer in the room and so far reporting is accurate and timely.

Also set a trigger to set temps based on certain events. Works well and resumes schedule on next interval which is how I think it should work.

One other note: Rebooting of the server will retain ecobee token credentials sometimes and other times it won't and requires re-authentication.

The only other "nice to have" for some people would be the home / away function, but I think it's a lower priority.

[rapamatic]

I did not test keeping authentication during a reboot. My guess is that it may not be saving the new tokens when the plugin abruptly stops running during a reboot. I will look into that when I'm back from vacation next week. I think home/away should be fairly easy, we just have to define a custom function for the thermostat device... I can take a look at that too next week.

[rapamatic]

By the way - thanks for all you detailed testing on this. With all the different ecobee devices and install scenarios its good to try it on as many systems as we can.

[jdhorne]

Yes, thanks to both of you @rapamatic and @trinchet for all the work you've contributed. I'm running the develop branch myself and haven't yet run into any issues. It's super nice not to lose authentication on restart!

Not sure why the rebooting would be different; the plugin seems to save the credentials every time they are regenerated, so they should still work after a reboot, right? That is, unless you cross the magical one hour expiration boundary before the plugin starts up again.