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.
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.
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.