This is more an issue of how you setup your system. It’s not a good idea to automatically record everything in the internal db and expose everything to InfluxDB. I have around 900 entities, but only a few of them I explicitly expose to InfluxDB and record to the database.
For what do you need this?
Adding an alias with the same structure as the entitiy_id (sensor.xxx, light.xxx) will make HA more complicated than it needs to be and I still don’t see any benefit out of this.
For example I have many temperature sensors because most aqara sensors also contain a temperature sensor. But I only want to have one logical sensor for temperature_inside. What physical sensor becomes the sensor for temperature_inside changes. Sometimes a sensor fails, sometimes it is not very accurate, or sometimes its placement is not ideal.
I’m sorry, you are circling the plughole here.
So you get a new device.
You ‘include’ it so that HA sees it and HA calls it sensor.centralite_3305_s_11097abc_1_1026 (note at this point it does NOT have a friendly name) it’s in the main bedroom and it has two sensors, one is temperature the other is movement (these are for illustrative purposes)
You go to entities and change the names to sensor.cl_temp_bed1 and sensor.cl_move-bed1 then when you need to write code you aren’t looking through databases to see which device you installed where and what its mac address is.
Call the friendly name whatever floats your boat.
This is normal
This is what you are meant to do.
As long as its less than 255 characters you can write a mini essay.
These are then the names used ALL throughout HA.
Why would you want to make it obscure ?
In last 30 years as a software engineer I learned to separate the logic in a logical layer, abstracted from the physical layer. Same with data modeling. You always have a physical layer and a logical layer. This is a well established approach in IT.
Sorry, was this aimed at me ? Cos you didn’t ‘Reply’ to me, so I didn’t get a notification. Or was it to @Burningstone ?
How long did you say you worked in IT ?
The ‘unique identifier’ here is the entity name, it is unique because the system won’t let you create another entity with the same name.
As I said above you have 255 characters to write whatever name you want : -
domain.manufacturer_device_revisionno_firmwarerev_macaddr_ipaddress_colourofdevice_whatyouwereeatingwhenyouinstalledit - go for it !
It’s friendly name can be ‘nothing’ or the name of the museum you visited last year in Rome - Who cares ! As long as you relate to it then it’s good
The entity name is the important one as far as HA is concerned
As all automations and scripts use it. AND that when writting them you will need to easily refer to them as they appear in triggers, conditions and actions along with permutations of them with the attributes they carry.
I see you are from Germany, joined 10 months ago and have read less than 15 hours on the forum - but given this I thought maybe you understood the relationship between the naming conventions.
But also remember that; when relaying to your wife, that she should not call the the main bedroom light ‘the main bedroom light’ but light.ikeatradfri4wclear_ecec1b9d418c Good luck with that
I also see that you are credited with two solutions and both of them were on topics you created.
I’m sorry but I don’t buy this, you work as a software engineer for 30 years and until a few months ago (Jul 2019) you didn’t knew what a pull request is?
Post from you of July 2019:
And yes this may be well established in IT, but fisrt it doesn’t mean that because its common practice that all projects need to do this like this and second you still did not explain what ypu need this for.
For a similar reason I created a custom multisource sensor - you can combine as many sensors as you like and you’ll only need to use its name in automations.
It allows to switch off any of the source sensors, too.
That feature would be very nice to have. Renaming a sensor ID might cause problems for the following reasons:
I’d like to have this feature, because I need to switch between devices, which are accessible under the a single name. For now, the multisource sensor is a good solution for me, but it would be nice to have such a feature built-in.
PS: Please stop being personal. It can definitely be that one has 30 years experience as software developer while still not knowing what a pull request is. A PR is not an integral part of the GIT workflow. The Linux kernel - for example - does just fine without PRs and not everyone uses GIT hosting solutions.
EDIT: Additional use case
Can I just clarify here when I go to entities to change the name there are really 2 fields relevant to this discussion and I just want to make sure I’m on the right path - there’s ‘Name’ and ‘Entity ID’. So when you refer to changing the name are you pointing to the ‘Entity ID’ or the ‘Name’? I’d like to believe I change the ‘Entity ID’. If so how does the ‘Name’ come into the picture?
I was making a point for our friend above that when you write code (with an eye to the future) then write it in a consistent manner so that you can steal bits of it for others rooms/devices (just use a bit of search and replace)
As you have found you can adjust 2 things : -
The ‘Name’ is as outlined in point 1 but should allow you to connect the two in your head. You are the system architect after all.
Thanks for the clarification.
I’m ready to leave the sandbox environment and start to plan with an “eye to the future”. Fully with you on that. And this advice comes in handy for where I’m at.
First step rename the entity_ids applying some logic such as .<function/name> or whatever works best in my case and create a ‘Name’ that mimics this somewhat (less manufacturer for instance). Got it.
Also re automations, triggers, actions etc. the entity_ID is used hence your point to make it simple/functional so the code becomes more readable. Right?
Lastly I refer to friendly names when interacting via a voice interface such as Google Assistant meaning the main use of this is for the dashboard and voice.
Partly,
Imagine when you have (say) a 10 room house and (say) 5 devices per room.
Some devices have multiple entity ids per device (I have a fibaro light sw with 11 entity ids for it and its sensors etc - and I have 19 lights)
So you are writing code and you want (say) an interaction between a humidity sensor in the Main Ensuite and the Ensuite fan, thi also has to interact with the time of day and if the light is on and if motion is detected. So if you have a system you can start writing code. If you don’t you need a ton of notes before you even start.
Haha, I have that test case running; i.e. turning on/off a fan based on the humidity in the room so the wife’s not after me for forgetting to turn on the fan after a shower 
The question on using the entity_ID was using the ‘entity_ID’ as opposed to the ‘Name’ and hence the need to make the ‘entity_ID’ meaningful but I think that’s clear now.
Thanks again. Got some planning to do
Okay, so you are ready to write your code for bath1
When you are finished and assuming all your devices have bath1 in their entity ids then just by copying the code replacing bath1 with bath2 you have just written bath2’s code as well.
You get the general idea.
I am a software engineer and as a studied software engineer I’ll tell you: don’t name the entity-id after the location where you use the device/sensor. Unless it is a wall plug which cannot be moved. If you have many sensors, you will find for example that the temperature sensor from ACME does not work very well in the bathroom, but for the fridge it is excellent. so you change the location.
For an entity-id it is necessary to be a unique id which identifies the device, and to make it easy for humans I suggest to use the manufacturers name and some numbering, for example the last digits from the MAC address. This way you can always keep track of your sensors.
I totally disagree.
If Acme temp sensor does not work in your bathroom then you will need to do some research for a suitable replacement. Ask on the forum, get a recommendation etc.
Then you need to order it and wait for it to arrive.
This all takes time.
Meanwhile you can change the friendly name and entity id of the device and (say) 3 sensors ( (say) 7 in total ) in about 2 mins, what is the big deal ?
Edit: the new kit arrives, you add it to HA, you change the names back to what they ‘should’ be in your automation (so parking the old sensor, or placing it somewhere else, then doing the ‘new’ rename) and you are up and running in 10 minutes tops.
As Mutt mentioned earlier in this thread we are our own system architects. It’s great to bounce around ideas from various experiences and exchange notes but in the end we come back to our own installs and implement what we feel most equipped with.
I wanted to understand the relationship between entity_IDs and friendly names and got a great understanding from the info shared here. I’ll leave it at that.
This is exactly the reason why I would like to have an sensor alias name for using in the automations and scripts.
Like with craftsmen and cooks, there are principles of good software design and system architecture, which have been evolved in the last 50 years of IT, and which reflect the experience and knowledge of software developers and architects.
Many of these principles cannot be justified in just one sentence.
I still don’t get it.
I don’t think your experience in software is in the fields of industrial design, it sounds more commercial/web based.
The time taken to update your ‘Alias’ would be exactly the same as we currently have.
We need a ‘slug’ to be used in code which has to fit in with the current processing engine (entity id)
And we need a ‘Name’ that can be used in the frontend - Which can be what you like.
You seem to be adding this extra layer, that does not achieve anything. it does not ease naming, it does not ease coding, it takes the same amout of time to update (even assuming that you can remember that “sensor.centralite_3305_s_11097abc_1_1026” is the temperature sensor you put in your main bathroom (probably not, you’d need to look for it in your notes - hence moving further away from self documenting code)
And yet consumimg extra resources (memory for the ‘store’, time to process item ‘X’ actually refers to sensor ‘Y’ which causes ‘Z’ to be turned ‘on’ which actually means switch ‘W’ or whatever. etc.)
Remember that simple is often best and we have to ensure that our memory/processing overheads fit within the capabilities of the base level hardware platforms we are targetting (RPi 3).
Steve Jobs famously threw out a BIOS set because it took ‘too long’ to boot. The result : - Saving 6 seconds per ‘boot’ saved apple users (across their then current userbase) 3.4 years per actual year.
The “official” sensor entity_id will be “sensor.centralite_3305_s_11097abc_1_1026”.
In the config, there will be an alias defined as “sensor.cl_temp_bed1” so in the code I can use “sensor.cl_temp_bed1”