Weird Ecobee home/away behavior

[rccoleman]

I noticed today that both of my Ecobee thermostats were set to "Home/permanent hold" when they should both be "Away/permanent hold".  My programs to set home/away have been working for quite a while and the ISY correctly knew that I was away, so I started to investigate.  It seems like there's some sort of mismatch between NodeLink and the ISY that's causing the Climate Type that I select in the GUI or through a program to turn into some other Climate Type when it's actually sent to Ecobee.  For instance, when I select "Away", it switches to "Home", and when I select "Sleep", it switches to "Custom 1".  Selecting "Home" keeps it at "Home".  I've tried restarting NodeLink and rebooting the ISY, but the weird behavior persists.  I can't quite figure out what's going on.

I'm attaching the complete log from today, which is pretty big and I'm sure spans multiple NodeLink restarts.  Hopefully it's not too much.

Any idea what's happening?

logfile_2018-05-02.txt

[larryllix]

I have some weird but very rare occurrences with my ecobees also.

 

Did you have any kind of a disturbance that rebooted your ISY or NodeLink close to the time it has done this? I had one ecobee4 set to it's lowest setting a few times but the last time I believe it coincided with an ecobee's server maintenance / fail recovery..

 

Not good at understanding io_guy's log files but there are many complaints of ISY having duplicate nodes in the log file. Do you have extra duplicate nodes hiding under the very top part of the device tree?

[rccoleman]

1 minute ago, larryllix said:

I have some weird but very rare occurrences with my ecobees also.

 

Did you have any kind of a disturbance that rebooted your ISY or NodeLink close to the time it has done this? I had one ecobee4 set to it's lowest setting a few times but the last time I believe it coincided with an ecobee's server maintenance / fail recovery..

 

Not good at understanding io_guy's log files but there are many complaints of ISY having duplicate nodes in the log file. Do you have extra duplicate nodes hiding under the very top part of the device tree?

I don't think so, and I think it worked yesterday (but can't be sure).  I just noticed that my "away" program triggered and my alarm was armed when I left this morning, but my Ecobees were in the wrong state.

My understanding from previous posts is that the initial messages about duplicate nodes are not a problem.  That's common even when everything is working fine, and it's just at the beginning.

[rccoleman]

@io_guy Any idea what's going on here?  I'm continuing to see some weird mismatch between what I set in ISY programs or from the admin console, and what actually gets set on the Ecobee (visible in the app, thermostats, and their website).  The typical behavior in the admin console is that I try to pull down a new climate type and it briefly changes to the new type, and then changes back to whatever it was set to before.  If I click the Climate Type button, it refreshes with a different, wrong, but predictable value.  I've tried restarting NodeLink, reuploading the profile, and restarting the ISY.  Logs are above, but I'm happy to provide any additional info that would be helpful.

[io_guy]

Definitely a me problem.  Does it happen on both stats or just one?

[rccoleman]

4 minutes ago, io_guy said:

Definitely a me problem.  Does it happen on both stats or just one?

Both have the same behavior. Each day I change the setting in the Ecobee IOS app from Home to Away and it works fine. It seems like there may be an off-by-one issue because selecting Away seems to trigger Home, and Home triggers Sleep. But I'm not convinced that it's consistent for all the settings because sometimes it just sets a hold for a temperature.

[larryllix]

58 minutes ago, rccoleman said:

Both have the same behavior. Each day I change the setting in the Ecobee IOS app from Home to Away and it works fine. It seems like there may be an off-by-one issue because selecting Away seems to trigger Home, and Home triggers Sleep. But I'm not convinced that it's consistent for all the settings because sometimes it just sets a hold for a temperature.

Are you using the third parameter "Hold Type"? This was a later addition and IIRC mine was doing some unexpected things while it had no option selected.
I had to add that new field  to my programs after io_guy advanced the control method options a while back.

 

I am just about to run a short Away / Sleep test program on my ecobee4.

