Changing Ecobee climate type with indefinite hold fails

[ISY4Me]

I am trying to implement a programmatic solution to emulate vacation mode.  The test was fairly simple.  In the first image you see the test command to change the Climate Type to "Away" with Hold Type "Hold Indefinite"

When this test condition is forced to run, it implements the change as seen in the next photo.

You can see that the Climate Type was changed to Away and the Comfort Settings for "Away" changes the Heat Setpoint to 52 degrees and that also is changed.  But the Schedule Mode is set to Hold Next.   

So, I just ran this test just before my normal 11:00 PM Comfort Setting change and the "Hold Next" did just as expected and changed to the 11:00 PM Setting and it reset the Schedule Mode to "Running" and the Heat Setpoint was set to the temperature for the 11:00 PM Setting... it did not hold the setting change indefinitely.

While I have not run the test case yet, I know I can manually change the Schedule Mode to "Hold Indefinite" by adding another command to programmatically change the Schedule Mode to "Hold Indefinite", but the subcommand in the Climate Type selection to change to "Indefinite Hold" is incorrectly changing the Schedule Mode to "Hold Next".

I am assuming this is a PG3 NS issue.  Please let me know.

[larryllix]

Just some observations

Why not use vacation mode if a permanent hold is wanted?
I am not sure Away climate will ever be Indefinite remotely, and may not be a possible combination .  I have never used Away on my ecobees. This is my third, now.
What is your internal schedule hold set to? This may be overriding any remote Hold.

I gave up trying to have my ISY control my ecobee stats (they already contain very advanced logic) and went the other way around, finding that the ecobee stat firmwares were so much more stable and didn't rely on cloud and multi-processor mediums to operate.

In the end, a much more reliable and easily settable  way was for the ecobee Vacation schedule status to control my ISY vacation logic for the whole house. If the connection failed it was only some fancy HA stuff like humidifier, HRV, fan cycling, security lighting etc.. not my home heating. Of course my house (slab heat in Canadian winter) would only reheat about 1 degree per hour, at best, so when it failed, we slept with a lot of blankets the first night home and used the stove a lot, the next morning

[ISY4Me]

@larryllix I agree with all of your comments.  I have test driven the Ecobee Vacation mode and it does work well.  This is an experiment to see if something equivalent can be done with programming control from IoP.

I did run the 2nd IoP experiment I mentioned... setting the Set Climate to Away and then followed it immediately with Set Schedule Mode to Indefinite and even then at the normal 7:30 AM Climate/Comfort Setting schedule change over it still changed to the normal schedule and did not hold the experiment settings.  That surprised me a little, I would have thought setting the schedule mode to indefinite would not change anything until the user intervened.

My internal schedule hold duration is set to "Next Scheduled Activity", so that could indeed be overriding any programmatic setting.  I can run those experiments.

This is my first heating season with the Ecobee, so I am still learning the best way to control things.  It is always fun having a little challenge and learning experience.  Thank you for the feedback.

[Jimbo.Automates]

Something must be overriding it or setting it back because I use this method extensively at our Lake House.  I created an "AwayExtended" Climate Type and have a program that sets it to that Cand Hold as Indefinite and it works great. 

[ISY4Me]

I ran multiple tests this morning and finally was able to get a persistent change.  I think @Jimbo.Automatesis correct, in that something was not under control.  So, this is the criteria that finally appears to work.

• I set the Ecobee app "Device Settings" for "Hold Duration" to the "Until I change it" selection
• In IoP, I programmatically set the Climate Type to my "Away" test comfort setting, but I had to set the "Hold Type" to "Indefinite Hold" to keep the changed value for climate.
• In IoP,  programmatically issue a "Wait" command for two minutes to give time for the last command to propagate to the thermostat settings.  Changing the Climate Type will change the Schedule Mode to "Hold Next", so that setting needs to be stable before forcing it in the next step.  Perhaps it can be shorter that a 2 minute delay... needs further testing.
• In IoP, programmatically issue a "Schedule Mode" change to "Indefinite Hold"

In the testing so far, the Temperature, Climate and Schedule Mode are all staying as set in the experiment.  They did not change when the Ecobee when through a Scheduled Comfort Setting change.  I then manually changed the schedule on the Ecobee App to go back to my standard daytime schedule and again, the Temperature, Climate and Schedule Mode remained the same as they were for the Away Test experiment.

Reverting back to standard operation is as simple as issuing an IoP command to change "Schedule Mode" back to "Running" and everything goes back to the standard schedule.

The standard Ecobee Vacation Mode is a very good tool, but I am optimistic that being able to programmatically control things will give me other options where they are needed.