Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[franzda]

Hallo zusammen,

ich beobachte wiederkehrende Verbindungsabbrüche meines ioBroker-MQTT-Adapters zu EMQX Cloud und suche nach einer technischen Erklärung.

Umgebung:

iobroker.mqtt 8.1.2

Node.js v24.22.1, js-controller 7.2.5

EMQX Cloud, MQTT über TLS auf Port 8883

Client-ID: womoraspi

Fehlerbild:

18:05:46.855 Reconnected to ...
18:05:46.956 Connected to ...
18:22:27.103 Client error: Error: read ECONNRESET

Der Abbruch erfolgt damit rund 1.000 Sekunden nach erfolgreicher Wiederverbindung. Ähnliche Zeitabstände traten wiederholt auf. Bei einem Messintervall von einer Minute ist der Fehler während meiner bisherigen Beobachtung nicht aufgetreten; nach Umstellung auf zehn Minuten trat er erneut auf. Ein kausaler Zusammenhang ist noch nicht bewiesen.

Zum Vergleich lief ein Python-Testclient mit Paho, TLS und Keep-Alive 60 Sekunden über mehr als drei Stunden stabil. Dieser Testclient hat allerdings keine Topics abonniert und keine Nachrichten veröffentlicht.

Meine Fragen:

**Ist ein solches periodisches ECONNRESET bei dieser Adapter-/Node.js-Version bekannt?

Gibt es im Adapter oder in MQTT.js einen Timeout bzw. Verbindungsmechanismus, der einen Abbruch nach ungefähr 1.000 Sekunden erklären könnte?**

Wie lässt sich zuverlässig feststellen, ob EMQX die Verbindung beendet oder ob der TCP-Reset auf Client- bzw. Netzwerkseite entsteht?

Ich möchte zunächst die Ursache eingrenzen, bevor ich Einstellungen ändere. Für Hinweise zu relevanten Debug-Logs, Adapteroptionen oder bekannten Issues wäre ich dankbar.

Viele Grüße

(von KI Auswertung erstellt !)

[mcm1957]

@bluefox

AI1 an AI2 - was geschieht denn da dabei ..?

[franzda]

Mir geht es in diesem Beitrag um eine konkrete technische Frage zum MQTT-Adapter und den wiederkehrenden ECONNRESET-Fehlern. Die Zeitpunkte und Protokolle habe ich nachvollziehbar dokumentiert.

Ich nutze KI als Unterstützung bei der Recherche. Entscheidend ist jedoch die technische Ursache des Problems.

Wer dazu konkrete Hinweise oder eigene Erfahrungen hat, ist herzlich eingeladen, diese beizutragen. Eine Diskussion über den Einsatz von KI hilft bei der eigentlichen Fragestellung hingegen nicht weiter.

[stenmic]

@mcm1957 sagte:

@bluefox

AI1 an AI2 - was geschieht denn da dabei ..?

Saugeil 🤣

[mcm1957]

@franzda said:

Wer dazu konkrete Hinweise oder eigene Erfahrungen hat, ist herzlich eingeladen, diese beizutragen. Eine Diskussion über den Einsatz von KI hilft bei der eigentlichen Fragestellung hingegen nicht weiter.

Da stimme ich dir voll zu. Das sollte auch keine solche Diskussion werden. Ich habe @bluefox explizit gepingt da er den Adapter am besten kennt und da helfen kann. das war der Zweck meines Postings. Der letzte Satz war explizit Kursiv markiert da er nur darauf anspielen sollte dass die intensiv im Entwicklungsbereich eingesetzte AI ev- auch was beitragen kann um das Problem zu lösen.

Also ganz kalr - keinerlei Kritik an dir oder deinen Werkzeugen. Sorry, wenn das falsch ankam.
Und Danke für die deine ausführlichen Infos.

[Bluefox]

@franzda Im Adapter gibt es keinen Timer, der nach etwa 1000 s etwas macht. Der Client übergibt an MQTT.js nur keepalive (Standard 10 s), reconnectPeriod (Standard 10 s), connectTimeout (Standard 30 s), clean und rejectUnauthorized. Ein ECONNRESET heißt, dass von außen ein TCP-RST gekommen ist. MQTT.js oder der Adapter beenden die Verbindung in so einem Fall sauber und erzeugen kein RST. Der Reset kommt also vom Broker oder von etwas auf dem Weg dorthin.

Fragen bzw. Ansätze:

1. Welcher Wert steht bei dir in den Instanzeinstellungen bei Keep-Alive? Wenn er deutlich höher als 60 ist und nur alle 10 Minuten etwas gesendet wird, passt das gut zu deiner Beobachtung (1 Minute stabil, 10 Minuten nicht). Ein NAT oder Mobilfunk-Gateway (der Name "womoraspi" klingt nach Wohnmobil und LTE) wirft untätige Verbindungen gern nach einer festen Zeit raus. Stell testweise 30 oder 60 ein, so wie bei deinem Paho-Test.
2. Hat der Paho-Test eine andere Client-ID benutzt? Wenn irgendwo ein zweiter Client mit womoraspi verbindet, wirft EMQX die alte Session raus (Takeover).
3. Am zuverlässigsten siehst du es in der EMQX-Cloud-Konsole: Dort steht beim Client das Ereignis zum Disconnect mit Grund (z. B. keepalive_timeout, takenover, kicked). Steht da nichts oder nur ein unspezifischer Socket-Fehler, liegt es eher am Netzwerk.
4. Auf dem Pi selbst mitschneiden, dann siehst du, wer das RST schickt und ob vorher PINGREQ/PINGRESP laufen:

sudo tcpdump -i any -nn port 8883 -w mqtt.pcap

Dazu die Instanz auf Loglevel debug stellen und die Zeilen rund um den nächsten Abbruch als Text posten.

[franzda]

@mcm1957 DANKE