I had the Bridge running since around two months together with an SL3P.
Bridge was used 99% for HTTP Calls from my Loxone Smart Home.
In preparation for the MQTT Beta I activated the SL3P Debug mode in the night for the first time (AND I missed to disable it). This morning the SL3P Battery was empty (Before it had ~ 37%) and the Bridge refused various HTTP Calls with the existing Token.
Although I had nothing more changed, in the Discovery Page I got exactly this situation the whole day:
If discovery is disabled via /configAuth or through the Nuki App, the IP is 0.0.0.0 and the port 0. In this case the /auth command fails with HTTP error 403.
I tried to use /configAuth [1/0] for the first time, but nothing changed.
A few hours ago I decided - and it was possible - to send an /factoryReset.
After that I paired the Bridge with the App, but I still only got:
Habe die Bridge nun auch nochmal in einem anderen Raum angebunden, in dem auch ein anderes Access-Point Modell hängt (Nur zur Sicherheit, auch wenn ich natürlich bereits die gesamte Infrastruktur durchgebootet habe…)
Mabe you discovered a problem in the beta with activating the mqtt API (which requires WiFi) while the SL3P is connected to a bridge (and the internal WiFi is off). I’ll forward this to the firmware team.
Inbetween i’d recommend to not activate the mqtt API (= debug mode) while the Smart Lock is connected to a bridge.
To recover the bridge you need to set it up and pair it with the Smart Lock again through the Nuki App > Manage Devices > Add Bridge section. You could also activate and set up the HTTP-API through the App and don’t need auto-discovery in this case.
… which does not have the MQTT API, therefore it could not cause the battery drop anyway. I double checked with the team in between and there is no problem with enabling debug while SL3P is connected via bridge only, even on the latest betas.