Current behaviour
On an authoritative commission pass (i.e. the user types a name in the Indigo commission dialog), every bridged child endpoint receives a name derived from spec.name — which encodes the user's chosen name. For a 10-bulb Philips Hue bridge named "My Hue Bridge", all children are named "My Hue Bridge", "My Hue Bridge 2", "My Hue Bridge 3", … via the _dedupe_name counter suffix.
This silently discards the children's own NodeLabel values (e.g. "Bedroom bulb", "Kitchen spot", …) that the user set in the Hue app — precisely the per-bulb names that are most useful in Indigo.
UX problem
The user's carefully maintained per-device names in the bridge's app (Hue, IKEA Dirigera, etc.) are wiped on first commission. The user then has to rename every bulb again inside Indigo, which is tedious for large bridges and confusing because the auto-generated "My Hue Bridge 3" names give no hint of which physical device is which.
Candidate designs
Option A — prefix with user name (recommended)
Keep each child's NodeLabel (falling back to product_name) as the device name, but prefix it with the user's chosen bridge name:
"My Hue Bridge — Bedroom bulb"
"My Hue Bridge — Kitchen spot"
The bridge hub device itself (endpoint 0 / root) gets the plain user name. Dedup still applies within the prefixed namespace.
Option B — authoritative name applies only to the bridge node; children keep their labels
The user's chosen name stamps only the bridge hub device. Bridged children always use their NodeLabel / product_name, same as a non-authoritative pass. This is simpler but gives the user no way to group-rename an entire bridge's children via the commission dialog.
Option A preserves discoverability and matches how Apple Home presents multi-endpoint accessories (room name prefix). Option B is the minimum fix.
Related
The current code comment at that site notes this open issue (see PR #42).
Current behaviour
On an authoritative commission pass (i.e. the user types a name in the Indigo commission dialog), every bridged child endpoint receives a name derived from
spec.name— which encodes the user's chosen name. For a 10-bulb Philips Hue bridge named "My Hue Bridge", all children are named "My Hue Bridge", "My Hue Bridge 2", "My Hue Bridge 3", … via the_dedupe_namecounter suffix.This silently discards the children's own
NodeLabelvalues (e.g. "Bedroom bulb", "Kitchen spot", …) that the user set in the Hue app — precisely the per-bulb names that are most useful in Indigo.UX problem
The user's carefully maintained per-device names in the bridge's app (Hue, IKEA Dirigera, etc.) are wiped on first commission. The user then has to rename every bulb again inside Indigo, which is tedious for large bridges and confusing because the auto-generated "My Hue Bridge 3" names give no hint of which physical device is which.
Candidate designs
Option A — prefix with user name (recommended)
Keep each child's
NodeLabel(falling back toproduct_name) as the device name, but prefix it with the user's chosen bridge name:The bridge hub device itself (endpoint 0 / root) gets the plain user name. Dedup still applies within the prefixed namespace.
Option B — authoritative name applies only to the bridge node; children keep their labels
The user's chosen name stamps only the bridge hub device. Bridged children always use their
NodeLabel/product_name, same as a non-authoritative pass. This is simpler but gives the user no way to group-rename an entire bridge's children via the commission dialog.Option A preserves discoverability and matches how Apple Home presents multi-endpoint accessories (room name prefix). Option B is the minimum fix.
Related
device_sync.py~line 164–170.The current code comment at that site notes this open issue (see PR #42).