UniFi Network: extend telemetry-gap preservation to other sensor types after controller updates or restarts #185638

The problem

@Kane610, this appears to be the broader telemetry-dependent sensor problem we discussed in #184231.

In that discussion, I suggested keeping the UPS fix focused and addressing recovery for other telemetry-based sensors separately. I now have a reproducible case affecting PDU aggregate power and device CPU/memory sensors.

A controller update or Network application restart creates an offline window during which HA logs HTTP 502/503 errors and WebSocket reconnection failures. After reconnection, previously discovered sensors are deleted from both HA's state machine and entity registry. The controller subsequently resumes reporting their telemetry, but the entities do not recover automatically.

I observed this during a controller update and reproduced it by stopping the Network application for approximately one minute, then starting it again. Neither case involved a gateway or device reboot.

The original incident deleted 30 sensors within approximately 100 milliseconds:

What version of Home Assistant Core has the issue?

core-2026.10.0

What was the last working version of Home Assistant Core?

Unknown.

What type of installation are you running?

Home Assistant OS

Integration causing the issue

UniFi Network

Link to integration documentation on our website

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

Diagnostics information

The exact triggering controller payload was not captured. The controller outage and subsequent deletions are confirmed, but whether the triggering device data arrived through polling or a WebSocket update remains unverified.

Anything in the logs that might be useful for us?

During the offline window, HA logged these errors (controller address omitted):

Server handshake error connecting to UniFi websocket:
502, message='Invalid response status'

Server handshake error connecting to UniFi websocket:
503, message='Invalid response status'

Websocket setup failed

aiounifi.errors.BadGateway:
.../proxy/network/v2/api/site/default/firewall-policies received 502 bad gateway

aiounifi.errors.ServiceUnavailable:
.../proxy/network/v2/api/site/default/firewall-policies received 503 service unavailable

Additional information

UniFi Network version: 11.0.83, running on a UCG-Fiber.

Relationship to the UPS fix

#184231 worked as intended: the UPS battery-pool sensors remained registered through the same incident. UPS-2U-Pro output power briefly reported unknown, then recovered automatically when telemetry returned.

The sensors deleted here use other support checks:

• PDU aggregate-power support depends on the current outlet_ac_power_budget value being non-null.
• CPU/memory support depends on the current system-stats fields being present.
• The shared entity update path removes the entity and its registry entry when a support check becomes false.
• Discovery listens for device-added events, so ordinary updates containing restored telemetry do not recreate the deleted entities.

This appears to conflate temporarily absent telemetry with permanent loss of sensor capability.

Proposed direction

I will take a stab at implementing a shared fix and submit a PR, extending the preservation principle from #184231 to all telemetry-dependent UniFi sensor types rather than adding separate preservation logic for each type.

Once a sensor has been discovered, a temporary missing/null field should not delete it or its registry entry. It should report unknown or unavailable as appropriate and recover when telemetry returns, while preserving entity IDs and customizations.

Genuine device removal should still remove entities. Initial discovery should continue to require evidence that the device supports the sensor; this should not create unsupported sensors on every device.