You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am experiencing very bad network availability issues with nuki_hub versions 9.0x.
Pinging the device shows a high packet loss and web requests often block für many seconds or even timeout:
# ping nukihub2
PING nuki-hub2.ms14.kloburg.at (10.0.1.92) 56(84) bytes of data.
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=6 ttl=64 time=4212 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=7 ttl=64 time=3194 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=8 ttl=64 time=2172 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=9 ttl=64 time=1157 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=10 ttl=64 time=133 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=13 ttl=64 time=6978 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=14 ttl=64 time=5957 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=15 ttl=64 time=4942 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=16 ttl=64 time=3918 ms
64 bytes from nuki-hub2.ms14.kloburg.at (10.0.1.92): icmp_seq=17 ttl=64 time=2894 ms
[...]
--- nuki-hub2.ms14.kloburg.at ping statistics ---
815 packets transmitted, 295 received, 63.8037% packet loss, time 832733ms
rtt min/avg/max/mdev = 3.000/2265.762/9921.020/1694.991 ms, pipe 10
IMHO it looks like the networking code is blocked by some other task for some time and is not able to handle requests.?
Until yesterday the problems only appeared after some uptime and I was having the impression that after a reboot of the lock, the problems would disappear for some time again. (I suspected it to be a BLE issue, see #619)
But since yesterday, the problems even outlast a reboot of the lock and the hub.
Looking at the MQTT log (without debugging enabled), I cannot see any suspicous entries. (See below.)
I have a second nuki_hub (connected to another lock) running 9.00 that doesn't show that problems.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
PROBLEM DESCRIPTION
I am experiencing very bad network availability issues with nuki_hub versions 9.0x.
Pinging the device shows a high packet loss and web requests often block für many seconds or even timeout:
IMHO it looks like the networking code is blocked by some other task for some time and is not able to handle requests.?
Until yesterday the problems only appeared after some uptime and I was having the impression that after a reboot of the lock, the problems would disappear for some time again. (I suspected it to be a BLE issue, see #619)
But since yesterday, the problems even outlast a reboot of the lock and the hub.
Looking at the MQTT log (without debugging enabled), I cannot see any suspicous entries. (See below.)
I have a second nuki_hub (connected to another lock) running 9.00 that doesn't show that problems.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
TO REPRODUCE
Publish a
rebootNukicommand:mosquitto_pub -t 'nuki-garten/configuration/action' -m '{ "rebootNuki": "1" }' -u nuki-garten -P "$(</etc/mosquitto/pw-nuki-garten.txt)"; echo "$? - $(date)"
ADDITIONAL CONTEXT
$ mosquitto_sub -t nuki-garten/# -F "%I %t: %p"The text was updated successfully, but these errors were encountered: