iOS 16.2 new architecture issues with HomeKit

Apple released the iOS 16.4 beta, apparently containing the new HomeKit architecture again. What is your experience with it?

We’re still aware of this problem. We will reach out to you individually via DM for more details. Thank you in advance for your help.

Hi Stefan, seems like the issue is still there on iOS 16.4. They only seemed to introduced back the new architecture toggle like someone already mentioned — but this was because they had issues with invites and such.

From my understanding, there is something underlying in the new architecture that demands more updates from the devices. Maybe because now the IoT devices have its status cached in the HomeKit hub (HomePod and such) whereas before it would ask the individual device for its status whenever needed. Maybe now the HK hub asks Nuki for its status too often and sometimes it doesn’t respond resulting in the no response issue.

That’s my 2 cents but one should be able to easily replicate it: just add a couple of nukis in the new architecture, using a HomePod as hub and then through the day you should get the no response pretty often.

Smart Lock Beta 3.6.1 contains a few changes that could potentially improve the behaviour with HomeKit, especially when the new architecture and/or HomePod Minis are used.

Apple did also release several updates across its product lineup (Several 16.4 Betas for all products).

If you use either Nukis or Apples betas (or both), could you please let us know if you still experience problems with HomeKit?

Thank you!

@Juergen I’ve been testing the new firmware on my two locks (Pro and non-pro) and so far this are my feedback:

  • Connection seems more stable and reliable. I think there was a time I brought the Home app from background into foreground and a lock (non-pro) showed as “no response” but restarting the Home app brought it back online again. It could have been some momentary hiccup. On overall, the connection seems to not be dropping at least as it was before.
  • There seems to be a major lag now reporting the status to he hub (HomePod) when unlocking at least. This is quite evident for me because I have an automation when the lock unlocks upon arriving (turn on the hallway light). Before the firmware update, it would turn on after like 1-5 seconds (if it didn’t have the bug of no response in the moment of the trigger) whereas now it’s consistently around 10-15 seconds after unlocking, making it unreliable for such automations.

Anyway, I think the firmware is in a good path, if you could just fix it the update delay it would be perfect. I’d rather have it like this (with lag) than having it consistently as “no response” and not even triggering the automations at all. There were multiple times that some of my lights kept on because it didn’t trigger the “lock event” and the automation to turn off the lights didn’t trigger as well.

Is this lag the same for both Smart Locks that you have?
Does it change, when you change Smart Lock settings Battery > Energy-saving mode to fast or slow?
Please DM me the Nuki IDs of your Smart Locks.

No. Actually not. Surprisingly the Pro is the slower one, the non-pro has like 2-5 seconds of lag. I must point that both locks have excellent coverage to the hubs. I assume that the pro is still using BLE for the communication with the HomePod (which would be great to use Wi-Fi instead for the HK, but that’s another topic).

I have both energy modes set to auto.

I’ll send you right away.

Beta Firmware 3.6.2 has additional changes that could improve the speed at which notifications / automations are processed by HomeKit after a lock action happended. Please give it a try and let us know if you notice any differences.

It works for me, thanks, much better response.

Only had 1 chance to try it out yet (last night arriving home) and it was much faster in fact. For me it’s really easy to test because I have it set to turn on the hallway lights when the door unlocks so it was really a bad experience having it unlocked and having to manually turn the lights on because it took like 5 seconds to trigger the automation, yesterday as soon as I opened the door it immediately turned on like 1 or 2 seconds at most.

Let’s give it a few more tries before confirming it’s actually working better.

Same for me!

It is better on beta, but not perfect. Response time is better, comparable to before new architecture. Still sometimes I get no response message and automations to close the door sometimes fail.

Yes, as an update @Juergen after using for a while with the new beta, I can confirm that is better but not perfect. I still experience a couple of “no response” every now and then in the Home widget, which means that the lock is reported as no response briefly sometimes for the Home hub — although not as often as before.

Automations seem to trigger on overall faster, but there were still times that the response was slow (like before).

Yes would be good if Nuki team works in their product without blaming left and right.

I use home app and contrôler that gives more details on the accessories. A simple automation : if Nuki unlocks turn off the light.

Here is how the unlock action shows into controller. Clearly the way the lock is programmed is messy and HomeKit struggles to understand the state of the lock and gives a no response.

Also, like mentioned multiple times before, Nuki should use Wifi for HK (more reliability) instead of BLE. I don’t bother having to charge the lock a bit more times if that’s the tradeoff.

There are other accessories which I don’t get why aren’t exposed to HK, like the door sensor (as a contact sensor to HK), that would make it easy for some automations as well. For people that are really into HK and have invested money in 2 Nuki locks, it’s a bit disappointing to such a expensive product behaving this way — fortunately the lock itself while using the Nuki app is good and rock solid, that’s the more important anyway.

I can’t go into details, but for HomeKit Apple is the gatekeeper who defines the HomeKit protocol, data model, requirements, test cases etc. i.e. they decide what they allow and what not, how much effort it is and if it is feasible at all.

Besides the official integration there are other ways to integrate Nuki products into HomeKit (Homebridge plugins which use the HTTP-API or MQTT API) which do not face such restrictions.

1 Like

I have already tried to go around the native implementation through MQTT but unfortunately the smart lock pro bridge doesn’t expose the API, so there’s no way I can use MQTT without having to buy the bridge just for that (which I’d rather not to, specially because I have 2 locks in two different areas of the house).

SL3 Pro = MQTT → MQTT API & Homebridge
Nuki Bridge = HTTP → Plugin #1 or Plugin #2

1 Like

Thank you @Juergen. I’ve just done it with NodeRed and MQTT with a simple flow and I was able to expose the MQTT implementation to HK (through NRCHKB) and it’s working rock solid now (finally!)

I wish there was a way to add this implementation to my other Nuki 3.0 non-pro lock without a bridge, I’d be glad with the MQTT implementation since it’s not an issue for me as I run a home server, but having to pay for the bridge just as workaround for a non-responsive lock, feels a bit wrong to me. So let me know if you find a solution for the non-pro without a bridge.

After switching from Nuki 2.0 to Nuki 3.0 Pro, I have similar issues as mentioned in this thread. Automations trigger only after opening the Home app. Still have the old Bridge installed, can I somehow override settings so homekit/Nuki use the bridge instead of the built-in wifi (if that’s the issue)?

Edit: Fixed through homebridge NB.

Using Nuki 3.0 pro and showing wrong status in homekit.