Support user defined aliases instead of numeric IDs in ValueId gateway type

[soumya92]

I see the argument against using names for the value classes (localisation, subject to change, etc.). However, it would be great if nodes could still be named. Those arguments do not apply to node names as they are specified manually in the UI.

This would help tremendously with moving/replacing z-wave devices.

Currently the options are /33/112/1/90, requiring downstream consumers to keep track of Node IDs, or /door5/sensor_binary/sensor, where sensor_binary and sensor are not guaranteed to be stable since they come from an external library. If we had a hybrid option like /door5/112/1/90, then consumers do not need to know which node ID to use, but they can still use constant IDs for the value.

[Fishwaldo]

The problem with using the node name or node locations fields is that it requires devices to support the NodeNaming CC - And less and less devices support that now days :(

So some external "mapping" needs to happen

[soumya92]

Oh I misunderstood how node names work then. I will change this to be a feature request for a "local" node ID to name mapping.

Basically, it would be great if the published topic had a user-defined constant in it, such that the constant could be moved to a different node if needed.

[robertsLando]

Yes this could be an interesting feature to add, I think I can do like with scenes, create a setting.json with node ids paired with a name and a location Daniel

…

On 28 Jun 2019, at 08:35, Soumya ***@***.***> wrote: Oh I misunderstood how node names work then. I will change this to be a feature request for a "local" node ID to name mapping. Basically, it would be great if the published topic had a user-defined constant in it, such that the constant could be moved to a different node if needed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[robertsLando]

Please @soumya92 check last commit

[soumya92]

Looks like a good start, although it seems that fresh node info from the stick overwrites any locally defined name and location. So when I set the Name and Location, the node changes to "Dead", and the Type and Product are empty. Shortly afterwards, the Type and Product are restored, but the Name and Location go back to empty.

And it might have broken the scenes tab: Error while calling api getScenes: Unknown API

Thanks for working on this, though! I need to spend more time to figure out how everything here works, otherwise I would definitely help out more :)

[robertsLando]

HI @soumya92, thanks for the isse about the scenes, it was caused by openzwave-shared updates, with OZW 16 scenes are deprecated so now I need to use just my custom implementation of scenes. Fixed with 5a23372. I will check for this

it seems that fresh node info from the stick overwrites any locally defined name and location. So when I set the Name and Location, the node changes to "Dead", and the Type and Product are empty. Shortly afterwards, the Type and Product are restored, but the Name and Location go back to empty.

[robertsLando]

Ok now everything should work fine, could you check last version please @soumya92

[robertsLando]

Just for reference:

Now node names and location are stored in a file named nodes.json and the UI buttons of Control Panel Import And Export are used now to import/export this json file

[soumya92]

Looks good. Thanks!
No more errors on scenes, and the location + name seems to persist even as the node changes states :)

For the MQTT topics, is there an option to use the user-defined location+name with the numeric values? Currently for a node with location "Floor1" and name "Door4", I see "TOPIC/Floor1/15/status=false". Is there a way to get "TOPIC/Floor1/Door4/status=false"?