Detect missing or faulty bluetooth connection

[clau-bucur]

Is there a way to detect, in HA, if the component is unable to read data from bluetooth?

From what I see now, there is no indication that the bluetooth connection is broken (either the dondle is removed, drivers crashed, whatever).
I run HassIO in a VirtualBox VM from a Windows host, so the bluetooth device can, from time to time, become unavailable to VM.

[Magalex2x14]

All entities created by our component have the force_update property set, therefore, it seems to me that a reliable enough solution is to use the last_updated attribute.
For example, like this:

binary_sensor:
  - platform: template
    sensors:
      bt_stuck:
        friendly_name: "BT"
        value_template: >-
          {% set btvalues = [
            states.sensor.mi_t_1.last_updated,
            states.sensor.mi_t_2.last_updated,
            states.sensor.mi_h_1.last_updated,
            states.sensor.mi_h_2.last_updated]%}
          {{ (as_timestamp(now())-as_timestamp(btvalues | max)) > 120 }}
        device_class: problem
        icon_template: >-
          {% if is_state("binary_sensor.bt_stuck", "on") %}
            mdi:bluetooth-off
          {% else %}
            mdi:bluetooth
          {% endif %}

However, there are still options - use the command line sensor in combination with a bash script (which starts and parses the output of the hciconfig command, for example). But I don’t have such a ready-made solution.

[clau-bucur]

Thanks Alex! That binary sensor is exactly what I'm looking for.
I'm testing it now, however it's never changing to state ON.

If I run the value_template in the Developer Tool / Template section, it returns "True" and "False" as expected.
I might be missing something, I'll keep on investigating.

[clau-bucur]

Looks like the sensor is not being automatically updated.
I added entity_id: sensor.time to the bt_stuck sensor and enabled time sensor component in my configuration.yaml:

sensor:
  - platform: time_date
    display_options:
      - time

The sensor changes state now, after two minutes of faulty bluetooth communication.

[Magalex2x14]

Yes, I forgot about this feature of the operation of template sensors. The time_date platform was already included in my config. I suspect that this is enough, and adding entity_id: sensor.time to the binary sensor code is not necessary (but this will not hurt).
I think this is worthy of inclusion in the FAQ.

Summary yaml:

sensor:
  - platform: time_date
    display_options:
      - time

binary_sensor:
  - platform: template
    sensors:
      bt_stuck:
        friendly_name: "BT"
        value_template: >-
          {% set btvalues = [
            states.sensor.mi_t_1.last_updated,
            states.sensor.mi_t_2.last_updated,
            states.sensor.mi_h_1.last_updated,
            states.sensor.mi_h_2.last_updated]%}
          {{ (as_timestamp(now())-as_timestamp(btvalues | max)) > 120 }}
        device_class: problem
        entity_id: sensor.time
        icon_template: >-
          {% if is_state("binary_sensor.bt_stuck", "on") %}
            mdi:bluetooth-off
          {% else %}
            mdi:bluetooth
          {% endif %}

where sensor.mi_t_1 and others are all sensors whose last_updated time is checked, and binary_sensor.bt_stuck will turn on if more than 120 seconds have passed since the last update of the "youngest" one. The number of seconds you must choose based on the update time of the "fastest" of your sensors and period option.

[AJolly]

Is it possible to more natively set a sensor state to unknown or unavailable after a configurable timeout? Similar to how mqtt let's us set :

expire_after integer (Optional, default: 0)
If set, it defines the number of seconds after the sensor’s state expires, if it’s not updated. After expiry, the sensor’s state becomes unavailable. Default the sensors state never expires.