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

Created on 28 Jun 2019  Â·  12Comments  Â·  Source: OpenZWave/Zwave2Mqtt

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.

enhancement

All 12 comments

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

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.

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 notifications@github.com 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.

Please @soumya92 check last commit

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 :)

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 5a2337244f161ed8e1c5c119420a78f94787c42e. 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.

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

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

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"?

Will add a flag on gateway settings to use name/location when selecting valueID topics :)

@soumya92 Check last commit :) Remember to rebuild the project once you pull changes by run npm run build

That's exactly what I needed! Thanks :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

christoph-luebbe picture christoph-luebbe  Â·  8Comments

CaCu15 picture CaCu15  Â·  9Comments

lsilva171 picture lsilva171  Â·  6Comments

hostrup picture hostrup  Â·  4Comments

cyclops1982 picture cyclops1982  Â·  8Comments