I couldn’t agree more with your perspective - the current implementation is indeed dangerous!
From a UX perspective, I find the HomeKit UI for the lock to be very misleading - the “unlocked” icon does not correctly reflect an “unlocked” lock/door, but instead an “open” one - this is a big difference!
I have disabled the HomeKit functionality now as I do not want anyone (myself included) to unintentionally open the door lock operated by NUKI, and am very unhappy with that, as the HomeKit integration was the reason to spend the additional money and update to the Smart Lock 2.0.
From my perspective, the current HomeKit implementation is completely unusable for safety reasons.
As HomeKit so far only knows certain few lock mechanism states (see https://developer.apple.com/documentation/homekit/hmcharacteristicvaluelockmechanismstate
for details), this is obviously a limitation which Apple needs to overcome. From my perspective, the currently possible values for the state of a lock mechanism are not enough and need to be updated with additional possible values.
@Juergen: The values which are currently possible to be used with HomeKit do not completely mirror the states which Nuki knows (Unlock, Lock, Open Door - I do not included Lock’n’Go here). HomeKit’s “unsecured” reflects Nuki’s “Open Door”, rather than Nuki’s “Unlock”.
Until Apple decides to update their constants, would it be possible for Nuki to change the HomeKit/Nuki mapping? This could enable users to trigger the “Unlock” command to the Nuki Smart Lock 2.0 instead of triggering the “Open Door” command?
As part of daily routines I would also much rather only unlock my door, instead of opening it, thus preventing an unwanted open door.