As you want 
but since it’s a false friend and it has a different meaning in French it can be interpreted differently in the UI, I would have gone more for « localization » otherwise there’s also « situation » or « position » but ok for their jargon — since I don’t have Z-Wave I’m not going to act all prissy 
Can you give me a technical review?
What I’m particularly interested in is the choices of data format for external_id and name 
1 Like
So I left a few comments, including one specifically about the consistency between the device’s external_id and the features’ external_id… Nice work
Thanks for your feedback @AlexTrovato, everything is fixed (I left comments for some feedback)
I’ve rebuilt a Docker image that’s already ready:
gladysassistant/gladys:zwavejs-ui-integration
Open to any live feedback!
Much better for the setup, but on the other hand, I managed to create a device without any features 
Is that a problem in itself?
lol no 
For the code, it’s OK with me.
For the tests, I can’t go any further, as I don’t have the appropriate devices.
1 Like
Are you subtly trying to get some gear? 
4 Likes
Image installed, broker connected but I can’t test any further either.
If I have time during my vacation I’ll see if I can add my devices
1 Like
I continued my tests and found a few issues. Maybe you covered these points during the live, but I didn’t have time to fit 7.5 hours of video into my days. I’ll look during my vacation.
I was surprised not to have any messages saying that the devices are not yet supported.
So I looked at the scan and if we fix the command then we’ll need to specify somewhere that the prefix and the MQTT name that we configured in Z-wave JS UI must be the same as those used in the command.
In the scan you put:
this.publish('zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/api/getNodes/set', 'true');
Whereas in Zwave I put zwave2mqtt instead of zwave-js-ui and by chance my prefix is zwave
Once changed in the settings it’s OK — I have the list of all my devices (not supported)
Once the devices are detected, I see two problems. The first is that I can save even though they are not supported — it’s a small detail but I think it could be confusing.
The second is about the name — I have one device per room named Radiateur (5 in total) and I don’t know which is which. I could change the name in zwave-js-ui but I don’t find it logical since it controls a radiator.
In ZwaveJSUI they are differentiated by « location ».
Maybe display « location » then?
I’ll continue and I think that for adding devices we’ll need to modify things as well. I’ll send another message about that when I’ve looked into it more closely.
1 Like
Hello,
What particularly interests me are the data format choices regarding the external_id and the name
What is the intention of this external id?
I started integrating an additional device (a smart plug with a simple on/off button). I’m skeptical about not using the nodeId as a unique identifier decoupled from the
The external_id is the unique identifier that allows identifying a device/a feature using the « external » identifiers on the integration side. It allows mapping between our internal identifiers and the external identifier.
Indeed, in the case of a device with « control », the nodeID seems required. For sensors it’s the opposite, the location/name is mandatory and the nodeId is not provided… not very coherent but oh well, we’ll deal with it
So we need to be able to handle both cases: identifying a device via location/name only, and identifying a device via Nodeid only.
I think we could possibly go back to my initial proposal:
- external_id of the device with the nodeId
- external_id of the feature with the location+name
Ah, you’re right! We need to specify that in the interface. Thanks for the feedback
We could possibly do that, yes!
[quote=« pierre-gilles, post:52, topic:8573 »]
Indeed, in the case of a device with « control », the nodeID seems required. For sensors it’s the opposite,
I received the device, I was able to run a test, and I confirm that the node_value_updated event is indeed sent:
Topic: zwave/_EVENTS/ZWAVE_GATEWAY-zwave-js-ui/node/node_value_updatedQoS: 0
{
"data": [
{
"id": 4,
"inited": true,
"name": "Detecteur Ouverture",
"location": "Entree",
"status": 1,
"isControllerNode": false,
"interviewStage": 5,
"deviceClass": {
"basic": "Routing Slave",
"generic": "Notification Sensor",
"specific": "Notification Sensor",
"mandatorySupportedCCs": [],
"mandatoryControlCCs": []
},
"zwavePlusVersion": 1,
"ready": true,
"zwavePlusRoleType": 6,
"isListening": false,
"isFrequentListening": false,
"canSleep": true,
"isRouting": true,
"supportedDataRates": [
40000,
100000
],
"maxDataRate": 100000,
"supportsSecurity": false,
"isSecure": false,
"supportsBeaming": true,
"protocolVersion": 3,
"firmwareVersion": "3.2",
"manufacturerId": 271,
"manufacturer": "Fibargroup",
"productId": 4096,
"productDescription": "Fibaro Door Window Sensor 2",
"productType": 1794,
"productLabel": "FGDW002",
"deviceDatabaseUrl": "https://devices.zwave-js.io/?jumpTo=0x010f:0x0702:0x1000:3.2",
"keepAwake": false
},
{
"commandClassName": "Notification",
"commandClass": 113,
"property": "Access Control",
"propertyKey": "Door state",
"endpoint": 0,
"newValue": 23,
"prevValue": 22,
"propertyName": "Access Control",
"propertyKeyName": "Door state"
}
]
}
In my opinion, the logic of switching to node_value_updated is the right one. We avoid naming/location issues and everything is handled via the nodeId (we use the Z-Wave id property for the node and for the features)
I just updated the PR [ZWaveJS-UI] Manage Binary Switch by sescandell · Pull Request #1996 · GladysAssistant/Gladys · GitHub
State updates are now handled by Gladys for a Binary Switch (this should in principle open the door to other devices).
We have a new type of device that is not a sensor (a smart plug) and that works for updates (from the dashboard) or from a scene, for example reacting to a change of state of the door contact sensor.
[Update] (the forum won’t let me add more than 3 consecutive messages)
Small thought: do you see any drawback to removing any notion of « ui » from the term « zwavejs-ui » in the integration code and only referring to « zwavejs » ? (@pierre-gilles )
I think the current integration is on the right track and sufficiently clean to consider a migration to zwavejs without the MQTT part in the more or less near future (in any case, I really want to try it). That would further simplify the integration. A first integration functionally equivalent to the current one (i.e., without association handling in particular) seems achievable at first glance. That wouldn’t prevent having zwavejs-ui alongside for adding/removing devices outside of Gladys.
I can take care of that renaming and propose it in the changes associated with the current PR. Once this PR is closed, I can continue to propose developments (zwavejs migration, integration of new devices).
We’re completely at the level of minor details on this point, I admit, but from a perspective where we dispense with zwavejs-ui for a direct zwavejs integration, it would be « a shame » to keep carrying that suffix.
1 Like
Indeed I hadn’t noticed, but everything is configurable in Z-Wave JS UI.
If we switch to this configuration:
I receive on:
zwave/capteur-ouverture/notification/endpoint_0/Access_Control/Door_state_simple
{
"id": "2-113-0-Access Control-Door state (simple)",
"nodeId": 2,
"toUpdate": false,
"commandClass": 113,
"commandClassName": "Notification",
"endpoint": 0,
"property": "Access Control",
"propertyName": "Access Control",
"propertyKey": "Door state (simple)",
"propertyKeyName": "Door state (simple)",
"type": "number",
"readable": true,
"writeable": false,
"label": "Door state (simple)",
"ccSpecific": { "notificationType": 6 },
"stateless": false,
"commandClassVersion": 5,
"min": 0,
"max": 255,
"list": true,
"states": [
{ "text": "Window/door is open", "value": 22 },
{ "text": "Window/door is closed", "value": 23 }
],
"value": 22,
"lastUpdate": 1704966002274,
"nodeName": "capteur-ouverture",
"nodeLocation": "salon"
}
With the nodeId!
Which saves us from using the location and the name.
Not a big fan of raw Z-Wave events. The whole added value of Z-Wave JS UI is precisely using their transformed events that are ready to use.
I prefer the option I showed above with the NodeId
Let’s stay as it currently is. It’s an integration with zwavejs-ui
As for integration with « pure » zwavejs, I’m becoming less and less in favor. Zwave-js-ui is growing day by day and allows doing things that we’ll probably never do in Gladys. No need to reinvent the wheel
For months/years many users like you have promised the moon about this integration on this forum, and I think we need to be pragmatic.
My goal is for this integration to be live as soon as possible.
I will make the change on the nodeId but that will be the only change I will make, then the current integration will go to production as-is
pragmatism pragmatism pragmatism!!
However, on that one I’m totally open to help Thanks for offering!!
I’ve already made a PR on your PR where I take all that into account and much more. Relying on the node_value_updated event seems more coherent. It’s tested and validated on real devices.
In this mode, zwavejs has indeed formatted everything and it’s similar to what’s done on the « per device » events. It seems more coherent and just as pragmatic to me.
Le lien de la PR au cas où tu ne l’aurais pas vu avec d’autres évolutions : [ZWave] Manage Binary Switch by sescandell · Pull Request #1996 · GladysAssistant/Gladys (github.com)
For the record, when I tell you I can make progress on the subject, I’m not just saying it (proof being this PR where I’m pushing improvements for this integration). And I think saying zwavejs rather than zwavejs-ui doesn’t put anything at risk.
On the naming issue, I’m open to discussing how that actually changes things from a user point of view? We’re operating on a hypothesis, agreed. I’m not saying Gladys should do everything zwavejs-ui does. In any case today or tomorrow with zwavejs in Gladys, for advanced node management you go through zwavejs-ui. Having zwavejs in Gladys doesn’t prevent that. The hypothetical pitch is indeed « simplify the integration into Gladys » (and not necessarily have another MQTT and another Node project running alongside). But to date that’s not really the issue.
Hello everyone!
I’ve made some fixes to the PR (pull request) following the various feedback:
- Clear explanations regarding the MQTT prefix used and the different settings required in Z-Wave JS UI for the integration to work.
- Use of nodeId to uniquely identify a device instead of location/name.
- Added a message to specify that this integration is in alpha and that only one device is supported
The current integration looks like this:
The updated PR (pull request): Z-Wave JS UI integration by Pierre-Gilles · Pull Request #1982 · GladysAssistant/Gladys · GitHub
I also worked on the documentation, to test in demo here:
- Documentation FR: Intégrez vos appareils Z-Wave grâce à Z-Wave JS UI | Gladys Assistant
- Documentation EN: Integrate your Z-Wave devices with Z-Wave JS UI | Gladys Assistant
The schedule
I promised it: the bet was a minimal Z-Wave JS UI integration managing a single sensor in one day, and the bet is met!
The integration will be merged tomorrow during the day and deployed on Monday in Gladys Assistant v4.35.0.
I’d appreciate your feedback if you have any before then
@Sescandell I saw your PR (pull request) and it’s great work! I think we misunderstood each other about the notion of pragmatism — I was referring to your wish to move to pure Z-Wave JS. For the rest (your current PR, etc.), I’m 100% aligned with you and would welcome your help to move forward afterwards to add other compatibilities!
2 Likes
Just a quick note on the doc for now, the links are not working :
Wouldn’t the link rather be https://zwave-js