Unfortunately Nuki decided not to include the local HTTP API in the Nuki 3.0 for now. According to them only way to get it to work is to connect the lock to a local physical bridge (like the 1.0 and 2.0). If Nuki changes their mind and enables the Local HTTP API for 3.0, then it may work.
Ah I see, it feels like they might not, likely due to battery reasons the bridge wouldnât be prone to, but eventually also due to technical limitations in reality.
How difficult would it be to follow the Nuki Web API implementation route for the manager to cover this use case, as other projects seem to have reasonably achieved?
It seems like it might be bringing further benefits for all, including updating the lock status when itâs been manually un/locked by the feedback on other threads 
Nuki Manager - v02.00.02
- (New) Added support for Nuki Lock 3.0 ( NOTE : It requires a separate Nuki bridge, the built in bridge in the Nuki 3.0 Pro does NOT support local authentication and requires a standalone bridge )
Nuki Lock Device Handler - v02.01.01
- < no change >
Hi,
Is there a way to get feedback regarding if the lock was locked manually with a key or otherwise via the app?
Unfortunately Nuki doesnât provide that information
hey rboy, do you have any action on the edge migration of this DTH?
This driver is on the backburner right now because of disabled/missing APIâs from SmartThings related to the automated discovery/provisioning process. Once SmartThings takes action on our feedback weâll look into migrating this driver. Plus we are also looking at adding support for the keypad with the Driver version
1 Like
Hi. Any update on this?
Seems there was an edge driver that worked but its no longer maintained. Be great to get support again
Have a working PoC but without automatic discovery it wonât be an easy use. Send in a request to SmartThings support to allow edge drivers to communicate with the internet so that automatic discovery and setup can be implemented.
2 Likes