Prevent Google Assistant from switching locked switches?

HI,

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.

Being as the lock i believe you are talking about is using a custom card, i doubt Nabu casa would have any info on their docs or a way to support it.

your other option would be if google assistant supported that and i dont thin it does. if its in the Google home app its available to voice commands.

i wonder if you could change the device_class of those switches to a lock?

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 :wink:
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?

The lock is purely a UI thing - it’s not native to Home Assistant.

You need to find out (check the states menu under Developer Tools) if that lock shows up in any entity either as a state or attribute.

If it doesn’t, you can’t fix this. If it does, we can help you.

well, maybe this could be it:

[switch.sw_audio_auditorium_template] off
friendly_name: Audio Auditorium
custom_ui_state_card: state-card-custom-ui
templates: { “icon”: “if (state === ‘on’) return ‘mdi:music’; return ‘mdi:music-off’;\n” } show_last_changed: true
confirm_controls_show_lock: true
extra_badge: [object Object],[object Object]
icon: mdi:music-off

meaning I have an attribute ‘confirm_controls_show_lock’ set to ‘true’
not native attribute, but one made by custom-ui

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:

automation:
  - alias: switch sw_audio_auditorium_template
    trigger:
      - platform: state
        entity_id: input_boolean.sw_audio_auditorium_template
    condition:
      - condition: template
        value_template: >-
          {{ is_state_attr('switch.sw_audio_auditorium_template','confirm_controls_show_lock','false') and (trigger.to_state.state != trigger.from_state.state) }}
    action:
      - service: switch.toggle
        entity_id: switch.sw_audio_auditorium_template

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 :wink:

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?

Anything you want to “lock” you can’t expose to other systems, you’ll have to build something like this to act as a buffer.

And, if the attribute never changes, you are out of luck.

ok thanks, I fired as much…

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/ ?

would that be pinnable in GA?

like this:

lock:
  - platform: template
    name: Audio system
    value_template: >
      {{ is_state('switch.sw_audio_auditorium_template', 'on') }}
    lock:
      service: switch.turn_on
      data:
        entity_id: switch.sw_audio_auditorium_cl
    unlock:
      service: switch.turn_off
      data:
        entity_id: switch.sw_audio_auditorium_cl

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?

a bit like on the alarmpanel where we can set the code https://www.home-assistant.io/components/manual/#code

anyways, no solution for now… thanks for you help

–update–

for reference, I changed the above lock template in to this:

lock:
  - platform: template
    name: Audio system
    value_template: >
      {{ is_state('switch.sw_audio_auditorium_template', 'off') }}
    lock:
      service: switch.turn_off
      data:
        entity_id: switch.sw_audio_auditorium_cl
    unlock:
      service: switch.turn_on
      data:
        entity_id: switch.sw_audio_auditorium_cl

I like it to be unlocked when the switch is ‘on’, so had to change the value_template and flip the (un)lock services