Bridge HTTP-API only sporadically reachable when no internet connection is avaiable (firmware 2.4.21)

Nuki APIs Bridge HTTP-API
21

Just received 2.50 (wifi still at 2.1.17). Events seem to keep coming in even though serverConnected is false. Is the fix part of 2.50?

Patrick

22

This is now fixed with the newest fw version 2.5.0 (Beta)

1 Like
23

Just posted in the same moment. :wink:

Yes, see also:

1 Like
24

Tested the current beta for several days now. The connection is stable, events keep coming in. Beautiful.

Patrick

1 Like
25

After the update to 2.5.2 (wifi 2.1.17) a similar problem seems to be back. The bridge goes into some kind of boot/connect loop: It is pingable for several seconds and after about 15s it is not responding. Enabling the internet connection ended the loop.

{"timestamp": "2020-05-06T14:03:37+00:00", "type": "HTTP-Info"},
{"timestamp": "2020-05-06T14:03:22+00:00", "type": "SSE-PushNukisResponse"},
{"timestamp": "2020-05-06T14:03:22+00:00", "type": "SSE-TimeResponse"},
{"timestamp": "2020-05-06T14:03:16+00:00", "type": "SSE-Connected", "serverNum": 1},
{"timestamp": "2020-05-06T14:03:16+00:00", "type": "SSE-PushNukisRequest", "count": 1},
{"timestamp": "2020-05-06T14:03:16+00:00", "type": "SSE-Gettime"},
{"timestamp": "2020-05-06T14:03:12+00:00", "type": "WLAN-Connected", "ipAddr": "192.168.150.72"},
{"timestamp": "2020-05-06T14:02:21+00:00", "type": "WLAN-Connect"},
{"timestamp": "2020-05-06T14:02:21+00:00", "type": "WLAN-Init"},
{"timestamp": "2020-05-06T14:02:19+00:00", "type": "WLAN-WiFiRestart"},
{"timestamp": "2020-05-06T14:02:19+00:00", "type": "WLAN-Error", "unconnCnt": 181, "unansMsg": 0, "lastMsg": 0, "pings": 0},
{"timestamp": "2020-05-06T14:01:29+00:00", "type": "WLAN-Connect"},
{"timestamp": "2020-05-06T14:01:29+00:00", "type": "WLAN-Init"},
{"timestamp": "2020-05-06T14:00:24+00:00", "type": "WLAN-Disconnected"},
{"timestamp": "2020-05-06T14:00:24+00:00", "type": "WLAN-Connect"},
{"timestamp": "2020-05-06T14:00:24+00:00", "type": "WLAN-Init"},
{"timestamp": "2020-05-06T14:00:17+00:00", "type": "WLAN-Connected", "ipAddr": "192.168.150.72"},
{"timestamp": "2020-05-06T13:59:20+00:00", "type": "WLAN-Disconnected"},

Patrick

26

Hi @PatrickR,
thanks for your provided feedback.

Can you please be a bit more specific about the applied steps and your setup?

  • Is this the direct result after the firmware update? Or did anything else happened in between?
  • Is any additional Nuki device paired with the Bridge (f.ex. a Smart Lock)? If yes, which firmware version is running there?
  • Is the Internet connection properly set up on the Bridge?

Your input is highly appreciated - thanks.

27

Hi Stefan,

you are right, the issue might not be related to 2.5.2. Unfortunately, the situation is rather complex.

