Allow Tri or Quad State device_Class and allow input_boolean to use device_class

[wills106 (Will)]

I think you should be able to use the standard device_class on input_boolean “sensors”
The reason being is that at the moment binary sensors do not survive a reboot / restart. So to get a persistent sensor you need to use and input_boolean instead. For example to remember the state of a door sensor being Open or Closed.

Tri / Quad State device_class

With RF Door / Window sensors for example they can emit up to 4 signals depending on their state.
Open
Closed
Tampered
Battery low

So the door / window class should support the current open/closed icon and also for example have an alarm icon and a low battery icon.

My supporting thread on trying to work around this limitation.
It’s quite messy to have to setup an input_boolean to remember the sensor state for a reboot and then have a binary sensor on top of it all for the open/close icon.

Can a MQTT Binary Sensor retain it's status or do I need an Input_Boolean?

The device sending the MQTT message to the MQTT broker needs to set the retain flag, looks like this is your SonoffRF Bridge. HA is on the receiving end… I’m still fairly new to MQTT but this is my understanding of it. EDIT: [https://www.hivemq.com/blog/mqtt-essentials-part-8-retained-messages/](Retain explained)

[danielperna84]

@wills106

With RF Door / Window sensors for example they can emit up to 4 signals depending on their state.
Open
Closed
Tampered
Battery low

Such additional values are, dependet on the component I guess, already available as attributes. By definition a binary sensor can only have to states. And ideally those even work when the battery is low (not dead). Have a look at this and template sensors.

[wills106 (Will)]

I know a binary sensor wasn’t the best option to use when I was setting up the mqtt sensor.
But it was the only one I could get my head around and get working.

I should look at using this form of mqtt sensor:

MQTT Sensor

Although I may still run into the other problem of retaining the sensor states following a restart.

I think it would look a lot neater to use a device class with more pre-builtin options.

The main device_class: door, window, motion, smoke etc
Would have the relevant icons for:
payload_on:
payload_off:

Ie door open, smoke signal etc.
But all the device_class 's should have optional parameters such as:

payload_alarm:
payload_lowbat:
payload_etc:

A lot of sensors who’s main function is on / off can have other parameters especially wireless ones.
It would look a lot neater and easier to program than the full template sensor style.
Especially for people who are new to it all like me.

[nickrout]

If you are using mqtt you simply need to get your component post with the retain flag set. Survives restart.

As far as your examples are concerned, a window is open or closed. That is a binary state. Tampered is conceptually different. As is battery state. In fact battery state is an attribute of the sensor, not of the window.

Or to put it another way, a window cannot be open and closed at the same time. It can be open and tampered with, so they are separate attributes. You can’t just being them all together.