Unreliable printer connection #61

New Issue

BasK · 2026-06-17T17:17:15+02:00

BasK commented

2026-06-17 17:17:15 +02:00

When running the bridge, the log consists of a constant list of failed connection attempts to the printer. What's strange is that for short periods the connection does seem to work, since I get information from the ams and turning the light on and off also works about 25% of the time. Is it possible that the frequency of connection attempts is overwhelming the printer?

kx-bridge-log_20260617-151225.txt

37 KiB

viewit commented

2026-06-17 19:56:31 +02:00

Thanks for the log, @BasK — it narrows things down a lot. In ~13 seconds it shows 80 successful connects and 78 immediate disconnects:

CONNACK rc=0            <- connect + login succeed
Reconnect erfolgreich
reader error: EOF       <- connection drops right away
Verbindung verloren – reconnect…

The TLS handshake and login succeed every single time (CONNACK rc=0); the connection then drops a few milliseconds later (EOF). There are no TLS errors, no timeouts, no rejected logins — so it is not the poll frequency overwhelming the printer. Each connection is set up cleanly and then torn down. There are two things that produce exactly this pattern:

1. Two clients sharing the same MQTT session (most likely).
The printer's broker only allows one connection per client ID. If a second client connects with the same ID, the broker kicks the first one off (per the MQTT spec), both reconnect, and they keep knocking each other offline in a loop — which also explains the ~25% "works" windows (the brief moments between connect and kick). The second client is usually one of:

a second/duplicate bridge instance (an old container or process still running against the same printer), or
the Anycubic app or Anycubic Slicer connected to the printer at the same time (same broker).

Please make sure only one bridge is running, and close the Anycubic app/slicer while testing.

2. A weak/unstable Wi-Fi link to the printer.
If the printer's Wi-Fi signal is poor, the connection can also drop repeatedly right after connecting, giving a similar EOF loop. Could you check the printer's Wi-Fi signal strength, and ideally test with the printer close to the router (or on a wired connection if possible)? A quick ping <printer-ip> from the bridge host for ~30s would also tell us if there's packet loss.

My money is on #1 (a duplicate session), but #2 is worth ruling out at the same time. If stopping the duplicate client or improving the Wi-Fi makes the loop stop, that tells us which one it was. On our side we can also make the bridge's client ID unique so a collision can't happen in the first place — but I'd like to confirm the cause with you first.

Thanks for the log, @BasK — it narrows things down a lot. In ~13 seconds it shows **80 successful connects and 78 immediate disconnects**: ``` CONNACK rc=0 <- connect + login succeed Reconnect erfolgreich reader error: EOF <- connection drops right away Verbindung verloren – reconnect… ``` The TLS handshake and login succeed every single time (`CONNACK rc=0`); the connection then drops a few milliseconds later (`EOF`). There are no TLS errors, no timeouts, no rejected logins — so it is **not** the poll frequency overwhelming the printer. Each connection is set up cleanly and then torn down. There are two things that produce exactly this pattern: **1. Two clients sharing the same MQTT session (most likely).** The printer's broker only allows one connection per client ID. If a second client connects with the same ID, the broker kicks the first one off (per the MQTT spec), both reconnect, and they keep knocking each other offline in a loop — which also explains the ~25% "works" windows (the brief moments between connect and kick). The second client is usually one of: - a **second/duplicate bridge instance** (an old container or process still running against the same printer), or - the **Anycubic app or Anycubic Slicer** connected to the printer at the same time (same broker). Please make sure only one bridge is running, and close the Anycubic app/slicer while testing. **2. A weak/unstable Wi-Fi link to the printer.** If the printer's Wi-Fi signal is poor, the connection can also drop repeatedly right after connecting, giving a similar `EOF` loop. Could you check the printer's Wi-Fi signal strength, and ideally test with the printer close to the router (or on a wired connection if possible)? A quick `ping <printer-ip>` from the bridge host for ~30s would also tell us if there's packet loss. My money is on #1 (a duplicate session), but #2 is worth ruling out at the same time. If stopping the duplicate client *or* improving the Wi-Fi makes the loop stop, that tells us which one it was. On our side we can also make the bridge's client ID unique so a collision can't happen in the first place — but I'd like to confirm the cause with you first.

viewit added the

question

label 2026-06-17 19:57:26 +02:00

BasK commented

2026-06-17 20:08:55 +02:00

#1 was spot on, I was running the Anycubic app at the same time as the bridge. Stopping the app immediately fixed all issues in the bridge. If there is anything you can do in the code to be able to run the anycubic app in parallel with the bridge then that would be great, otherwise I'll gladly switch to orcaslicer + the bridge fulltime. And I've said it before, but thanks again for both the speed and quality of your responses!

viewit commented

2026-06-17 20:34:28 +02:00

thx for the tip ;-)

viewit closed this issue

2026-06-17 20:34:28 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#61