Toon ignores scheduled program, possibly due to Home Assista

[Rudolf]

My Toon1 seems to ignore its schedule at certain times. i.e. changes from Home -> Comfort don't happen reliably.

I've been trying to make the smart Thermostat even smarter by integrating it with Home Assistant and its presence detection.
This results in HA changing the mode of Toon and might confuse Toon.

This morning for example, Toon was scheduled to go from Home -> Comfort @ 9.00 AM.

At 8.30 HA checks if there's presence and sets the 'Home' state.
(In this example that's a non-change, but that isn't always the case)

08:31 Toon wordt ingesteld op 'Thuis' want er is iemand thuis
08:30 Toon wordt ingesteld op basis van de huidige aanwezigheid

My guess is that this causes confusion because Toon is already pre-heating to reach 'Comfort'-setpoint at 09.00 AM.
Or maybe Toon ignores the schedule for a certain amount of time after a manual change?

I'll make HA monitor http://toon:10080/happ_thermstat?action ... mostatInfo more closely for strange behaviour.

[Rudolf]

Can anyone shed some light on the meaning of the values in the web-API of happ_thermostat?

http://toon:10080/happ_thermstat?action ... State=yyyy

state:
0 = program/schedule enabled
1 = program/schedule disabled
2 = ??? (changed by user, only if different from schedule)

temperatureState:
0 = comfort
1 = home
2 = sleep
3 = away
4 = holiday
-1 = ???

I checked the custom component for Home Assistant:
https://github.com/cyberjunky/home-assi ... on.py#L150

Secure Toon Control doesn't do that:
https://github.com/jonkootje/secure-too ... /js/app.js

I modified the component for HA
https://github.com/cyberjunky/home-assi ... s/issues/8

It seems that when I the program from the GUI the state switches to '2', as if there's a special flag for a user setting.
There must be some logic behind it to prevent it from returning to it's ordinary schedule shortly thereafter....

[TheHogNL]

Could be the lock feature. Older toons allowed to to press a temperature state twice which locked in on to this state, not allowing the program to override it. Exactly what you are describing

[mAiden]

TheHogNL is right..

This is indeed the lock function, which used to be in 1 of the 4 program positions to be locked. See the picture below

Screenshot_8.png (12.41 KiB) Viewed 4854 times

[TheHogNL]

Not sure why they removed that function

[yjb]

Well, technically they did not remove the functionality but replaced it with the slider switch "program on/off"

[Rudolf]

Thanks for insights! Good to know that there was such a feature in the past.

It seems that changing the mode using the GUI 'locks' the program implicitly; because state changes to '2'.
This probably doesn't last forever, but it sure does take a while to return to normal/scheduled operation.

It's also very nice to know that there's been user interaction that changed the mode; I can use this to disable some automations...