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

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.

Patience… Hah. What I did was have the Zwave2Mqtt page up on that node and select re-interview, but dont hit go yet. Then, on the ZCOMBO, near your Z wave stick, pull the battery, press and hold the test button, reinsert batteries until it beeps once and release. Click enter for re-interview quickly. It should beep again in maybe 5ish seconds. If you’re lucky, itll pick it up the make/model in a minute or so. I had to re-try a few times for each of them, trying re-interview, then heal the next time on that node only. It just picked it up eventually. Dont be too quick at re-trying the re-interview/heal commands either. I think that jams up the network.

I did not exclude and re-add, only re-interview and heal.

2 Likes

For instance, when I updated today, it took the ability to manually put in the device path, which brought down my Z-wave network until I figured out that the device path was not absolute but logical and since that was changed it left it blank. I am usually good at stopping breaking changes and release notes. However, I did not catch this change…please show where this is at.

Thanks! I will continue trying. My poor dog is going crazy every time the thing beeps!

its wasn’t the fact they we’re working or not, I wondered why these new entities weren’t named according to the device name in HA

I just updated to zwavejs2mqtt 1.1.1 which obviously restarted my network. I have a couple battery-powered leak sensors, and i’m surprised that zwavejs2mqtt basically completely forgets everything about those leak sensors until they check in again, which is pretty infrequent. Is there some setting I can use to enable caching of the device info for battery powered devices so that they don’t just show as unavailable in HA until their check-in?

I think the startup process is similar as before, it just takes awhile to populate and shows up differently than were used to. I noticed the same thing the first time I restarted. It seemed like everything was gone. But even sleeping devices populated completely as Asleep and Restartfromcache after a few minutes. It was definitely unnerving when I spent hours getting things set up and it all went away. Just restarted again this morning and saw the same thing, but it all came back within 5 or so minutes.

It would be nice to have some kind of network ready event again. I cant find anything to indicate this with ZWaveJS

For those of you with locks, update your ZWaveJS (or ZWaveJS2MQTT) containers. They made an update that properly updates for manual lock/unlock operations. I have a Schlage BE468 and BE469. Both work great now.

2 Likes

Has anyone had luck with battery powered motion sensors? I get them to show up on the zwavejs2mqtt server and the nodes do habe a binary sensor and multi sensor there, but when I start the Zwave js integration in HA, then the nodes are found but no entities are created. Any help would be highly appreciated, because now I’m stuck with a setup where no motion sensors are working…

Check for disabled entities under that device in Home Assistant. Also, restart Home Assistant again. It seems its required to be restarted when you make some updates to Zwave now. Hopefully that will get fixed soon.

thanks, but doesn’t see to be happening for me. i restarted 3 hours ago, and my leak sensors still have no info: (

i also had to restart HA after restarting zwavejs2mqtt before any of the entities were available.

Still no love for my Yale yet. But I know its on the list :slight_smile: