Let's start talking about the new Z-wave JS integration

@petro

I put the logging to debugging, and think I see why there is a delay when turning on (vs instantaneous state change when turning off).

Turning off I see two lines from CNTRLR, one almost immediately (in middle of the debug) and again towards the end, about 5 seconds later:

11:12:56.101 SERIAL » 0x010a001303032601002519fd (12 bytes)
11:12:56.105 DRIVER » [Node 003] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 25
└─[MultilevelSwitchCCSet]
target value: 0
11:12:56.110 SERIAL « [ACK] (0x06)
11:12:56.114 SERIAL « 0x0104011301e8 (6 bytes)
11:12:56.116 SERIAL » [ACK] (0x06)
11:12:56.118 DRIVER « [RES] [SendData]
was sent: true
11:12:56.129 SERIAL « 0x010500131900f0 (7 bytes)
11:12:56.131 SERIAL » [ACK] (0x06)
11:12:56.133 DRIVER « [REQ] [SendData]
callback id: 25
transmit status: OK
11:12:56.145 CNTRLR [Node 003] [~] [Multilevel Switch] currentValue: 99 => 0 [Endpoint 0]
2021-02-08 11:12:56.147 INFO ZWAVE: Node 3: value updated: 38-0-currentValue 99 => 0
11:13:01.163 SERIAL » 0x0109001303022602251aff (11 bytes)
11:13:01.167 DRIVER » [Node 003] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 26
└─[MultilevelSwitchCCGet]
11:13:01.173 SERIAL « [ACK] (0x06)
11:13:01.177 SERIAL « 0x0104011301e8 (6 bytes)
11:13:01.178 SERIAL » [ACK] (0x06)
11:13:01.180 DRIVER « [RES] [SendData]
was sent: true
11:13:01.192 SERIAL « 0x010500131a00f3 (7 bytes)
11:13:01.195 SERIAL » [ACK] (0x06)
11:13:01.196 DRIVER « [REQ] [SendData]
callback id: 26
transmit status: OK
11:13:01.202 SERIAL « 0x01090004000303260300d7 (11 bytes)
11:13:01.204 CNTRLR [Node 003] [~] [Multilevel Switch] currentValue: 0 => 0 [Endpoint 0]
2021-02-08 11:13:01.205 INFO ZWAVE: Node 3: value updated: 38-0-currentValue 0 => 0
11:13:01.207 SERIAL » [ACK] (0x06)
11:13:01.209 DRIVER « [Node 003] [REQ] [ApplicationCommand]
└─[MultilevelSwitchCCReport]
current value: 0

But turning on, only see the one at the end, which happens about 4-5 seconds after initially turning off the switch:

11:13:37.088 SERIAL » 0x010a001303032601ff251b00 (12 bytes)
11:13:37.093 DRIVER » [Node 003] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 27
└─[MultilevelSwitchCCSet]
target value: 255
11:13:37.097 SERIAL « [ACK] (0x06)
11:13:37.101 SERIAL « 0x0104011301e8 (6 bytes)
11:13:37.103 SERIAL » [ACK] (0x06)
11:13:37.104 DRIVER « [RES] [SendData]
was sent: true
11:13:37.116 SERIAL « 0x010500131b00f2 (7 bytes)
11:13:37.118 SERIAL » [ACK] (0x06)
11:13:37.120 DRIVER « [REQ] [SendData]
callback id: 27
transmit status: OK
11:13:42.142 SERIAL » 0x0109001303022602251cf9 (11 bytes)
11:13:42.145 DRIVER » [Node 003] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 28
└─[MultilevelSwitchCCGet]
11:13:42.150 SERIAL « [ACK] (0x06)
11:13:42.153 SERIAL « 0x0104011301e8 (6 bytes)
11:13:42.154 SERIAL » [ACK] (0x06)
11:13:42.156 DRIVER « [RES] [SendData]
was sent: true
11:13:42.168 SERIAL « 0x010500131c00f5 (7 bytes)
11:13:42.169 SERIAL » [ACK] (0x06)
11:13:42.171 DRIVER « [REQ] [SendData]
callback id: 28
transmit status: OK
11:13:42.183 SERIAL « 0x01090004000303260363b4 (11 bytes)
11:13:42.185 CNTRLR [Node 003] [~] [Multilevel Switch] currentValue: 0 => 99 [Endpoint 0]
2021-02-08 11:13:42.186 INFO ZWAVE: Node 3: value updated: 38-0-currentValue 0 => 99
11:13:42.187 SERIAL » [ACK] (0x06)
11:13:42.189 DRIVER « [Node 003] [REQ] [ApplicationCommand]
└─[MultilevelSwitchCCReport]
current value: 99

Not sure if this is the switch itself that is causing the delay, or something in the code.

I have a real big delay when pushing more then one of my roller shutters up or down. the first does it instantly, but the other 2 only react with a delay of 10 seconds each.
The order in which I start doesn’t matter and with the old OZW-Beta integration these problems did not arise

