All Zones Away Switch

[tedinorbit]

Enable the ability to use the "All Zones Away" option. It's something I frequently do in the Bryant App now when leaving the house for any length of time. I would personally tie this to a homekit automation that if the last person leaves the house, All Zones Away is set.

Describe the solution you'd like: Create a switch that when "on" enables the "All Zones Away" function. When turned "off" it ensures "All Zones Away" is not currently set. This could be a permanent hold, or a timed hold, similar to the already implemented "holdBehavior" options for until_x, for_x, or forever. activity doesn't really make sense as an option here because activities could differ for each zone.

Additional context: This can be set by setting the "config" object values for "wholeHouse".

     config.wholeHouse.hold = ["on"];
     config.wholeHouse.holdActivity = ["away"];
     config.wholeHouse.otmr = [""];

It can be reset by using the following values for "wholeHouse".

     config.wholeHouse.hold = ["off"];
     config.wholeHouse.holdActivity = ["none"];
     config.wholeHouse.otmr = [""];

I believe otmr is treated the same way as an individual zone's is, except its for the whole house feature.

[tedinorbit]

For reference, here are some screenshots of the function from the thermostat interface.

[grivkees]

Few questions on some edge cases here since I dont have a multi zone system to test with:

When you set the whole house hold activity from the thermostat, and wholeHouse.holdActivity gets set in the config, do you know if per zone holdActivity's are also set in the config? Or does a config for wholeHouse.holdActivity effectively override a per zone hold activity setting.

If you have a whole house hold set, and you change the activity in just one zone, what happens to the other zones?

Thanks!

[tedinorbit]

The whole house setting is independent of the per zone. So a zone can be set to “sleep” for example but a whole house home/away overrides it.

When the whole house activity is set, the thermostat forces you to cancel it if you are going to set an individual zone.

After testing the changes you made for v1.6.0, a single HomeKit scene where you turn off the manual hold for all zones, and another scene to enable the away activity for all zones honestly suffices for my use case (and is probably a much cleaner implementation).

I’ll leave it up to you if you want to close it but I don’t know if it would bring a whole ton more value for the increase in complexity it’ll probably require.

[jlg89]

I've just installed the plugin, and I'm trying to figure out how you're setting up those scenes. I don't see a way to enable/disable manual hold, for example, or enable certain activities. Would you please elaborate on the procedure?

[tedinorbit]

Here’s what I have set up. The gist of it is that you set the comfort profile you want and use the indefinite hold (which I believe is the default), and it will stay on that setting indefinitely. In my case I set away for all my zones when I leave home. When a comfort profile is selected, you’ll see the manual hold switch turn on, indicating that you aren’t on your normal schedule. To resume, just cancel the manual hold and it’ll go back to whatever comfort profile you have selected for your schedule.

[tedinorbit]

Oh also there’s a config option you need to set in the config.json I think you are asking about. I’m not sure if it was added to the documentation yet…I found it in the schema. https://github.com/grivkees/homebridge-carrier-infinity/blob/ff670ccd53da3086a1544ab9fbf46c83d02b1cb4/config.schema.json#L59 I think it says default true but I vaguely recall having to explicitly set it to get it working.

[jlg89]

OK...my config is below. I just added the showZoneComfortActivityControls line, but the switches aren't appearing in HomeKit. Anything special I need to do in order to refresh that, other than restart the homebridge server?

{ "platform": "CarrierInfinity", "username": "****", "password": "****", "holdBehavior": "forever", "showOutdoorTemperatureSensor": true, "showFanControl": false, "showIndoorHumiditySensors": false, "showZoneComfortActivityControls": true }

[tedinorbit]

I also have @latest installed. Maybe it’s included in a later version than what’s currently published on npm?

[jlg89]

Yeah, 1.5.13 is current, I had to install "next." Looking good now. I'm using HOOBS, so that may have something to do with it. Thanks for the help.

[grivkees]

To confirm, the comfort profile control is not yet released on “latest” it is only on “next”. I have some more stability improvements I want to make before I release it to the main release, but haven’t been able to complete them yet. In the meantime, you can do explicitly install the “next” version from npm and set the config option (which is mentioned, is not yet documented).

