after re-setting everything again and starting over and playing around with it half the night I figured that it has to be the fact, that the bridge is LAN-only.
Now with the newest beta-firmwares installed and reset, it works reliable since about 6 hours to call the API, when the bridge is connected to the internet. When it is LAN-only it stops working properly and gives me all the above headaches.
Could you please revisit the LAN-only behavior of the API and make sure the bridge can work reliable when not connected to the internet?
This is a bug in the Android App which is fixed in the newest beta (going live soon).
Thanks for the work you put into testing. I will further investigate on our side and put up some testing scenarios. We have several users with a local offline-setup, but there definitly seems to be a problem related to the bridge showing an IP of 0.0.0.0.
Did you find any workaround for the issue? Without any hint for an upcloming patch, i. e. a sane solution I was thinking of rate limiting the packets to the nuki servers or to try to introduce a fake local one. The last idea wouldnāt work if the certificate is pinned.
is that issue with not obtaining a local IP address properly finally solved and can the Bridge work LAN-only? I donāt want it to talk to the internet. I want my local server to talk to it and process all events. I have several bridges and locks in different places and I want to have them finally proper integrated in my āhouse managementā solution, have rules triggered, etc. without that I need to give them access to the internet (which I donāt have in two places - yes, believe it or not, thereās houses that donāt have internet access and donāt need it ).
I started using the Nuki Bridge HTTP API with firmware 2.14.0 to integrate a Nuki Smart Lock 3.0 Pro (firmware 3.5.12) in my home automation software Jeedom.
The cURL requests very often return the error āRecv failure: Connection reset by peerā (as mentioned above by @bblattschuss) for following URLs:
).