Polyglot V2 Ecobee Nodeserver

[Jimbo.Automates]

This is the official main thread for the Polyglot V2 Ecobee Nodeserver for https://www.ecobee.com Thermostats and sensors. 

The original author of this nodeserver is @einstein.42 but he is to busy with other things currently so I've agreed to help since @Michel Kohanim sent me a thermostat for testing.   There was not a main thread for this, so I've started this one for my first update.

I've only been using the thermostat for a day, and haven't received my room sensors yet so my knowledge is pretty limited on how it all works.  It's not actually currently installed, it's just powered up.Please move any discussions to this tread so we can all keep track.

[Jimbo.Automates]

Version 2.0.6 is released: https://github.com/Einstein42/udi-ecobee-poly#release-notes

It should be in the store within the hour.  This fixes most known problems except for a couple.

1. https://github.com/Einstein42/udi-ecobee-poly/issues/2
2. https://github.com/Einstein42/udi-ecobee-poly/issues/6

I'm going to look at the first one next, so just want to warn everyone that node addresses may change with the next release.

 

[beninsteon]

Issue 6 is a biggie .... 

Thanks for looking into this. Will test tomorrow

Ben

[Jimbo.Automates]

On 12/9/2018 at 7:04 PM, beninsteon said:

Issue 6 is a biggie .... 

Thanks for looking into this. Will test tomorrow

Ben

Yes, and it's a biggie to fix as well.  Feel free to comment here if you have a more indepth understanding of the api:  https://github.com/Einstein42/udi-ecobee-poly/issues/6

[automationgeek]

I had a chance to test it tonight, the Climate Type is working, the Hold Type seem odd as Permanent or Transition doesn't seem to change the behavior.

The is Schedule Mode is still not working, Here the trace stack :

2018-12-11 22:11:49,775 [Controller] [ERROR] _parseInput: failed 311013547759.runCmd(CLISMD) invalid literal for int() with base 10: '19.0'
Traceback (most recent call last):
  File "/root/.local/lib/python3.5/site-packages/polyinterface/polyinterface.py", line 759, in _parseInput
    self.nodes[input[key]['address']].runCmd(input[key])
  File "/root/.local/lib/python3.5/site-packages/polyinterface/polyinterface.py", line 663, in runCmd
    fun(self, command)
  File "/root/.polyglot/nodeservers/Ecobee/node_types.py", line 297, in cmdSetScheduleMode
    heatHoldTemp = int(self.getDriver('CLISPH'))
ValueError: invalid literal for int() with base 10: '19.0'

 

[Jimbo.Automates]

1 hour ago, automationgeek said:

I had a chance to test it tonight, the Climate Type is working, the Hold Type seem odd as Permanent or Transition doesn't seem to change the behavior.

 The is Schedule Mode is still not working, Here the trace stack :

2018-12-11 22:11:49,775 [Controller] [ERROR] _parseInput: failed 311013547759.runCmd(CLISMD) invalid literal for int() with base 10: '19.0'
Traceback (most recent call last):
  File "/root/.local/lib/python3.5/site-packages/polyinterface/polyinterface.py", line 759, in _parseInput
    self.nodes[input[key]['address']].runCmd(input[key])
  File "/root/.local/lib/python3.5/site-packages/polyinterface/polyinterface.py", line 663, in runCmd
    fun(self, command)
  File "/root/.polyglot/nodeservers/Ecobee/node_types.py", line 297, in cmdSetScheduleMode
    heatHoldTemp = int(self.getDriver('CLISPH'))
ValueError: invalid literal for int() with base 10: '19.0'

 

