[DEPRECATED] Universal Ecobee Suite, version 1.7.**

Ron -

That’s weird… I just checked my code, and it never sends an attribute change without first checking that the new value is in fact a new value (by calling isStateChange(…) before sendEvent(…) ). So something else has to be generating the double events. I have long suspected that SmartThings will randomly send 2 events without reason or detectable cause (so I can’t fix it).

FWIW, I have in the past tried to prevent these by checking if the event I recieve is a duplicate of a prior one, but as you note the two events seemingly arrive so close together that there isn’t even time to do the comparison…

If these become consistent and not random, please let me know and I’ll see if I can get help from SmartThings to resolve the issue…

SmartThings has failed to put my thermostat into Away mode a couple of times this week.

Hello. I’m having a persistent issue where at least one, if not more, of my thermostats go into a “HUB_DISCONNECTED” state on SmartThings. I know SmartThings is having an issue with Device Health and that this is the primary cause, but the issue with my Ecobee Thermostats continues to persist which makes me wonder if there is an attribute within the Thermostat DTH that is contributing to the cause. Sometimes the issue will correct itself if I reboot my SmartThings V2 Hub, but the inverse can happen where all of my Ecobee Thermostats (3) are in an “ACTIVE” state and then at least one will go into a “HUB_DISCONNECTED” state after a reboot. Also, the “HUB_DISCONNECTED” state is cosmetic as the thermostat device(s) still function in SmartThings and report properly, but show as “Unavailable” in the SmartThings app (iOS).

Thanks in advance for your help!

Duwayne -

As long as they keep working, rest assured that it is the SmartThings bug.

If you’d like, you can try commenting out the line at the top of Ecobee Suite Thermostat and Ecobee Suite Sensor that says "capability "Health Check" (delete it or put two slashes in front of the line like this: // capability "Health Check".

Let me know if that makes your problem go away…

Allison -

I’m going to need more information than that if you want me to assist…

Thank you, sir. I rem’d out the Health Check capability which at least solves the “Unavailable” issue in the App, but I have one thermostat that is staying in a “HUB_DISCONNECTED” state even after rebooting my hub several time.

Another issue cropped up at approx. 3:30 PM CDT. The following error started appearing in Live Logging for the Ecobee Suite Manager SmartApp:

This is appearing at every poll interval. I can’t correlate the start to anything that has happened on my side (IE: hub reboot, Thermostat DTH mod by rem’ing out Health Check, etc). Shortly after I started seeing this I received a notification from SmartThings Support that the system wide Device Health issue had been solved. I’m not sure if there’s a correlation there or not, but my Device Health issue(s) still exist.

Thanks again for the help!

Update: Now all of my Ecobee Sensors are “Offline” and two of my three Thermostats are in a “HUB_DISCONNECTED” state. :frowning:

Update: Problem solved. I re-authenticated the Ecobee Suite Manager and all sensors are now “ONLINE”, one of the two thermostats that were “HUB_DISCONNECTED” is now “ONLINE”, and the error in Live Logging has stopped. I still have one thermostat that persists in a “HUB_DISCONNECTED” state regardless of what I do.

Since this is Hubitat I don’t think calling SmartThings will help. But I bumped up logging last night to catch the even and darn the logging buffer on the Hubitat rolled out the duplicate events from this morning. What I will do is watch it closely over next couple of days and try to catch the details you may need to debug.

This is occurring again. The actions I took earlier (re-authenticate the Ecobee Suite Manager app) does not have any affect now.

Ecobee Suite updates posted on 25 July 2019 at 8:10am EDT

Mostly cosmetic fixes with some bugs squashed as described below:

  • Ecobee Suite Thermostat, version 1.7.24
    • Fixed type conversion error in setFanMinOnTime() & setVacationFanMinOnTime()
  • Ecobee Suite Manager, version 1.7.29
    • Fixed null currentProgramOwner & currentProgramType references for Auto Home/Away programs
  • Ecobee Suite Open Contacts, version 1.7.29
    • Clean up appLabel in sendMessage() (cosmetic)
  • Ecobee Suite Routines, version 1.7.14
    • Eliminate duplicated subscriptions to currentProgram/currentProgramName - only need the first one
    • Clean up appLabel in sendMessage() (cosmetic)
  • Ecobee Suite Smart Mode, version 1.7.16
    • Clean up appLabel in sendMessage() (cosmetic)
  • Ecobee Suite Smart Vents, version 1.7.09
    • Removed redundant LOG texts
    • Fixed the new fan only option
  • Ecobee Suite Thermal Comfort, version 1.7.13
    • Clean up appLabel in sendMessage() (cosmetic)
  • Ecobee Suite Working From Home, version 1.7.09
    • Clean up appLabel in sendMessage() (cosmetic)
2 Likes

Ron -

The issue is fixed in Ecobee Suite Routines, version 1.7.14

1 Like

The fix is in ES Manager version 1.7.29, just posted to my GitHub

Ecobee is down as of 4:20EST if anyone needs to know

Working great now…thanks…

Just wish Hubitat had a easy way to update drivers and apps like SmartThings. Copy and overwriting the code for 8 devices/apps can be “error prone”.

Ron -

Use “Import”. Hubitat will remember the source location for Apps, and I’ve coded in the source location in the two Drivers - so all you have to do is open each file, Import, and Save…

1 Like

I’m going to need to know what information you need to know…

It’s failing again tonight.

Allison -

Please understand that I have no way to look at your installation of SmartThings or Ecobee Suite Manager, so I need you to be my eyes and describe the situation for me so that I can help you.

Let’s start by describing what you are trying to accomplish, and how you have configured things to make this happen, and what isn’t working as you expect it should?

Then I’ll need the following:

  1. What date and time did this failure occur?
  2. Ecobee was down at times yesterday - first for some issues, then for some maintenance. If Ecobee’s servers are unavailable or unreachable, my Ecobee Suite can’t make the thermostat do anything. It will try to replay any failed commands once the servers are available again.
    a. Were you able to use the Ecobee Mobile app to control the thermostat at the time it was “failing?”
    b. Did you check https://status.ecobee.com/ to see if there were any issues at the time of your failure?
  3. SmartThings also has been suffering some outages since July 27, and there are issues that are not yet resolved, according to an email I received from them this morning.
    a. Did you check https://status.smartthings.com to see if there were any outagees there at the time of your failure?
  4. What are the version numbers of ES Manager and ES Thermostat that you are using?
  5. Which ES Helper are you using?
    a. What version is it?
    b. How is it configured - could you send me a screen shot of the configuration pages?
  6. Have you looked at the Live Logging for ES Manager, ES Thermostat, and the Helper(s) to see if any Errors or Warnings are flagged when it “fails?”
    a. If so, can you send me (PM) the relevant log entries?

That should be enough to get me started…

2 Likes

Hey Barry, I found a couple bugs:

Smart Mode 1.7.16: The status message (Off - Hold: Home) is being appended and not replaced resulting in multiples of it in the name

Thermal Comfort 1.7.13: New instances don’t show the notification configuration section. Existing instances error and can’t load the configuration section.

java.util.NoSuchElementException: Cannot access first() element from an empty List @line 208 (doCall)

Thanks, Richard - glad to have you here on both platforms (I’m still running both as well).

Fixes for both issues posted - Smart Mode 1.7.17 and Thermal Comfort 1.7.14

1 Like