Bug in Reconnect ?! #33

New Issue

icebear · 2026-05-26T11:22:02+02:00

icebear commented

2026-05-26 11:22:02 +02:00

When i switch off my printer over night and switch on in the morning, i can syncronize the filament but not start a printjob (connection refused) .. i must restart the software .. (Its the Windows Version .. :)

and a question .. Would it be possible to include kobra 3 as well ? or is it to much different ?

When i switch off my printer over night and switch on in the morning, i can syncronize the filament but not start a printjob (connection refused) .. i must restart the software .. (Its the Windows Version .. :) and a question .. Would it be possible to include kobra 3 as well ? or is it to much different ?

harrygeier commented

2026-05-29 12:18:03 +02:00

Similar here, linux bridge, windows orca. I must reconnect every time when printer off a while 9.16 .

I suggest : Try a reconnect first, when printer is not responding on upload or camera start. That is what i manually do.

Similar here, linux bridge, windows orca. I must reconnect every time when printer off a while 9.16 . I suggest : Try a reconnect first, when printer is not responding on upload or camera start. That is what i manually do.

viewit commented

2026-05-30 20:38:46 +02:00

Reworked the reconnect path on the dev branch (98dad91).

Root cause: The MQTT reader thread only tried 5 reconnects with backoff [2,4,8,15,30]s — about 60 seconds total. When the printer is powered off overnight all 5 attempts fail and the reader thread dies silently. Filament sync still works because that goes over fresh HTTP connections to printer port 18910, but MQTT-bound actions (start print, set temperature, …) fall through: publish() runs its own short reconnect cycle that may briefly succeed, but with a dead reader thread the printer’s replies never arrive — so the call times out and you get HTTP 504 "no response from printer".

Fix: The reader thread now reconnects indefinitely (backoff caps at 60s) until the printer answers or the bridge is shut down cleanly. First 5 attempts log at WARNING, after that at DEBUG so an overnight outage does not spam the log. publish() and publish_web() additionally revive the reader thread on every call if it should ever be missing.

Will ship in the next bridge release (0.9.18). @harrygeier @icebear — if you want to test against a dev build, let me know.

Would it be possible to include Kobra 3 as well?

Not right now — the Kobra 3 uses a different MQTT dialect and a different cert mechanism. Probably only worth it once someone with a Kobra 3 reverse-engineers the protocol. Feel free to open a separate issue if you want to take a stab at it.

Reworked the reconnect path on the dev branch ([98dad91](https://gitea.it-drui.de/viewit/KX-Bridge/commit/98dad91)). **Root cause:** The MQTT reader thread only tried 5 reconnects with backoff [2,4,8,15,30]s — about 60 seconds total. When the printer is powered off overnight all 5 attempts fail and the reader thread dies silently. Filament sync still works because that goes over fresh HTTP connections to printer port 18910, but MQTT-bound actions (start print, set temperature, …) fall through: `publish()` runs its own short reconnect cycle that may briefly succeed, but with a dead reader thread the printer’s replies never arrive — so the call times out and you get HTTP 504 "no response from printer". **Fix:** The reader thread now reconnects **indefinitely** (backoff caps at 60s) until the printer answers or the bridge is shut down cleanly. First 5 attempts log at WARNING, after that at DEBUG so an overnight outage does not spam the log. `publish()` and `publish_web()` additionally revive the reader thread on every call if it should ever be missing. Will ship in the next bridge release (0.9.18). @harrygeier @icebear — if you want to test against a dev build, let me know. > Would it be possible to include Kobra 3 as well? Not right now — the Kobra 3 uses a different MQTT dialect and a different cert mechanism. Probably only worth it once someone with a Kobra 3 reverse-engineers the protocol. Feel free to open a separate issue if you want to take a stab at it.

viewit commented

2026-05-31 20:27:54 +02:00

Shipped in v0.9.18. Closing — if the printer-reboot-during-the-night case still hits you on the new build, please reopen with the bridge log.

Shipped in [v0.9.18](https://gitea.it-drui.de/viewit/KX-Bridge-Release/releases/tag/v0.9.18). Closing — if the printer-reboot-during-the-night case still hits you on the new build, please reopen with the bridge log.

viewit closed this issue

2026-05-31 20:27:54 +02:00

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#33