Set home/away mode manually

[benno666]

Hey,

first of all I‘d like to thank you for your quick responses and adding my suggestions to your plugin! It works really well now!

Right now I have another suggestion: Is it possible to use Tado‘s api to set the home or away mode manually? I know that it wasn‘t possible to switch the state to away unless you actually were outside of the geofencing area. But with the new app update it is possible to change the state even when you‘re at home (but I don‘t know if this applies to all hardware versions and subscriptions of Tado). Do you think there is a possibility to implement this in your plugin? Something like a home/away switch? Thanks again!

Best regards, Benno

[lukasroegner]

Hi @benno666, It would be possible. I think that there are 3 states (AUTO, HOME, AWAY), do you have an idea on how to map that to HomeKit services?

[benno666]

I could imagine that using a security system service might work. Its target and current states are quite similar (stay/away/night/disarm). In fact, if you add this to the existing occupancy sensor in your plugin, these two services merge in an unexpected but pleasant way.

This is what it looks like with a security system service:

If you combine these two, that's what you get:

But most important of all, you can change the values manually without additional switches:

One should be able to map out the night mode, so you could have settings like this:

• stay in security system: manual home mode in Tado
• away in security system: manual away mode in Tado
• disarm in security system: automatic mode in Tado

The occupancy sensor could work on top of that like before:

I hope this helps for the moment, what do you think of it?

Best regards, Benno

[bxlouis]

Hello This is a great suggestion by @benno666.

In addition, as I don't own a security system myself and don't know how it behaves in the Homekit app, it would be great that the Home/Away toggle can be set from a scene. I am saying this because regular presence sensors are marked as "Always On" so you cannot change their state from a Scene or Automation.

Regarding the Tado API, here is what I found so far:

Presence check GET https://my.tado.com/api/v2/homes/{{homeID}}/state

Set Home/Away PUT https://my.tado.com/api/v2/homes/{{homeID}}/presenceLock With body { "homePresence": "HOME" } or { "homePresence": "AWAY" }

[lukasroegner]

@benno666 That might work. I like the merged sensor and security system controls, however, an occupancy sensor is created for each device in Tado, it is not just a single one. Any idea on how to handle that?

[lukasroegner]

The new version (0.4.0) contains an option to enable the global Home/Away "switch". It is an occupancy sensor that shows the global home/away state. The accessory contains a 3-state switch (from the security system):

• Home
• Away
• Off (which means manual override is off...which means AUTO mode)

[bxlouis]

@lukasroegner I just tested the new version.

It works great for "Home" and "Away" and I can find the additional alarm button in the "Accessory Automation" menu, which is perfect.

However, I'm having a hard time understanding the "Off" mode. I don't understand the purpose and when I try to enable it, the console gives me the following: [TadoPlatform] HOMEID - Failed to set presence to AUTO

And in the Home App, the switch comes back to its previous state (Home or Away).

[lukasroegner]

@bxlouis do you have the v3 version of Tado and the Auto-Geofence skill?

[benno666]

@lukasroegner I tried the new version 0.4.0 and it works like expected! I see you managed to use a single occupancy sensor for all thermostats. Thank you, great work!

@bxlouis The security system service that is used has fixed names for its states. While the stay and away states match home and away in Tado, there is no equivalent for the auto mode in Tado. That‘s why the disarm/off state is used to match this. That means, if you set the security system to disarm, Tado will go in auto mode. It‘s not intuitive, but once you understand its logic (and why there is no obvious other way to handle this), I hope it becomes clear.

I can‘t figure out why you get this message in the console. What Tado version (V2, V3) are you using?

[bxlouis]

@lukasroegner I have 4 Tado V3 thermostats but the Tado app geofencing feature is disabled as I am using the native geofencing from the Home app to automate everything. Also, I am not paying for the Tado "Auto-assist" feature, maybe this is the reason?

@benno666 thank you for clarifying. There is still a thing I don't understand: If I set the sensor to "Home", I expect that my thermostat will follow the schedule I set for each of them which, in my understanding, is the Auto mode ? There is definitely something I'm missing here, sorry.

And finally, I noticed that in @benno666 example, there was a "Night" mode. It would be great to have the possibility to enable this mode, even if it does not trigger anything, just for the sake of automating in the Home App. It would allow to trigger or respond to additional scenes.

Thanks for you help, I really appreciate your reactivity! :)

[bxlouis]

And also, something I don't quite understand, when I set the sensor to "Away" the Thermostats do not switch to "off" in the Homekit app but are set to "Auto". However, in the Tado app, they are correctly set to "Off" (frost protection). Is it again linked to something I am missing with the Auto mode you are referring to?

If it's not a bug I find it very confusing to see the thermostats powered on in the home app while they are turned off in reality.

[benno666]

@bxlouis Ok, now I see why there is some room for confusion :) If you use Tado‘s geofencing feature, it‘s called auto mode. It decides whether you‘re at home or away and uses the schedule you set in the app. The new sensor is able to override this behaviour, it‘s not a global on/off switch!

I assume that‘s why your thermostats don‘t work as you expect. I will have a look...

[benno666]

@bxlouis @lukasroegner I have the same bug... if the security system is set to away, the Tado app shows that the thermostats are off, but they are shown as active in HomeKit. Something‘s not right here...

[lukasroegner]

Are you sure it is a bug? Please check the discussion at #4

[benno666]

@lukasroegner You are right, this isn‘t really a bug but by design. I will check why you made this decision at #4 and comment there!

[lukasroegner]

New version 0.4.1 on NPM.

@bxlouis There is a new configuration option to determine whether Auto-Assist is used. In your case, the config should be:

...
"isGlobalHomeAwayEnabled": true,
"isAutoAssistEnabled": false,
...

In this case, a simple switch is added to the occupancy sensor. On -> HOME mode, Off -> AWAY mode

@benno666 Your configuration should be:

...
"isGlobalHomeAwayEnabled": true,
"isAutoAssistEnabled": true,
...

In this case, the security system controls are used.

[benno666]

@bxlouis @lukasroegner I asked this in #4, but I think it could be important at this point in this discussion, too.

Sorry if I have to ask, but is there a need to have the thermostat set to off when you‘re in auto mode? What‘s your use case for this? Wouldn‘t it be sufficient to switch to manual mode when turning the thermostat off?

Somehow I don't seem to see the benefit of seeing whether the thermostat is off in auto or manual mode. What am I missing here?

[lukasroegner]

@benno666 I think you misunderstood the issue in #4: Even when the plugin reports the current thermostat state as "Off" to HomeKit, the Apple Home app still does not "gray out" the icon, instead, it is still green and reports "set to 5 degree" (the minimum temperature).

[benno666]

@lukasroegner I think I got that part, but I don't understand why the plugin should work like that? As I understood it's meant to be by design, but I don't see a use case for that. Sorry :)

In my eyes it should work like this:

If Tado reports "settings.heating.Power.Off" then the plugin should set its current heating cooling state to off. As far as I can see, the plugin does that. I think there is some misunderstanding in the thermostat's color schemes and how to influence them.

As long as we have a heating only thermostat (like Tado), the current heating cooling state shows if the thermostat's valve is open or not. If the thermostat should be active in any way, regardless if it's heating or not, the target state is set to heat or auto and a green circle appears in the app, if the thermostat's valve is closed, a yellow circle appears if the thermostat's valve is open. A gray circle appears if the thermostat should be off (target heating cooling state off) but the thermostat is still heating. The thermostat grays out completely if you want it to be off (target heating cooling state off) and it is actually off because its valve is closed (current heating cooling state off).

It seems to me that the plugin isn't changing the target heating cooling state aswell if the current heating cooling state is off, that's why it doesn't gray out.

[lukasroegner]

@benno666

If Tado reports "settings.heating.Power.Off" then the plugin should set its current heating cooling state to off. As far as I can see, the plugin does that.

Exactly. The plugin reports the correct current state from what it gets from the API:

zone.thermostatService.updateCharacteristic(Characteristic.CurrentHeatingCoolingState, state.setting.power === 'ON' && state.activityDataPoints.heatingPower && state.activityDataPoints.heatingPower.percentage > 0 ? 1 : 0);

If the thermostat is on and the heating power is > 0, then the plugin reports the current state as heating, otherwise it reports off.

It seems to me that the plugin isn't changing the target heating cooling state aswell if the current heating cooling state is off, that's why it doesn't gray out.

