"state" binary "ON"/"OFF" casing consistency for Waveman-Switch decoder

[DigiH]

There are several decoders with the "state" key being a binary "ON"/"OFF" option.

To be able to create a single Home Assistant discovery routine for all of them, without having to create a separate one just for the Waveman-Switch decoder, brining the casing in line with all the others makes things more consistent and easier for discovery implementation.

See
Brennenstuhl RCS 2044
Nexa
Proove

[zuckschwerdt]

I'd say that if we change the output of binary keys we should directly go to 0/1. rtl_433 is not the presentation layer and should provide a machine-oriented format that is easy to parse and process.
But then again "state" is a confusing key here, I suspect it really is a command ("cmd")?

[DigiH]

0/1 would be fine as well, as long as there is some consistency, especially for commonly creating discovery messages for all such keys, with the payload_on and payload_off being the same. Then with assigning appropriate type device classes for different decoders the HA display would be converted nicely from ON/OFF - 1/0.

https://www.home-assistant.io/integrations/binary_sensor/

When there is no device class specified (None) the default binary sensor for HA is actually showing ON/OFF, so maybe it might be ok to keep. This would also mean less of a breaking change for existing users with different controllers, when only one decoder has a casing change from on/off to ON/OFF!?!

And yes, the key name "state" is also confusing, as it appears as binary ON/OFF 1/0 as above, but also as open/closed (again with inconsistencies throughout as "open", "Open" or "OPEN") or as completely arbitrary strings or an integer.

But aligning all binary keys and generalising string casings would be a great help in making discovery messages a lot easier, without having to investigate every individual decoder.