Enhance device meta data beyond name and location

[ahochsteger]

Currently it's possible to set a location and device name that can be used to derive data for different integrations (e.g. MQTT topics, Home Assistant discovery).
I think there's potential to do much more, esp. if you want to use it to drive automation.

Here's some food for thought to get the discussion started:

• Unique name or ID: Smart Home systems refer to a device using a unique name or ID that can be used for further automations (e.g. device name in Home Assistant).
• Descriptive title: This title can be used in UIs of z2m or Smart Home systems
• Unique location name or ID: Smart Home systems may identify locations (or areas) using a unique name or ID
• Channel name: Using switch_light or switch_fan instead of switch_1 and switch_2 would greatly improve the legibility of automations that refer to a certain channel. It also allows to decouple the exact channel number from automation rules - esp. if they may change.
• Description: A longer description that may be used to describe the purpose of the device or document certain device aspects.
• Custom metadata: Ability to define custom metadata that may be used e.g. in HASS discovery templates or MQTT topics

The current fields name and location already cover some of them but there's no clear semantic distinction and so one has to decide between the following ways:

• put the unique name there and suffer from non-human friendly device names in the UI of the smart home system
• put a human readable title there (and automatically derive the name from it), causing unwanted changes to internal device names if the UI title is changed

The same may apply to the location field.

Let's discuss what kind of metadata is needed and what use cases they are required for ...

[robertsLando]

I don't get the point of this, could you show me an example where this would be useful?

[robertsLando]

Currently all switches show up as power switch - no matter, if they control lights, fans or something else.
Being able to attach the type to individual switch channels would improve that as we could automatically use that in the generated discovery JSON.

This could be fixed by using the device class informations, btw atm @billiaz is supporting mqtt discovery, I'm not focused on that as now there is also hass with his zwavejs server implementation working on that side so it's not a priority.

About device names. AFAIK hass allows you to give entities a friendly name property, couldn't you just use that for all this stuff?

[ahochsteger]

About device names. AFAIK hass allows you to give entities a friendly name property, couldn't you just use that for all this stuff?

I could use the name in z2m for the friendly name but this affects everything (from MQTT topic names to device names) and in turn breaks everything if the friendly name changes.
Another problem is that - depending on the language you use - there may be characters in the friendly name that are not suitable for unique device names and may affect other systems that use this data.

Maybe I'm missing something but I wonder if nobody else has faced these issues?

[robertsLando]

@billiaz, @DanielWinks ?

[ahochsteger]

Of course I could keep it the way I currently do it (use name as unique internal device name) and manually set the friendly device name in Home Assistent but that defeats the purpose of auto-discovery and since I'm using it not only for Home Assistent but also for OpenHAB as well I'd have to manually change the friendly names multiple times in multiple systems that use the devices provided by z2m.

[robertsLando]

what about improve the entity template for this? Maybe by allowing to use a function