Yale YMC420-W: fingerprint_unlock missing from action enum / HA MQTT event_types

[rubempoli]

What happened?

What happened?

Yale YMC420-W publishes fingerprint_unlock, but this value is not included in the exposed action enum / Home Assistant MQTT event_types.

This causes Home Assistant to log:
Invalid event type fingerprint_unlock for event.entrance_locker_action

Current exposed action values include:
unknown, lock, unlock, key_lock, key_unlock, auto_lock, manual_lock, manual_unlock, non_access_user_operational_event

But at least these valid actions appear to be missing:
fingerprint_unlock
rfid_unlock
password_unlock

The YMC420-W device page also does not list them under Action.

What did you expect to happen?

fingerprint_unlock, rfid_unlock and password_unlock should be included in the YMC420-W action enum / HA MQTT event_types.

How to reproduce it (minimal and precise)

Open the lock using fingerprint and check Home Assistant logs.

Zigbee2MQTT version

2.9.2

Adapter firmware version

2026.4.3

Adapter

Sonoff_Zigbee_3.0_USB_Dongle_Plus

Setup

Raspberry 4 Pi

Device database.db entry

No response

Debug log

No response

Notes

No response

[eduseiden]

Hi, try to use this external converter and check if you get the fingerprint in MQTT. For me, it works.
I got this code .. it's not mine.

yale420w.js

[rubempoli]

Thanks!

In my case, fingerprint_unlock already reaches Home Assistant through MQTT.

The problem is not that the action is missing from the MQTT payload. The problem is that the Home Assistant MQTT discovery generated by Zigbee2MQTT does not include fingerprint_unlock in event_types.

So Home Assistant receives fingerprint_unlock, but rejects it with:

Invalid event type fingerprint_unlock for event.entrance_locker_action

Current event_types for event.entrance_locker_action do not include:

fingerprint_unlock
rfid_unlock
password_unlock

So I think the official YMC420-W definition/exposes should include these values in the action enum / Home Assistant MQTT discovery.

The external converter may work as a workaround, but ideally the official device definition should expose these valid actions correctly.

[eduseiden]

Hi @rubempoli I agree and, based on our suggestions, the official converter is updated.
Let's wait.

[rubempoli]

Correct! Let's see if they approve my pull request to get it to Production...

[rubempoli]

@eduseiden - this has already been deployed and is available. did it sort your issue?