Thanks for trying.  What do you mean by "Hold Type"?  (I'm still learning this thermostat while trying to fix current issues)

That traceback is a different error, but an easy fix.  I have to decide if that goes in on it's own or part of one or both of the other 2 fixes which are both getting close.

 

[Jimbo.Automates]

Question for users of the Ecobee's and how this nodeserver should work.

1. Sensor ID's are not unique when you have multiple thermostats https://github.com/Einstein42/udi-ecobee-poly/issues/2

This will require everyone to delete the old sensor nodes in the Polyglot UI because deleting nodes from from python is broken in the current version of Polyglot.  Anyone have an issue with that?

2. Changing setpoint when program running changes the actual "comfort setting" https://github.com/Einstein42/udi-ecobee-poly/issues/6

It seems to make more sense to change the to a "Hold" when the setpoint is changed from the ISY?  and if so, what type of hold should it be?  https://www.ecobee.com/home/developer/api/documentation/v1/functions/SetHold.shtml I'm thinking nextTransition, but should it be indefinite?  Also, if the thermostat is already in a Hold, should that hold be canceled before adding a new one?  I think so. 

Both changes are close to ready, just want to make sure before releasing since I've only been using this guy for a few days, and not using it actually hooked up to anything.

- Jim

[automationgeek]

11 hours ago, Jimbo said:

Thanks for trying.  What do you mean by "Hold Type"?  (I'm still learning this thermostat while trying to fix current issues)

That traceback is a different error, but an easy fix.  I have to decide if that goes in on it's own or part of one or both of the other 2 fixes which are both getting close.

 

Permanent vs Transition, if you set permanent then is should stay on that setting until you decide to remove it. Transition should be until the next program kick in.

 

[automationgeek]

11 hours ago, Jimbo said:

Question for users of the Ecobee's and how this nodeserver should work.

1. Sensor ID's are not unique when you have multiple thermostats https://github.com/Einstein42/udi-ecobee-poly/issues/2

This will require everyone to delete the old sensor nodes in the Polyglot UI because deleting nodes from from python is broken in the current version of Polyglot.  Anyone have an issue with that?

2. Changing setpoint when program running changes the actual "comfort setting" https://github.com/Einstein42/udi-ecobee-poly/issues/6

It seems to make more sense to change the to a "Hold" when the setpoint is changed from the ISY?  and if so, what type of hold should it be?  https://www.ecobee.com/home/developer/api/documentation/v1/functions/SetHold.shtml I'm thinking nextTransition, but should it be indefinite?  Also, if the thermostat is already in a Hold, should that hold be canceled before adding a new one?  I think so. 

Both changes are close to ready, just want to make sure before releasing since I've only been using this guy for a few days, and not using it actually hooked up to anything.

- Jim

1) I would prefer not to have to, but understand the need for it :)

2) I would personally prefer nextTransition.

 

[Toddimus]

31 minutes ago, automationgeek said:

1) I would prefer not to have to, but understand the need for it

2) I would personally prefer nextTransition.

 

I concur with @automationgeek

For item #2... I know this might be a big ask but could we have the best of both worlds:  the option to change the setpoint for both nextTransition AND indefinite?  If that's not feasible, then nextTransition would be the first choice since that's the way the Ecobee phone and web applications work, so it would be more intuitive.

[beninsteon]

Thanks @Jimbo for your work with this.

Agree with above. nextTransition would be the preferred hold type.

Also, it would be nice if when setting comfort mode that is also until nextTransition. Right now, my thermostat is programmed to 'home' mode M-F at 5pm and 'sleep' mode M-F at 10pm. If I come home at 3pm and use the ISY to change my comfort setting to home, it would be nice if the thermostat still changed to sleep mode at 10pm.

Ben

[Jimbo.Automates]

Thanks for the comments! 

I wish there was a way to change a sensor node address, but currently there is not, so we have to do it that way.  If there were a lot users who had these in programs, I could not do the delete node, and just put up a notice telling you to delete them?  This would allow it to still show up in your programs and you could search and replace. (Edit: Nevermind, delete node is broken in the current polyglot release, so users will have to delete them anyway)

I will use nextTransition, and I was also thinking that we could add another param to allow you to chose between them, but can look at that later.

I had also noticed that changing the comfort setting was indefinite, and had created an issue for it last night https://github.com/Einstein42/udi-ecobee-poly/issues/9

 

[jratliff]

I'm using the ISY Link / NodeLink Ecobee node server by io_guy currently and still use IFTTT triggers I had before Polyglot came out. I have this one installed too but it isn't working currently, maybe having both is messing it up. I haven't had a chance to mess with uninstalling one to test the other (I also just switched to the Ecobee4 from an older model so that may be part of it). Anyhow, the program options look pretty much the same for both. If this one works the same way as the NodeLink version, you can use "Schedule Mode" to manually set the thermostat to "hold" (permanent hold) or "hold next" (next transition) or "running" (resume the normal schedule).

 

It would be nice to have the option in line with setting the temperature to choose which hold you want, but as long as adding the schedule mode line after it would work then that would be a great start.

 

I use Schedule Mode - Running to resume the schedule around midnight (if not set to away mode by no one being home) or with my bedtime scene from a keypad linc to clear any permanent holds or make sure if someone changed the thermostat even after sleep mode was activated that it will reset back to the normal schedule instead of the change all night. I use a mix of permanent and next transition holds depending on what program is triggering the change.

 

Looking at Climate Type in an ISY program, it has a second option box for hold type of Permanent or Transition, but looking at the code snippet you put on the git issue it looks hard-coded for permanent or is there another place that handles this option box? To me it should be pulled from the variable set in that option box (attached image). Unless I'm misunderstanding the question.

 

And thank you for working on it!

 

 

 

[Jimbo.Automates]