[jlg89]

I really appreciate this plug-in, esp with the new comfort profile control. I've been trying to use homebridge-infinitude (stock and v2), with no success. I prefer the local control vs. requiring internet access, but your plugin works!

[tedinorbit]

I second that! I was also trying to use infinitude, but I much prefer this method using the API since I use both HomeKit and the Bryant app to make changes. I tried to write my own a while back with some success, but limited knowledge prevented me from making it work very well.

[jlg89]

I set all three zones to "Away" using an Automation (as tedinorbit shows above), and both the thermostat and the Carrier Home app reflect the "Away" setting. The log shows "Changes sent to carrier api successfully." But at some point (I assume at the next schedule change, but haven't verified this) it all goes back to the schedule, even though "holdBehavor" set to "forever." Am I missing something in the config?

{
    "platform": "CarrierInfinity",
    "username": "****",
    "password": "****",
    "holdBehavior": "forever",
    "showOutdoorTemperatureSensor": true,
    "showFanControl": false,
    "showIndoorHumiditySensors": false,
    "showZoneComfortActivityControls": true
}

[tedinorbit]

I assume when you check the app/thermostat it says just “holding” instead of “holding until 5:00pm”, correct?

[jlg89]

The settings get applied as expected, i.e. I toggle "Away" in the Home app, it gets reflected fairly quickly in the Carrier Home app, and then the thermostat picks up the setting a couple minutes later, shows "Away" as it should. But then at some point the thermostat spontaneously reverts to the schedule. Just now, I watched it revert as I stood there.

I had the thermostat proxied through infinitude, which isn't supposed to matter, but based on reported odd issues with infinitude's ability to reliably communicate with the Carrier cloud, I suspect that may in fact be the issue. I just disabled the proxy on the thermostat, and the Away setting seems to be sticking, at least for the moment. I'll test it for a few days and report back.

[tedinorbit]

Oh you’re still using infinitude? I had lots of issues when trying to make updates via the app/api and having them make it back through infinitude correctly. There seemed to be some issues with which side (api or thermostat) was the source of truth and I noticed similar conditions where things would spontaneously overwrite. I’m currently just using the api directly again and haven’t noticed any strange behavior since.

[jlg89]

I can confirm that Infinitude was the issue. Once I deactivated the proxy on the thermostat, this plugin started working immediately. The t-stat also pulled a long-overdue firmware update. It seems that Infinitude doesn't do pass-through or updates from the cloud very well; it basically just takes over and assumes it's in charge. That's a shame, as I really liked having access to the detailed info from the Infinitude web page. I've made a suggestion to the infinitude dev to add the ability to put infinitude in "read only" mode, with better pass-through capabilities.

[tedinorbit]

I’m struggling to find it now, but I vaguely recall reading the author of infinitude saying something to the effect of “It should work with passing most things through but I don’t use it myself so I can’t be sure”

[jlg89]

I recall reading the same thing, but I don't remember exactly where either.

[tedinorbit]

So I believe this is still on “next” so I’ll add this note here.

When updating to iOS 16, the activities all show up as generic names. I can no longer tell which one is “home” or “away” or “sleep” or whatever.

Here are some screenshots

[tedinorbit]

Strangely enough if I cleared the names of each of them, the correct activity name would auto populate. All I had to do was type that name and it would save correctly. Not sure what would happen if this was populated fresh (as in not already in HomeKit pre-iOS 16). I don’t really want to try since mine are all linked to automations/scenes and don’t want to redo all of that 😬

[etomnash]

Yes, it is strange, but not new as I recall having to do this earlier with this (and maybe other Homebridge plugins).

[grivkees]

v1.6.13 released yesterday on 'next' fixes the display name issue and has a bunch of other stability improvements to the activity switches. tl;dr they actually work pretty well now,

Ill leave this open still to track the whole home activity switches, which seem worth doing still, and I'll revisit after I make some improvements to multi-zone/multi-system naming #384