Before today my setup was as follows:

  • Nuki bridge connected to a ssid in a separate vlan. In this vlan, DHCP is available, the DNS is reachable but the bridge is not routed to the internet.
  • One Nuki Lock was connected to the bridge.
  • A home automation system is connected to the local(!) bridge API including callbacks.
  • Bridge version 2.5.1, wifi version 2.1.17
  • The connection from the home automation system to the bridge was almost stable:
    2020-05-02 01:06:53 NUKIBridge NUKIBRIDGE state: connected state connected
    2020-04-28 13:46:06 NUKIBridge NUKIBRIDGE state: connected state connected
    2020-04-28 12:00:50 NUKIBridge NUKIBRIDGE state: not connected state not connected
    2020-04-24 14:29:18 NUKIBridge NUKIBRIDGE state: connected state connected
    2020-04-24 14:28:47 NUKIBridge NUKIBRIDGE state: not connected state not connected
    2020-04-21 20:39:11 NUKIBridge NUKIBRIDGE state: connected state connected
    2020-04-21 20:37:41 NUKIBridge NUKIBRIDGE state: not connected state not connected
    2020-04-21 17:24:19 NUKIBridge NUKIBRIDGE state: connected state connected
    2020-04-21 17:23:49 NUKIBridge NUKIBRIDGE state: not connected state not connected
    2020-04-20 22:02:12 NUKIBridge NUKIBRIDGE state: connected state connected
    2020-04-20 22:01:49 NUKIBridge NUKIBRIDGE state: not connected state not connected
    2020-04-11 05:25:49 NUKIBridge NUKIBRIDGE state: connected state connected
    2020-04-11 05:25:32 NUKIBridge NUKIBRIDGE state: not connected state not connected
    2020-04-10 18:51:01 NUKIBridge NUKIBRIDGE state: connected state connected

Because of a mechanical fault of the lock I received a replacement today. Since It took me quite a while to get everything to work again I might miss some steps:

  • I added the new lock to the app, calibrated it and updated the firmware to 2.6.6.
  • I tried to add the lock to the bridge via the app. Getting the bridge connected in maintenance mode failed several times. After about 10 attempts it worked.
  • I deleted the old lock and added the new one. The app announced a bridge reboot.
  • I noticed that the connection from the home automation system to the bridge didn’t work. I tried several things (enabling internet access to the bridge etc.) and finally got a connection. I forced a firmware update through the local API and updated to 2.5.2. I disabled the internet access again.
  • After again failing to connect to the bridge via lan/wifi, I managed to get into maintenance mode again and reset the bridge to factory defaults. I configured everything again (ssid, psk, api key, enabled http api, disabled cloud api magic, added the lock). But the connection from the home automation system didn’t work. I pinged the bridge and received a bunch of unreachables then about 15 echo replies then a bunch of unreachables, 15 replies etc. So I activated the internet connection. After about half a minute, the lock was connected to the home automation system and pingable without packet loss.

As I said, It was a rather complicated process and I’m not sure I got it 100% right but I hope this helps. Definitely helpful would be a higher log level for the bridge logs.

Patrick

28

Hi @PatrickR:

Thanks for your detailed response. Please check following points:

  1. Please check the log of the Bridge, which is accessible through the HTTP API -> /log
    Please comment the results to the post here.
  2. Make sure that the Gateway-IP is pingable by the Bridge, as the Bridge detects herewith whether or not the WiFi connection is up and running - this was actually introduced in Bridge 2.0 beta 2.5.1 and is therefore also featured in the lastest Bridge 2.0 beta 2.5.2.

Thanks!

29

Hi!

See post #25 but don’t expect any useful debugging information from the log. But once again: A detailed(!) log would really help debugging.

The gateway is and always was pingable.

Patrick

30

Today, I had to reboot the access point the bridge was connected to. After reconnection, the bridge went into the connect/disconnect-loop again. I had to temporarily activate the internet access for the bridge and power cycle it.

I would really appreciate, if this problem could finally be solved. After all the time consuming problems with the bridge and I wonder if it’s possible to use Nuki products without a part time administrator.

Patrick

31

Since I just encountered an about 10 minute bridge reconnect-/boot loop: Are there any plans to work on a fix or is the strategy to wait if the broken code fixes itself?

Patrick

32

I also have these problems. When deactivating internet access to the bridge, my bridge disconnect/connect about every 210 seconds. When activating internet access, the problem disappears.
Firmware of this bridge is 1.15.1
I’m not happy to let have the bridge internet access…

Raimund

33

any Updates to this topic? I hope this will be fixed in the future. It doesn´t make sense to have a local API when the architecture need a internet connection.

If the bridge needs a internet connection can anyone describe with ports / URLs/ IPs are nessasary?

1 Like
34

AFAICS, they fixed it. Blocking all internet traffic from the bridge and it works fine.

Patrick