Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[mschmid]

Systemdata	Bitte Ausfüllen
Hardwaresystem:	Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
Arbeitsspeicher:	4GB
Festplattenart:	SSD TOSHIBA-TL100, 120GB
Betriebssystem:	Debian Buster
Node-Version:	10.?
Nodejs-Version:	10.15.2
NPM-Version:	6.13.1
Installationsart:	Skript
Image genutzt:	Ja
Ort/Name der Imagedatei:	weiss nicht mehr, inzwischen mehrfach aktualisiert

von einem MQTT-Client aus mache ich ein Subscribe für alle Daten. Das funktioniert einwandfrei, ich kann auch jederzeit neu verbinden, aber nach ein paar Stunden geht das nicht mehr. Im Log liest sich:

2019-11-28 11:04:02.629 - info: mqtt.0 (31897) Client [E1686K6261020021] connected with secret 1574935442611_2868
2019-11-28 11:04:02.635 - info: mqtt.0 (31897) Client [E1686K6261020021] connection closed: TypeError [ERR_INVALID_ARG_TYPE]: The "chunk" argument must be one of type string or Buffer. Received type undefined

Ein Neustart des Adapters löst das Problem für ein paar Stunden.
Ein Update des Adapters von 2.0.4 auf 2.1.1 hat nichts gebracht.

Ich habe keinen Schimmer, wie ich den Adapter debuggen kann. Das Log zeigt ja auch keine Info über den Ort des Fehlers, sonst hätte ich einen Einstieg. JS kenne ich soweit ich das für Webseiten brauche, Node.js und die Interna vom IObroker kenne ich bisher zuwenig.

Als aktive Instanzen (und somit als Datenquelle) habe ich:

admin.0 Admin 109.8 MB
discovery.0 Gerätesuche 49.0 MB
hm-rega.0 HomeMatic ReGaHSS 60.2 MB
hm-rpc.0 HomeMatic RPC 57.7 MB
hm-rpc.1 HomeMatic RPC 58.0 MB
info.0 ioBroker Informationsseite 72.6 MB
mqtt.0 MQTT Broker/Client 98.4 MB
ping.0 PING Adapter 55.2 MB
sia.0 SIA Server für Alarmanlagen 50.6 MB
yr.0 yr.no Wetter 6 * * * *

Mod-Edit: Code/Log in Code Tags gepackt. Bitte benutzt die Code Tags Funktion -> </>
Hier gehts zur Hilfe.

[LordArchidux]

Hallo zusammen,

bei mir gibt es das gleiche Fehlerbild: Ein zentraler Mqtt-Client (in meinem Fall nodeRed) verliert die Verbindung zum Broker und verbindet sich unmittelbar erneut (ohne Erfolg) bis nach einer variablen Anzahl an Versuchen die Verbindung wieder steht. Dazu wird eine Nachricht gelöscht (siehe Log unten). Die Anzahl der Versuche bis zur Löschung liegt dabei auch mal bei niedrigeren Werten. Das Problem ist, dass während dieser Phasen meine nodeRed-Flows nicht funktionieren, bis entweder der MQTT-Adapter neu gestartet wurde oder eben diese automatische Nachrichtenlöschung passiert ist.

Leider fehlt mir hier das notwendige Wissen, um tiefer in die Fehlersuche einzusteigen. Falls es hilft, hier auch einige Versionsinfos zu meinen Adaptern und SW:

• Node.js: v12.16.3
• NPM: 6.14.4
• node-Red: 1.13.0
• MQTT Broker/Client: 2.1.2

Ich würde mich freuen, wenn hier jemand mit mehr Ahnung einsteigen würde, um meinem Vorredner und mir bei der Fehlereingrenzung und/oder -behebung helfen könnte.

Viele Grüße
LordArchidux

mqtt.0	2020-05-22 13:34:38.717	warn	(30375) Client [mqtt_25d91b6d.8a0494] Message 72855 deleted after 176 retries
mqtt.0	2020-05-22 13:34:38.708	info	(30375) Client [mqtt_25d91b6d.8a0494] subscribes on "mqtt.0.shellies.shelly_shutter_WC.online"
[einige weitere Shellies]
mqtt.0	2020-05-22 13:34:23.560	info	(30375) Client [mqtt_25d91b6d.8a0494] subscribes on "mqtt.0.shellies.shelly_shutter_office.online"
mqtt.0	2020-05-22 13:34:38.657	info	(30375) Client [mqtt_25d91b6d.8a0494] connected with secret 1590147278654_1017
mqtt.0	2020-05-22 13:34:23.644	info	(30375) Client [mqtt_25d91b6d.8a0494] connection closed: TypeError [ERR_INVALID_ARG_TYPE]: The "chunk" argument must be of type string or an instance of Buffer. Received undefined
```

[Norb]

Hallo,

ich hatte das gleiche Problem.
Die messageId wird in der server.js mit 32Bit statt 16Bit maskiert.

218 | messageId++;
219 | messageId &= 0xFFFFFFFF;  

So kommt es zu Fehlern bei messageId > 65535, weil unzulässig.

Da auch die messageId 0 nicht zulässig ist, habe ich das Problem bei mir so gelöst:

218 | messageId++;
219 | if (messageId > 65535) {messageId = 1;}  

MfG

[GrillKoenig]

@Norb Danke, das hat das Problem bei mir ebenfalls gelöst.