I think I see the issue, my ecobee was offline. So the current program was classified as Offline. When I left, it scucessfully set to away, and then about 15 minutes later it finally said I was in vacation mode. At that point, the away hold had already been set and overrode the vacation mode that was already active. Looks like it was just a fluke. Very strange though.
In setThermostatProgram, I guess you could do a check to see if the current status is offline, and try and do a refresh at that point to see if it comes back online. Then check for Vacation mode? Just seems odd that it couldnât communicate a few minutes earlier to get the status (shows as offline), but it was able to set to Away.
Yeah, I was about to switch to that, but I have to then call out each thermostat one by one instead of using a device variable. I looked at the away function, and it calls the following:
void away() {
// Change the Comfort Setting to Away
LOG('away()', 5, null, 'trace')
setThermostatProgram('Away')
}
So, it will default to indefinite. I really am thinking it was a communication glitch.
Yes, away() is all you need. Probably was the comms error. I am working on caching failed commands when the link is down, then replaying them in order when the link comes back.
It will default to whatever the Thermostat settings is. You can change that to whatever you want. But also, that shouldnât be canceling vacation either because I use setThermostat away with indefinite and it doesnât cancel. Thatâs odd.
As a potential backup plan for you⊠I have a vacation piston for basically this purpose. It monitors presence sensors and ST mode. Itâs setup so if the house has been âawayâ for more than 12 hours, it triggers a vacation routine (putting ST into vacation mode/etc), which subsequently triggers an ecobee vacation hold via the Ecobee suite mode helper. I usually trigger vacation mode manually as we drive away, but this is my failsafe if that gets disrupted by a rogue piston/program.
Any idea why my automations are not setting the temperatures correctly? They seem to be off by a value of 3 degrees. I.E. If I set an automation to set the ecobee to 68 heat/73 cool, it will be set to 71 heat/76 cool. I have two zones and both react this way.
Ok, I am seeing something strange (any maybe it is not, but it is just perceived that way). I am utilizing webCore to set my theremostat mode (either away or resume, that is all I am doing). I have two webCoRE pistons: one for monitoring my SHM status (Armed/Stay, Armed/Away, Disarmed) and a second one that monitors presence of two individuals. I am going to focus on what would set the thermostat to Away. Either Piston monitoring SHM sees it go to Armed/Away or both individuals leave the area around my home. What this causes is away() to be called from one piston and then a few minutes later away() called from the other piston. What I am seeing is the first away() call sets everything correctlyâŠno issues. However, the second away() call will get inside the setThermostatProgram() function and as it proceeds through ends up doing a resumeProgramInternal() call then proceeds to set to away. This ends up working, but seems like unnecessary calls.
Just wondering if the function is intended to operate this way. Seems to me like you could check the curentProgram against the requestedProgram, and if they are the same (and of course the hold types/times are the same) just exit and leave what is set.
Also, one other odd thing. If I go.look at my thermostat information in Smart things, the data it shows is sometimes invalid. As you can see in the picture, the main tile is all messed up. The only way I can get it back is to go into the Ecobee Suite Manage SmartApp and press the save button. It almost seems to reload it.
Yes, it is working as intended, and indeed I could add the suggested optimization.
I will look into adding the optimization, but it gets tricky because âvacationâ isnât actually a hold, but changing the fan mode or temperature IS a hold. Just means a bit more checking, but itâs not impossible.
What is your heating/cooling differential set to (you will have to look at the thermostats themselves to see these)?
If you set the heat temperature to 68 and the heatingDIfferential is 3 degrees, you are actually telling the thermostat âdonât turn on the heat until the temperature gets below 65 degrees, and then run the heat until it gets back to 68 degreesâ. When not heating, my Ecobee thermostat devices show the Heat At temperature; while heating, they show the Heat To temperature. The temperature sliders should always show the actual Heat To temperature.
AndroidsâŠthere are constantly issues with the thermostat multiAttributeTile in SmartThings. (I cringe because all 3 icons in the top row are actually the same size, but Android renders them as 3 different sizes).
Have you tried:
Pull down on the device page - this should cause SmartThings to redraw the page
Tap the âBeeâ icon, wait for the "Beeâ to re-appear, then tap it again. This âtwo-tapâ action causes a forced refresh of the page
Gâday all,
This is my first Smart App install so be gentle.
I think I followed the install instructions to the tee (as far as I can see, I have triple checked) but I can not for the life of me figure out why the Ecobee app/s will not show up as âpublishedâ in either the âMy Device Handlersâ or the âSmart Appsâ pages.
I have tried refreshing (suggested in the instructions), shutting the page and opening it again to no avail.
I did read on a different forum page that ST was having issues but that was from the 15th of March (if I remember correctly, I canât find the page again)
Any advice would be appreciated.
Cheers
J
Yeah, no dice. It is happening on one of my thermostats right now. I tried both solutions mentioned, and neither worked. But, if I go into the Ecobee Suite Manager SmartApp, and resave then it is fine. Very strange.
This doesnât seem to be the case, when I look at âRecentlyâ under the device, it seems to me that simply the wrong JSON payload is being sent. I have the automation set to 68-74 but the device is showing that it is sending âcoolHoldTempâ:â740â,âheatHoldTempâ:â650â. The cool hold temp is correct but the heat hold temp is not. When I ran the same automation manually standing in front of the thermostat, I could see that the correct JSON values were sent and my thermostat was set to 68/74. Iâve attached some screenshots of what Iâm talking about.
Usually this means that you have installed the apps into the wrong SmartThings âshard.â I suggest you search for âshardâ in this forum for more info, but generally you should:
Click on âMy Locationsâ (top left after you have logged in)
Click on the name of your location - this will bring you to the proper server for your location/hub
Then install everything from there (you will probably get a message that you have no SmartApps or Device Handlers install). Select My SmartApps and My Device Handlers as is appropriate.
Could you please run that same test, but this time with Debug Level 5 (in Ecobee Suite Manager preferences) and with Live Logging on for the Thermostat device? Iâd like to see what is actually being requested by the âEcobee Wakeâ routine - I think I know whatâs happening, but the log should help confirm it.
I canât run a test manually to reproduce the results. This happens when the automation fires by itself, and even when it does happen it doesnât seem to happen consistently. I had it happen once on Friday and once today. If I run the automations manually the correct data seems to be sent every time. I can change the time of the automations for to execute one minute ahead and see if I can get some data for you but no guarantees, heh. Itâs strange.