hass_nuki_ng
hass_nuki_ng copied to clipboard
Error when using bridge without internet-access
Hi, I'm using opener, lock and bridge. My bridge is not allowed to connect to the internet, but that throws some errors inside the integration and won't let it work properly. But it should be possible to only use the bridge-API and not the web-API, right? I am using no Web Api Token anyways.
Error in logs:
2022-04-14 04:47:38 ERROR (MainThread) [custom_components.nuki_ng.nuki] Failed to get latest data: Http response: 401 Traceback (most recent call last): File "/config/custom_components/nuki_ng/nuki.py", line 323, in _update bridge_info = await self.api.bridge_info() File "/config/custom_components/nuki_ng/nuki.py", line 72, in bridge_info return await self.async_json(lambda r: r.get(self.bridge_url("/info"))) File "/config/custom_components/nuki_ng/nuki.py", line 38, in async_json raise ConnectionError(f"Http response: {response.status_code}") ConnectionError: Http response: 401 2022-04-14 04:47:38 ERROR (MainThread) [custom_components.nuki_ng.nuki] Error fetching nuki_ng data: 2022-04-14 04:48:08 ERROR (MainThread) [custom_components.nuki_ng.nuki] Failed to update callback http://192.168.2.2:8123/api/webhook/nuki_ng_bridge_hook_bc1927bcb5ec97f1db6e578549480df7
When allowing the bridge to connect to the internet it works like it should, so it's definetly regarding internet-access of the bridge.
so it's definetly regarding internet-access of the bridge
Well, in this case, Nuki NG integration can't do anything. Web API is optional, and configured Web API means that the integration will make API calls to the web service and not to the bridge.
and won't let it work properly
What does that mean? The integration should be pretty functional even without the callback set
Web API is optional, and configured Web API means that the integration will make API calls to the web service and not to the bridge.
Right, but as I said I don't have the web API configured, only the local bridge API.
What does that mean? The integration should be pretty functional even without the callback set
When the bridge has no internet access, the integration won't start, saying I need to check logs, where you find the output I attached above.
Now I understand what you mean.
You can make a very simple test: just try to access /info
bridge API without an internet connection:
smth. like:
curl "http://<BRIDGE_IP>:8080/info?token=<BRIDGE_TOKEN>"
if the command above works with internet enabled and doesn't work without the internet - then the bridge isn't usable without the internet
It does work without internet, just the Web-API does not (obviously), but the local API works fine without internet.
Edit: Output of the info-command is [...] "wlanConnected": true, "serverConnected": false [...]
That's interesting.
Could you please make one more test?
Please go to nuki_ng
source code and change the line https://github.com/kvj/hass_nuki_ng/blob/c9c0531239720135a009c7c800c8c65a2e96a2c9/custom_components/nuki_ng/nuki.py#L33
to self.use_hashed = False
And restart your HASS and try again
When the bridge has no internet access, the integration won't start, saying I need to check logs, where you find the output I attached above.
One thing to take into account: If the bridge can't ping the default gateway, it restarts its wifi, please make sure in fw rules to allow ICMP to the gateway.
Interesting.. Since I enabled internet-access for the bridge and re-enabled the fw-rule I can't reproduce the error. Even restarting HA doesn't show any errors. Even tho I changed nothing else.. Last time the integration somehow lost connection to the bridge (after about 5 hours) and after that, trying to restart the integration gave the errors. Maybe it only happens after some time, I'll have an eye on it and give an update.
One thing to take into account: If the bridge can't ping the default gateway, it restarts its wifi, please make sure in fw rules to allow ICMP to the gateway.
Nice to know, I have ICMP allowed tho, so that seems not to be the issue.
The bridge doesn't need internet access to work locally.
Keep ICMP allowed, otherwise you'll see these pings: 0
in the bridge log, and wifi disconnections:
{“timestamp”: “2020-01-29T17:18:57+00:00”, “type”: “WLAN-Disconnected”},
{“timestamp”: “2020-01-29T17:18:57+00:00”, “type”: “WLAN-Connect”},
{“timestamp”: “2020-01-29T17:18:57+00:00”, “type”: “WLAN-Init”},
{“timestamp”: “2020-01-29T17:18:55+00:00”, “type”: “WLAN-WiFi Restart”},
{“timestamp”: “2020-01-29T17:18:55+00:00”, “type”: “WLAN-ERROR”, “unconn-cnt”: 181, “unans-msg”: 0, “lastmsg”: 2, “pings”: 0},
Can you post the bridge log with internet disabled and ICMP enabled? So we can see what it's doing when the problem occurs. You can use this command:
curl "http://<BRIDGE_IP>:8080/log?token=<BRIDGE_TOKEN>"
Can you post the bridge log with internet disabled and ICMP enabled? So we can see what it's doing when the problem occurs.
I'll do so when the problem occurs again. For now there is noting special in the log, as the connection to HA works (without internet).
I'll do so when the problem occurs again. For now there is noting special in the log, as the connection to HA works (without internet).
So right now you have it with no internet access and ICMP allowed to gw? Should work fine like that.
In case of issues, please post the HA log and the bridge log.
So right now you have it with no internet access and ICMP allowed to gw? Should work fine like that.
Correct, but that was the case all the time. Except when I restartet HA and enabled and then disabled internet access for the bridge earlier today.. Well, let's see if the problem appears again.
So it happened again, all states are unavailable.
HA Log says Error fetching nuki_ng data
and then the same error as I posted here on top of the issue.
Nuki-Brige-Log says absoloutly nothing, everything seems to work on that side.
I changed line 33 of nuki.py to false and restarted HA. Now the connection to the bridge works again, but not sure if it was just the restart or the file change (still using 0.3.0 btw, if that matters).
HA Log says
Error fetching nuki_ng data
and then the same error as I posted here on top of the issue. Nuki-Brige-Log says absoloutly nothing, everything seems to work on that side.
Show the HA log and the bridge log if possible, even if you think they provide no valuable information. It can help reconstructing what is going on.
There's a bigger problem here, I'll try to address it. Generally speaking, the connection between the integration and the bridge isn't always reliable, so errors could happen. In the way how it's implemented now, any fetch error during the first data update will prevent the integration from starting. Most likely I will suppress errors at the startup to make it more reliable
Show the HA log and the bridge log if possible, even if you think they provide no valuable information. It can help reconstructing what is going on.
HA log is exact the same as in my first post.
Bridge log is a loop of {"timestamp": "2022-04-16T21:27:00+00:00", "type": "HTTP-List"},
and {"timestamp": "2022-04-16T21:27:00+00:00", "type": "HTTP-Info"},
even when the connection is not working. There is nothing more to see there.
@kvj Okay, I'll update to 0.3.4 and give an update when the problem occurs again.
Most likely I will suppress errors at the startup to make it more reliable
Could you postpone the connection after the startup phase?