Correct, and that (the fact that is doesn't also set the target state) is by design. The target state is the exact target state from the API:

zone.thermostatService.updateCharacteristic(Characteristic.TargetHeatingCoolingState, !state.overlayType ? 3 : (state.setting.power === 'ON' ? 1 : 0));

If there is no overlay (Tado exposes an overlay object if you override the automatic mode), the plugin reports the target state as AUTO. If there is an overlay, it reports HEAT if the overlay is set to power on, and OFF if the overlay is set to power off.

The discussion in #4 has been around the fact that (as you already said) the Apple Home app (if the current state is off) does not turn its visual representation to gray if the target state is other than off.

What would you like to change in comparison to the current implementation?

[benno666]

@lukasroegner

What would you like to change in comparison to the current implementation?

I would like to see a similar behavior of the plugin in comparison with Tado's HomeKit implementation. Because HomeKit has no AUTO in the current heating cooling state by design, if the thermostat is OFF in the Tado app, it also grays out in HomeKit because its target state is set OFF, too. This is the only way to see if the thermostat is turned OFF because of HomeKit's limitations and I would like to see this in your plugin, if you could make this happen.

You could implement this with inverting the logic:

If state.setting.power is OFF, the target state is OFF. If state.setting.power is ON, there are two cases:

• If there is an overlay, the target state is HEAT
• If there is no overlay, the target state is AUTO

This way the thermostat should work as expected.

[bxlouis]

@lukasroegner I tested version 0.4.1 and it works well with the option you added. I also agree with @benno666 regarding the logic which should be implemented.

@benno666 thanks for your explanations with the auto mode. I temporarily subscribed to the Tado "Auto-Assist" feature and understood the concept of AUTO.

[lukasroegner]

You could implement this with inverting the logic:

If state.setting.power is OFF, the target state is OFF. If state.setting.power is ON, there are two cases:

If there is an overlay, the target state is HEAT If there is no overlay, the target state is AUTO

Yes, can be implemented as alternative logic. How would you handle the AUTO mode in this situation: the thermostat is set to OFF via Tado schedule. In this case (with the described logic implemented), the target state in HomeKit would be OFF. If you now switch the target state in HomeKit to AUTO, it will immediately jump back to OFF.

[benno666]

@lukasroegner Thanks for brainstorming with me! I have to dig deeper into the subject because I never had the need to turn the thermostat off using the smart schedule while I'm at home. Normally I reduce the temperature and only turn it off when I'm away. I will have a closer look on how to handle this regarding the AUTO mode.

[benno666]

@lukasroegner I just had two ideas, each with its pros and cons. I didn‘t have much time to test it and think everything through, though. :)

If Tado is in automated schedule mode and turns the thermostat off,

A) one could set a manual overlay to turn the thermostat off that ends automatically after the time block, or B) one could set the target temperature to 5 degrees in HomeKit only. Because HomeKit differentiates if the temperature is set in auto or heat mode in the thermostat’s info box, one would see if it was set manually or by Tado‘s schedule.

[lukasroegner]

@benno666 Thank you for the feedback. I don't understand either of your solutions. I would suggest that I implement the alternative logic and make it available via config. Then, you can play around with it and tell me what is missing in the code.

[lukasroegner]

@benno666 New version 0.4.4 has the option isAlternativeStateLogicEnabled. If enabled, your target state logic is used.

[benno666]

@lukasroegner Thanks for adding this! I will see if it works for me, but it looks good so far. :)

Regarding my other solutions, if you could create a control function in your plugin to check and manage the "matching process" between the states and settings in Tado and HomeKit (instead of calling the API directly) to prevent illogical behavior, a part of this logic could look like this:

If Tado uses its smart schedule (i.e. no overlay is set) and the thermostats should be turned off completely (i.e. heating.power is OFF), the control function could interpret this as a target temperature of 5.0 degrees and set this value in HomeKit. Normally, if you would change the temperature in HomeKit, it would call Tado's API and change its target temperature, too, resulting in a manual overlay. But if you disregard a setting of 5.0 degrees in HomeKit (i.e. don't call the API), Tado wouldn't "know" that HomeKit is showing a target temperature of 5.0 degrees. This way one could see in HomeKit that the thermostats are still using the smart schedule and are set to anti-freeze (5.0 degrees), while turning them off manually results in a grayed out thermostat showing the OFF label.

[lukasroegner]

This sounds way too complicated and people using the plugin won't understand this behavior. You could fork the plugin and implement this behavior.