Publish entity_category for diagnostic properties

[jcsanyi]

Description

Home Assistant lets an entity be marked diagnostic, which moves it out of the device's main sensor list into a separate section. Nothing the gateway publishes uses it today, so a device's battery percentage and packet counter sit alongside its temperature as equally prominent readings. This adds a -Dd / --discovery_diagnostic option (default 0) which marks the diagnostic ones with ent_cat.

Follows from decoder discussion #703 and the bvpp tag bit added in decoder #705. Per the design settled there, the decoder says only which devices treat battery or voltage as their primary reading; all the per-property judgment lives here.

What gets marked diagnostic

Two lists in discovery.py, 16 keys covering 120 (model, entity) pairs:

• Always diagnostic: packet, packet_1, packet_2, rssi, tx, txpower.
• Diagnostic unless the device is flagged bvpp: batt, batt_case, batt_l, batt_low, batt_r, charging_case, charging_l, charging_r, lowbatt, volt.

The bvpp payload strip

The first commit is separate from the feature and allows us to include the decoder's new bvpp flag without it leaking through to the non-advdata JSON payload. Copies how we deal with the track flag, which we need for discovery, but gets stripped for the published copy.

Open Question - default config

I defaulted the config to 0 for now - meaning no existing devices or entities see any changes unless this is explicitly turned on. Worth considering whether that's the right call, or if we want to default to 1 to help nudge towards the standard.

Related Releases

• This doesn't include the rssi work in Add RSSI sensor to Home Assistant discovery #323 but rssi is included in the list of diagnostic sensors so it'll be properly flagged once that is merged.
• This needs a decoder release before it can fully work. bvpp is in 3da3902, which is untagged - the latest release is 2.3.0 and setup.py pins theengsdecoder>=2.3.0. Until a release carries the tag, no device sets bvpp, so BM2/BM6 (and similar) devices get their battery and voltage marked diagnostic like everything else. Recommend waiting for a decoder release and bumping the pin before merging this - or at least before releasing it.
• Once this is released, a new gateway-docker update is needed to add an ENV var for the new config option. See Add DISCOVERY_DIAGNOSTIC environment variable gateway-docker#34

Testing

I built a capture harness that records every discovery topic and payload the gateway publishes for a set of decoded devices, and ran it over 20 models - the multi-property and edge-case ones, one device per alias key, and two bvpp devices.

• Option off: byte-identical to development across 120 topics and 194 publishes.
• Option on: 27 entities marked, nothing missed and nothing marked that shouldn't be.
• bvpp injected: the battery-family entities lose ent_cat, and the always-diagnostic keys keep it.
• Payload strip checked in both publish paths at both publish_advdata settings.

Also running live against my own broker and HA with three BLE sensors (a LYWSD03MMC and two SwitchBot outdoor meters), which covers the batt/volt path. The bvpp suppression couldn't be tested here though, since I don't have any bvpp devices.

mypy clean, ruff at the development baseline at every commit, vale passes.

Note that existing entities only move to/from the diagnostic section in HA once the MQTT integration is reloaded - republishing the discovery config to MQTT isn't enough. There's a use.md note covering it.

Checklist:

• I have created the pull request against the latest development branch
• I have added only one feature/fix per PR and the code change compiles without warnings
• I accept the Developer Certificate of Origin (DCO).

[1technophile]

Thanks