Please make sure to have the latest version at my store (you need to use the sellfy download link to get it)…
Also, refer to the ST community wiki for any troubleshooting. Everyting is documented at the wiki.
In your case, especially if you don’t have the latest version, you may have lost your auth tokens and you need to re-login at ecobee using MyEcobeeInit under Automation/Smartapps in the ST classic mobile app.
You can use a single watchdog to avoid any ST scheduling issue that impedes the auth tokens refresh. Refer to the following for more details:
As indicated in the last paragraph of the ST community wiki:
You can use either a temp Sensor (such as Aeon MultiSensor, SmartSense or Keen Vents), a motion sensor (such as the SmartSense), a power meter (such as Aeon HEM) or a powerSwitch to reschedule the smartapp if needed (as long as this device is polled on a regular basis -ex. every 5 minutes ) so that it can create a ‘heartbeat’ for the smartapp.
Do not use an ecobee remote sensor or the ecobee thermostat as this is not an external “heartbeat” for ensuring proper scheduling.
Finally, please use 1 or 2 watchdogs as too many can also cause too much rescheduling.
@yvesracine, lately I’ve noticed that the EcobeeChangeMode and the EcobeeResumeProg routines haven’t been working as consistently as before. I have my alarm system linked to SmartThings (via Envisalink) so that SmartThing’s mode is changed to Away whenever the alarm system is away armed. When that happens, I have EcobeeChangeMode to change Ecobee’s mode to Away. Upon returning to the house, when the alarm system is disarmed, then I have instructed the EcobeeResumeProg to resume Ecobee’s normal program. This has worked flawlessly in the past couple of years, but lately I haven’t seen the notification of the changes in Ecobee’s mode. Just now, my wife left the house and armed the system, but Ecobee continued to remain in Home mode. Is there a fix for this issue?
Please refer to my previous post. In brief, make sure to have the latest versions of the MyEcobeeInit smartapp and My ecobee DTH. The code for ecobeeChangeMode and ecobeeResumeProg is very stable, so there has not been significant changes for years. Check at my github and resync if necessary.
Finally, you need to make sure to enable notifications in the respective smartapps to receive notifications.
Thanks for the quick response. I’ve updated the MyEcobeeInit Smartapp and gone through the setup to link it to my Ecobee account. However, it now created another instance of my Ecobee device (now I have two, one call “My Ecobee3”, and the other (new one that just got created) “My Ecobee My Ecobee 3”. I want to avoid having to relink all my CoRE routines to the new instance. Would the old instance of my Ecobee Device still work, or do I have to go through each CoRE routine and switch the thermostat link to the new instance of the device?
If your old version was after v4, then just remove the new devices by clicking on the remove button within MyEcobeeInit.
If your previous version is very old, then, yes you have to substitute the old devices with the new ones in all smartapps & routines.
BTW, In the future, FYI, I have many support packages at my store so that you don’t need to worry about upgrading and monitoring your devices…When you subscribe to support, all is taken care of…
“Running Schedule” in my ecobeeSetZoneWithSchedule shows a zone that should not exist. It shows two zones with the same name, “Upstairs.” The first is correct. The second incorrectly contains the single vent “EastBedRoom.” The vent “EastBedRoom” also appears correctly in a completely different zone.
The problem is that there is only one “Upstairs” (Zone 1) in Zones Setup. That single zone somehow morphs into two zones with different contents in “Running Schedule.”
Sorry, but I don’t know exactly how you got the 2 zones in running schedule as this never happened to me.
You may have created another instance by going back/forth in the setup flow and changing the number of zones.
If you feel that this wrong instance is causing any issue, just remove the smartapp and restart your configuration from scratch. SmartThings doesn’t allow a lot of input options when you have many embedded sections (rooms->zones->schedules).
I have an ecobee4 that I’ve labeled Main that resides in the Living Room. I also have 1 remote sensor placed in my Master Bedroom (labeled Master). During my Sleep comfort setting, only the Master remote sensor is used.
Overnight during my Sleep comfort setting, I want to track the temperature difference between the Master remote sensor and the Main thermostat sensor. In webcore, I have a simple piston that updates a global variable calculated using [Master Sensor : temperature] - [ecobee Main : temperature].
Because my Sleep comfort setting uses only the Master Sensor to control the temperature, I’m not sure if [ecobee Main : temperature] returns the same value as the [Master Sensor : temperature].
Am I correctly accessing the real temperature measured at the Main thermostat, independent of which sensors drive my comfort setting as programmed natively on my ecobee?
Yes, the main thermostat’s temperature is usually dependent on the avg calculation based on all remote sensors participating in the scheduled comfort setting, and the temperature at the main temperature sensor is the ambient temperature at the thermostat, so they may be different.
I am looking for a way to find out if the thermostat is not connected. I tried the “status” variable but it says that it is online even though I have the thermostat unplugged. The Ecobee mobile app knows it is offline but the “My ecobee” device doesn’t seem to have a clue. In the Smartthings mobile app under Recently tab there is and entry “Verbose Trace is Getthermostaterevision>Thermostateid xxx Not Connected” . So I think the “My Ecobee” device is being told the thermostate is disconnected but it is not indicating that the thermostat is disconnected.
I am using WebCore and would like a way to tell if the thermostat is connected or disconnected.
Hi, @DigitalD, just grab the latest version at my store by clicking on your original sellfy download link. The version 5.9.9x9 has exposed the connected attribute.
I got the new code. According to the release notes only myecobeeinit and the device handler changed. I updated them and published them. And “connected” is available.
I tested the connected attribute and it acts strangely. When I unplugged the thermostat, the connected attribute, flips between true and false. The WebCore piston fires twice every time a poll is taken of the thermostat.
Hi, I did some tests at home, and the first time it did flip like you said. The second time, it didn’t, so the problem is on the ecobee API side (maybe some caching issues?) as my code doesn’t manipulate the data, just exposes it.
I left mine unplugged for an hour. It flipped several times. It does what is important. Let you know when there is trouble. I have gotten one notice so far of a disconnect.