[OBSOLETE] Universal Ecobee Suite, Version 1.8.01

Thanks sir! One issue down, but of course – a new one has shown up.
Im not sure what happened with device availability - but it finally showed up as available (I did not disable health check as i haven’t had an issue with it in a few years and no other devices were having the issue).

For some reason I am now having an issue with resuming on my ecobee after an ‘off’ event. For example: i have a contacts& switches helper set up to turn off my ecobee if a door is open for 3+ min then turn back on after the contact sensor is closed with a 0 min delay. I have setup a virtual switch to help troubleshoot the issue (and plan to use it for quiet time).
The thermostat turns off as expected when triggered. Once the door is closed the contact sensor shows that it is closed and the virtual switch is off (expected position when sensor is closed) - however the thermostat does not turn back on as expected.

I do have logs (but can grab more if needed) however I would prefer to DM them to you if you would like to see them.

Thanks again!

Something doesn’t sound right - I use pretty much exactly the same setup myself. So we’ll have to dig into things to figure out what’s going wrong.

First things first - please verify that Ecobee Suite Manager, all of the SmartApp ES Helpers and both of the Device Handlers are the latest versions available from my GitHub. It is best to check each from within the App or the Device, where the version is plainly displayed.

Then PM me your logs for ES Manager, ES Thermostat and the ES Helper in question…we are looking for errors or warning logged in ANY of the three at the time the sensor shows closed and the switch turns off.

PS - if you decide not to turn off Health Check, then you will have to ignore any “UNAVAILABLE” status that you see for the Ecobee Suite devices. SmartThings has never fully documented how 3rd party devices are supposed to interact with Health Check, and many users report “random” reports of UNAVAILABLE, even though everything is working properly and smoothly.

Hello,

So first off, thank you as always for the hard work on this! I can’t tell you how much I enjoy using it. I have several helpers set up for mode changes which work great. The issue I am having is being able to adjust temperature via the arrows in the app. Every time I try I get a network error reported back by ST. If I change the temp via the Ecobee app, it will report back to ST, but can’t change temp via ST arrows. Any help would be appreciated.

If the error you are referring to looks like this (in the Thermostat device handler), you can ignore it - it is a leftover debugging log entry that I will remove in the next release:

[a2796537-9b68-4f15-853d-7281888a629a] 6:59:40 AM: error generateEvent(Map): [coolingSetpoint:74.0, heatingSetpoint:68.0, lastHoldType:nextTransition, thermostatHold:hold]

Tell me more about the errors our are seeing…could you please send me a screen shot from your mobile, and/or the error(s) displayed in Live Logging?

Hello. Please see attached. One is the error I get in ST. The other is the list of log events for the device. Seems like I get a “false warn” I have highlighted that event.

The second snap is from the Device Event Log… I need to see the error as logged in Live Logging…log into your IDE, then click on Live Logging. This will collect the Live Logs for every app and device - try to change the setpoint, and then check the logs for the Thermostat and for Ecobee Suite Manager.

Have you tried changing the setpoint using SmartThings Classic? (I just tried on both Classic and New app and it worked without any issues).

Finally, I need to know the version number of Ecobee Suite Manager AND for the Ecobee Suite Thermostat - using SmartThigns Classic mobile app, ES Manager version is at the top/bottom when you open the App, ES Thermostat is shown when you edit the device settings on your mobile by clicking on the Gear icon. If they aren’t the latest from my GitHuB, please update and run the test again…

Hello,

Thank you for the reply. Information and logs attached .

Ecobee Suite Manager Version is 1.8.43
thermostat manger Ecobee 3 is 1.8.16

Sorry for the delayed response - had a busy weekend.

Would it be possible for you to run the same test, but with the Debug Level (in ES Manager/Preferences) set to 4?. The Live Log for ES Manager should give me what I need to fix this. If so, please send me the ES Manager log starting with the text setHold() for EcobeeTherm: Home

Thanks!

Firstly, this app is amazing. It brings so much great functionality to my home HVAC! I’ve been using it for a couple years now (and I’ve happily donated). However, in the past couple months I’ve noticed an issue with the way the smart circulation helper is working. I’m not even sure the problem is with the smartapp/helper, because it appears to be updating the thermostat, but the thermostat is not doing what it’s told. Here’s the scenario:

I have the smart circulation helper set to measure the temp between my main thermostat and an upstairs bedroom. When it’s beyond 1.5 deg difference, it begins increasing the ran runtime per hour. Or at least it used to. Lately, I’ve noticed that the thermostat appears to be getting “stuck” in the last mode it was in. If at one point, the smart circulation helper told the fan to run for 45min/hr, it will continue to run for 45min/hr, forever. Even if the helper app sets it back to 0 (and it is reflected as 0 in the ecobee app), it will continue to run for 45min/hr. That is, until I go into the ecobee app and toggle the fan from “Auto” to “On” and back to “Auto.” At this point, it will start operating the fan for the amount the smart circulation helper has told it to. What’s weird is that in the ecobee app, it shows the proper fan runtime. But the thermostat is not operating for the amount of time it shows in the app. It is still doing what it was told to do, potentially from days ago (since the last time I toggled the fan slider in the app).

This seemed to start happening when I installed a bunch of your helper apps to control my Keen Vents. However, the vents are behaving perfectly. How can I effectively troubleshoot this?

Thanks again,
Dave

I am sorry for my delay. My computer had to be disconnected while we were moving stuff around. I will have this later today.

Hello,

