@morningz I am using the Device Name as the Unique name for the device as the * on the Device sheet states the Device Name and Device Network Id have to be unique.
And abbreviated because the Device Name is what I print on a Dymo machine to stick on the device.
(particularly as I am renting and that means I will be moving and sorting it out without labels would be tough )
@ritchierich Thank you for raising this point - EXACTLY why I raised the question - to trap unforeseen issues with taxonomy. You raise a good point I have not got into with HE yet - Which attribute does Echo use the Device Name or Device Label use - Because I am Ok if it is Device Label - because realistically I would expect to create a virtual Device and expose that to Echo, 99% of the time we only use scenes or 'Alexa turn on the printer' 'Alexa Goodnight' 'Alexa Turn on Freshen Up' 'Alexa Turn on Away Mode' etc - very rare to expose a device more an action.
@Rxich an interesting point here. This is a draw back HE, other HAs I have played with have allowed users to group devices together, In my case it was generally by room/zone but I did gather specific functionalities together as a group such as Heating (all things relating to heating) another one for Audio Visual devices, Speakers, Power usage Monitors etc.
Don't have that optioning HE so it makes the naming convention all the more important.
As long as I am consistent in naming - I can use the Device Search to create an ad hoc Group of say TRVs or Controllers so I think I am ok.
@JB_TX I like the way you do it but tough to print out a label that will fit on some of the devices
Something I really like in HE is quite a few of the Devices have a Date of last battery change built into them - really helpful.
icon = single character for "class" of object
"╚" for Lutron, "~" for Zigbee,
"⌐" for locks, "■" for virtuals, etc.
Room = room/area containing device, always capitalized
Location = *optional* location of device, if necessary
i.e., "N" or "S" for identical ceiling lights
object = description of object
"light", "chandelier", "switch", "sensor", etc.
Examples:
╚ Dining Room chandelier
~ Basement E wall sensor
⌐ Side Door lock
■ VACATION
The key is consistency - looking at an object in the field, you should be able to know exactly what the object will be named on your hub(s).
I'll echo the consistency theme, but also add that if you're using a voice assistant the command you use to interact doesn't necessarily need to contain the same name; i.e. if I have a device called Front Room Zigbee Outlet 46 Left the Alexa command could be as simple as Turn on the Blue Lamp - the routine needs the exact reference, but the UI doesn't always (there are ways of overriding this for dashboards using CSS too)
Label if specified otherwise name. Once you link them to Alexa, HomeKit, etc you should be able to rename them there too if that helps. But at least with Alexa you don’t have to say exact name as she usually figures it out.
Just one hint that makes things in HE easier. I’m using Emoji’s at the beginning of device name to identify the device type.
For Rule I use the same principal, based on what is the Rule about.
By this approach, you have device types group together and you can easily find them. As a side benefit, you have those emoji visible in dashboard tiles. Also notifications can be enhanced by emoji to see what is happening without need of reading.
Do the emojis interfere with voice command with a Google Home?
I have learned that when creating scenes and groups, I can put a [S] or [G] in front of it and still use voice command with Google Home. It is able to understand to ignore the bracket letter. So I'm also adding LED lighting scenes, but start those with an [L]. This way from a list sorting, they are together.
So wondering, if Google ignores the bracket letters, I guess it also ignores the emoji?
I guess I need to look up how I'd add emojis to my names now...
@igor.lehotan thank you. When I use the [L] and [G] it does not read those back. If I have a group of [G] Kitchen lights, and tell google to turn on the kitchen lights, it says, "turning on kitchen lights".
For the emoji, I wonder if brackets would make Google Home ignore saying it if it had a bracket around it?
I might play around by expanding the [G] into a word [Group] and see if that changes the behavior, but I like that Google "ignores" what is in the bracket.
Subtopic - The consequences of changing those names & labels later
Can one expect FULL propagation of all name/label changes through all apps & rules after being changed/updated later after the initial configuration.
I just went through some two step with one Sonos device shared on the same LAN by two hubs where I went in and changed the respective names/labels on the respective hubs to make them MORE specific to the hub doing the talking through the Sonos ( I HAD named everything exactly the same initially, then decided I might not want ANY naming/labeling the same between hubs on a shared LAN as and when I start to mesh devices or use Hub Connect etc).
I had something come up that made me wonder if changing the names/labels later on was detrimental to any Apps & Rules set up with the initial names. Not worth elaborating here because I didn't take notes on what all I had done that might have been material to the issue.
But in a generic sense, I thought I'd raise this question....IS THERE A DANGER in changing this stuff way later after it's been referred to in rules and other apps????
Rules and apps typically reference a device via its database ID not it’s name. This is the ID you see in the URL such as device/edit/258. Integrations typically use the device network ID set within the device. With Sonos specifically you should find the device network ID set to the hex value of its IP address.
I have renamed devices many times and even on meshed devices and haven’t run into any issues.
So, does the often discussed "database corruption" exhibit the scrambling of some, or all, of those IDs ...or even an "old name" being presented as a part of the symptom?
No because the device ID is basically the row ID in the database - think an excel spreadsheet with the row numbers on the left side. That won't change but database corruption could affect a row causing issues but restoring the database will replace it back.
Let's say I have ZigBee device "A" used in Rules and the device itself is giving me problems...i.e. needs to be retired.
Can I pair a new device "B" , NOT the same exact model but same function (contact using ZigBee Generic Contact Driver)
....then take battery out of device "A" to pull it from the mesh and STEAL it's Device Network ID and replace device "B's" Network ID with "A's" in order to get all Rules to just carry on
...since just replicating device "A's" name in/for device "B" is not going to achieve this due to the relationships previously established between device "A", it's Network ID, and the respective Rules.
So the ZigBee ID is not like a MAC Addr of a device? e.g. fixed and assigned at manufacturing? That actually gets assigned by the hub upon discovery????
Honestly cannot remember. I did this with a Zigbee motion sensor a while back and I recall either the device network ID or the Zigbee ID changing when I reset the device and repaired it. So pair the new device and collect those bits and then copy then into your old device, change the driver and save. Then remove the new device, reset device and pair again and it should realize it’s been paired before and then make sure you click configure once paired since it’s a different driver.
Leaving this here for future reference on the topic. ST but I'm sure it applies just the same:
""
When a “Works with SmartThings” ZigBee device is added to SmartThings, two unique identifiers are assigned to it during the pairing / joining process, which you can view in the list of Devices on your hub’s IDE webpage:
Zigbee Id - a 16 hexidecimal digit (8 byte) string that is unique only to that ZigBee device, assigned by its manufacturer
Device Network Id - a 4 hexidecimal digit (2 byte) string that uniquely identifies the ZigBee device on your hub’s network that is assigned by your SmartThings hub
""
A few days into my conversion from VeraPlus to Hubitat and glad I found this thread. In my experience, people understimate the importance of a good taxonomy, especially the re-work saved by starting with a good one.
Thanks @igor.lehotan for the emoji idea! @fegriffith didn't see it stated here how to add them. Maybe it's possible to do it directly if you know the unicode, but the easiest way I found was to first add the device from the web interface then rename it from a mobile (worked from android phone and apple ipad).
I use Alexa -- she speaks the emojis regardless of brackets For example, she calls device
outdoor plug
"light bulb outdoor plug". But I never hear this unless there is a problem, like device unresponsive, because my Alexa is in brief mode.
Enjoy this thread and the ideas people are sharing. Agree with avoiding abbreviations if possible.
That being said, anyone know if there is a documented character limit for names? Not really a big deal for my devices as much as variable names used in connectors for rules.
For example, she calls device
outdoor plug
