-
-
Notifications
You must be signed in to change notification settings - Fork 97
Support user defined aliases instead of numeric IDs in ValueId gateway type #45
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 ***@***.***> 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.
|
…des name and location are stored in a JSON file and it will be imported/exported from the Control Panel UI instead of the zwcfg.xml file. This is back compatible as if there is no nodes.json configuration present the config is read from the existing xml file but the writeConfig button has been removed
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: 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 5a23372. I will check for this
|
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 |
Looks good. Thanks! 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 |
That's exactly what I needed! Thanks :) |
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
, wheresensor_binary
andsensor
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.The text was updated successfully, but these errors were encountered: