Is this the best way to crate a no-biased MQTT binary sensor?

Configuration
1

I've got a bunch of binary sensors accessed via MQTT that trigger an alert if they flip into the On state. Problem is that binary sensors have four states, On, Off, Unknown, and Unavailable (so even more than { True, False, FileNotFound }), and the monitor treats everything that isn't Off as On, thus triggering an alert if the MQTT broker goes offline or some device providing input reboots or something similar.

Making this a no-biased sensor, so anything not On is treated as Off, seems pretty straightforward with a template sensor:

state: >
  {% if is_state( 'binary_sensor.sensor', 'off' ) or is_state( 'binary_sensor.sensor', 'unavailable' ) or is_state( 'binary_sensor.sensor', 'unknown' ) %}
    off
  {% else %}
   on
  {% endif %}

but I'm wondering whether this is the appropriate way to do it. I can't see anything in the MQTT binary sensors description that would make this any easier, but having to pipe everything through a set of template sensors just to make the binary sensor actually binary seems a bit awkward. Is this the only way to do it? And if it is, is it worth submitting a request to add a "disposition: { default | default_on | default_off }" setting to binary_sensors?

2

What exactly is the "monitor"?

3

Whatever's monitoring the binary sensors.

4

What exactly is monitoring them? Automations?

The reason why I am asking is because, instead of monitoring an MQTT Binary Sensor, your application may benefit from monitoring an MQTT Event. It's stateless, so you need not be concerned with the possibility of undesired states occurring.

For example, people often choose MQTT Binary Sensor to model a doorbell. However, MQTT Event is better for this application because it fires a single event when the doorbell button is pressed. There's no on/off/unavailable/unknown states. The monitoring automation uses an Event Trigger to detect the doorbell event.

5

Several different things, but the main one of concern is Alarmo. This works with binary sensor states rather than events, e.g. smoke alarm triggered, smoke alarm trigger cleared, motion alarm triggered/cleared, etc. There's a couple of other things as well, e.g. automations that warn if a sensor is in state X for more than Y minutes.

6

Are these MQTT Binary Sensors created via MQTT Discovery or have you defined them in YAML?

If in YAML, please post the configuration of at least one of them.

7

It's all YAML, here's one of them:

  binary_sensor:
    - name: esp32_input_1
      unique_id: uniqueid__esp32_input_1
      state_topic: "ESP32/SENSORS/STATE"
      value_template: "{{ value_json.input1.value }}"
      payload_on: true
      payload_off: false
      device_class: motion
8

What specific conditions have you noticed that have caused the binary_sensor to report unknown or unavailable?

The automation's State Trigger can be configured to ignore state-changes from unavailable/unknown.

9

The device that provides the sensor status restarting, temporarily going offline, and odd glitches that happen maybe once a week where the sensors... well, HA won't tell me whether they're or unavailable or unknown but just groups them all as !off, therefore on.

(That is, it's probably buried in some log file somewhere, but the alert I get is just that the sensor was triggered because it's no longer in the off state).

10

Post the automation that produces that alert, at minimum its triggers section.

EDIT

Example of a State Trigger designed to trigger when either door sensor's state changes exclusively from off to on and remains on for a minimum of 15 seconds. It will not trigger for any other kind of state-change (i.e. any other combination of on, off, unavailable or unknown).

alias: example 
  triggers:
    - trigger: state
      entity_id:
        - binary_sensor.front_door
        - binary_sensor.rear_door
      to: 'on'
      from: 'off'
      for:
        seconds: 15
11

The manually-added automation is just any state change, to alert me to the fact that it's changed:

 - alias: "Alert on Smoke Trigger"
    triggers:
      - trigger: state
        entity_id:
          - binary_sensor.esp32_input_10
    actions:
      - action: notify.notify
        data:
          title: "Smoke Sensor Triggered"
          message: "Smoke sensor has been triggered, alarm will sound in 15s."

This means I get 15s advance notice that the alarm might go off, so I can silence it before it wakes the neighbours. However I don't know how Alarmo itself triggers, i.e. how it handles a four-state binary, thus my question about converting it into a binary binary.

Another possible approach, now that I've written the above down to illustrate the problem, is to try and find out how Alarmo triggers. I've had a few cases of false triggering in the past, which is why I was playing around with state-change-alert automations, so I could get ready to silence the alarm manually if required as soon as it went off.

12

That means it will trigger for any nominal state-changes (on -> off, off -> on) and any non-nominal state-changes (off -> unavailable, unavailable -> off`, etc).

The non-nominal states are by design and tell you something is wrong with the entity (unavailable typically indicates communication loss between the physical device and Home Assistant). There are no configuration options to suppress the reporting of non-nominal states.

If you don't want your automation to trigger for non-nominal state-changes, simply constrain it to the desired nominal state-changes using the to, for, not_to, or not_from options. The example I posted above constrains it to an off -> on state-change.

I understand your goal of constraining the binary_sensor to report purely nominal state-changes; you are uncertain how Alarmo handles non-nominal state-changes.

Which integration are you using to connect binary_sensor.esp32_input_10 to the Alarmo service?

The reason why I am asking is because, depending on which integration you are using, the integration itself may suppress reporting of non-nominal state-changes to Alarmo. (There's a custom integration for Alarmo whose author added this feature several years ago.)

13

For the simple case you can simply check if the state is on:

{{ is_state( 'binary_sensor.sensor', 'on ) }}

However as mentioned by the other posters, in a lot of cases your not really interested in the other states, you just want to know when the state changes to on which will be an MQTT event so watching for the event is often a better option.

A complication is the retain flag, it can be difficult to decide if you should configure the sending system to set it:

  • The advantage is that if you get an event while HA is offline/rebooting it will be visible when HA comes back on line.
  • The disadvantage is that it can trigger every time HA is rebooted since the event is "rediscovered" on ever reboot.
14

I'm currently travelling with limited net access so replies will be a bit delayed... the trigger-on-any-change is deliberate, it's to give me 15s advance warning that Alarmo may trigger once the 15s interval is up. This is based on an unfortunate incident about a year ago where it had triggered while I was away and left the siren running. The idea is that if I get a heads-up that the state has changed I'll be ready to manually shut down the siren if Alarmo triggers it.

However after several weeks of checking it appears that Alarmo is requiring an explicit transition to on rather than just the state not being off any more, since it hasn't triggered again. Next step, once I get back home, is to remove the 15s delay and see if there are any more false triggers. That is, there's a template sensor between the raw MQTT input and Alarmo that requires it be triggered for a full 15s rather than just a one-shot, for example if your partner puts a blast of bug spray across the smoke sensor, just to pick a completely random example.

15

I don't mind a delay if the reply contains an answer to my question. However, ten days later, your reply overlooked to provide it. Unfortunately, I can't continue to help you without the requested information.