I switched to the new integration and it looks promising. Have some Fibaro Shutter Controllers v2. When I go in the control panel in ZwaveJS to mqtt I can see a tilt position, I also can adjust it there. Unfortunately its not exposed to HA. Also no luck with the shutter tilt command.

Any idea ?

It took a few days to get things fully working, but everything is way faster for me now. For example, I have a few Innovelli Illumin bulbs I got on clearance awhile back for the kid’s rooms. In the past, they always responded very slow. I just thought it was the bulbs. Now, they operate instantly. I’ve noticed better response in my garage’s devices as well after I got the door lock re-added and interviewed properly.

1 Like

Sensative strips, anyone?
I have several sensative door/window strips. They worked well under the legacy zwave integration, but not so under zwavejs. In zwavejs2mqtt they look fine, and the binary sensor shows true/false as it’s supposed to. In the zwave js integration, only the battery sensors are available.
image
I tried to exclude/include without improvement (that didn’t surprise me, since the problem seems to be in the integration part.)

i have one strip and it working fine.
But I have to exclude first and include again to get all entities… I think it was a problem with the sleeping device.

and 2 or 3 entities where disabled in HA, I have enabled them and all was fine

seems not: Sensative strips binary sensor isn't available in HA · Issue #46277 · home-assistant/core · GitHub Integration fully recognizes the sensitive strips

I tried to enable the Strips-MaZw: Access control device. It’s always OFF. So I guess it’s actually unavailable too.

99 is the max for multilevel switches…

I dont get it, these developers do an update change the configuration and the inputs and they do not document it. HA should enforce these folks to comply and update documents before being approved to update…DEVOPS 101

What are you talking about that’s not documented?

Here’s the official documentation for zwave_js.

1 Like

I see something for the GD00Z-7 but not seeing GD00Z-4, wondering if anyone knows what/where exactly a pull request would need to be made. I see this node-zwave-js/packages/config/config/devices/0x014f/gd00z-7.json at 939af5570dcbc8263e8b926cb2c90ac4635e16c2 · zwave-js/node-zwave-js · GitHub but I’m not even sure if that’s the right place to get the other model added or if there is a different homeassistant repo that needs something. Hopefully someone knows more about it and has the desire to get it added.

1 Like

Yeah mine is the NGD00Z-4.

Looks like still on the master list to import: :loudspeaker: Announcement: About supporting new device configuration files · Issue #1600 · zwave-js/node-zwave-js (github.com)

1 Like

Missed that announcement, cool thank you!

Would you mind sharing the template yaml for your config or link me to where I might find?

Strange but good to know. Thanks for info. Thankfully the cover services were fixed in the latest release.

Sure. These are all template binary_sensors.

  - platform: template
    sensors:

#Downstairs Smoke - Z Wave
      smoke_downstairs:
        value_template: >-
          {%- if is_state("sensor.smoke_downstairs_alarm_type", "1") 
              and is_state("sensor.smoke_downstairs_alarm_level", "255") -%}
          true
          {%- else -%}
          false
          {%- endif %}
        device_class: smoke
        friendly_name: 'Downstairs'
        delay_off:
          seconds: 10

#Downstairs CO - Z Wave
      co_downstairs:
        value_template: >-
          {%- if is_state("sensor.smoke_downstairs_alarm_type", "2") 
              and is_state("sensor.smoke_downstairs_alarm_level", "255") -%}
          true
          {%- else -%}
          false
          {%- endif %}
        device_class: gas
        friendly_name: 'Downstairs'
        delay_off:
          seconds: 10

#Downstairs Smoke Test - Z Wave
      smoke_downstairs_test:
        value_template: >-
          {%- if is_state("sensor.smoke_downstairs_alarm_type", "12") 
              and is_state("sensor.smoke_downstairs_alarm_level", "255") -%}
          true
          {%- else -%}
          false
          {%- endif %}
        device_class: smoke
        friendly_name: 'Downstairs'
        delay_off:
          seconds: 10

For reference, I usually see alarm_type = 13 and alarm_level = 255 on these units when nothing is going on.

So far I have only done a test alarm on 1 of 4 of my units and it did trigger OK based on this code. I have, in the past with on OZW, tested the smoke pickup by burning some paper near one of these. I have never seen a CO condition come in (which is a good thing).

2 Likes

so after having updated to the latest version of the ZwaveJS integration, several extra sensors are discovered per already registered (and renamed) devices. However, the newly created sensors dont follow the naming of the parent device, but return to the original naming scheme.

Would this be a bug of the new integration? I understand where this is coming from, being the hardware device not having a name and the name really being a Home Assistant thing. But, since this is created within the Home Assistant environment and the core ZwaveJS integration And add-on, I would have expected the new devices to get the HA naming scheme?

Yeah those sensors aren’t working just yet. There are several locktypes in the repo that are pending import so your lock type might be hanging out in there like mine is. I have a Yale lock and while my sensors are showing that they’re now alive they don’t report anything…yet

Any tricks to getting zwave-js to recognize the zcombo? I tried excluding and re-including and the device adds but nothing is pulled in. Doesn’t show the manufacture or anything.