New Z-Wave JS binding released

Add-ons Bindings
21

Done: [zwavejs] Add Rollershutter channel to Z-Wave JS for multilevel switch (UP/DOWN/STOP/position control) · Issue #19066 · openhab/openhab-addons · GitHub
But I’m not sure about the logs. I have one (TRACE), but it’s huge. Do you need information like this:

RECV | {"type":"result","success":true,"result":{"state":{"driver":{"logConfig":{"enabled":true,"level":"debug","logToFile":true,"maxFiles":7,"filename":"d:\\Smart Home\\JWaveUI\\zwave-js-ui\\store\\logs\\zwavejs_%DATE%.log","forceConsole":false},"statisticsEnabled":false},"controller":{"type":1,"homeId":4117226365,"ownNodeId":1,"isUsingHomeIdFromOtherNetwork":true,"isSISPresent":false,"wasRealPrimary":true,"manufacturerId":134,"productType":1,"productId":90,"supportedFunctionTypes":[2,3,4,5,6,7,8,9,10,11,16,17,18,19,20,21,22,23,28,32,33,34,35,36,39,40,41,42,43,44,45,46,47,55,56,57,58,59,60,63,65,66,68,69,70,71,72,73,74,75,76,77,79,80,81,83,84,85,86,87,88,94,95,96,97,98,99,102,103,120,128,144,146,147,152,161,180,182,183,184,185,186,189,190,191,208,209,210,211,212,238,239],"sucNodeId":1,"supportsTimers":false,.....

22

Yes that seems to be the right one. Please also add the full log line to GitHub. If too large a link to a shared file is also perfect.

23

I switched over to zwavejs on both my sites this evening. Small issue on one site with the message file being above the maximum size, but once I found the advanced settings easy enough to fix.

I’m running zwavejs on the same machine as OH on a Pi 5, had some issues with it connecting/disconnecting if I used the 192.168.x.x address, once I changed it to localhost things were stable.

Thanks for your work on this!!

24 
I’m running zwavejs on the same machine as OH on a Pi 5, had some issues with it connecting/disconnecting if I used the 192.168.x.x address, once I changed it to localhost things were stable.

I just came across a hint by chance which could be the reason for this:

You may choose to limit websocket connections to only those coming from localhost for security reasons, though doing so may require you to alter your integration's configuration to use the localhost IP. To do so, change the port mapping to "127.0.0.1:3000:3000"

zwave-js documentation

26

Just wondering if there have been any updates regarding rollershutter support in the binding? No rush at all, just curious if there’s any news.

27

Not yet, I’m home again, but I spend a bit less time to openHAB these days due to the excellent weather. Won’t take long though.

2 Likes
28

I’m interested too. It’s weird now because my Somfy ZWave to RTS channels are Dimmer, while my Hunter Douglas channels are Rollershutter. Of course, it works as Dimmer, except for the lack of the ability to use STOP.

29

I have a question about locks…

I have 2 Allegion BE469ZP locks. The old Z-Wave binding had a “raw” channel. It’s not obvious if the new binding has that (OMG there are so many channels on these devices), or if ZWaveJS even exposes that through it’s interface.

Before I start looking into it, has anyone else run across this?

30

And I have one observation about the Aeotec Wallmote. It’s not a problem, it’s just that the device is modeled differently than with the old binding. The old binding had a single channel that accounted for all the buttons, whereas ZWaveJS has separate channels for each button. I actually prefer having one channel per button, however, it did require some rework to my rules.

31

Yeah, this was the biggest change for me too. I have a lot of aeotec and fibaro remotes for which this was true. In the end, I went the other way and kept all my rules the same and just linked all the new channels to a single item with a profile that then replicates the old button#.event payload.

32

I’m not aware of that raw channel. If it is not listed in the zwave js ui, it is also not exposed in zwavejs binding. What is it supposed to do?

your observation is right, only in a few cases the endpoints are aggregated. For a color channel and soon for a rollershutter.

For scenes/buttons it is not so obvious from binding perspective

33

Good idea!! If I had more than 1 device this would’ve been the way to go.

34

In the old binding it looks like the alarm_raw channel comes from the COMMAND_CLASS_ALARM version 8 command class. From the zwave binding DB…

alarm_raw
alarm_raw2108×1008 183 KB

Here are a couple examples:

{"notification":"ACCESS_CONTROL__MANUAL_LOCK","level":"1","type":"ACCESS_CONTROL","event":"1","status":"255"}

{"notification":"ACCESS_CONTROL__KEYPAD_LOCK","level":"0","type":"ACCESS_CONTROL","event":"5","status":"255"}

{"notification":"ACCESS_CONTROL__LOCK_JAMMED","level":"0","type":"ACCESS_CONTROL","event":"11","status":"255"}
35

For my Fibaro devices (FGD212 Dimmer 2, FGBS001 Universal Binary Sensor, FGR222 Roller Shutter 2) the Scene Activation Command Classes are missing which I often use (not an openHAB binding problem).

I opened an issue about that on ZUI which is unanswered since 4 weeks :joy:

36

I wasn’t around at the beginning, but the believe the alarm_raw channel (and alarm_number) were a way to simplify/ condense many possible notifications of the Alarm Class, particularly for locks, by returning a JSON string

        // Processing for special channel types
        if (channel.getUID().getId().equals("alarm_number")) {
            return new DecimalType(eventAlarm.getV1AlarmCode());
        }
        if (channel.getUID().getId().equals("alarm_raw")) {
            Map<String, Object> object = new HashMap<String, Object>();
            object.put("type", eventAlarm.getV1AlarmCode());
            object.put("value", eventAlarm.getValue());
            return new StringType(propertiesToJson(object));
        }

In text it is explained this way.

Provides the raw alarm status information as a string, including alarm type and level, in the following json format:

{"notification":"ACCESS__MANUAL_LOCK", "type":"ACCESS_CONTROL","event":"1","status":"255"}
{"notification":"ACCESS__MANUAL_UNLOCK", "type":"ACCESS_CONTROL","event":"2","status":"255"}
{"notification":"ACCESS__KEYPAD_LOCK", "code":"1", "type":"ACCESS_CONTROL","event":"5","status":"255"}
{"notification":"ACCESS__KEYPAD_UNLOCK","code":"1", "type":"ACCESS_CONTROL","event":"6","status":"255"}
{"notification":"ACCESS__LOCK_JAMMED", "type":"ACCESS_CONTROL","event":"11","status":"255"}
{"notification":"ACCESS__KEYPAD_LOCK", "type":"ACCESS_CONTROL","event":"5","status":"255"}
{"notification":"ACCESS_CONTROL__KEYPAD_TEMPORARILY_DISABLED", "type":"ACCESS_CONTROL","event":"16","status":"255"}
{"notification":"BURGLAR__TAMPER_UNKNOWN", "type":"BURGLAR","event":"2","status":"255"}
{"notification":"HOME_SECURITY__INTRUSION_UNKNOWN", "type":"BURGLAR","event":"2","status":"255"}
{"notification":"POWER__REPLACE_BATTERY_SOON", "type":"POWER_MANAGEMENT","event":"10","status":"255"}
{"notification":"POWER_MANAGEMENT__REPLACE_BATTERY_SOON", "type":"POWER_MANAGEMENT","event":"10","status":"255"}

Also, I don’t have ZW lock, so don’t know how zw-js is handling.

37

Ah, I see, so the content of the alarm_raw channel is something that is fabricated by the zwave binding. I wonder if a zwavejs channel (or channels) contains effectively the same information.

38

That would be my bet too, but I didn’t want to speculate. If I did speculate, I think the HA design is to have zwave-js websocket output at the “lowest” zwave level and use python/yaml overlays to summarize for the user. Edit: you could check your channels to see if there is something like your raw outputs.

I did also look to see how the OH HA configs were handling locks and it appears they include a json channel option.

39

I couldn’t find your github issue, but it might be a quick fix. Scene activation is CC 43 and I think the binding code starts processing at CC 44. I picked this out of the BaseMetadata class

    private static final List<Integer> COMMAND_CLASSES_ADVANCED = List.of(44, 117);
40

First a discussion has to be opened, a plain user can’t open an issue directly :joy:

I tried to add the Scene Activation class through a custom device file but was not successful.

Thx for having a look, very much appreciated.

Edit: just to make sure: I am pretty sure it is not a zwave js binding problem, it is a zui problem …

41

Ok, could be. Only comment is the scene commands are fleeting. They show up and then disappear. I do have one on another device (ZEN15). (from Mqtt)

scene activation 2025-08-16 105522

And this same info did appear in the Zwave-js binding “store dump” when I was testing earlier this year. I’m not running the new binding right now, but when I get a chance, I can test to see, but it might not be relevant to your devices. You could fire up MQTT in parallel and see if the topic appears there to sort out where the issue is.

{"endpoint":0,"commandClass":43,"commandClassName":"Scene Activation","property":"sceneId","propertyName":"sceneId","ccVersion":1,"metadata":{"type":"number","readable":true,"writeable":true,"label":"Scene ID","valueChangeOptions":["transitionDuration"],"min":1,"max":255,"stateful":false,"secret":false}},{"endpoint":0,"commandClass":43,"commandClassName":"Scene Activation","property":"dimmingDuration","propertyName":"dimmingDuration","ccVersion":1,"metadata":{"type":"duration","readable":true,"writeable":true,"label":"Dimming duration","stateful":true,"secret":false}}