Second Owntracks entity after updating to 94.3

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?

36

the device_tracker shows and behaves correctly now, but doesnā€™t seem to have a name of its ownā€¦

43

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.

1 Like

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.