Assigning Scripts and Scenes to Rooms in Google Home and Assistant

I would like to make the case for having the ability to add scripts and scenes into the main UI of Google Assistant and or Google Home, so that they can be assigned to various rooms.

For starters with the addition of Google Home Hub, there is now a user facing GUI to interact with smart home assets. It makes little sense to have the ability to turn devices on or off, change their color or brightness, etc, via a GUI, but be required to voice a command just to run a script and or scene.

More importantly though, as of a few months ago each Google Home is finally aware of which room it resides in. This finally added the ability to say simple commands such as ā€œturn on the lightsā€ and the Google Home will assume you mean to turn on the lights in the same room it resides in, and not ALL lights. In other words it is contextually aware of the command you just gave.
This same logic should hold true for Scenes and Scripts, unfortunately since we can not view them in the Home UI, we can not assign them to the various rooms.

This no big challenge for me when interacting with Google, but Iā€™m not the only one that lives in the house. Explaining to other people in my home that they need to give very precise commands such as ā€œActivate, (roomname), (script name)ā€, while other commands such as ā€œturn on the lightsā€ can be said naturally with the Google Home understanding the context of this command, is confusing for most.

Iā€™ve had the same thought myself just recently and was looking to see if someone else had requested this. You can do this already in the config file, but thatā€™s a bit unwieldly IMHO.

It makes more sense to me to have this implimented as a set of custom attributes. Iā€™ve had a look at the code, it seems pretty straight forward to implement. The way Iā€™d do it is have attributes google_assistant_hidden, google_assistant_room, google_assistant_aliases for each entity, Thereā€™s already homebridge_hidden, and homebridge_name, so I donā€™t see why google shouldnā€™t have attributes.

Itā€™s pretty easy to configure these in the UI.

Am I missing something? I already assign scenes to roomsā€¦ I donā€™t have any scriptsā€¦

  scene.bedtime:
    room: bedroom

as an example

You can do that in the config file, but you canā€™t use custom attributes to do it. Config file editing is more of an ā€˜advancedā€™ technique really, and also requires restarting HA to pick up the change.

Well you can still assign them in Google Assistant itself if you donā€™t assign a room.

I donā€™t consider it any more advanced than adding the YAML to enable either cloud integration or component integration.

Yes along with 90% or other changes in HA you have to restartā€¦

1 Like

If you assign them rooms in GA, and you have to update the assistant connector for any reason (say adding a new user) then you have to do your room assignments again. It gets annoying real fast.

Anyhow, this is how homekit works with custom attributes.

Which is why you assign them in the YAML file! Done once, done forever. I donā€™t at all understand why you want to argue about this! Itā€™s a built in feature for cloud/component.

If itā€™s in the google assistant portion of the yaml file itā€™s not grouped with the device. I think that if itā€™s in the deviceā€™s custom attributes thatā€™s a better location. It has several advantages:

  • Itā€™s grouped with the device itself
  • Itā€™s easy to edit from the existing UI
  • If the device ID gets changed in the UI cog menu (and the custom attributes are synced with it which doesnā€™t currently happen but probably should) the attributes go with the device without any extra effort
  • If the UI is updated to allow editing of custom attributes from the ā€˜cogā€™ menu in the UI, itā€™s right there with the device
  • You can change the attributes in the UI without having to reboot HA to pick up the change

Thereā€™s no particular advantage I can see to having the attributes stored in the google assistant section of the config.yaml file, it makes a lot more sense to me to have them as custom attributes. They can still be picked up from the yaml for backward compatibility, but have the custom attributes override this.

bit of an old post but fight with this also atm

where do you add those to lines in the configuration.yaml ?