FOLLOWUP: Three program runs proved successful here, each time.. 

Wait 10 sec
Set ecobee4 to Awat, Hold Type Transition
Wait 1 minute
Set ecobee4 to Sleep, Hold Type Transition

[rccoleman]

I always use hold type "permanent" when switching to away, and just set the thermostat to "running" when coming home.  Here's my program:

Ecobee Home/Away - [ID 00CA][Parent 00C9]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Set 'Devices / Downstairs Ecobee / Downstairs Ecobee' to Away, Hold Type Permanent
        Set 'Devices / Upstairs Ecobee / Upstairs Ecobee' to Away, Hold Type Permanent
 
Else
        Set 'Devices / Upstairs Ecobee / Upstairs Ecobee' Schedule Mode Running
        Set 'Devices / Downstairs Ecobee / Downstairs Ecobee' Schedule Mode Running
 

After manually setting both thermostats to "Away" in the iOS app, I just selected both lines, made sure that the correct hold type was selected, updated both lines, and then ran the "then" clause.  Now both thermostats are showing a permanent "Home" climate type.  That's the problem.

[larryllix]

43 minutes ago, rccoleman said:

I always use hold type "permanent" when switching to away, and just set the thermostat to "running" when coming home.  Here's my program:

Ecobee Home/Away - [ID 00CA][Parent 00C9]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Set 'Devices / Downstairs Ecobee / Downstairs Ecobee' to Away, Hold Type Permanent
        Set 'Devices / Upstairs Ecobee / Upstairs Ecobee' to Away, Hold Type Permanent
 
Else
        Set 'Devices / Upstairs Ecobee / Upstairs Ecobee' Schedule Mode Running
        Set 'Devices / Downstairs Ecobee / Downstairs Ecobee' Schedule Mode Running
 

After manually setting both thermostats to "Away" in the iOS app, I just selected both lines, made sure that the correct hold type was selected, updated both lines, and then ran the "then" clause.  Now both thermostats are showing a permanent "Home" climate type.  That's the problem.

Just an experiment, ever try putting a Wait 1 minute between sets? Maybe the multiple set is causing some protocol confusion some place.

[rccoleman]

The same thing happens when I manually change the Climate Type in the admin console, so I don't think it's a problem with the program.

[io_guy]

Yep,
Got some work to do.  Looks like ecobee have no consistency with the order of their climate program structure.  I need to do some cleanup.

[rccoleman]

22 hours ago, io_guy said:

Yep,
Got some work to do.  Looks like ecobee have no consistency with the order of their climate program structure.  I need to do some cleanup.

Thanks for the confirmation!  Curious that it's been working fine for so long and just started to cause problems.

[io_guy]

It has to do with the way ecobee sent the data.  I've always assumed it was set since it (many users of data compared) has always been the same structured way.  Now your data stream has mixed up the climate order.  I love ecobee and their ridiculous API.

[larryllix]

NodeLink v9.13 installed. The automatic install (when I enabled it and then rebooted) wiped out my config.xml file again. (fresh start data)

Then I attempted to re-install ISY parameters and when I hit Set it wiped my config-bak.xml file.

Luckily  I keep another config-saved.xml file (not invoved in any automatics) that I recovered with.

Looking good again

Perhaps a manual "Restore" would work there, and/or some protection against automatic invovement of the config-bak.xml file to prevent further automatic dumping across to the -bak file if it already exists?

 

[larryllix]

...and another ecobee4 stat set to the bottom.

I decided to reboot my ISY from Nodelink afterthe  NodeLink 9.13 upgrade, to ensure the ISY node defs were matching NodeLink. I found my ecobee4 setpoint at 16C Hold until next climate type change again.

I know this was not an Away climate type set this time as Away is preset to 17c.  My ecobee4 setpoint limit is >= 16c so I know Away wasn't the setting attempt but rather 16c or lower. (I guess  0c setpoint attempt but the stat won't allow it)

