An example: I have an accent light in my living room that I leave on most of the evening. I also have several other lights in the living room that I turn on or off sometimes when I’m in the room.
I’d like to say “OK Nabu, turn off the living room lights” and only turn off the “other” lights, leaving the accent light on.
How are y’all organizing your lights like this into areas for voice control?
I realize that I could simply leave the accent light out of the “living room” area. I guess my question is is that the best way to handle them?
The implementation depends on whether you use LLM from control or not.
In the first case ( w/o LLM), you create your own voice automations and override existing phrases. For example, the phrase “turn off the lights” might turn off only the lamps you’ve assigned the “main light” label to.
In the second case (w/ LLM), you also need to separate devices (labels work here too) and explain the desired behavior to the agent.
Thanks. I’m not sure what your first/second cases are… with and without LLM?
Right now, I’m not using an LLM conversation agent. I like the idea of being able to group by area everything that’s in a room, but then label “main” or “accent”, but if I understand correctly, the non-LLM version is always going to try to turn on all lights in an area.
But I can do a one-off automation for “Turn off/on living room lights” and handle things by tag in that automation.
I started with @mchk 's automation. Although I love how elegant it is to get the current area from the location of the assistant being spoken to, I needed mine to take an argument of the area name since I’ve got an open floorplan and just a couple voice assistants. I also needed mine to work with switches because I have a couple lights that are on appliance modules.
Like mchk’s automation, label lights with “mainlight” and make sure they’re assigned to areas. If there are no labeled lights in the area, nothing’ll happen, but it’s easy enough to add an “else” to handle all lights in the area. I just didn’t want that for my situation.
alias: "Assist: Turn on main lights by area name"
description: Turns on lights with the 'mainlight' label in a specific area via voice.
triggers:
- command:
- Turn {action} [the] {area} lights
id: turn on or off lights in an area
trigger: conversation
conditions:
- condition: template
value_template: >-
{{ (states |selectattr('entity_id', 'in',
label_entities('mainlight'))|selectattr('entity_id', 'in',
area_entities(area_name)) |map(attribute='entity_id') |list |count) > 0}}
- condition: template
value_template: "{{ trigger.slots.action in ['on', 'off'] }}"
actions:
- action: homeassistant.turn_{{ trigger.slots.action }}
metadata: {}
data: {}
target:
entity_id: >-
{{ states |selectattr('entity_id', 'in',
label_entities('mainlight'))|selectattr('entity_id', 'in',
area_entities(area_name)) |map(attribute='entity_id') |list }}
variables:
area_name: "{{trigger.slots.area}}"
label_id: MainLight
mode: single
Glad to hear the problem is solved.
That’s right. We need to create automation for the required command type. Contextual commands and explicit room selection are the two most frequently used groups.
If needed, a similar automation can be created for auxiliary lighting by adding a unique word to the phrase template.
And we still have full control over all the lights in the room if we use the other phrase options. I usually just add “all” to the command.
@mchk any thoughts on why “Turn on kitchen lights” will use (what I take to be) the Home Assistant default and turn on every light in kitchen and not use my automation? Even if I set “Turn {action} {area} lights” as one of my trigger commands instead of leveraging optional words.
I checked with the dev tool and then checked the debug log for the voice assistant. Also tried with a trigger sentence of simply “turn off living room lights”
If I leave off the “the”, I always trigger HassTurnOff with the area rather than my automation. Seems like that version takes priority over my automation. None of them are fuzzy matching.
edit: I was able to get the automation to run with “Turn off living room lights” as one of the triggers. It just fails if I use slots “Turn {action} {area} lights”, Then the generic HassTurnOff (or ON) takes over.
You need to run more tests to achieve stability. The more variables, the greater the chance of error.
Have you tried splitting the automation into two parts?
Turn on [the] {area} lights
and
Turn off [the] {area} lights
The thing that got me thinking I was going about this wrong was thinking how it might work better if HA knew that “action” would only be on or off (I mean in the trigger - I have a condition template looking at that) and that “area” was a list of the areas in my home. Kind of how slots work with intents from my Alexa skill.
Thanks @mchk splitting things into separate automations looks to be working well. I can see where there can be ambiguity with two variables side by side in different but similar orders.
For anyone dropping by later, here’s what worked for me (for the turn on automation). This’d probably work just fine as one automation for on and off using IDs for the on vs off trigger.
alias: "Assist: Turn on main lights by area name"
description: Turns on lights with the 'mainlight' label in a specific area via voice.
triggers:
- command:
- turn on the {area} lights
- turn on {area} lights
- turn on the lights in the {area}
- turn the {area} lights on
trigger: conversation
enabled: true
conditions:
- condition: template
value_template: >-
{{ (states |selectattr('entity_id', 'in',
label_entities('mainlight'))|selectattr('entity_id', 'in',
area_entities(area_name)) |map(attribute='entity_id') |list |count) > 0}}
actions:
- parallel:
- set_conversation_response: I turned on the {{trigger.slots.area}} lights
- action: homeassistant.turn_on
metadata: {}
data: {}
target:
entity_id: >-
{{ states |selectattr('entity_id', 'in',
label_entities('mainlight'))|selectattr('entity_id', 'in',
area_entities(area_name)) |map(attribute='entity_id') |list }}
enabled: true
variables:
area_name: "{{trigger.slots.area}}"
label_id: MainLight
mode: single