Yale Z-Wave Module 2 and USB Z Wave stick?

I wonder what was changed then…
thank you for sharing your template, using the first one would achieve what i’m looking for.

are you able to tell if the door was:
manually opened or locked
remotely (via HA) opened or locked

what information do you get from zwave_js_notification?

Not sure either. The original github issue got closed as resolved, but to be honest I can’t see any difference

I added it as it was supposed to contain more than just locked / unlocked, and to some extent it does, for example right now its value is “Manual lock operation”, but again not everything I want hence the template trigger sensor…

@phairplay in case you’re having another go: my zwave-js got updated to the latest version today (4.4.0) and since my conexis always ends up dead. Just reverted back to 4.3.1 and it works again…

1 Like

Hi phairPlay,

Since updating to Z-wave JS…

0.1.22

  • Bump Z-Wave JS Server to 1.6.0
  • Pin Z-Wave JS to 7.5.2

Everything seems back to normal with the my Conexis lock. Getting notified on all lock status.

Hopefully it’ll stick!

1 Like

Great
Could you tell me what notifications you are getting?

Im using a sensor template, so far tested and working (Yale app isn’t used).

Alarmtype 9 - jammed
Alarmtype 21 - locked manually
Alarmtype 22 - unlocked manually
Alarmtype 24 - locked by zwave
Alarmtype 25 - unlocked by zwave

Alarmtype 144 - unlocked by RFID…

144 For tag level recognition has always worked for me prior update.
Ill let you you know how I get on today and also whether a HA reboot does any harm. :grimacing:

1 Like

OK…

Being monitoring throughout the day, it was fine until a HA reboot - then notifications stopped. Soon later a new update arrived…

0.1.23

  • Bump Z-Wave JS Server to 1.7.0
  • Pin Z-Wave JS to 7.6.0

Tried a HA reboot then a Z-wave JS container restart after the above update and notifications were fine!! Hurrah!

All seems good except the ‘unlocked by z-wave’ and ‘locked by z-wave’ which seem intermittent.
If the z-wave call is done twice in a row, the notification comes through fine.

Battery levels don’t respond which was expected, I’m relying on a daily entity update to get feedback on that.

1 Like

I really appreciate you coming back on this. :+1:

Interesting that the z-wave unlock is not working fully.

Is everything okay in regards to alarmlevel.

1 Like

Your welcome. I understand the frustration. Its a useful feature that SHOULD just work. :slight_smile:

I have a cleaner that comes and goes and so lock status is critical.

Must be a timing issue with Z-wave status…I’m no developer so who knows. But re issuing the service call after a second makes status work

Yes, alarmLevel works perfectly. Just double checked. :+1:

1 Like

So I am I right in thinking that with ZWaveJS that its no longer possible to access the “lock_status” attribute?

Sure you can. Depends on what data you’re after, the lock attributes are different with zwave-js.
The lock status is only locked or unlocked with zwavejs, but you get additional sensors that you can use to identify the lock’s detailed status, e.g. homeassistant/Yale.yaml at a7d64d08a185bbce824458475dc0cdced26f3aa7 · lolouk44/homeassistant · GitHub
You just need to make sure that you’ve set the 2 additional sensors to be enabled in Settings > Integrations as (unless it’s changed) they’re disabled by default:

Hey all. Ive just added the wave module to my Yale Keyfree Connected. Using Z Wave JS - first thing I’ve noticed is that when I send the unlock command, the lock receives it three times and it unlocks 3 times in quick succession. Anyone else seen this? Also the other sensors, alarm types show unknown, and battery shows 0% - is this a known issue?

I don’t know about the Yale Keyfree Connected, but with Conexis L1 I have to manually pull a refresh from the Zwave-JS Server:

  - service: zwave_js.refresh_value
    data:
      entity_id: sensor.yale_conexis_l1_battery_level
      refresh_all_values: true
1 Like

Hi,

Thanks for the reply, would you mind being more specific about where I would use that?

Thanks

In any automation. I’m using mine as part of my nightly tasks at 4AM and goes under the actions block

Ah looks like this may be the issue I am seeing that unlock by zwave and locked by zwave which seems intermittent

Yes, not ideal. Issuing the service call in a automation twice seems to guarantee a Zwave lock status response.
Other alarmTypes and alarmLevels are fine for me as it stands.

These are the alarm types I’ve noticed for myself:

AlarmType 9 - Jammed
AlarmType 19 - Unlocked by keypad (AlarmLevel corresponds to user slot - 01 to 30 for my lock)
AlarmType 21 - Locked manually
AlarmType 22 - Unlocked manually
AlarmType 24 - Locked by Z-Wave
AlarmType 25 - Unlocked by Z-Wave
AlarmType 27 - Auto relock
AlarmType 33 - User code deleted
AlarmType 112 - User code changed
AlarmType 113 - Duplicate user code
AlarmTyoe 145 - Unlocked by fingerprint (AlarmLevel corresponds to user slot 01 to 10 for my lock)
AlarmType 162 - Unlock code attempted outside of schedule
AlarmType 167 - Battery low
AlarmType 168 - Battery critical
AlarmType 169 - Battery too low to operate lock

Does anyone know what AlarmType 154 corresponds to? I get this every 3-4 hours, and I have no idea what it means. Is it some sort of sleep mode notification?

I have no idea sorry, not something I have noticed.

Are you using a Conexis L1 lock?

You could be right linking it to a sleep notif, 154 is not in my sensor script so wouldn’t of picked it up.

Yes it’s similar to the Conexis L1 (it’s using the Yale Z-Wave module 2 (SD-M1100) in an YDD424+ lock, which essentially works similarly to the Conexis L1). I’m wondering if it’s some sort of ping/wake up notification instead.