How to identify device friendly name via UPnP/API call?
I'm working on a couple of different tools that integrate with the Nanoleaf API(s). One of the things I've noticed is that even though I've set names for all of my devices in the Nanoleaf mobile app, I can only find the factory default name (model name + last 2 bytes of MAC - e.g. “Shapes 4473”).
Both the REST API responses and SSDP NOTIFY messages (in header “nl-devicename”) show this name
From the Nanoleaf documentation, I see the following note for nl-devicename on the SSDP NOTIFY:
Could be updated by an iOS user using WAC.
This brings up a few questions:
- What is WAC? Publicly available documentation suggests it's an Apple pairing technology, but it's unclear how those names are actually set in practice/how the updated name is communicated over the air.
- Is there a different mechanism to read the user-configured friendly name of the device?
- If the answer above is “no”, can we get something like one of the following?
- nl-devicename / analogous mDNS properties updated to match user-configured device display name in the Nanoleaf app
- TCP80 /device_info REST endpoint extended with device display name
- LocalAPI method for reading the display name (preferably without requiring authentication)
-
Offizieller Kommentar
The “user-friendly name” isn’t actually stored on or accessible from the device itself. Support for renaming was added to meet HomeKit certification requirements, but providing a way for users to change it depends on Apple’s interface, which is not currently available.
As a result, the device name defaults to the unique identifier printed on the controller. This is intentional, as the device name is used to set the service instance name on mDNS. Allowing it to be freely changed could lead to naming conflicts between devices, which may cause connectivity or discovery issues.
By keeping the controller’s predefined unique name, it ensures reliable mDNS operation. This may also explain why Apple has not enabled a user-facing option for renaming, despite requiring OEMs to support the capability.
-
Hey there, I stumbled into the same issue: Users are used to name their devices - AND find their devices by their user-defined name. If you feel that there should be a unique name, make that a e.g. “uniqueName” field, and store the user defined name in the name field.
Regarding mDNS discovery: Any app that would not use the device ID and instead use the device name for unique identification would be considered bad coding.
When you change behavior in this case, inform developers about it in advance. A properly developed app should not stumble about this in any way.0 -
I agree that having the user-configured friendly name available through the API would be very useful, especially for people managing multiple devices. It would make device identification much easier than relying on the factory name and MAC address. Hopefully Nanoleaf can expose this through the LocalAPI in a future update
0 -
. A few checks that fix many connection problems: make sure the controller and your phone are on the same 2.4 GHz Wi-Fi network (many smart-home controllers can’t join 5 GHz), turn off any VPN or private DNS on the phone, and give the app the Bluetooth and local network permissions it asks for. Then factory-reset the controller and set it up again from scratch, close to the router. It’s also worth confirming that the new controller is the right type for first-generation Aurora panels, since controllers for newer product lines may not be compatible, and asking Nanoleaf support with your order details. While you wait for support, a quick coffee break helps, and you can check a live about chek bansos kemensos.go.id website on your phone to pick a drink. Good luck getting your panels lit up again
0 -
A few checks that fix many connection problems: make sure the controller and your phone are on the same 2.4 GHz Wi-Fi network (many smart-home controllers can’t join 5 GHz), turn off any VPN or private DNS on the phone, and give the app the Bluetooth and local network permissions it asks for. Then factory-reset the controller and set it up again from scratch, close to the router. It’s also worth confirming that the new controller is the right type for first-generation Aurora panels, since controllers for newer product lines may not be compatible, and asking Nanoleaf support with your order details. While you wait for support, a quick coffee break helps, and you can check a live about fiori app library website on your phone to pick a drink. Good luck getting your panels lit up again
0 -
I’ve been tinkering with UPnP for my Nanoleaf devices, but I sometimes struggle with the API calls. Anyone else tried using it in automation projects? What’s your go-to method for identifying device names? slope rider
0 -
Hi Sean,
This is an interesting question, especially for developers working with smart home devices and API integrations. Having access to the user-configured device name through UPnP or a REST API would make device identification much easier and help avoid confusion when multiple devices are connected. It would also be useful if the Nanoleaf app could keep device names consistent across different platforms. Hopefully, the developers can consider adding this feature in a future update. Thanks for sharing the details!
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
7 Kommentare