How to handle current conflicts with HassGetState

[TheFes]

There are currently 4 device classes for binary sensors which have conflicts with other domains if you want to use the all, any, how_many, and which

conflicts with cover domain

• door: This device class conflicts with the same device class in the cover domain.
• garage_door: This device class conflicts with device class garage in the cover domain.
• window: This device class conflicts with the same device class in the cover domain.

Optimally it would be best if you could combine them in one intent, so asking how many doors are open would return both the cover entities with state open (and technically also opening and closing) and the binary sensors with state on. However there is currently no option to combine domains in one intent, and to query for multiple states.
Matching could take place using the device_class

conflicts with other domains

• lock: This device class conflicts with the lock domain.

Optimally it would be best if you could combine them in one intent, so asking how many locks are locked would return both the lock entities with state locked and the binary sensors with state on. However there is currently no option to combine domains in one intent, and to query for multiple states.
There is no option to match on device_class so the slots or requires_context settings would need to allow or structures to make matching with both options possible

potential future conflicts

• update: This device class would conflict with the update domain if that domain would be supported

The states are the same, so no issue there, however it is currently not possible to create intents for multiple domains.
There is no option to match on device_class so the slots or requires_context settings would need to allow or structures to make matching with both options possible

Short term suggestions

I think for door and window the binary sensors are used a lot more than actual covers. So I would suggest to exlcude those device classes from the cover intents, and move them to the binary sensor intents. If someone does have a door or window cover entity, then it is relatively easy to create a template binary sensor for it.

For lock and garage I think it makes sense to me to use the lock and cover entities for now. If you actually automate a door, the garage door makes most sense to me. And I think smart locks are quite common nowadays.

Before making changes to EN and NL, I would like to know how others think about this.

[tetele]

I agree with your short term suggestion, provided that your gut feeling (same as mine) is correct. I've asked for telemetry data on the matter (if available), but haven't got a response yet.

[synesthesiam]

I remember somewhere we were discussing maybe adding groups of constraints, so you could have something like:

intents:
  HassGetState:
    data:
      - sentences:
          - "how many doors are locked"
        response: how_many
        slot_groups:
          - domain: lock
          - domain: binary_sensor
            device_class: lock

We would need to think carefully about this though, since maybe there is some connection with requires_context, etc.

[tetele]

I'd bundle slots with requires_context and excludes_context in a group rather than just bundle slots together. Otherwise there are surely going to be conflicts.

[tetele]

Here's my proposal:

intents:
  HassGetState:
    data:
      - sentences:
          - "is <name> {lock_states:state} [in <area>]"
        match_criteria:
        - response: one_yesno
          requires_context:
            domain: lock
          slots:
            domain: lock
        - requires_context:
            domain: binary_sensor
            device_class: lock
          slots:
            domain: binary_sensor
            device_class: lock

The issue with this construct is where would one place it? Given the current constraints, it can't reside in neither lock_HassGetState.yaml, nor binary_sensor_HassGetState.yaml.

Alternatively, we could do something like this

intents:
  HassGetState:
    data:
      - sentences:
          - "is <name> {lock_states:state} [in <area>]"
        response: one_yesno
        requires_context:
          domain: lock
        slots:
          domain: lock
        alternative_match_criteria:
        - requires_context:
            domain: binary_sensor
            device_class: lock
          slots:
            domain: binary_sensor
            device_class: lock

where one "main" set of criteria is backwards compatible and determines the main usecase, but multiple additional_match_criteria (naming TBD) could allow using the same sentence in other contexts.

Thoughts?

[TheFes]

@synesthesiam @tetele
This would solve the issue to support multiple domains, but it doesn't address the issue that we should also match multiple states
Eg lock entities are locked or unlocked, while binary_sensors with device_class lock are on or off

[tetele]

I was going to say you could easily add a second sentence, but given that the exposed wording is the same, the intent matcher would not know which sentence to match, therefore would fail. So very good catch, sir! :)

I do have a solution for this as well, but it involves merging the local expansion rules.

intents:
  HassGetState:
    data:
      - sentences:
          - "is <name> <state> [in <area>]"
        expansion_rules:
          state: "{lock_states:state}"
        response: one_yesno
        requires_context:
          domain: lock
        slots:
          domain: lock
        alternative_match_criteria:
        - expansion_rules:
            state: "{bs_lock_states:state}"
          requires_context:
            domain: binary_sensor
            device_class: lock
          slots:
            domain: binary_sensor
            device_class: lock