UniFi Device Bridge support: bridged-device names and throughput on the LAN Flow Map#1027
Merged
Conversation
Two related gaps for UniFi Device Bridge (UDB) setups (e.g. a Protect camera wirelessly bridged onto the LAN): Names: UDB-bridged clients carry no user name/display_name, only an auto hostname, but expose a friendly name in unifi_device_info_from_ucore (e.g. '[Camera] Driveway'). Add that field to UniFiClientResponse and use it as a label fallback (display name > name > ucore name > hostname > MAC) on the 2D/3D map and Client Performance. Rates: a UDB uplinks over Wi-Fi with the bridged client on its single downlink port, whose own client counters UniFi reports as zero. Its real throughput is on the UDB's own port_table. Fold DeviceBridge into the mesh-AP backhaul synthesis (new contributor reading the bridge's downlink port, gated to DeviceBridge) so the UDB's uplink link shows the flow, and source the bridged client's leaf-link rate from that same aggregate (gated to bridge parents). Switches, their clients, and mesh APs are untouched.
The live UDB rate fix routes through LanFabricAggregator + MonitoringLiveStats, which are in-memory only. Historic LAN-flow-map playback re-derives rates from the durable interface_counters measurement instead - which works for switches/ APs/mesh (their bytes are in an SNMP port or vwiresta series) but not for a UDB, whose throughput lives solely on its own port_table (a UniFi-API signal, never SNMP). So the UDB uplink and its bridged-client leaf were blank in playback. Persist each UDB's summed downlink port_table rate to interface_counters under a synthetic 'bridge-downlink' series (BridgeInterfaceRecorder), from the shared recording path so both directly-monitored and agent-relayed sites record it. Teach the historic MeshBackhaul and WiredClient resolvers to read that series (the latter via the existing BridgeParentMac marker), matching the live directions. No new measurement; switches/APs/mesh playback is unchanged.
The historic node-badge fabric-sum treated the UDB's synthetic bridge-downlink series as switch fabric, summing its single directional flow into ingress/egress (low in, high out) - so a bridge looked asymmetric during playback while live showed it symmetric. Exclude the bridge-downlink series from the fabric-sum so the UDB falls back to adjacent-link summing, matching the live badge. Real switches never carry that series, so they're unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds first-class support for UniFi Device Bridge (UDB) setups - friendly names for bridged UniFi ecosystem devices, and throughput for the bridge and the device behind it.
Monitoring - Live View
Bridged device names on the LAN Flow Map - A device bridged onto the LAN through a UDB (e.g. a UniFi Protect camera) carries no user-set name and no system display name - only an auto-generated hostname - so it rendered as that raw hostname. It now resolves the friendly name the console keeps for it (
unifi_device_info_from_ucore), reading as e.g. "[Camera] Front Door", with the bridge itself shown as "[Bridge] ...".UDB throughput on the LAN Flow Map - A UDB uplinks over Wi-Fi with its bridged client on a single downlink port, and UniFi reports that client's own wired counters as zero - so both the UDB's uplink link and the bridged-client leaf showed no throughput at all. Both now show the real rate, read from the UDB's own port_table and folded into the existing mesh-AP backhaul synthesis (gated to bridges, so switches, their clients, and mesh APs are untouched). It works in live view and in historic timeline playback - the bridge rate is persisted so the scrubber can replay it - for both directly-monitored and agent-relayed sites.
Client Performance
Known limitation
If a bridged client is physically moved to a different bridge, historic playback attributes its leaf to whichever bridge it is on now (the map overlays past rates on the current topology - the same simplification every link makes today). This is left for the planned historic topology / port-role recording to resolve uniformly rather than special-cased here. The bridge uplink links are unaffected.