No record of anything in the logfile_2018-05-06.txt but I have it set at Notice level. Last time there was no recorded line either set  on Debug level. This always seems to be coincidnet with an ISY reboot. I don't have time to retest this further today.

[io_guy]

34 minutes ago, larryllix said:

...and another ecobee4 stat set to the bottom.

I decided to reboot my ISY from Nodelink afterthe  NodeLink 9.13 upgrade, to ensure the ISY node defs were matching NodeLink. I found my ecobee4 setpoint at 16C Hold until next climate type change again.

I know this was not an Away climate type set this time as Away is preset to 17c.  My ecobee4 setpoint limit is >= 16c so I know Away wasn't the setting attempt but rather 16c or lower. (I guess  0c setpoint attempt but the stat won't allow it)

No record of anything in the logfile_2018-05-06.txt but I have it set at Notice level. Last time there was no recorded line either set  on Debug level. This always seems to be coincidnet with an ISY reboot. I don't have time to retest this further today.

You can post this 50 times if you want.  Without a log there's nothing I can do.  This has never happened to another user and could easily be an ecobee issue or something you're setting through the ISY.  

[rccoleman]

@io_guy Working great!  Thanks for the quick reseponse!

@larryllix I recommend turning debug on everywhere, including the devices (the Ecobee devices have their own debug options) and uploading the log.

[larryllix]

[mention=1310]io_guy[/mention] Working great!  Thanks for the quick reseponse!
[mention=4697]larryllix[/mention] I recommend turning debug on everywhere, including the devices (the Ecobee devices have their own debug options) and uploading the log.

Thanks. I had Debug on for a month but it doesn't show anything related.

Sent from my SM-G930W8 using Tapatalk

[rccoleman]

7 minutes ago, larryllix said:

Thanks. I had Debug on for a month but it doesn't show anything related.

Sent from my SM-G930W8 using Tapatalk
 

I think you'll continue to see the issues and continue to get pushback from io_guy until you let him evaluate it. As you mentioned earlier, there's a huge amount of information there that's hard to decode. I'm not seeing that issue, so I don't have a dog in this fight, but I kinda understand his frustration. Are you concerned that there's private data in the log?

[larryllix]

I think you'll continue to see the issues and continue to get pushback from io_guy until you let him evaluate it. As you mentioned earlier, there's a huge amount of information there that's hard to decode. I'm not seeing that issue, so I don't have a dog in this fight, but I kinda understand his frustration. Are you concerned that there's private data in the log?

Nope. Not a privacy issue. Logs were posted before and they didn't show anything.

I will have to spend more time trying to recreate this.


Sent from my SM-G930W8 using Tapatalk

[larryllix]

On ‎2018‎.‎05‎.‎06 at 9:59 AM, io_guy said:

You can post this 50 times if you want.  Without a log there's nothing I can do.  This has never happened to another user and could easily be an ecobee issue or something you're setting through the ISY.  

Here is the log in "Notice" mode.

From the ecobee records the setpoint set to very low (minimum was 16c) happened about 8:50 AM.
The NodeLink v9.13 update happened before that when the config.xml file was wiped out. I swapped an old config.xml back in to recover.
I rebooted ISY from NodeLink attempting to update the ISY nodes to the dehumidify updates you made. 

I put the log mode back to Debug and will attempt to cause this event again.

Thanks.

 

logfile_2018-05-06.txt

 

UPDATE: MY bad here! I recreated this upon ISY reboot. I found an old porgram that played with temperatures on the stat.

The program was disabled but running upon ISY rebooting and setting the stat setpoint based on ecobee parameters that would not be setup yet.

I believe I have this resolved as a user error....mine.

Lesson learned here: Disabling an ISY  program doesn't stop it running at power up in ISY.

Thank you again, io-guy for your hard work and my apologies for any unnecessary research you did on this.