Unifi Protect - Fingerprint Reader Event Triggers on Reboot

[nstefanelli]

The problem

Triggering a reboot of the Protect integration via HA or of the camera itself causes the event for fingerprint reader to re-fire. This is causing an issue with the recommended trigger to use for automation, especially in cases where auto-update is enabled on the cameras causing a reboot overnight.

I've also noticed that the event does not change to "not identified" or "unknown" between scans, so this may be the cause of it re-firing.

What version of Home Assistant Core has the issue?

core-2024.12.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

unifiprotect

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[nstefanelli]

@RaHehl - are you able to reproduce this in your environment?

[RaHehl]

@nstefanelli with the example from here: https://www.home-assistant.io/integrations/unifiprotect/#fingerprint-identified-event

a reboot should not trigger a event, do you have "not trigger.event.data.old_state.attributes.get('restored', false) and
not trigger.event.data.old_state.state == 'unavailable' and" in your script?

[TheJulianJES]

Yeah, the above should work.
I do want to post an alternative condition that, instead of checking that the state is not triggered by restoring or by switching back from "unavailable", checks the actual state of the event entity. It's a timestamp that's definitely only updated when the Protect integration fires an event for it.

{% set ent=states("event.doorbell_fingerprint") %}
{{ ent != "unavailable" and as_datetime(ent)+timedelta(seconds=1) > now() }}

This is just for getting rid of false triggers. You still need to (separately) check that the event_type of the event entity state is identified and that the ulp_id (fingerprint id) matches the one you want. You should be able to do that entirely in the UI though.

IMO, this might be a bit more solid than checking the restoration and unavailable explicitly, as this would cover unexpected cases as well. (The ent != "unavailable" check in the template is just to avoid converting the state in as_datetime. It would still stop the automation, as it can't be converted, but might log a warning otherwise?)

[home-assistant]

unifiprotect documentation
unifiprotect source

[issue-triage-workflows]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[spali]

Still an issue with 2025.3.3

[twynne]

I believe I experienced this overnight when our G4 Pro Doorbell decided it was due an update, and then restarted. I woke to a notification on my phone that the front door had been unlocked by my fingerprint at ~3:30am!

As an immediate fix I've stopped the doorbell from being allowed to self-update daily, but I'm struggling to read between the lines above and tell if there's something I should be checking in the automation to prevent this from firing on a restart of the doorbell. Or is it just a known issue with no available workaround right now?

[spali]

I believe I experienced this overnight when our G4 Pro Doorbell decided it was due an update, and then restarted. I woke to a notification on my phone that the front door had been unlocked by my fingerprint at ~3:30am!

As an immediate fix I've stopped the doorbell from being allowed to self-update daily, but I'm struggling to read between the lines above and tell if there's something I should be checking in the automation to prevent this from firing on a restart of the doorbell. Or is it just a known issue with no available workaround right now?

The updated doc condition or the above timestamp condition works both. But if you want to be sure, use a webhook called by protect. The only problem there is, currently you only get the id, but not other details of the user like the name.

[twynne]

The updated doc condition or the above timestamp condition works both. But if you want to be sure, use a webhook called by protect. The only problem there is, currently you only get the id, but not other details of the user like the name.

Thanks, I think I've identified the change you're referring to by 'the updated doc condition', but I notice there are now two 'fingerprint identified' examples in the doc. Not sure if that was the intent?

Sorry if I'm misunderstanding. The technicality of the post above (#133241 (comment)) is completely lost on me. Maybe it's too early! :)