See screenshots of logs at level 4 from ES manager starting with requested command. Starts at time stamp 6:33:07 and ends at 6:33:24. Thank you again!

Got it. Fix being posted momentarily…

Ecobee Suite updates posted 18 June 2020 at 4:00pm

Fixes and Enhancements:

  • Ecobee Suite Manager, version 1.8.44
    • Fixed setHold() using Hourly Hold (holdHours)
  • Ecobee Suite Smart Room, version 1.8.18
    • Allow operation during thermostat “Hold” events or “Vacation” modes
  • Ecobee Suite Smart Vents, version 1.8.13
    • Allow vent manipulation during thermostat “Hold” events
1 Like

Dave -

I’m not sure I can replicate this, but I will try.

First, a couple of questions:

  • how are you determining that the fan is continuing to use the old fanMinOnTime?
  • is your Ecobee running the new eco+ release?
  • if so, what are your eco+ settings? (PM me photos of your thermostat settings screens, if that’s easy)

Finally, have you contacted Ecobee support? If your thermostat shows that the fanMinOnTime is zero, and you can see that the fan is running more than 0 minutes an hour, then it quite likely is an Ecobee thermostat code bug… Send photos and screen shots to support@ecobee.com without mentioning any 3rd party software and they might just admit that there is a bug :slight_smile:

Thanks for using Ecobee Suite!

Working great! Thank you so much!

I am having some issues after I updated recently. I am now on 1.8.44, and after seeing problems with one of my thermostats (Ecobee, I have 2) not showing any information in the SmartThings app (although it says connected in the logs), I decided to just remove everything and re-install.

After re-install now neither of my thermostats are reporting stats, however the sensors all do, including the ones that are the thermostats them self. This causes my helper apps to report the thermostat as “null” and I am going to assume any automatons are not going to work right now.

Just a secondary note, I did find an odd interaction when I started graphing my temperatures, before I broke everything by re-installing. When you set the offset for a vent, I noticed the app now tells what range above and below the vent will open. Being summer my thermostat is in “cooling” mode, but it does still have a heating set point. I never paid much attention to setting this since it will never heat in cooling mode. However the mode of cooling isnt’ accounted for when the smart vent helper decides if a vent should be open or closed.

For example
cooling : 74
heaing : 72

If a room drops to 74, the vent will close. However if the system is still cooling (other rooms aren’t at temperature hence having a smart vent in this room) and it makes it to 72 (or maybe 71.5) the vent will open again. Because it falls below the heating point. To fix this issue, I just lowed the heating point further, but I always just assumed that it would only consider the cooling set point for closing the vent while the system was cooling, and the heating set point while heating.

---- edit ----
Just wanted to throw in that I did find the following error in my debug
groovy.lang.MissingMethodException: No signature of method: script_dth_f75eccf0e1778faafb4533a0a93e2b21abdc1146b03b0051eaf1395d3c5e299a.generateEvent() is applicable for argument types: (java.util.ArrayList) values: [[[forced:true], [nextHeatingSetpoint:null], [nextCoolingSetpoint:null], …]]

Well, I guess I solved one problem (totally me not the application). When I did my update I updated AND published the application. When I did the device type handlers, I did the update, but forgot to check the publish box. So apparently the sensors work with the older code, but the thermostats didn’t.

So they once again have information flowing in. I still am using the “work around” of setting a really low heating point for the cooling mode. Again not exactly a bug but, it wasn’t until I was graphing my vent temperatures and open/close states that it occurred to me this was happening.

It’s hardly a workaround IMHO: your cooling and heating setpoints need to be far enough apart so that cooling never invokes heating, and vice versa - otherwise “Auto” mode will never work (well, it will work, but it will ping-pong between heating and cooling).

Question: do you have “adjust always” enabled? If so, try with that setting disabled - then I think it will do what you want…

I will add an enhancement request to my list to have only heating or cooling setpoints monitored, based on the most recent thermostatOperatingState. It may take a while, however - crazy times for me right now…

Thank you for your response! I’m sorry I missed the notification and didn’t see it sooner.

  • I graph my thermostat state (among other things) in Grafana, and pretty religiously check to see how often/when my HVAC is running. I used to easily see the ramp up/down of the fan run time in the afternoon, but now it just continues to operate at the same intervals until I toggle the fan on/auto slider.

  • My Ecobee 3 Lite is running firmware v4.6.3.64, and it does have the eco+ settings option. However, I have permanently disabled the eco+ functions. I do feel like this may be an Ecobee issue, because the fan behavior does not reflect the ran on time in the Ecobee app (which is being controlled solely by the Ecobee Suite), but I wasn’t sure if some behavior in your app may have recently changed to cause the issue. I had considered sending them a support request, but I wanted to make sure nothing had changed here first.

  • Here is a screenshot of the Eco+ settings menu. I’ll be happy to send you more screenshots of specific areas if you feel it is relevant.

The more I type/think about this, the more it seems like an Ecobee issue. I appreciate your response here. I will send them a message as well.

Is there any way to make a set of vents open/closed based on the temperature from two different rooms? For example I have one room which is almost always cooler than another. I give it an offset so it closes a little before the set point. If by some chance this room IS the warmer room, it will still close early, and both vents might be closed even though the system is on (the other one is smart b/c in winter it is the reverse, It needs to close).

Any way I can tell these two vents to open the “warmer” room when cooling? It doesn’t happen often but if someone opens a window or something a non-standard cooling situation can occur and my vents might both end up closed.