CHILD LOCK

[Seyko91]

Hello,
thank you for this great thermostat that I have been using for two months.
however it is missing an essential function in my opinion. Child safety so you cannot touch the thermostat by mistake and for safety.
Would it be possible to integrate this function soon? Thank you so much.
Good evening

[jmcollin78]

restriction-card is your friend !

[Seyko91]

Yes i know, but don't Work with horizontal-stack
..
It's better if it's directly in option in your card

[jmcollin78]

I will not do that because some best system already exists.
Why do you speak about horizontal-stack ? custom:restriction-card works with all card type, I guess.

[KipK]

@jmcollin78 , restriction-card won't really fit all use cases I think.

A lock switch entity feature could be interesting when you want to force a vtherm to be off or locked to a specific presets/temp without having to disable your schedulers/agenda or automations that could change it.

Also personal assitants like Google Home or Alexa will still be able to change vtherm settings if lock is only implemented on UI card.
Same for external displays like NSPanel Pro.

When I have some AirBnB guests, I'd like to prevent them to change thermostat settings from a wall panel not using HA UI.

I was about to post a thread about it before finding this one :)

[KipK]

Bumping the thread @jmcollin78 , I'd really like we discuss about this.

This is a common feature in many hvac devices ( at least in north america ), also on Jeedom thermostats,.
There's so much other uses cases I haven't listed yet, I feel it deserves some debate.

Cheers

[jmcollin78]

Hello @KipK

This is not a matter a debate but a matter of development resource and time.

I just can't do all what people are questing and I'm really not the king in front end developement. More over this issue is not a VTherm issue but a Vtherm UI Card issue (I will relocate it).

If someone can take it and do a PR, I would love to merge it in the next release. That is how open source works.

[KipK]

ho it's no a frontend one. The lock should be a switch entity just preventing changing vtherm settings on backend side. On frontend, there's no really needs, but perhaps adding a lock switch button on your vtherm card to enable/disable it ( that's something I can probably help with and perhaps other fancy UI stuff, but haven't gave a look yet on HA ui dev ). But it can be added manually using custom:stack-in-card anyway.

There's no important needs to lock the UI temperature buttons and modes + presets. When locked switch is on, it will just not change anything when clicking on other buttons.

If it's done only on UI side, it won't prevent Schedulers, Automation, Voice Assistant and external panels to change vtherms settings.

I've started to install a dev env to tryout, but still really lost to it. I've not given up anyway ;)

[jmcollin78]

Hello @Seyko91 ,

How do you image the child lock feature ?
One common need, is to avoid click without intention on the card when the round circle is displayed and specially on mobile device.
This is a totally case from @KipK explaination.

On my case, I want to lock the screen so that I won't change anything when scrolling but I want to let the scheduler and automation do their jobs. So it is really a front end case which is supported by restriction-card (see here for the "bug": #46).

@KipK
Totally blocking on backend is a totally other feature and is on the contradiction with Scheduler integration that controls the main preset. You said when you have guests, you don't want that they change the preset or whatever. But they interact with a UI, i think. So a restriction-card with a code will do the job. And you let the Scheduler or automation do their work.

[Seyko91]

Bonjour, I use restriction-card with a popup message. Cdlt Le dim. 16 févr. 2025, 07:55, Jean-Marc Collin ***@***.***> a écrit :

…

Hello @Seyko91 <https://github.com/Seyko91> , How do you image the child lock feature ? One common need, is to avoid click without intention on the card when the round circle is displayed and specially on mobile device. This is a totally case from @KipK <https://github.com/KipK> explaination. On my case, I want to lock the screen so that I won't change anything when scrolling but I want to let the scheduler and automation do their jobs. So it is really a front end case which is supported by restriction-card (see here for the "bug": #46 <#46>). @KipK <https://github.com/KipK> Totally blocking on backend is a totally other feature and is on the contradiction with Scheduler integration that controls the main preset. You said when you have guests, you don't want that they change the preset or whatever. But they interact with a UI, i think. So a restriction-card with a code will do the job. And you let the Scheduler or automation do their work. — Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCOLSWN6X55J4NVPJR3JM4D2QAY47AVCNFSM6AAAAABXGKRS2WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRRGM3DAOA> . You are receiving this because you were mentioned.Message ID: <jmcollin78/versatile-thermostat-ui-card/repo-discussions/65/comments/12213608 @github.com>

[KipK]

@jmcollin78

Some realistic use cases of the backend side lock feature:

I'm going away for few days, I've set the vtherms to 14°, and then Lock all of them. Then I'm sure the scheduler won't change the settings while I'm away

I receive some guests for a dinner tonight. I don't want the scheduler to lower the heating after midnight, I then lock it up to comfort until party is over.

I'm a medic, and I have my office at home. Scheduler start heating the office everyday but the week end at 6am. But exceptionnaly tomorrow I'm closed. I then lock the office vtherm the day before to prevent it heating for nothing.

In all those kind of use case, the only solution for now is to disable the scheduler, or worst have to edit it if the same schedule control different vtherms

I have BnB guests, I want them to prevent changing the settings from the wall panel display ( those wall panels do not use the HA user interface ) or using the Google/Alexa voice assistant. I'm locking the related vtherms while they stay home preventing them to change anything whatever the way it's controlled. Restriction card won't do anything here.

On this last case, if I need the scheduler to still be able to change the presets/temp while locked, I still can make an automation that check if it's locked, unlock the vtherm, change the setting, then lock again.
But as you said, restriciton card is more suited for this one.

'Child lock" is a confusing term as many use cases are not child related. They call it like this in north america for any lock feature related to heating/Ac/cooking, and we can find it named like this also on Matter/Zigbee specs. But it's just a basic lock preventing to change anything.

[jmcollin78]

Some realistic use cases of the backend side lock feature

For all this use case, what you have to do is just to deactivate the Scheduler. What you explain is not to lock the Vtherm but is to deactivate the Scheduler :

Just one click for the exact same feature.

In all those kind of use case, the only solution for now is to disable the scheduler

Exactly.

And the other use cases and simply possible with the restriction card (I fix the issue this week-end and it is working fine now).

I'm still not convince it is something useful. I will keep the discussion open for others advices.

[KipK]

I don't get how restriction card or disabling the scheduler could prevent using Google assistant or ZigBee thermostat panels , or any other wall display like the NSPanel which doesn't use HA UI

On my case I also have few automations that can control the vtherms, it means disabling them too, plus editing the scheduler as I have one schedule for all the vtherms. But if I just want to lock few of them, it would be a UX nightmare.