Easy conversion of binary_sensor into cover

[tetele]

Problem

Asking Assist "how many windows are open?" or "which doors are closed?" will only count/list the doors and windows that are defined as covers (with the respective device_class, of course). If a user has binary_sensor doors and windows (i.e. just for reporting status, not for actuating them), then they will simply be ignored.

Asking "is [door entity name] open?" will work, because binary_sensors can be queried by name.

Cause

The architecture of hassil and the default conversation agent permit referencing a single entity "filter" in a sentence. That filter can have a domain, a device_class, an area, a name or a combination thereof, but it does not allow for multiple such filters.

As such, all sentences have been defined per domain and, as a result, there's no current way of querying both device_class: door covers and device_class: door binary_sensors to answer a question such as how many doors are open?. The current implementation only targets cover entities.

Solutions

The proper solution

The best ("most correct") way to handle this would be to allow multiple filters per entity referenced in a sentence (e.g. accept all entities which have either {domain: cover, device_class: door} or {domain: binary_sensor, device_class: door}).

However, this takes a lot of overhaul of the entire conversation logic, along with hassil.

The dirty solution

A current patch job would be to target questions about doors and windows towards the binary_sensor domain, which seems to be more prevalent than the cover entities. However, that would be a breaking change in how Assist works (with no easy fix for users who do have cover doors/windows). It would be just as bad as defaulting.

It has been opened up here.

The compromise solution

If binary_sensors with device_class: door and device_class: window could easily be converted to cover entities, then this would be an easily fixable problem. For that to happen, covers must support not having open and close services, as the binary_sensor representation of these covers only reports state and cannot be actuated programatically.

Approach

1. Allow cover entities which don't have any actuation, such as open and close controls (services, interface etc.). already supported
2. Create a new helper integration called binary_sensor_as_x, similar to switch_as_x which allows a binary_sensor to be converted to an entity pertaining to a different domain (initially, cover, but maybe more in the future) from the web interface, without writing any YAML. New integration: Change device type of a binary sensor core#117423

[balloob]

I think that we should aim for the correct solution.

[frenck]

I think the proposed solution isn't correct. A binary sensor is a read-only entity and in that was not similar to what switch_as_x resolved, as the entity only provides information. A cover is a read/write entity that can be interacted with.

[tetele]

But then why can you have a cover with no functionality? https://developers.home-assistant.io/docs/core/entity/cover

[frenck]

That is a side effect of having covers that can only support tilting or only open/close. This is not intended for the functionality you describe in this proposal.

[OzGav]

What would be the correct solution then? In Tetele’s poll (small sample size) most people have binary sensors for windows and doors.

[Didgeridrew]

There is an analogous issue with Climate/Temperature sensors. Only climate entities are targeted by the intent HassClimateGetTemperature, but it is very common for users to actually want the values from sensor entities.

[witold-gren]

Do we have any decision on how these problems should be solved?

[witold-gren]

The only sensible workaround for this problem I found is use https://www.home-assistant.io/integrations/cover.template/:

cover:
  - platform: template
    covers:
      bathroom_window:
        device_class: window
        friendly_name: "Window in the bathroom"
        value_template: "{{ is_state('binary_sensor. bathroom_window', 'on') }}"
        open_cover:
          action: script.open_fake_cover
        close_cover:
          action: script.close_fake_cover
        stop_cover:
          action: script.stop_fake_cover

[tobiloeb]

I have similar Problems currently. In my opinion another not technically solution would be to make things like windows, doors, temperature sensors and heating valve (maybe others as well) explicit configurable in the frontend for each area. Like it's already done for temp and humid sensor.
So the user can set explicitly the entities for each room or area. Otherwise the default behavior get into account.

I know this will not solve all problems but it could be an 'easy' way which every user of HA understand?

[Nardol]

If I understand correctly this discussion, it is about Assist behavior. And configure temperature and humidity for the room also does not change anything when asking to Assist which only looks for a thermostat so in this case, it is also not possible to ask for current temperature except if I missed something.

[tobiloeb]

Yes you are right. That's why I mean 'not technically '. An approach next to the technical solution would be (maybe) to let the user explicit configure which sensors, thermostats, helpers and so on should be considered for each room (for window, temp, humid...) by the assist first.

So first the user knows best which sensor should be selected from assist when the User ask about the e.g. temperature in a specific room. In all other cases the device_class, domain and so on should be considered (as discussed here). Maybe this is not the right place for my perspective.

Just an idea from my side. :)

[Oliv4945]

I second this. I just stumbled on this issue to get the temperature of an area:

• Configure Assist, it is the first time I use it
• Assign a temperature sensor to each area
• Ask for living room temperature: it works
• Ask for any other area: assist does not understand

It makes sense now as I have only a climate entity for the living room.

I had to create a custom sentence overwriting the GetClimate, then the following intent script, querying all temperature devices of an area and averaging them:

intent_script:
  CustomTemperature:
    speech:
      text: >-
        {{
          expand(area_entities(area)) 
          | selectattr('attributes.device_class', 'defined')
          | selectattr('attributes.device_class', 'eq', 'temperature')
          | map(attribute='state')
          | map('float', None) | list | average
        }} degrés.

Small note: by doing this we lose the ability to use an alias, unless I missed it, it is not seems possible to get an area_id from an alias in a template (WTH!?)