Because the extra configuration step is not needed for most people. You want it because you want to have your old configuration match your new one. This is what you keep glossing over. Any new template that you create will appear with an entity_id that matches your name. A normal user will just use it. When they put it into their ui at a later date they might rename it. But they wouldn’t change it in their config, they’d change it through the UI.
Not to mention, most users now don’t even want yaml. Just the power users of the past.
It just seems to me to be quite trivial to accomodate everyone with the small tweak to either the friendly_name or the forced template_ prefix logic.
There seem to be a lot of workarounds for it (many of which you’ve kindly given, for which I thank you), but why work around something that could be adjusted to accomodate everyone.
I take the power user point though, although going back and rehashing everything to fit the new paradigm seems unnecessary work, but otherwise things end up in an inconsistent mess.
That is handled. You don’t understand the full system. The object_id is created from the unqiue_id only when name doesn’t exist. Every unqiue_id uses the integration as the first part of the unique_id so that it does not step on the toes of other integrations (because they all have a unique name). This only translates into the object_id when you don’t provide a name but only provide a unique_id.
Even if you provide a name, the unique_id will still have a template- in front of it, but you wont see it translate to the object_id because the object_id pulled from the name.
OK that’s clearer. I just see the upper level that gets exposed to me, and from that viewpoint this is the only place I see something like the template_ being forced on me.
Would be great if the ‘new’ device_trackers did so too, instead of suffixing with _2, _3, leaving the user without a clue which integration created the device… but that probably is off topic here
I think this topic is about done for it’s original purpose, so feel free to go OT.
One last question - is there any documentation anywhere detailing the specs for entity pictures, such as recommended/max dimensions?
Just playing with my HDHomerun set-up, and have got it working nicely and using channel logo pics for the entity picture (via a template sensor). Now having issues finding decent logo images to fit (as it seems to require them to be circular too?), but the search would be helped to know recommended/usual size etc.
if you have devices that cycle entity_id’s with that integration, it’s due to the mac address on the device changing. Nothing you can do about that. The unique_id is based on the mac.
no, it’s caused by the fact eg nmap device tracker sees a device and uses the name for object_id, and the same device gets tracked by Asuswrt, which obviously creates the same object_id, but that is already taken, so _2 is added. the _3 could be added on the same device, because of wifi/lan ip addresses? Dont suppose the tracker can see if it is wifi or lan.
in any case, I would have expected device_tracker.asus_device_name instead of device_tracker.device_name_2.
will wait for the Asuswrt to get back in the config in 2021.5.4, and see what happens.(it now is dysfunctional and cant be installed, PR is merged)
That doesn’t happen if the mac address is the same. So these devices must have new mac addresses each time.
If the unique_id is the the same, it will assign the entitys the entity_id that’s attached to the unqiue_id. The unique_is created from the mac address.
ok, will check on next update. Just to be precise, I was referring to the object_id, not the unique_id. Also, it didnt keep changing these, it was only added upon installation of the Integration, or, of course, when adding a new device to the network, that hadn’t been identified by the new tracker.
Right, but again, once you have a unqiue_id, you can change the entity_id and it will persist if the unique_id persists. If you’re just upset about the default naming convention, then just rename the entities. I can’t help you there as that’s the normal workflow.
No, it’s not that, (and yes, I did start to rename them manually and prefix asus_ )
What the larger issue was, was that it was very hard to map the created devices to the actual physical devices, because of no indication of the Mac or IP address in the device info.
Name the devices on your router and they (should) be named what they are named in your router. That’s at least how other device_tracker integrations do it.
This sounds similar to what happened with the recent Fritzbox move to the integration, at least if the legacy code in the config wasn’t removed first (ending up with _2 sensors for everything, as the original ones were still there or got restored).
I can confirm at least for that set-up that the device_tracker does get named for what the router name for the device is (requiring a clean-up and renaming of a few Android devices when I swapped over to the integration a while back).
