Looks like it is working again. I just re-authenticated the app and it went through without errors.
@storageanarchy, I did go into my schedule on the web interface last night and update the schedule (opened each one and saved). It is still showing 18 minutes late. My schedule change this morning has already hit, so I canât test this. I will try and do your test tonight to see what it does.
The thermostat device also has some hard-coded log.debug statements that document currentProgram and currentProgramName changes as they occur (at any debug level)âŠ
Ok, I will try and capture things tonight at my transition time around 10:00.
I just went into the api site and listed my events for one of my thermostats. The history there goes back for about 3 hours. The only currentProgramName change I see occured at 7:18 (18 minutes late). See below.
However, looking further back in my log, at 7:00 when the transition occurred I see the setpoint actually change.
So, it seems to be getting that the setpoints change based on the schedule at 7:00AM. But for some reason doesnât get that the currentProgram has changed until 18 minutes later.
Scott,
Thanks for the additional insight.
Still, I canât tell if the problem is that the API isnât reporting the program change, or if I somehow screwed up and didnât ânoticeâ the change - hence the request for the Live Logging. The oddity is that all my thermostats are working fine, reporting the changes within a minute of them occurring (whether scheduled, manual or via API call).
Here are some additional details from the list events. The first is the change at 7:00AM and the second is when the current program actually updated at 7:18AM. One thing to note is that I have mine setup to poll every 3 minutes, so that is what the APP_COMMAND appears to be triggering off of.
I was able to reconnect the Ecobee to my SmartThings, their support people never returned my calls yesterday. I am going to watch the program changes to see if they are still showing up delayed. After removing the SmartApp, deleting and re-adding my programming on the Ecobee, and Reconnecting I hope it fixes the delay issue.
I did set my self up with a Ecobee developer account yesterday and right when I was going though the authorization validations the Ecobee hell broke lose. If the delays come back I may take a look at some of their raw returns.
Have you tested/verified whether a manual program change, made from the thermostat or the WebApp (but NOT from Ecobee Suite)? It would be good to know whether Ecobee Suite recognizes the program change this way.
One place where there could be an issue is whether the Ecobee API is properly notifying my code that something in the Thermostat collection (thermostat program and settings). In debug level 2 or higher, Ecobee Suite Manager logs what is being requested at each poll cycle, and this is based off of what the Ecobee API has indicated has changed (I do this to keep data transfers to a minimum). If the API fails to note that there are changes, it could cause the delay. So, please check your live logs for Ecobee Suite Manager around the time you make a manual change and see whether or not you see this or not:
info Getting ( equipmentStatus settings program events runtime extendedRuntime sensors ) for thermostat ##########
If you donât see âprogramâ until some time later, please let me know ASAP (you too, @ssilence).
Thanks!
I created a new schedule to transition from home to Sleep at 11:00AM. here is what I saw in the live logging:
Ecobee Suite Manager
Ecobee Thermostat - Master
It looks correct now, but that could be because it is a new schedule entry. When I did a manual change to Away, it did the same thing. So, not sure what is wrong with existing schedule. Might be time to delete them and readd.
Yes all manual changes appear within the 1 minute polling interval. I would have to setup my home computer to keep the debugging sessions alive for the transition tests so I can capture the logs. I can setup tonight when I get home. Also I bumped the debugging to level 3.
OK, all. Iâm pretty sure I have found and fixed the issue - it was very complex, multi-faceted, and at the root a stupid mistake on my part. Fixes being posted momentarily that should solve not only the currentProgram problem but also initialization errors many new users have been reporting.
Give me a few minutes to clean up the code, and Iâll get everything posted.
UPDATE ANNOUNCEMENT
As of 3:40pm EDT on Wednesday, April 4, 2018, the following have been updated:
-
Ecobee Suite Managernow v1.4.17 -
Ecobee Suite Smart Circulationnow 1.4.03 -
Ecobee Suite Thermostatnow 1.4.08
Changes in these releases include:
- Thermostat devices were not initializing properly, causing a variety of errors (e.g., null string in getProgramsList, contains() on a null string, etc.).
-
currentProgramand other attributes were not being updated to the UI in a timely manner - Changes to
currentProgramandcurrentProgramNamewere not being reported as they occurred - The secret double-click resumeProgram action was not reliably refreshing the icon
- Setpoints were not being updated in a timely manner after a call to resumeProgram
- In Smart Circulation, multiple simultaneous temperature updates (as when using Ecobee sensors) will no longer make multiple repeated calculations of the temperature datapoints
- Miscellaneous optimizations and logging cleanup
One operational enhancement has been added: as before, currentProgramName will change to âOfflineâ when connectivity to the Ecobee Cloud and/or the wifi connection to the thermostat is lost (currentProgramName is used to specify the appropriate icon in the UI). Effective this update, currentProgram will NO LONGER CHANGE; instead, it will continue to report the program last in use - this to avoid causing inappropriate state changes to currentProgram.
This is a MANDATORY UPDATE for all users of my Ecobee Suite
1 Like
Just tried it. Everything seems to be working for me now.
Youâre awesome. Thank you!
1 Like
Just applied the updates, have live logging turned on, log level to 3 and no sleep on my computer. Will let this run until the next few schedules to validate.
Iâm having difficulty using Webcore to turn my Ecobee Thermostat to âawayâ mode when my âawayâ routine executes. Iâm not sure what the issue is. The Piston tests true when the routine changes, but the Ecobee Thermostat does nothing.
I also tried Custom Away (), SetThermostatProgram() - these also had no affect to switch to Away Mode or Away ScheduleâŠ
I have all the latest updates 
@Godman, Donât call âSet schedule to Awayâ, just call the away function. See below. (note I have two ecobees)
This works great for me.
Thanks for the reply.
I tried that too, but the thermostat is still not switching to away.
The code seems to look fine, but the actual Thermostat is doing nothingâŠ
Thatâs weird. Thatâs what I use and it works fine.
Working for me too.
I did notice thereâs huge blank space in history, but minor. Also the green circles dont have temperature label.