It would be very useful if one could specify an alias name for a sensor in the customize: section.
This way if you have a sensor.centralite_3305_s_11097abc_1_1026 you could give an alias name sensor.temperature_inside. if you write values to the influx-db, you would only use the alias name. If some day you change the physical sensor, you just give the alias name to the new sensor.
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. This means that all sensors must keep their name, but temperature_inside switches from sensor1 to sensor2.
I have a sensor.centralite_3305_s_11097abc_1_1026 and want an alias name sensor.temp_outside.
All automations, graphs, influxdb use the alias name āsensor.temp_outsideā. If the sensor gets exchanged, the new sensor gets the old alias. I donāt want to change the entity names because they are unique and contain the MAC of the sensor. Changing the entity names of zigbee sensors is a bad idea.
(the friendly name is of no use of course because it cannot be used in automations)
You entity names will also be unique afterwards, you cant have 2 entities with the same name. Why do you care whether the MAC address is in your sensor name?
I am facing the same issues and I also do not know how to solve this issue and the solution of OP seems to be very efficient. A file to rename/alias entity_id or devices.
Right now if I am correct this could be achieved by overriding the entity_id or devices within lovelace. This is storing the result in one of the .storage folder.
Two issue with this:
before renaming the device, entity_id the graphs, influxdb, internal db ā¦ gets polluted by the -non renamed- name.
there is no visible summary of renamed entities, devices.
On top of this if this renaming capability is available on several integration, few integration cannot deal properly with renaming devices, entities.
So having a way to keep track of devices / entities aliasing would be a great way to clarify configuration and improve maintenance.
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:
The configuration.yaml has to be changed to use the new sensor ID
The data in InfluxDB becomes almost useless, because you now have two different names for the same device
It seems that there are sensors that change their IDs after a battery change: (Feature request Rfxtrx Sensor Alias)
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.
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 friendly name - what the system displays when showing your device, so you have a have a handle on what it is.
The entity_id - is actually the system name for it, in some ways this is more important as a) this needs to be unique (friendly names can be repeated, no idea why youād want to but thereās no prohibition) b) when writing your code (by hand or via gui) then you need to know which devices and where, doing what. Hence my argument against leaving it as sensor.centralite_3305_s_11097abc_1_1026 or whatever the system generated for it.
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.
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.