Recommended ways to manage devices and entities names

Configuration Z-Wave
15

I think it’s because the documentation for Customizations presents it primarily as a way to tweak an entity’s “look and feel”, namely its standard attributes like icon and device_class which determine its appearance in the UI. It overlooks to mention that you can add whatever attributes you want to serve as metadata.

While creating a template, I needed to know an entity’s integration and wondered why it wasn’t included as an attribute by default. Rather than submit the idea as a Feature Request (and wait for it to be implemented, if ever) it was easier to just add it as a custom attribute.

3 Likes
16

In general I would concur but the major reason I do this is to Simplify coding.
And different light ‘devices’ sometimes support different features requiring slightly different coding techniques. For example I believe you mentioned a light that can have its level adjusted whilst off.
The fibaro dimmers support a nominated switch on brightness, others don’t only supporting switching on at the last switch off value etc.
The dim2 bit tells me it’s z-wave plus
And as you’ve seen if it’s largely irrelevant I just include the ‘aeon_labs_dsc06106’ bit so I know what it looks like.
These are also what I have from starting 3 years ago, were I to start again I may do it differently.

However the point I was trying to make was about changing entity_id 's from the default

EDIT: And the method I showed was not to expound a particular naming convention (that is upto the individual) but to show how easily it can be undertaken and the benefits consistency provides

17

That used to be available but was removed. I don’t recall why it was removed. That whole battery notification mess you saw in the other thread relied on it at one point.

18

I change the enity_name and friendly_name to be same.

light.living_room
Living Room

lock.front _door_lock
Front Door Lock

I do not change device name

By doing this if I ever change device the new device replaces old in UI

19

I’m using custom attributes in 0.117.4 so what exactly “was removed”? Do you mean it was documented at one time but that was removed?

1 Like
20

Huh, I recall them being removed. TIL, they aren’t removed.

21

But I have replaced a device, delete the old entities, add the device, rename to the new, restart and you are good to go. 10 minutes if that.

All automations intact and working

22

I like the concept for specific entities that could benefit from it but I think having to write a customization for single every entity would be mind numbing. And maintenance would be horrible if you did it for every entity that you add in the future (or even worse the ones you might remove later) especially since the integration is easily accessible to you in the entities list.

But the battery type example is a perfect use case for that.

But to each their own and knowing that it’s even possible is good to know. Another tool in the toolbox.

So thanks for the info.

23

I understand your point. However it’s not always a case of extra effort. If someone invests the time to change an entity’s name so that it contains metadata, I believe that time is better served putting the metadata in a custom attribute. In other words it’s not necessarily more mind-numbing work just the same amount of it but with better results.

To your point, I agree that battery type is one of the better applications of this technique. Most people don’t have a need to use an entity’s integration in a template (so they don’t need it as an attribute). If they simply need to know an entity’s integration it’s available in the Entities view. Nevertheless it was used as an example of the kind of metadata one can include should one need it to, for example, create an inventory of installed gadgetry. :slightly_smiling_face:

1 Like
24

Does it require anything special to add a new attribute, e.g. do I have to edit a list of attributes or anything? Can I simply call a new attribute anything I want?

25

You can edit a list as described in the documentation or you can use Configuration > Customizations (one entity at a time).

You can name the new attributes whatever you want just avoid using existing names.

UPDATE

As of version 2021.12.0, Configuration > Customizations no longer exists. You can continue to create custom attributes via the customize.yaml file.

26

Thanks, I wasn’t sure if there was other required actions other than simply adding new. Super helpful!

27

Hi, I like this idea since the device has so many entities but where are you pasting to? and what is the syntax, if yaml seems to be missing headers and whatnot.

28

In this instance I was using the z-wave configuration manager, selecting the newly added node, and then selecting entities of this node.
But you can just as easily (well maybe not ‘quite’ as easily) do it from the frontend.
I use a lovelace frontent so I could select ‘unused entities’ from the 3 dot menu
But I suppose if you use an autogenerated frontend then it would just be the new items that appear.
Either way, click on them and choose the cog option to configure them

29

I’m guessing that these custom attributes can’t contain templates, is that correct?

30

Correct. It has the same limitations as customizing existing entities as described here (i.e. no mention of the ability to employ templates): Customizing entities

1 Like
31

Does that mean that I have to add every entity to customize.YAML manually?

Is there a way to do this automatically?

By going to Configuration > Entities > entity > Integration, it is possible to see what integration an entity belongs to. Is there no way to do this programmatically?

32

Created a new blueprint to help with groups. It doesn’t support adding entities by attribute (yet) but it is substantially easier to create groups, plus it can automatically add or remove entities! Might help those looking to organize their HA.

2 Likes
33

This convention seems to assume that no two different varieties of sensor will ever have a “type” field with the same value? That is, what happens if you have a battery sensor for AAA batteries, and also a (silly hypothetical) video game quality sensor for AAA games? Your attribute selection code wouldn’t be able to distinguish between them. Would you add a filter based on the entity id, or add another custom attribute for the type of sensor? And if you do the latter, how do you feel about it being redundant with part of the entity id?

34

Yes.