Connection with server is lost sometimes

For a while now the connection with the brewblox server is lost sometimes.

When system is idling I can notice the error because all the sensors and valves show the red connection error symbol and I cannot give any commands.

When I give commands just when the connection is lost but not yet detected (no red connection lost symbols yet) the commands are queued and carried out when the connection is back again.

I think most of the times the connection is back within one minute.

When I check the devellopers tool in chrome I see these errors. One of these error for every command I gave during the connection error.

Here the exports of UI logs and the blocks export of my two sparks (v2 and v3)
brewblox-blocks-spark-two.json (23.7 KB) brewblox-logs.json (3.4 KB) brewblox-blocks-spark-one.json (16.6 KB)

424 errors are the result of the service being unable to talk to the spark itself.

What is the controller uptime? We recently noticed short hangups that start after the spark has been running for > 7d. If this is the case, rebooting the controller should fix the problem for the next week.

I thought we solved that issue with the latest firmware upgrade that discards the oldest TCP client if a 4th one arrives.

Have you updated to the latest version?

Can you share the brewblox-ctl log output?

As far as I know I run the latest version.

The requested log:

I had a similar issue at home.
Maybe you have a similar situation with a mesh repeater, then this info might help.

When I pinged the spark (not the pi, but the spark) I saw a 20% packet loss. Command is ping -r

I have a router and repeater from Fritzbox, provided by my Internet provider. This is decent equipment, but the way it is automatically configured is a bit strange to me.

When the mesh repeater is configured automatically by the Fritzbox, it uses the same WiFi channel as the main router. With a wifi analyzer app, I can see that they completely overlap. So I had 2 access point on the same channel with the same credentials. I always thought this was a bad idea, but perhaps Fritz has made it work for most cases?
I figured this could explain the package loss, so I reconfigured the mesh access point to:

  • not be automatically configured
  • use a fixed wifi channel, other than the fixed channel of the main router
  • only use 5GHz to communicate between mesh repeater and the main router. So the repeater broadcasts a network only on 2.4 GHz and only uses 5 GHz as a link to the main router.
  • Wifi name and password are still the same on both, so devices can hop between access points.

Well I do have a wifi network with mashing. The access points are all wired. Both the access points were sending 2.4ghz wifi on channel 1. I now set them both on a different channel and my first impression is that it is a lot better now! Hard to say if it is completely solved, time will tell for sure.

Thanks for the wifi channel idea!

1 Like