@armills, thanks for your PR! By analyzing the history of the files in this pull request, we identified @turbokongen, @andrey-git and @balloob to be potential reviewers.

But discovery schema depends on labels. What happens of you change the "open" in cover to something else?

Even if this works it now requires users to rename or they will get unstable ids.

None of the primary values which determine the entity_ids match based on label. We're also probably better of using index to match instead of label anyway.

The requirement to change conflicting names exists in all platforms. No one wants to have the complicated entity_ids, but it was required because they previously didn't have this capability. The goal is to eliminate workarounds from zwave. I'd much rather expose more features of an underlying library, than keep extra workarounds in hass.

Also, with previous versions since we were forcing an entity_id decision, conflicts failed much worse since they both tried to update the same state. Now it's the same as a conflict in any other platform.

Where is the label stored?
If it is zwcfg_xxx.xml (or the device itself) then the change would affect all users of the device. I dislike that.

Maybe store the name as HA-intenal mapping?

@andrey-git the labels are extracted from the values of the node.

@andrey-git The label changes are stored in zwcfg.xml.

I don't quite follow what you mean by all users of the device, can you elaborate? If users are running another program that uses the zwave device that program can maintain its own zwcfg.xml if that's desired.

You are right, zwcfg is good.

@andrey-git Are you OK merging this portion? The old entity ID format will still be used, but this allows the values to be renamed. It looks like the Polymer PR got merged.

Cherry-picked for 0.46.1