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”
This is a software forum. Starting to argue against a person (ad hominem) is inappropriate and inacceptable. Don’t do this any more.
This is not directed at YOU per se, so I’m not sure you’ve used the term correctly.
But simply saying that industrial software is more aimed at performance with the resources available.
Commercial/Web software is often aimed at development speed and ease of deployment.
We have a moderator here that works (professionally) on coding for CNC machines, often the production benefits of turning out a ‘widget’ 0.3 seconds faster can mean the difference between 6000 units per day and (say) 6200 per day mutiplied by (say) 6 parallel machines can mean thousands of dollars per month.
This does nothing but add complexity and additional overhead to the entity registry and core systems.
In order to do what you are suggesting, an additional property would need to be added to the entity (alias), which would also need to be checked to ensure it is unique. Given that HA doesn’t use an actual database for devices, that means that those checks are done internally in the Python code on top of what is already being done to check that entity_id is also unique. Entitiy IDs provide a single source of truth for which device is actually being referred to in scripts, automations, and the REST and websocket APIs. There would be changes needed for all of the above as they are both written to check against entity_id and would have to be reworked to allow for an either-or situation (entity_id || alias).
Put simply, the entity registry is already complicated enough. There is little value that I can see by adding something that can already be accomplished by just renaming the entity_id to something more descriptive. I honestly do not see this making anyone’s life easier or saving any time. If nothing else, it increases complexity in an already complex system.
I came across this thread because I ran into a situation where I had to remove, then re-add my Synology DSM integration. I had spent some time editing each of the entity IDs since I did not like the defaults (e.g., sensor.synology_temperature_2 should be sensor.synology_temperature_disk1, etc.). However, when I added a new hard drive, the integration did not detect the addition of the new hard drive until I removed, then re-added, the integration. At that point, all of my renamed entities had reverted back to the defaults of (sensor.synology_temperature_2, etc.). This was quite frustrating. Having the ability to specify a list of aliases in customize.yaml would have solved this issue.
Technically I could create an alias using a template sensor, but it does not seem like the most efficient solution.
I just realised I created a similar feature request, so I up-voted this one. I find I move devices around - for example replace a smart plug with a smart powerboard. It’s a monumental pain finding and renaming all of the instances. And when my two daughters moved into separate rooms it was a nightmare. Especially around Xmas when all the lights get plugged into different smart plugs every year. If I could have an alias of light.rosie_lamp pointing to a physical entity, and only programming to the logical entity, changing it would be a breeze.
Want that. Just because stupid InfluxDB can not rename series. Which creates serious problems.
I have tried multiple solutions to this, all of varying complexity. The latest was “virtual” template switches, paired with an input text to map virtual to physical. The template then pulled the physical entity id from the input text. It works fine, but a pain to set up. And then I had an epiphany of sorts - an alias is the same as a group of one.
I’ve converted one room of logical devices over to groups, and it seems to work brilliantly. And a benefit for me is that everything in Rosie’s room can be found easily as ‘group.rosie_*’. Not to mention you can reload groups without restarting HA.
I have yet to test if Google Home can cope changing a switch to a light, for example. So if I replace a smart plug on a dumb light with a smart light, will Google ‘magically’ know that I can now set its colour and brightness. I suspect I will have to tell the GH app to check for new devices, but magic would be nice.
UPDATE: The Google Assistant integration only supports on/off for groups, which is a bummer. However, it looks like groups are a good option for aliases if (a) you don’t use GH or (b) you only care to turn things on or off with GH. I also found that in the GH app when checking for new devices, it found the group entities, but didn’t ask me to assign them to a home/room. Not sure why.
I’ve been stewing on this for a while now.
Opened a FR here for something similar as well
Here’s the scenario that I have run into that I suspect is much more plausible for people to run into. I have three dehumidifiers that only run in the warmer months, which are connected to smart plugs. During the holidays I reclaim the plugs for controlling my tree and outdoor decorations.
Each year I have to rename the smart plugs to indicate that they’re now controlling this or that, and then rename them back. It would be great if I could just keep the same alias attached to the single device, so that the basement dehumidifier becomes the Christmas Tree light and vice versa when I put it back to summer use.
Alternatively as the other software engineer rightly pointed out, there should be a unique device ID for each, so I when I grab plug #A3562, I know exactly which device it is when I repurpose it. But I also don’t want to reference it as device_A3562 in my scripts; I want my scripts to be intelligible by a human being. So when it’s dusk, turn on the tree lights, not turn on device_A3562.
I agree this is useful - especially when making products based on HA, where the only difference between each product is the entity-ID of components - the ‘code’ needs to be the same for each
I’m using the GROUP function for now … so for our product, we have 4 CCT lights …
create 5-light-groups …
group1 = L1 = entity “light.gu10_light_xyz”
group2 = L2 = entity “light.gu10_light_abc”
group3 = L3 = entity “light.gu10_light_uvw”
group4 = L4 = entity “light.gu10_light_lmn”
group5 = LG1 = light.L1, light.L2, light.L3, Light L4
then i use light.L1 etc throughout the code. For each product we just have to change the ‘groups’ file, everything else stays the same AND when a light fails, we just put the new entity-id in the groups file
Isn’t it so that the information about the light’s properties is lost in the group? If the light can change the color temperature or the color, is this still available in the group? Or if the light is able to do some effects?
