Ecobee - Command missed?

[rccoleman]

I've never had good luck with the geofencing support in the Ecobee app (it just stops triggering from time to time), so I've switched to using Locative to set a state variable in my ISY, and have that trigger a home/away program.  As part of that program, I either set my two Ecobee thermostats to "away/hold" or "run program" for leaving/returning.

 

Locative always successfully triggers, and did so last night.  The "home" program ran (my alarm disarmed and my state variable indicated "home"), but my Ecobees were still in away/hold.  I did some cursory checks in the Nodelink log and didn't see any obvious errors.  I re-ran the portion of the program that sets the Ecobee state and it worked fine.  The exact same programs, setup, and geofence have worked fine every day since last weekend, so I think the logic is sound.

 

I collected the verbose log from NodeLink and I wonder if you could take a look and see if anything seems out of the ordinary.  Or if there's some other diagnostic information, I'm happy to collect that.

 

I suppose it could be a delay between NodeLink sending the command to the cloud and my thermostats getting it, but it was a good 10 minutes or so after the geofence trigger before I manually re-ran the program.  For reference, I think the geofence trigger was around 19:48 and the manual trigger was around 20:03.

 

Log is here: nodelink_ecobee.txt

 

Thanks!

Rob

[io_guy]

You'd need to enable the ecobee verbose log in NodeLink to see any of the errors that would have been returned by the ecobee cloud.  It was likely a failure on the cloud side.

If it was an actual NodeLink send failure there would have been an error displayed.

 

I disable a number of cloud errors from showing up intentionally because there are some really stupid errors returned sometimes that either mean nothing or are not really failures.

[rccoleman]

Ok, fair enough. I didn't look to see if there was an Ecobee-specific logging option earlier, but I'll turn it on when I get home.

 

Thanks for the quick response!

[rccoleman]

This is now officially driving me nuts. I've added lots of pushover notifications that tell me everything that happens when I enter or leave my geofence, and I'm still seeing extremely flakey behavior from my Ecobees.  I've even tried sending the command multiple times with a 10 second delay in between and it still doesn't work reliably.

 

When I was standing in front of one of my thermostats last night, I was able to run my home/away program through my IFTTT command repeatedly and it worked every single time - it properly set the home/away state and sent the appropriate notification to my phone.  This morning, I exited my geofence, got my "away" notification and "alarm armed" notification, but I didn't get the "ecobee away" notification.  Sure enough, my thermostats were still in "home" mode.  About 20 minutes later, I opened the Nodelink web page and the log clearly shows that both thermostats were set to "away", 10 seconds elapsed, and both were again set to "away".  As far as the Ecobee website and the iOS app were concerned, they were still in "home" mode.

 

Last night, I made sure to check the "verbose logging" box to try to catch the log if it failed in the future.  When I logged in this morning from a different machine, I noticed the "verbose logging" box was now unchecked.  Should that setting stick between machines and over that period of time?  In any case, I re-checked it and Nodelink dumped its current state into the log.  I then manually ran the "ecobee away" program and, of course, it worked fine - the thermostat went into "away" and I got my notification.

 

Given that "verbose" seems to have been unchecked during the failure, will the log that I captured be of any use to you?  I can clearly see the failed and successful instances of "away", but I don't see any indication of an error in the first case.

 

Thanks,

Rob

[io_guy]

VerboseLog not sticking is a bug, I'll fix in the next release.

 

Let me give you a little background on how the interaction works.

Ecobee is a cloud API which updates it's info at 3 min (very few items) and 15 min intervals.  Since this would be an incredible lag to the ISY (when setting something), I do the following:

 

- ISY sends command to NodeLink

- If the command came back with a "success" return from the cloud, NodeLink immediately updates the variable and changes it on the ISY

- If the command was unsuccessful, you'd see it in the verbose log

 

So, if it's being changed in NodeLink/ISY but not on the Ecobee, it means Ecobee's cloud returned a success but this wasn't actually the case.

[rccoleman]

That's good information, thanks.  I updated to 0.6.4 to keep verbose sticky and I'll continue to monitor it.  It failed last night and worked this morning, so it's just very flakey for me.

 

Rob

[rccoleman]

I caught it in the act.  This ended up in my verbose log:

2016-09-25 16:00:11 - Web Request: /isylink/nodes/n001_dnecobee/cmd/AWAY
2016-09-25 16:00:12 - Ecobee Status Error - 3, Update failed due to a communication error. [dnecobee]
2016-09-25 16:00:12 - Web Request: /isylink/nodes/n001_upecobee/cmd/AWAY
2016-09-25 16:00:12 - Ecobee Status Error - 3, Update failed due to a communication error. [upecobee]

And then this a bit further down in the log, repeated 3 times at 3 minute intervals:

2016-09-25 16:16:39 - Ecobee Web Error - The remote server returned an error: (404) Not Found. [dnecobee]
2016-09-25 16:16:39 - Ecobee Timer Error - Deserialization has failed [dnecobee]

It only complained about my downstairs thermostat in those messages, not my upstairs one.

 

When I got home, I was able to set home/away through programs without any trouble.  Just a temporary glitch on Ecobee's server?

 

In the meantime, I'm setting a variable when the thermostat state changes and I built a loop around the setting logic with a 1 minute wait to improve my chances.

 

Rob

[io_guy]

The 3 min cycle is the polling for status from the system.  To get 404s on it is almost certainly ecobee's cloud service hiccupping.

 

Just as an example, my ecobee cloud was down for 1h this morning and 30min this afternoon.  Pretty brutal, yet they refuse to open any sort of local API.