HA using gibberish IDs (like "12bf...76c4") leading to impossible untangling after Tasmota/MQTT screw-up

Configuration
1

I can’t figure out when this started, or how to aptly describe what happened, but… what the hell is up with these entity IDs like “12bf71c48991ce9af8d997974dd376c4”? It seems like it barfed them into my scripts when it got confused and lost connection to the device.entity_name entities they previously belonged to. I’d never seen these IDs before, and everything I built was based on entity_names as such.

image
image2140×984 140 KB

The entire system seems to make no reference to these gibberish entity IDs, so I don’t know how I could have ever picked them. But once the devices broke (by trying to replace one blown-out Tasmota board with another), everything about my automations - across multiple devices and probably 12 different scripts/automations - fell completely to hell.

I’ve repaired/recovered from breakdowns like this before, but never with this level of confusion, where I can’t even infer what device it was previously referring to. Worse, when I try to edit them to target the proper replacement “entity_id” for things I can recognize & know what it should be targeting, the editor complains that I need to provide a “device_id” as well as the “entity_id”. WHAT EVEN IS A “DEVICE_ID”? Everything in HA has a unique entity ID, so why is it requiring me to provide a “device_id” that isn’t displayed or known anywhere in the entire HA ecosystem except in these scripts that it edited by itself?

image
image1880×1414 275 KB

image
image2146×1128 157 KB

image
image2156×1402 203 KB

Feeling very lost, frustrated, and confused… all my automations are now broken in a way I don’t understand how to reference, how to come back from. Whose decision was it to start putting these cryptic entity IDs in place, or to make silent changes to my automations to inject/replace them? This wasn’t how I wrote them… I would never have used such cryptic IDs. :frowning:

edit: honestly I can’t see any way to recover from this other than to risk it all and try restoring a backup, hoping that the MQTT database will come with it…

image
image1172×596 21.9 KB

edit: That worked. I’m now back to having things properly associated. What the hell happened? Who on earth decided it was a good idea to give “devices” such precarious, unmanagable device IDs? I read about “oh, use Call Service instead of Device”, but why? The context there doesn’t make sense - I’m not “calling a service”, I’m referring to the state of a device. A device with a specific entity ID. A globally unique, human-readable entity ID. Why is it so difficult for the device picker to use THAT instead of these cryptic, unmanageable gibberish string IDs?

image
image2136×1370 172 KB

2
3

The “use device_id’s instead of those pesky entity_id’s” was a decision made a long time ago because users inexplicably found it too hard to use entity_id’s and services. The whole thing was so that users could use an “easy to use” GUI instead of writing real automations/scripts.

the unintended consequence of that is that if anything ever goes wrong (like in your case) it’s next to impossible for a user who doesn’t know anything about HA other than the GUI to figure out how to fix it (kind of like your case it sounds like).

And if you ever have a device die on you and need to replace it then you need to adjust your config to account for the new unique device_id given to the replacement device.

device_id’s were never intended to be accessed directly or modified by the user so it really didn’t matter if they were human readable or not.

That’s why every user who has been around for a while and does the more advanced stuff (i.e “advanced users”) don’t/rarely use device based things and stick to entity_id based things.

2 Likes
4

Good brief explanation!

2 Likes
5

Unfortunately, you can’t avoid them for actions on devices, e.g., button clicked. Those device triggers reference the device by id and so far as I can tell there is no way around that, especially if you use the UI to create automations. It seems this could be fixed if folks wanted to.

1 Like
6

I don’t get it. So, if advanced users figure out never to use the default mechanism, why is it the default?

The only reason it ever happened is because it’s the default - the lowest resistance path to getting done what needs to be done, among a very complex system. I’m not here to tinker with code or write YAML directly. But when something like this happens, it really needs to be easier to recover.

I’ve had to dig into deep bowels, including revealing really nasty hidden files in order to reveal the names of saved remote codes… stuff that really shouldn’t have to be touched. But this behavior, especially with no visible way to determine device IDs, seems absurdly broken.

Why does this persist, despite everyone saying it’s bad?

7

It’s an architecture choice, and it was designed for use by the GUI editor and the machine backend and was not designed for people to program. The original entity system was designed for people before the GUI stuff.
Beyond that, ask the designer.

