Add the serial number to the DeviceInfo

[edenhaus]

Context

Currently, it is hard for the user to identify a device when the name and the model are the same. Some integration/API's are only providing default names.

He can only identify it by activating some sort of action on the device like:

• switching on the light bulb
• activating the siren of the smoke detector

The device info page does not provide any information that allows identifying the device (if they have the same name and model).

Proposal

I propose to extend the DeviceInfo by the serial number. This new field is optional and should only be shown by the frontend when it is set.

Example:

With the serial number, a user has an additional identifier to identify a device.

Consequences

As the serial number is fixed per device and will not change over time, I think there are no consequences for adding the serial number to the device info.

What will happen with the current devices?

As the serial number is optional, there is no action/change required for the current devices.

[joostlek]

One concern I want to address, do we apply rules to what a serial number is? For example my switchbot curtains are connected via bluetooth. (Maybe they have a serial number, not sure) But the switchbot app uses the mac address to identify the curtains. I think by default when you add a curtain to HA, it will show you the last 4 characters of the mac address in the device name. In an ideal world, the name would not contain this and we could identify the device via device info, which we can't right now:

So my question is, are we going to use this field purely for serial numbers, or just a number/barcode/macaddress that will help the user identify the device?

[elupus]

I would prefer it being some generic user identification field.

[joostlek]

But in the case of displaying a mac address, we are already storing that in the connections. Sounds a bit overkill to explicitly have to set the mac address again after we already provided it in the connections list.

[elupus]

True. Im thinking rfxtrx here. The identifer would be some part of the address of a device (not mac). So its not a real serial. I probably could abuse serial for display, but it seems a bit wrong. I suppose formatting it MAC:ish would work too, but again would abuse its meaning.

[joostlek]

What if we could add MAC address: ... as a separate field? I mean when I go to device info in the Switchbot app or Philips hue app, I am also greeted by the mac address of the device, so it's not a really strange thing to add imo

[frenck]

I would prefer it being some generic user identification field.

I would not use that as such, or make this proposal about that. Having a "general" purpose field result in the field having no factual meaning. I think the good thing about this proposal, is that the field proposed an common thing and has a clear meaning.

[frenck]

Looking at the codebase: A serial number is a very common thing for a device; as a matter of fact, search for serial_number alone gives 1123 results in 328 files.

It is pretty much static, so it is a good fit for the device registry as well.

Thumbs up from my end 👍

[thecode]

I think we should have a more generic approach which will also support other identifiers. I am sure the most common one is MAC, probably much more than a serial number.

This can be accomplished in

• Separate fields for MAC & SN (meaning we implement the Serial number as suggested here and also implement a MAC field)
• Instead of storing/displaying Serial Number: 1234, name the field Identifier, so it will fit both MAC & SN (for example Identifier: 12345 or Identifier: 11:22:33:AA:BB:CC)
• Make this a free text field (for example, the storage can be named metadata, integration will put any text needed there), most versatile but is a place for integrations using it incorrectly.

In any case, I would not go forward with this unless we cover at least MAC address.

[elupus]

Mac may be part of device info, but we are not display it in GUI. That might be a separate concern, but I think that is part of this discussion.

[frenck]

Mac may be part of device info, but we are not display it in GUI.

That is a frontend/display/ux issue and not limited by any architectural decisions at this point.

[thecode]

@frenck from the description of this architectural discussion:
I propose to extend the DeviceInfo by the serial number. This new field is optional and should only be shown by the frontend when it is set.

Example:

--

The discussion clearly states that this field is optional and is used for display. Currently the MAC address we store in the device info is used for connection info, which means that if an integration store this data it would not be able to indicate if this value should be used for display or hidden from the user. The reason I am putting this now is because later it would be harder to answer this.

Many devices uses MAC address for the connection info, however for many devices you would not want to visualize this data (same as we don't visualize the device IP), many devices has a serial number (for the user to identify the device) but the integration identify the connection to the device using a MAC address.

Since the CONNECTION_NETWORK_MAC is part of the connections set and as I understand this architectural discussion describes adding a new field to the device info, if the field is not part of the connections set and as described above is only used for display we can't answer the need for displaying a MAC address, this is why I suggested to consider alternatives such as naming this new field identifier or metadata

[frenck]

The discussion clearly states that this field is optional and is used for display. C

Correct.

Currently the MAC address we store in the device info is used for connection info, which means that if an integration store this data it would not be able to indicate if this value should be used for display or hidden from the user.

That is a UX decision. From an architectural design, the MAC address is stored and available.

this is why I suggested to consider alternatives such as naming this new field identifier or metadata

Sorry, don't follow. Identifiers already exist, and are not related to any of this. metadata is a different architectural discussion and has not been accepted at this point. (Not would I personally support a random data proposal myself).

I think we should focus on this proposal and not the MAC address. If you think the mac address needs changing, I suggest opening a new proposal for that.

../Frenck

[thecode]

That is a UX decision. From an architectural design, the MAC address is stored and available.
This is wrong, the discussion is about adding a field for used only by the UX, not for core to identify the device (as I already try to explain above, maybe not good enough

Sorry, don't follow. Identifiers already exist, and are not related to any of this. metadata is a different architectural discussion and has not been accepted at this point. (Not would I personally support a random data proposal myself).

When writing this I did not go and look about any historical discussions, I only suggested that if a field is used only for display as suggested here, naming the field "serial number" (or similar) would only cover UI support for a serial number and make it harder to support MAC in the UI, while if you give it a more generic name (e.g. "device identifier") it would be easier to support displaying MAC in the UI:

I think we should focus on this proposal and not the MAC address. If you think the mac address needs changing, I suggest opening a new proposal for that.

I am really limited in time and my participant in this discussion was because I want the optimal design for Home Assistant. I do believe this is going wrongly just because you don't try to understand my suggestion & would still suggest this is given a second thought.

[frenck]

We've discussed this today and are accepting this proposal to add just serial_number to the device info right now, as it is really common.

Other suggestions have been discussed, but we have kept them out of scope for now. There is a proposal/idea in the making to add the actual notion of devices to Home Assistant, which would be a better fit to discuss all other needs.