Yes, I was just changing to use schedule mode to set the desired hold mode. Seems like it will work as expected. I'll look at the program options. Thanks for the info.

Sent from my Pixel 3 XL using Tapatalk

[Jimbo.Automates]

Version 2.0.7 is released: https://github.com/Einstein42/udi-ecobee-poly#release-notes

It should be in the store within the hour.  I didn't review the program options, but will do that next, just wanted get the current changes out for now.

[Toddimus]

Jimbo,

Thanks for the updates.  I did notice that the names for the sensors are now too long for the ISY to display.  In Nodelink, I actually get a warning in the logs that says there are duplicate node names for the four sensors.  Maybe get rid of the word thermostat in the sensor name?

 

2018-12-13 18:18:14 - ISY Error: Profile (isylink) not setup in ISY, please follow howto
2018-12-13 18:18:14 - ISY Node Server profile set to 1
2018-12-13 18:18:15 - ISY Warning: Duplicate node names exist on the ISY (Ecobee - Thermostat Sensor - )
2018-12-13 18:18:15 - ISY Warning: Duplicate node names exist on the ISY (Ecobee - Thermostat Sensor - )
2018-12-13 18:18:15 - ISY Warning: Duplicate node names exist on the ISY (Ecobee - Thermostat Sensor - )
2018-12-13 18:18:20 - ISY Error: Timeout from the ISY (programs?subfolders=true) [5]

 

[Jimbo.Automates]

Jimbo,
Thanks for the updates.  I did notice that the names for the sensors are now too long for the ISY to display.  In Nodelink, I actually get a warning in the logs that says there are duplicate node names for the four sensors.  Maybe get rid of the word thermostat in the sensor name?

2018-12-13 18:18:14 - ISY Error: Profile (isylink) not setup in ISY, please follow howto2018-12-13 18:18:14 - ISY Node Server profile set to 12018-12-13 18:18:15 - ISY Warning: Duplicate node names exist on the ISY (Ecobee - Thermostat Sensor - )2018-12-13 18:18:15 - ISY Warning: Duplicate node names exist on the ISY (Ecobee - Thermostat Sensor - )2018-12-13 18:18:15 - ISY Warning: Duplicate node names exist on the ISY (Ecobee - Thermostat Sensor - )2018-12-13 18:18:20 - ISY Error: Timeout from the ISY (programs?subfolders=true) [5]

 

Yes, if you delete the old nodes then the warning will go away. I didn't change the names only the address. Personally I would like to remove the entire Ecobee - Thermostat from the sensor names but didn't know what everyone thought about that. Also, you can rename the nodes to whatever you want and it should not cause a problem.

Thanks for updating, let me know if you have any issues.

Sent from my Pixel C using Tapatalk

[Toddimus]

I did delete the old nodes.  It's the new nodes that seem to have a name length issue.

[Jimbo.Automates]

Oh I see, but I don't think I changed the names, and once the exist I don't think the nodeserver can change them.

Sent from my Pixel 3 XL using Tapatalk

[Toddimus]

The names I have aren't particularly long.  I'm wondering if you can delete part of the name (i.e. delete "Thermostat - Sensor -" ) to shorten it?

These are from how the actual Ecobee web interface have the names:

 

[Jimbo.Automates]

Ya that's what I said above Personally I would like to remove the entire Ecobee - Thermostat from the sensor names but didn't know what everyone thought about that.

Sent from my Pixel 3 XL using Tapatalk

[automationgeek]

Same here name it way too long, causing it to not appear in ISY and having to go in polyglot figure out the name

[Toddimus]

22 hours ago, Jimbo said:

Ya that's what I said above Personally I would like to remove the entire Ecobee - Thermostat from the sensor names but didn't know what everyone thought about that.

Sent from my Pixel 3 XL using Tapatalk
 

 

21 hours ago, automationgeek said:

Same here name it way too long, causing it to not appear in ISY and having to go in polyglot figure out the name

I think we have a quorum (the three of us) who think that shortening the names of the sensors is the way to go.  Can you do that?  That would be awesome because now the three external sensors all have the same name in the ISY tree on the left.  That just doesn't seem right.

[Jimbo.Automates]

I think we have a quorum (the three of us) who think that shortening the names of the sensors is the way to go.  Can you do that?  That would be awesome because now the three external sensors all have the same name in the ISY tree on the left.  That just doesn't seem right.

Yes I'll do that next. So just use the sensor name only, no common prefix so they are ordered together in program selection?

Sent from my Pixel C using Tapatalk

[Toddimus]

Yes I'll do that next. So just use the sensor name only, no common prefix so they are ordered together in program selection?

Sent from my Pixel C using Tapatalk

Maybe “Ecobee- {sensor name}”


Sent from my iPhone using Tapatalk