"Motor blocked" event in Home Assistant

I have a pull up handle and I’ve been trying to remind people in the house that they need to pull it up when they enter or leave so that it can lock properly. I’d love to go one step further and set up some automations in Home Assistant when the Nuki cannot lock due to the handle not being pulled up.

Is there a way, via Matter or MQTT, to trigger an automation when this happens?

I came here to raise a similar issue. I have a lock connected via MQTT over WiFi. On some occasions when the handle is not lifted - or not lifted all the way there is a ‘Motor Jammed’ event.

However, this doesn’t happen every time (or at least is not always received by my HA). It does always trigger the notification through the app.

In addition, less than a second later there is a ‘Motor Locked’ event even though the lock is not actually locked (because it was jammed).

Screenshot below of the sequence of events when this has happened
Door unlocked at 18:06:52 >
Door jammed but then immediately reported locked at 18:07:20 >
Door re-locked once the handle had been lifted at 18:07:29

I have moved to the Beta version 4.3.2 in case it was already fixed in here, but it is the same.

It would be great if

  1. There is no ‘Motor Locked’ event sent if the motor is Jammed. Then the most recent status would be ‘Jammed’ which would be easily visible on a dashboard and could be used to trigger automations.
  2. The Motor Jammed event is sent every time there is a blockage - at the moment it is sometimes not received on my HA. It is possible that it’s being ‘squashed’ by the Locked event coming immediately afterward - if that’s the case then fixing (1) would also fix (2) :slight_smile:

Many thanks, Dave

1 Like

I really like that suggestion, that would be very easy to create automations for.

Jammed lock is a transitive state.
After the state is sent to MQTT, the lock stop and the actual state is locked if the position is locked or unlocked if not.
Physically the motor should not stay blocked at all, just after it is blocked it is unblocked so the state changes.

I think the jammed state is not raised when the transition is too short to be triggered by HA, it is only my personal opinion.

The reason why it is then locked even it is not is the lock is considered locked too soon.
That’s something I always noticed and make the calibration not enough exact.
Some other smart lock ask the user to calibrate manually so we can set when the lock is just locked and unlocked, for example Switch Bot if I remember correctly.

Thanks for your reply.
I have Nuki on two different doors, both of which are the ‘lift the handle’ type which is common in the UK.

In case anyone is not familiar with these, the door has a ‘multipoint’ locking system where lifting the handle engages a number of sliding bolts into slots in the frame. This pulls the door into the frame, but also means that the door cannot be locked unless the handle has been lifted - the key will not turn anywhere near a full turn.

With these doors I do not believe it is an ‘exact’ calibration issue - the ‘key’ (Nuki in this case) has not travelled anywhere near far enough - nor as far as it normally travels. The outcome is that (at the moment) on both HA and the Nuki app, the system will say that it is locked (by which I mean protecting the house from bad people), when in fact it is very much unlocked and bad people could just walk in.
Hopefully this can be improved :slight_smile:

1 Like

Experiencing the exact same issue in the exact same circumstances, i.e. UK multipoint lock with a “lift the handle” action needed to engage the multipoint locks. If this has not been done (i.e. handle still down) and the nuki is locked remotely then it jams but reports the jam transiently in home assistant before then reporting ‘locked’ even though it is still unlocked, or sometimes doesn’t report the jam at all (but the nuki still flashes red and knows it is jammed).

Hey everyone, I have the solution for you!

I spoke to Nuki support about this and the reason this happens is because when you calibrate the lock there is a certain point of travel where the door is considered locked, and in the case of UK multipoint door locks this can be before the door is actually locked.

The locking / unlocking action actually has nothing to do with if the door reports locked / unlocked via Matter or in the app, it is purely and entirely controlled by this point of travel.

Now luckily, you can actually configure where this point is, and as long as you make sure it is configured to be after the point where the door is actually locked it should work as expected.

To do this, in the Nuki app go to Features & Configuration > General > Optimize locking > Custom and adjust the Transition unlocked → Locked setting to a positive offset. The exact value will depend on your door so you’ll need to play around with it, but when set correctly the state of the door should not change to Locked unless the motor moves past this point.

Also, make sure you are on the latest firmware update, Matter support previously had been a bit dodgy for me and stopped reporting updates correctly after a few days but on the latest version it’s been pretty rock solid.

Apologies for not replying earlier about this, I subscribed to this thread a few months ago while also raising a ticket with Nuki support and I forgot to update this thread when I found the answer.

Hope this helps everyone :slightly_smiling_face: