Builds the two name indexes Hue.Bridge keeps beside its resources.
A light's name is not on the light
light.metadata is deprecated in CLIP v2 and can hold a stale value. The name
a user sees in the Hue app lives on the device that owns the light, and the
only path from that device to the light is the device's services list. So
naming is a walk, not a field read, and it is a walk this module does once per
index rebuild rather than once per lookup.
Rooms, zones, scenes, and smart scenes are different: those are named things
in their own right, and their metadata.name is authoritative.
grouped_light is deliberately unnamed. It is a service of a room or a zone,
and it is addressed through the room or the zone — see Hue.Bridge.Graph.
Two directions, one pass
Both indexes come out of the same walk because they are two views of one fact:
{:name, type, name} => rid— whatHue.Light.get(bridge, "Desk Lamp")needs.{:rid_name, type, rid} => name— what event dispatch needs, to answer "does this event concern the light someone subscribed to by name?" without re-walking the device graph for every event.
Summary
Functions
Returns every index entry implied by resources, as {key, value} pairs
ready for :ets.insert/2.
Functions
Returns every index entry implied by resources, as {key, value} pairs
ready for :ets.insert/2.
Two devices can share a name — the Hue app does not stop a user from doing
it — and when they do, this function returns two entries with the same
key, in the order their devices appeared in resources. That ordering is
the only guarantee made here: what a consumer does with two entries sharing
a key (an :ets.insert/2 on a set table keeps only the last) is the
consumer's business, not this module's.