I implemented a fob using an NRF51822 (GitHub - zilluss/Open-Nuki-Fob: Open Source Nuki Fob based on the the NRF51822 SoC). It works without issues on a Nuki V1. I recently bought a Nuki V2 and pairing works without any issues, however if I try to discover the BLE services in the default mode on the V2, the Nuki disconnects without returning any services. In pairing mode querying the services works just fine. What could be the reason?
Do you get an error code on the following line?
uuid_type is used here?
128-Bit or 16-Bit?
Hi Marc, it’s a 128bit UUID, the call to ble_db_discovery_evt_register finishes without an error. What’s odd is that service discovery works while pairing, I get to pair the fob and it shows up on the Nuki’s User list. After pairing no services are ever received from the Nuki. I can see the services from BLE apps on my phone though. Maybe it’s a fundamental issue like the initial MTU being larger in default mode as opposed to pairing mode, because the NRF51822 max MTU is fairly low, I think 23 bytes.
The MTU is indeed the issue: The Nuki tries to initiate a MTU exchange but the NRF51822 doesn’t reply, because it’s not implemented. The Nuki then disconnects after a timeout. Will this behaviour be fixed, e.g. with a fallback to the default MTU if the Nuki doesn’t get an MTU reply after a timeout? I have a couple of people asking me why the fob isn’t working with their V2 lock and I’d like to give them an answer.
The default MTU is always 23 and is only increased if the connecting device responds to the MTU exchange request with an MTU exchange response containing an MTU size larger than 23.
Are you sure there is no MTU reply sent (maybe by the BLE stack itself)?
You may also try to send a MTU reply with 23.
Yes, the BLE stack does not implement MTU exchange at all, so the device doesn’t reply automatically and the API has no functions to do so manually (See for example this reply from Nordic in their forum: https://devzone.nordicsemi.com/f/nordic-q-a/41658/nrf51824-is-support-mtu-change/162312#162312)
Unfortunately, I don’t have a BLE sniffer to provide a trace of the communication. But it’s the most likely explanation why pairing works but unlocking doesn’t, since the Nuki doesn’t do MTU exchange in pairing mode. Since the BLE stack doesn’t automatically reply to the MTU request, and the API doesn’t implement it, there’s no way for me to solve this issue on my side. If you won’t change this behaviour that’s understandable, but I think it would be helpful to note it in the documentation, since I spent quite some time figuring out what the issue was.
If there’s an update on the issue, even if it’s a “we can’t help you with that” I would appreciate it. I’ve since checked the NRF52832 port of my code (which does support MTU exchange) and got it to pair and unlock my V2 Nuki.