Inverting or reversing binary sensor display states

[jaym25 (Jay McGee)]

There are times when a binary sensor is used in an unconventional application where I would like to reverse open vs closed, wet vs dry, etc. I would be nice to have a switch or checkbox in the entity customization menu or manually through yaml to invert the displayed state.

Depending on the device class, open and closed, wet and dry, clear and detected would be reversed based on the sensor state.

This would eliminate the need to hide the original sensor and create a separate template sensor for this purpose.

[tom_l]

Don’t forget to vote for your own request.

[code-in-progress (Bill - I write code.)]

THIS. I have a contact sensor on my bathroom door and I always have to remember to reverse it in automations. Thanks for the tip about using a template sensor for this though.

[tom_l]

I believe what Jay is asking for would only affect the Lovelace display of the device class. You would still be stuck with the same reversed states.

[jaym25 (Jay McGee)]

Inverting the actual states would be nice. However, if it is more difficult to implement or causes unforeseen negative side-effects, then the display version would still be helpful.

[jaym25 (Jay McGee)]

Here is a simple way to invert the state using a template sensor.

binary_sensor:
  - platform: template
    sensors:
        new sensor name:
        friendly_name: 'xxxxx'
        value_template: '{{ is_state("binary_sensor.original_sensor", "off") }}'
        device_class: xxxx
        attribute_templates:
          battery_level: '{{ state_attr("binary_sensor.original_sensor_,"battery_level") }}'
             Remember to grab your attributes from the original sensor if you want them to appear on the new one.

[richieframe (Richie)]

Another application for this would be where the status of a relay is on to switch something off, and you are viewing the state of the relay for the state of the device

Relay on = device off, relay off = device on

[emkay (Marc)]

I’m having a hard time getting the battery level to get passed through. Anyone have a thought as to how to handle that? The original sensor ID is: sensor.window_door_sensor_battery_level My code is:

binary_sensor:
  - platform: template
    sensors:
      inverted_sensor:
        value_template: >-
          {{ is_state('binary_sensor.window_door_sensor', 'off') }}
        device_class: door
        friendly_name: Inverted Sensor
        attribute_templates:
          battery_level: '{{ state_attr("sensor.window_door_sensor_", "battery_level") }}'

[chewyf5]

Hello Community,

A lot of device classes were added in the last Home Assistant releases. One is the “Problem” device class. It is “Ok” when the sensor is offline (off) and “Problem” when the sensor is on. Its a philosophical question if this is right or wrong.
My Point: In some cases it is necessary the invert the result of a binary sensor. At the moment I resolve this problem by creating an additional template sensor with

state: {{ not is_state('input_boolean.my_sensor','on') }} 

or

state: {{ is_state('input_boolean.my_sensor','off') }} 

I think its only a little bit of an implementation afford to make the result of a binary sensor invertible. But - to be honest - I have not the skills to add this feature on my own and send a pull request.

Kind Regards

Chewy

P.S.: At the moment I try to implement an error system to my home assistant instance (here) (some ping sensors) so that home assistant alerts me if some system is not reachable anymore.

[tom_l]

What is the source of the original sensor that needs inverting?

[chewyf5]

Hi @tom_l,

it could be everything. In my case its a Ping sensor.

[CChris (Christoph)]

I created a similar FR some time ago.

Option to invert icon_state coloring

I think, with the already implemented - and upcomming coloring features, this might actually increase it’s importance. By default, there are defined settings for the colors of specific entities (security related, when is a door safe / unsafe?) But - as we are all individuals, that means, that the new states might not be the same for all devices that we have. Sometimes, a “locked” door can be ‘safe’ - in other cases, a “locked” state for some device should require our attention. Therefore, i…

The requirement for this has lowered since the new color options were introduced, but still - you might have sensors that are reporting ON while others are reporting OFF in a similar case.

Then, your color schemes may still be broken, since we cannot colorize icons individually without using something like card_mod.

[EdwardTFN (Edward Firmo)]

I have a case for this, @tom_l. I’m using a door sensor as a bed occupancy sensor, however, based on how the sensor works, it is “on” when the bed is empty and “off” when the bed is occupied, which makes not useful to use with sensor class “occupancy”, which will make my solution much easier and nicer.
OK, I know the problem is on the fact that door sensors are not bed occupancy sensors and I should have designed better the system, but having an option to simply invert the sensor will make the solution for this much easier.

[tom_l]

I’m definitely aware there is a legitimate need for this. I was just checking that the integration chewy was using could not be inverted in its config (it can’t in that particular case).

If your door sensor is connected via Zigbee2mqtt it should be able to be inverted in zigbee2mqtt.

[EdwardTFN (Edward Firmo)]

@tom_l

If your door sensor is connected via Zigbee2mqtt it should be able to be inverted in zigbee2mqtt.

I’m reluctant to migrate from ZHA to Z2M…

[tom_l]

Understandable. That’s why I said “if…”

[jcd420]

@emkay

inverted_sensor:

just create a binary with the inverted return

- name: "vLiveVentClosed"
  unique_id: "binary_sensor.vliveventclosed"
  state: "{{ is_state('unique_id OF YOUR SENSOR', 'off') }}"

[baroldgene (Barry Brinkley)]

Honestly I’d skip this and just allow users to override the values presented in the UI with whatever they want. The device classes are convenient when they fit, but they often don’t and the lack of ability to customize them is incredibly annoying sometimes. Seems easy enough to allow a binary sensor setting of “Display value for true” and “Display value for false” which would cover this use case and many others.

And I realize this can be done with Templates, but it’s a bit ridiculous to make templates on top of every sensor just to change the display values.