Entity Name Fix & Cleanup Process

[benhanson]

I probably have an atypical setup, with 3 Zwave JS/UI instances, and I know I’ve moved things around, changed IPs, etc, etc, and that’s why I end up with a bunch of broken entities and cards and automations, and have to spend hours cleaning it up . . . but I digress.
It would be great if there was a workflow that could be triggered from a broken entity on a card/scene/automation/any place that “Entity Not Available” might be displayed. This workflow could jump to a developer tools tab that would show a reference to the missing entity and any OTHER references to this same missing entity, and then allow “connection” to a valid entity. This would eliminate one of the complexities of doing entity name cleanup, as it would give you a central spot for “broken” entity references.

As a bonus, this same area could show the old/stale entities that end up causing _2 and _3 iterations of entities, and provide a mechanism for merging/renaming/cleanup up these entities.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Hi benhanson,

I suggest installing Spook, It should be able to help straighten that up.

I suggest a little de-cluttering, however, sounds like you have build a dragon that is pretty tough to control there.

[Edwin_D]

Yes, Spook is great for the things built in the UI. For yaml, Watchman is still great, those complement each other perfectly:

Watchman - keeps track of missing entities and actions in your config files

Would like to present a custom integration to identify entities and services in your configuration files that either no longer exist or have a wrong state. Along with a few sensors, it may create a text version of the report or send it via notification service of choice. Please don’t be afraid of the documentation volume, I’ve tried to keep the balance between versatility and simplicity of use during development, so all parameters are optional: GitHub - dummylabs/thewatchman: Home Assistant cu…

Note that if you use device actions, conditions etc, and the devices are no longer there, then it is impossible to tell what device was referenced. That is because the id’s used in device actions no longer have any information attached to it. That makes auto-fixing next to impossible, because no one ca tell what is what.

This is why this advice is there:

Why and how to avoid device_ids in automations and scripts

Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [image] It works… but it is certainly not a “great way to start” because it is storing up problems for the future. Far better to use an entity, with state or numeric_state. Device_id problems The yaml will be longer and harder to follow, which may make maintenance difficult, especially a few months down the line when y…

The answer to this problem: use entity_id’s everywhere. When devices are replaced, change the entity_id of the new entity to what it used to be for the old entity and everything starts working again. That is way easier then changing every reference to point to the new entity.

[benhanson]

I’ll have to take a look at that. All-in-all, my system is actually quite stable and not much cruft, but my zwave environment involves 3 bridges due to: detached garage, and another outbuilding. I’ve also upgraded/swapped zwave sticks. So it’s just been those transitions that interject a bunch of entity chaos.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Zwave mesh network is completely capable of handling a hundred devices,

[benhanson]

It’s primarily a distance, foil faced insulation and metal siding issue. Also found that some devices, Schlage locks for instance, don’t work well if they aren’t directly connected to the controller.