Truncation of '_v1' at End of unique_id?

Good info. So I’m thinking that I:

  1. Standardize on using entity_id.
  2. Create a loose standard schema for myself for setting the entity_id strings with all this mind. I.e., edit out the device-specific address the Insteon integration puts in it? Use names that reflect it’s location in the house, etc, blah, blah, blah.

Pretty much exactly what I do, though can’t guarantee it is best practice :stuck_out_tongue:

For some things like lights I really hate the default entity id/name scheme and my OCD forces me to change them manually. I typically name the device according to location and what it is, so something like Lounge Ceiling Bulb (as opposed to say a Fixture which would imply something with a non-replaceable light source).

But then the light entity gets the generated name Lounge Ceiling Bulb Light with the even more redundant id light.lounge_ceiling_bulb_light, so I manually change those to only Lounge Ceiling and light.lounge_ceiling respectively. Entities that I deem secondary i.e. things that will never show up on a dashboard and seldom be used in automations I leave the default ids/names.

Yep, that’s kinda what I’m thinking as well. Location (which for me would be the room) and the thing being controlled. E.g., Living Room Couch Lamp =‘LvRoom_couch.’

Thanks everyone for being patient with me as I figure this stuff out.

1 Like

No worries.

What I find is I TRY not to change the default name given if possible.

Reason.
A lot of troubleshooting solutions you’ll come across include remove integration X and reinstall it.

Guess what if you did a bunch of naming customization?

One of my integrations is SPAN for instance. It adds well over 200 entities per electrical panel and I have two of them. I spent my time making sure the default configuration comes in as clean as possible (they derive names from settings in a cloud app - so I made changes there so I have to make as few changes as possible.) so now I only edit about 10 entities.

Unfortunately because open source and alternative perspective on data dictionaries and interpretations of thier own schemas, languages etc. at the integration level you won’t find one ‘single way’ for best practices.

As to naming I point at a thing and ask my wife what it is and start the naming there because voice. The I adapt my entities etc. based on that, trying to make as FEW changes from defaults as possible because above.

Having not yet had to do that; that thought never crossed my mind. So that’s good info to be aware of as well.

1 Like

Yeah it’s a real pain.

I also just found out that labels don’t stick when you do that. :skull:

I HEAVILY label my circuit breakers and electrical system. Over 400 entities each usually has at least 5 labels… That was… Fun. I found out after Month of WTH happened or it would have been one.

now that’s just lovely :face_with_spiral_eyes:

1 Like

I mean, I would imagine that labels are tied to the non-user-visible hardcoded ids in the database, not user editable things like entity id. If they were tied to entity id, then certainly just like automations breaking the labels would be lost whenever something was renamed?

By now you probably already have a solution. If not, look into Spook which has actions for setting labels through automations. Since you seem to have a strict naming scheme you should be able to quite easily filter down your entities by regex and apply the labels.

Already on the same path you’re thinking - and exactly how i intend to solve

Its a lot of panel 1, panel 2, kitchen appliance x, etc

Wouldn’t happen to know if spook exports? :slight_smile:

Edit.: no but it’s easy enough to recurse through a list and write a file or sensor output with it… :slight_smile:

Pro tip:

You’ll thank me whenever you change entity IDs.

EDIT: actually, thank @Frenck.