[de] ambiguous sentences for light = on

[akloeckner]

I was trying to query my lights' states saying
"Welches Licht ist an?" And got a none response: "Keins ist an." But I have a light on.

The debugger told me, I was querying for binary sensors with device class light, which I don't own any.

That made me think, we have ambiguous sentences. In this case, it's these two:

intents/sentences/de/homeassistant_HassGetState.yaml

Line 72 in bd33544

- "<welche> {on_off_domains:domain} (ist|sind) {on_off_states:state}[ <area_floor>]"

intents/sentences/de/binary_sensor_HassGetState.yaml

Line 474 in bd33544

- "<welche> Licht[er] (<ist_wurde>|<sind_wurden>) {bs_light_states:state} <area>"

I don't have a solution to this, as both might be legitimate queries. I wanted to raise the issue anyways. Maybe someone has a sparking idea...

[akloeckner]

Would it maybe make sense to add requires_context, as proposed in #3738 ?

[hecktech27]

while i have never actually seen a binary_sensor entity with device_class light as it is/should be required by the mentioned sentence from binary_sensor_HassGetState - i think this aims at sensors like "binary brightness sensors" in motion sensors etc. which detect if there is light somewhere.

When adding

        requires_context:
          domain: binary_sensor
          device_class: light
        slots:
          domain: binary_sensor
          device_class: light

as suggested above the current tests fail because the parser(in my opinion rightfully) raises a domain-mismatch(light instead of binary_sensor).

a little more context: bs_light_states(used in the sentence definitions) covers (entdeckt|ausgelöst|erkannt|an) for "state: on"
My suggestion would be to keep sentences with focus on "erkannt/entdeckt" for the binary sensor domain(so definitley remove "an" as an option there since this should be covered by light entities in my opinion).
I would further suggest to rework the following sentences:

          - "<welche> Licht[er] (<ist_wurde>|<sind_wurden>)[ <area>] {bs_light_states:state}"
          - "<welche> Licht[er] (<ist_wurde>|<sind_wurden>) {bs_light_states:state} <area>"
          - "<welche> Licht[er] <area> (<ist_wurde>|<sind_wurden>) {bs_light_states:state}"

to something like welche Sensoren haben licht erkannt (have to think more about the details here - feedback very welcome!)
and make sure that sentences like "Welche Lichter sind an" default to HassGetState/the light domain and no longer to binary_sensors.

maybe @andreasbrett and/or @mib1185 can share their opinion on this as well?

and maybe one more thing to add: i´m not sure if it is sufficient to run tests like these only against test fixtures with state:off since there is no difference in the response for e.g. "Wurde in der Küche Licht erkannt?" for both cases:

• no matching test fixture found
• fixture found but state:off

and as a result you don´t really know if the sentences are working as expected.

[andreasbrett]

Let me say upfront that I'm sorry that the following won't provide much value for this particular topic (but maybe food for thought). If you can't bear my pessimistic opinion on this, do yourself a favor and skip this post...

I personally don't use any of the HassGetState sentences since I think (regardless of language) they provide the worst experience in Assist and make it look like a hobbyist project. Other intents are much better but HassGetState targets weirdly and responses feel like talking to a dumb robot. To me they feel like old and outdated intents that are not on par with newer ones. In general I feel that ordering commands through Assist provides much more value than querying (unless you use AI + local fallback).

IMHO for Assist the HA voice team should either...

• improve the backend side of Assist to better support those device classes and allow to respond in a smart and grammatically correct way or
• ditch them completely and ask users to use AI Assist with local fallback if they want to query states and counts

Back to topic: while I understand that there's a need to fix this issue, I couldn't really say which solution @hecktech27 presented is better. I would rather bin the bad stuff that makes Assist look worse than it is, than finding ways to make it only slightly better. How would language leaders (at least those that don't architecturally work on HA) know what a sensor with domain binary_sensor and device class light would be, how commonly this appears in users' homes and why querying those (supposedly uncommon) devices should be supported at all? That should be handled by devs or product managers, not "translators".

[akloeckner]

the following won't provide much value for this particular topic

Let me share my newbie experience with HA voice: I found it very hard to query things, because queries mainly ask for a name to be said. I have all my entities named with the area and the device name in them. So, I would have to ask something like "Welchen Zustand hat Gästezimmer Klima Temperatur". That was impractical and made me deep-dive and implement my own sentences. This was then basically the first thing that really worked with voice. I can now query sensors and binary sensors by area/floor. This is a very helpful feature and I would not want to share these states with an online AI provider. Also, I did not use intent-script for this, because I found the matcher in the built-in HassGetState intent very useful. But I agree: I had to find a better way to query them and I also created better responses. I'll propose them in a new PR and will be curious to see your comments.

Back to topic:

If the requires_context does what I think it does, I would just make the current sentences require the right domain and maybe device class, if possible.

I would then expect:

• The sentence will just not match if no matching entities are found.
• A generic "didn't understand" would be answered. Instead of "no entities found".
• Both answers seem rather useless to me, so I wouldn't care which one is given. 😄

[andreasbrett]

With the introduction of labels, areas and floors and new device entity selectors in 2025 I renamed all my devices. I used the same approach you use: add the area in the name. This is not necessary anymore luckily. So now I have e.g. multiple Deckenlampe devices and don't have to rename them on dashboards or provide them with Assist aliases. That made it much easier for me and this is also the way the HA teams intends them to be used now. More semantic less structured as HA itself should structure your devices.

[hecktech27]

Back to topic: while I understand that there's a need to fix this issue, I couldn't really say which solution @hecktech27 presented is better. I would rather bin the bad stuff that makes Assist look worse than it is, than finding ways to make it only slightly better.

@andreasbrett
as i partly already mentioned in my initial response i would propose to move sentences containing only requests like "ist licht[ an/aus" to the light domain/to homeassistant_HassGetState.yaml since these sentences are(for me) clearly targeted at requesting states of lights and not binary sensors.

if i had to decide i would probably keep "wurde licht erkannt"(and similar - e.g. hat sensor x licht erkannt) for the binary sensor to at least somehow cover these edge cases.

if you are fine with moving the main "light" sentences to hassgetstate and away from the binary sensors i would give it a go to maybe solve this issue for the next release.

that being said you are right with the needed backend upgrade for this ;)