Case in point, device_id’s don’t currently even work with templates. Only the Entity_id’s do…

8

Persist, though? I don’t get why it persists (when the only effects of doing so appear to be negative and unnecessary).

The GUI seems to have been developed as… well, I won’t say an “afterthought”, but certainly a later extension to HA. My experience with HA has been muddied by countless people, posts, tutorials, references, and docs, all talking about coding in YAML directly into config files. None of that exists in the GUI “happy path” of today. The GUI practically goes out of its way (case in point: HA’s File Editor add-on locking you into a useless path and hiding key config file folders by default) to hide those commonly-used config files and make them appear invisible. The GUI (Lovelace) seems to be designed to be God, to be your only interface to HA.

And yet the GUI practically seems to be in direct conflict with the design principles of the HA core in some places like this. Is there some place that improvements and architectural corrections are planned to overcome some of these issues?

At bare minimum, to be using “device_id” values, and complaining that it can’t be found and needs to be corrected, the system needs to present these device IDs in visible places and ways. Otherwise how is anyone intended to correct breakdowns like this?

9

¯\(ツ)/¯

10

yep, there are definitely limitations using the GUI editor. And that’s why not many (if any) advanced users use it. Some might just use it to whip up a quick basic automation from a mobile device but even then they still won’t use device stuff for the reasons illustrated above.

Because as the years have went by and HA got more popular for it’s power and versatility, there has emerged a user base that can’t figure out how to actually use HA for that power because they don’t want to get past the learning curve. So the HA team came up with the “make it easy” mantra and has catered to that user base more and more.

It’s the laws of unintended consequences in action. Make it easy for new users to get started and never requiring them to actually learn anything past the UI. Until they either want to start doing more advanced stuff or something breaks and then they get frustrated because they never learned the tools to accomplish what they want/need to do.

you can find them but that’s missing the point. and that’s also missing the point of the other criticisms you posted above.

the UI was strictly meant to make it easy for new users to do things. Those users were deemed to not need to worry their pretty little heads about the complexities under the hood because they didn’t need to know that stuff in Apple/Alexa/some other various mass consumer “home automation” system.

Just because it was written by god doesn’t mean it’s the only way.

I almost never use the UI except for integrations that require it. My HA system is pretty much all yaml.

the UI is for beginners or those simply satisfied with basic stuff. To unlock the power of HA you need to eventually move beyond the UI into yaml/Jinja2 configs.

That’s because that’s exactly what happened.

3 Likes
11

Except that HA, as it exists today (as nothing but a GUI), has absolutely no “in-point” to doing that. Absolutely none. In fact, the GUI fights you, as I said - it hides config files where you would be editing those things, hides the core OS (to access it, you’d have to… stick a USB drive in, with a key file, that unlocks SSH access to the base-level OS?!). HA goes far, far out of its way to stay locked down. And none of the users touting “just editing yaml, bro” ever tell you how to get into it - actually WHERE/HOW to edit those files or WHERE to insert said YAML. Out on the surface, the only interactions you have are with a GUI. There is no command line to speak of (except to restart or recover the system).

It’s like the two camps work on completely different pieces of software under the same name, and it’s my most frustrating reservation about ever telling people about HA.

Why is it so hard to just agree that the device_id and entity_id system is a bad idea? What part about being a GUI means that it has to use these IDs instead of just using the human-friendly entity IDs that are also already right there?

12

I never said I don’t agree.

the device_id and entity_id system is a bad idea.

There I said it. And I’m sure many, many others agree as well. That’s the exact reason we don’t recommend it.

:smile:

But that doesn’t change anything because the people who agree with us aren’t going to change it.

totally not true.

there is even an add-on for Supervised systems called Visual Studio Code that allows you to directly edit your config files. Well, I think…I don’t use a Supervised system but at least that’s my understanding using HA for 8 years.

all yaml goes into the config folder. that folder is the same folder where your configuration.yaml resides.

as to the how, all of the manual configuration examples (if they are available and most are) are in the docs.

of course there is a learning curve. And for some users that curve is pretty steep (hence the UI) but it’s not insurmountable. If it was there wouldn’t be anyone using HA at all since anyone starting HA before the UI was available had no choice but to learn yaml. And there are plenty of us around.