I wasnāt referring to lovelace. The files I mentioned, and the fields in them, is where the HA backend stores some stuff, including some of the configuration you enter via the frontend. E.g., <config>/.storage/core.device_registry
looks like this (for a single owntracks device):
{
"data": {
"devices": [
{
"area_id": null,
"config_entries": [
"d5c8a70b7e974476a67f6cc67c02d0e9"
],
"connections": [],
"hub_device_id": null,
"id": "ad5c35ea93224815af2c1d076e5d9526",
"identifiers": [
[
"owntracks",
"phil_s7edge"
]
],
"manufacturer": null,
"model": null,
"name": null,
"name_by_user": "Phil",
"sw_version": null
}
]
},
"key": "core.device_registry",
"version": 1
}
As I mentioned above, if you click the gear icon in the top-right part of that second picture you showed, and entered a āName overrideā (I think thatās what itās called), it gets saved in the name_by_user field of that JSON data.
And hereās what <config>/.storage.core.entity_registry
looks like (for a single owntracks entity):
{
"data": {
"entities": [
{
"config_entry_id": "d5c8a70b7e974476a67f6cc67c02d0e9",
"device_id": "ad5c35ea93224815af2c1d076e5d9526",
"disabled_by": null,
"entity_id": "device_tracker.phil_s7edge",
"name": null,
"platform": "owntracks",
"unique_id": "phil_s7edge"
}
]
},
"key": "core.entity_registry",
"version": 1
}
Notice the entity_id field that controls what the entityās entity_id will be.
Iām just trying to explain how it works ābehind the scenes.ā These files are not intended to be directly edited by the user. The UI provides the interface to them (at least to some extent.) This is really implementation stuff, but you asked.
FWIW, that second picture you showed from the OwnTracks Integration page represents a ādeviceā, and the bottom part of it represents an āentityā that is associated with that device.