using the google assistant (and Nabucase) Ive noticed (or should I say inadvertently experienced) accidental direct switching of switches that are ‘secured’ with a lock in my Ha setup.
apparently the integration doesnt respect/see this, and switches immediately. In several cases in m setup this is unwanted behavior…
Would there be a way to prevent GA from doing this? I havent found an option in the Nabucasa docs https://www.nabucasa.com/config/google_assistant/ to do so unfortunately. Switches don’t have a ‘Pin’ option afaik.
Another option would be if we could have GA not listen to dedicated entities. I mean to have to full set of switches integrated in the GA app, and be able to click those, but have several entities not exposed to Google assisant over voice commands.
Is that in any way possible at all?
thanks for having a look.
What you’ll likely have to do is expose an input_boolean or template switch to Google, and have it control that. Then you can apply your own logic (assuming that the “lock” status is visible as the state or attribute of an entity).
sounds like a way to pursue…though Im not yet clear as to how. Right now clicking a ‘locked’ switch gives a few seconds to affirm it, just in case one mis-clicked the wrong switch
how would I do that with an input_boolean in Google assistant?
I have a template switch that switches one of these locked switches (among a few other things). Clicking that switch in regular HA gives the more info of that switch and needs the affirmation of a second click.
Could one use that in Google Assistant to reach the same effect?
That looks good. Now you’ll “just” need an automation that handles what you want, and an input boolean - for each switch. You can do this with a single automation and templates, but I’d start easy.
Let’s assume you create input_boolean.sw_audio_auditorium_template that you expose to Google instead of the switch, then you’d have something like:
It may need some tweaking and tuning, I haven’t checked the syntax is 100%, but it should get you started. Basically, every time the state or attributes of input_boolean.sw_audio_auditorium_template change, the automation starts. Then only if the state changed ((trigger.to_state.state != trigger.from_state.state)) and the device is unlocked (is_state_attr('switch.sw_audio_auditorium_template','confirm_controls_show_lock','false')) does it toggle the switch.
This will of course get out of sync with the actual switch, so you’ll need to consider an automation to ensure that the boolean is kept in sync with the switch.
a yes, thanks!
this needs some more thinking indeed, because the out of sync thing is an issue, especially when handled by the family
not sure how this is handled by the switch, so need some experimenting. clicking it give some time to re-confirm one has pushed the correct button, and only after that the automation would need to trip and actually switch.
but wait: the attributes never changes, it merely is a pointer to the system the switch has a ‘lock’. It will never change from true to false…
would you have any thought on the voice commands also? Can we single out entities from the voice command, while in fact they are in the set of entities in google assistant/home?
How is this done with the Pin-able entities? I don’t have one so no experience there.
Suppose there’s no way either to fake it to be a lock, just as with the template switches, maybe a template lock https://www.home-assistant.io/components/lock.template/ ?
I don’t believe there’s any way to get something locked so that you can’t control it. You’ll need some way of tracking that you don’t want it changed, and then use logic like I previously posted. Turning it into a lock won’t help you as far as I can see.
fear you’re right. Misread the optimistic variable to be of help here, and thought it might popup the pin to enter, but it merely dispenses with the value_template check.
Wouldn’t it be a great additional feature though, to have an optional pin as variable on these integrations? especially lock and cover would benefit from that?