[Feature] Create a new entity from the "hostname" field

[oleksandr-belei]

The problem

Can we have possibility to choose whether new device_tracker entities are created from the name or hostname field? If I'm not mistaken, the AsusWRT integration with hostname value known to the router creates object names from it. That would be much more convenient.

Specific device(s)?

No response

Firmware type

No response

[Vaskivskyi]

Hey, @Oligarch,

I would need a bit more explanation of what exactly you mean by "name" for this feature.

Currently, the device_tracker entity name (and its host_name attribute) are obtained from the router with the following priority:

1. Friendly name of the device if set manually in the router configuration (e.g. user has renamed the device by going to Clients - View list - click on Client name)
2. Name as reported by the device (e.g. Device name for Android / iOS, System Product name for Win 11 and whatever it is called for other OSs). For most WiFi smart things this could be a model name)
3. If neither of the above, this would be just MAC address

This priority list is built with the following thoughts:

• if the user has named a device - of course, this is the way to name an entity
• if not, but it reports some name - this is enough to distinguish the device
• if not, MAC is unique and this way user again can find out what is the device

So, what other option do you see to improve the naming?

Does it not work this way for you?

[oleksandr-belei]

I meant to give priority to the hostname while creating entity_id

[Vaskivskyi]

Unfortunately, this data is not available in any of the API endpoints with device information. The only way to get it - directly read dhcp_staticlist value from NVRAM. But NVRAM doesn't have almost any other value used for identifying connected devices and their connection.

So if I add the possibility to read this value, the integration will have to do 2 different requests (NVRAM read + get everything else from API - those requests cannot be merged), - this would take twice more time and may significantly influence the performance of some slower Asus models. Also, if any of the 2 requests fail, part of the data will be missing - should it then be:

• acquired again (will take even more time and the result is not guaranteed)
• submitted to HA partial, keeping not-available part as was before (there is a chance of keeping data which became wrong)
• submitted to HA partial with removing non-available part (some data will be missing from the device_trackers)
• or should it be completely not updated in HA (so HA will have older data of tracker)?

For now, I am not sure this feature will be as useful, as it would influence the performance.

But, in any case, I am not completely denying the idea. Just need to find a way to not make anything worse for XX% of users, who don't use this optional field.