since I was already using the Owntracks entity, as per https://www.home-assistant.io/components/owntracks/
I was surprised to see a secondary entity (using the _2 ) being created and listed under the integrations tab for the same Owntracks device.
What should be changed to get rid of that? Or put differently, how could we point HA to the existing device to set up in the integrations section?
This question has been asked a lot lately, both on this forum and in discord.
Basically you need to remove the old owntracks-related entries in known_devices.yaml and restart. Then you can customize the new owntracks-related entities to remove the ā_2ā.
thanks, sorry to be such a nuisanceā¦ update went so smoothly and quickly (kudos HA team!), I didnāt have the time to check all posts hereā¦
Iāve managed in the meantime, and deleted the _2 in the .storage because I didnāt want incorrectly named entities in the backend show nice names in the front-end.
should I have anything listed in the name override section, clicking the cogwheel?
the device_tracker shows and behaves correctly now, but doesnāt seem to have a name of its ownā¦
If you click on the bottom part of that second picture, youāll be able to actually change the entity_id of the entity. There would be no difference between the entity_id in the backend and frontend.
Ok, when I do that I get an enhanced version of the first image.
Just to be sure I understand what this is doing: entering a name there, would be the same as setting a friendly_name in the customization (which is what I have now, and why the device_tracker isnāt called by the mqtt account name, but has my (friendly) nameā¦?
homeassistent:
customize:
device_tracker.mqtt_login_name:
show_last_changed: true
entity_picture: /local/family/me.jpg
friendly_name: Me Owntracks
When you click the gear icon at the top of that second picture, youāre effectively editing <config>/.storage/core.device_registry. The part you circled comes from the value of name_by_user I believe.
When you click the bottom part of that second picture, then click the gear icon, youāre effectively editing <config>/.storage/core.entity_registry. When you change the entity ID youāre changing the value of entity_id, which is what controls what the entity_id of the entity will be. Itās not a ācustomizationā, per se.
The customize entries you show in your last post would apply to the entity_id defined above.
How all of that correlates to the UI, I leave to the interested student.
ok thanks,
name_by_user is new to me, will readup on that. I guess I am at a crossroads between manual yaml configs, and native Lovelace config edits. name_by_user sounds like a field the user enters in the Lovelace editor.
It is still very much in development I would think, because when clicking the configuration tab and then general, I see all messages like these:
Editor disabled because config stored in configuration.yaml.
which doesnāt really match the possibility for manual settings per entity tbh.
Might be best not to meddle too much for now, and see where things are going from hereon.
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.
Sure, I am aware of that. Should not have mentioned Lovelace but Ha94.xx
Iāve been editing the .storage files manually ever since they were introduced and know the pitfalls and advantages of doing soā¦
Always have a backup at hand, but never needed one thus far ā¦
Iāve been doing that mainly because of the horrific names several integration give their entities, and didnāt want to friendly_name these. But wanted these to have regular and recognizable, but most of all useable names.
Maybe now the time has come to start using the native Ha editors. Using Yaml mode in Lovelace, and used to the tricks and tools of handmade editing in yaml wonāt make that switch an easy one though.
Havent seen any Ha editor write nice yaml (automation editor ) yet, and really donāt think the automated ui-lovelace.yaml which is many thousands of lines is preferable to a handmade one with nice includes and separated and reusable config files.
Anyways, rambling here. Sorry. Not complaining!
Thanks for your consice explanation, Iāve pinned it.