Value sensors display 'off' instead of the reading — SupportsSensorValue missing from creation props

[simons-plugins]

Reported by CliveS (with his Claude doing the write-up) after Thread-validating the plugin with an Aqara FP300 presence multi-sensor — commissioning via the share model worked first time (~10s join, all four endpoints, battery fan-out, live attribute reports).

Bug

Value sensors (temperature, humidity, illuminance, etc.) hold readings correctly in sensorValue, but the Indigo device list shows "off" instead of the reading:

"deviceTypeId": "matterTemperatureSensor",
"displayStateId": "onOffState",
"displayStateValUi": "off",
"states": { "batteryLevel": 100, "onOffState": false, "sensorValue": 24.0 },
"supportsOnState": true,
"supportsSensorValue": false

Cause

Same as the colour lesson (HANDOVER 2026-06-09 item 4): Indigo applies Supports* capabilities via creation props, not Devices.xml statics, for API-created devices. It was caught for locks (IsLockSubType), colour (SupportsColor) and meters (SupportsPowerMeter/SupportsEnergyMeter), but the sensor family slipped through — _SensorHandler.create_indigo_devices passes no SupportsSensorValue/SupportsOnState, so Indigo defaults to SupportsOnState=True and derives displayStateId=onOffState. The XML <UiDisplayStateId>sensorValue</UiDisplayStateId> is ignored; the sensorValue that does populate is the XML-declared custom state shadowing the disabled built-in.

Affected types (display = sensorValue): matterTemperatureSensor, matterHumiditySensor, matterIlluminanceSensor, matterPressureSensor, matterFlowSensor, matterAirQualitySensor, matterCO2Sensor, matterPM25Sensor, matterTVOCSensor. Binary sensors (motion, contact, smoke/CO) display correctly via the SupportsOnState default but should set it explicitly.

Fix

• Value sensors: SupportsSensorValue: True, SupportsOnState: False in creation props; binary sensors: the inverse, explicitly.
• Extend the issue Capability props (SupportsPowerMeter/EnergyMeter/BatteryLevel) missed when node_added fires mid-interview — reconcile never re-asserts them #45 self-heal (_reassert_capability_props) to re-assert these display props on existing devices via replacePluginPropsOnServer.
• If a device's displayStateId is still onOffState on a later reconcile (Indigo caches it at creation and may not re-derive), log a startup warning naming the device with the remedy: delete the Indigo device and reload the plugin — reconcile recreates it with correct props (no decommission needed).

Follow-ups (not this fix)

• matterButton (display should be lastButtonEvent) and the air-quality string display (airQuality) depend on whether UiDisplayStateId can ever apply to API-created sensor devices — needs hardware testing.
• Thread can be promoted from "expected to work" to validated (Aqara FP300, matter-server 0.6.8).

[simons-plugins]

Live-rig verification (jarvis, 15 virtual devices incl. 9 pre-fix value sensors): the fix is fully self-healing — no delete-and-recreate needed.

Deployed the 2026.2.22 build over a fleet created pre-fix and watched two reconciles:

1. First pass healed every device in one replacePluginPropsOnServer each (display props + createdTypeId); every replace passed the read-back persistence check.
2. Second pass: reconciled 16 Matter node(s) with zero stale-display warnings — i.e. real Indigo re-derives displayStateId from a props replace. Confirmed on-device: the temperature sensor's built-in onOffState disappeared (on_state: false → null) and the list display now follows sensorValue.

So for CliveS: just upgrade to v2026.2.21+ — the three FP300 value sensors will heal themselves on the first plugin start. The startup warning ships as dead-man insurance only.

This also unlocks the remaining follow-ups cheaply: since the display re-derives from a props replace (no recommission needed), the matterButton/lastButtonEvent and air-quality string-display questions reduce to a live experiment — set both Supports* props False on a test device and observe whether Devices.xml UiDisplayStateId finally applies. The button + air-quality virtual devices are running on the rig, ready for that experiment.

[simons-plugins]

Both follow-ups resolved — live-verified on jarvis, fix on PR #59.

Experiment: set BOTH SupportsOnState and SupportsSensorValue to False on the button and air-quality handlers, instrumented displayStateId across two reconciles.

Result — the precedence rule for API-created devices:

• A True Supports* prop wins (built-in display).
• With both explicitly False, Indigo falls back to the Devices.xml <UiDisplayStateId> after all: button → lastButtonEvent, air quality → airQuality ("good"/"poor" instead of the raw enum int).

Implemented on PR #59: display_props = {both False} on GenericSwitchHandler and AirQualityHandler; the reconcile self-heal upgrades fielded devices automatically (verified — no recreation needed); the stale-display nag now covers UiDisplayStateId-fallback types; the zoo invariant permits (False, False) only when the XML declares a UiDisplayStateId pointing at a declared custom state — and that invariant immediately caught generic_switch not merging display_props into its spec props.

Full display census of the 16-node fleet after the fix: relays/locks/valves onOffState, dimmers/covering/fan brightnessLevel, thermostat temperatureInputsAll, value sensors sensorValue, button lastButtonEvent, air quality airQuality — all correct. Nothing left open in this issue once #59 merges.