Proposal: HA discovery for RSSI

[jcsanyi]

Theengs Gateway already publishes RSSI in every device's MQTT payload (it comes from the BLE scan itself, so it's there regardless of whether the decoder recognizes the device) - it's just not exposed as its own discoverable entity. Currently the only way to get it is a hand-written MQTT sensor config in HA.

I'd like to propose adding Home Assistant discovery for RSSI as its own sensor per device. Since this adds an entity per device, I'd
also add a config option to turn it off for anyone who doesn't want the extra entity.

Before I put together a PR: has this been considered or discussed before, and is there a reason it hasn't been done already that I
should know about? Also open to any advice on how you'd want this approached, or things I might be missing.

(Scoping this to Theengs Gateway for now - I'd look at OpenMQTTGateway separately if this proves useful here.)

-Jonathan

[1technophile]

I think that's useful, if I recall HA has a special category "diagnostic" for this kind of "technical" entity so that they don't clutter the device data. You could have enabled by default false for users that have concerns with the qty of entities.
I would not change the gateway configuration or have an option a config option for it. I prefer to have it as part of the standard.

[jcsanyi]

I like the idea of dropping the config and using en: false - that's a cleaner solution.

On ent_cat: diagnostic: I wanted to give a bit more context before just adding it. I'm working on a separate, larger proposal for proper entity_category support across Theengs generally - marking things like battery level as diagnostic across the existing decoder library. That's a bigger change, since it touches theengs/decoder and needs to be figured out for all the already-supported devices.

Given that's (hopefully) coming, I could still add it for this new RSSI entity as a simple first case, or I could leave it out and add it when we later add support for the other diagnostic properties. What do you think?

-Jonathan

[1technophile]

It makes more sense to have the decoder output a kind of “diagnostic” tag or property. So feel free to leave it out in the gateway for now.
You could open a discussion in the decoder about the diagnostic category if you want.

[DigiH]

Re the battery level as diagnostic …

1technophile/OpenMQTTGateway#2115

So including it in Decoder as a default is likely not that good an idea as many users would reject it and it is already possible to have it in a different 'diagnostic' section in HA by setting it up manually if desired.

While a flag could be set in Decoder, only for the devices where the battery level is actually a diagnostic entity, the only option to have this differ in the discovery messages would be to have it processed in Theengs Gateway and OpenMQTTGateway through this flag, where the discovery messages are created, with an additional boolean setting option to have it processed or not.

[DigiH]

Thinking about this a bit more I would suggest the following:

• Create a new flag in Decoder for devices where battery/voltage are NOT diagnostic like the BM2 and BM6
• As the voltage for the BM2 and BM6 is retrieved by connection in OMG only, the flagging would need to be defined there.
• OpenMQTTGateway and Theengs Gateway would need to process this flag and conditionally create the discovery messages as diagnostics or not.
• I would suggest to also have a boolean settings option to turn this option on or off, with the default being off, as otherwise all existing already discovered and placed devices would get messed up, but allowing for it to be turned on if so desired.

[jcsanyi]

Thanks for the details and suggested approach - I've opened theengs/decoder#703 for further discussion on the entity_category.

[jcsanyi]

I've raised a PR for adding the RSSI entity: #323