Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Asgothian]

@lakelounge sagte in mqtt Adapter 4.0.7 Hohe CPU Load:

@asgothian Danke für deine Antwort! Wenn alle Prozessor-Cores zwischen 85 und 100% stehen, kann das nicht wenig sein. Man merkt am Raspberry auch, dass er warm/heiß wird. Kein Script wurde geändert und bis Vorgestern liefen die alle problemlos. Die aufgeführten Operationen können nicht das Problem sein. Es gibt keine schnellen Abfragen von Datenpunkten, keine Heartbeat-Operationen und es laufen auch keine Timeouts, die nicht abgebrochen werden. Bis vor dem Adapter-Update (mqtt 4.0.7) lagen die Prozessor-Cores meist bei 1 bis 10 % im Durchschnitt. Klar gehen die zwischendurch hoch, aber dann auch wieder runter. Das hat sich nun geändert. Jetzt bleiben sie hoch und die ganze Hausautomation arbeitet mit Verzögerungen.

Prozessor cores Zwischen 85% und 100% sind recht weit von den vorher genannten 2.8 bis 3 weg. Aber seis drum.

Ich würde initial alle selbst geschriebenen Skripte anhalten um zu verifizieren ob die Last durch das System oder durch selbst geschriebene Skripte entsteht.

Danach die Skripte eines nach dem Anderen reaktivieren, sofern die Last herunter gegangen ist.

A.

[lakelounge]

@bananajoe wie schon geschrieben, treffen die Dinge von @Asgothian nicht zu. Heartbeat hab ich keine, Timeouts (derzeit keiner aktiv) und meine Datenpunktabfragen bzw. gelegentliches schreiben in diese hat nie ein Problem gemacht. Ich muss mal sehen, ob ich den mqtt-adapter nochmal auf 3.0.7 runter bekomme. Damit ging alles problemlos. Ich hab vorgestern Abend das Update auf 4.0.7 gemacht und gleich am nächsten Morgen ist mir das verzögerte Licht-schalten aufgefallen. Aber Danke für die Hilfe und die Anregungen!

[Homoran]

@asgothian sagte in mqtt Adapter 4.0.7 Hohe CPU Load:

Ein Load von 2,8% - 3% ist vergleichbar wenig

reden wir hier von cpu Last in % oder von load average, die über den Daumen die Anzahl Kerne nicht überschreiten sollte. Eine Load average von 3 wären dan etwa 75% Auslastung.

[mickym]

Kann ich auch nicht bestätigen - ich vermute mal dass Du eine Endlosschleife drin hast, in dem Du Zustände publishst. Ggf. erst mit Änderung sodass das Verhalten nicht sofort auftritt. Und glaube mir, bei mir läuft einiges über den Adapter

und meine CPU Last ist im grünen Bereich

Bei sind es max . 50% und ja dann habe ich vielleicht ein Verzögerung von 1-2s

Dazu läuft auch noch ein Desktop mit Firefox auf dem Raspberry - der ca. 2-3% Dauerlast erzeugt. Also wäre ich in Ruhe bei ca. 10% - was im Vergleich zu dem was bei Dir ohne mqtt läuft, ja sonst vergleichsweise hoch ist.

Ich weiß aber das ist der DVD Adapter - alle Viertelstunde und der Linux Device Adapter den ich inzwischen auf 35 Minuten eingestellt habe, sodass der nicht zur gleichen Zeit aktiv wird.

Und das was hier drüberläuft über den mqtt-Adapter ist mehr oder weniger Grundlast - alle Shellies die alle 30s - ihren Momentanverbrauch melden etc.

[lakelounge]

@homoran also ich habe von einer CPU-Last von 85 - 100 % je Core und einer Load von 2,8 bis über 3 gesprochen.

[mickym]

@lakelounge sagte in mqtt Adapter 4.0.7 Hohe CPU Load:

@homoran also ich habe von einer CPU-Last von 85 - 100 % je Core und einer Load von 2,8 bis über 3 gesprochen.

Klingt nach 100% Endlosschleife - nimm mal Zustände publishen raus.

[BananaJoe]

@lakelounge genau, zeig mal bitte die Einstellungen deines MQTT Adapters

[lakelounge]

@bananajoe gerne, sobald ich wieder Zuhause bin …

[lakelounge]

@bananajoe vielen Dank schon mal im Voraus für die Hilfe! Bei den Einstellungen lasse ich mir sehr gerne helfen. Bin eben angekommen und zum Glück ist die Auslastung heute über den Tag normal geblieben. Ich muss das weiter beobachten …

[mickym]

@lakelounge Tja wie ich vermutet habe - Zustände schicken und redudant wieder reinholen.

lakelounge* bei eigenen States (hier zeigt sich in meinen Augen, dass Du nicht wirklich weißt, was die Parameter bedeuten) - wegmachen - ich denke so einen Adapter gibts nicht. Und subscribe Patter # ist auch Käse, wenn man dahinter dann States eingrenzt. Mit # holst Du alles. Bei den eigenen States gehört max. noch die mqtt- Instanz also zum Beispiel mqtt.0.* - so wie es am Anfang drin stand rein. Wie gesagt bei der Konfig wundert mich das nicht - hat aber auch 0,0 mit der Adapterversion zu tun. Was Du unter Umständen machst - ist - dass Du damit im TR-04 Adapter rumpfuschst.

Ansonsten habe ich hier die Dinge zusammengefasst - ich weiss ja noch nicht mal ob Du Deinen Adapter als Broker oder Client betreibst: https://forum.iobroker.net/topic/57365/mqtt-broker-empfängt-daten-sendet-aber-nicht-an-client/8?_=1662032439387

[lakelounge]

@mickym Erst einmal vielen Dank für deine ausführliche Hilfe! Ich hatte weiter oben geantwortet, dass ich mosquitto als Broker benutze und ioBroker als Client. Danke für die Erklärung der Pattern! Ja, da wusste ich bei einigen, trotz Google-Suche nicht, was sie genau bedeuten. Bei der Konfig wundert mich nur, dass diese jetzt 2 Jahre funktioniert hat und mir dann 2 Mal die Performance davonfliegt wenn ich den 4.0.7 Adapter installiere. Aber das kann auch Zufall sein.

Danke dir und allen anderen in diesem Thread für deine/eure Hilfe!

[lakelounge]

@mickym @BananaJoe ich hab jetzt noch etwas weiter gesucht und poste das mal hier. Ich habe die mqtt-Einstellungen entsprechend eurer Tipps und Dokumentationen angepasst.
Nun ist im mqtt.2. Screenshot von @mickym die Checkbox „Sende auch Zustände (ack=true)" angeklickt. Das hab ich auch gemacht, weil ja die TR-04 Daten rausgeschickt sollen.

Ich habe zwei Delock-Steckdosen (mit Tasmota 12.1.1) im Einsatz. Bei einer davon laufen unter stat Tausende von Meldungen auf, wenn ich „Sende auch Zustände (ack=true)" anschalte (reproduzierbar):

Hier der gesamte „Baum“ aus dem mqtt-Explorer:

Es ist „RESULT“, das immer zwischen "Command":"Unknown" und "ON" hin- und herschaltet. Das passiert bis zu 50.000 Mal in kürzester Zeit (da schließt sich der Kreis zur hohen Load vom Raspberry).
Ich schalte diese Steckdosen nicht über mqtt! Ich messe nur. Es gibt keine Skripte, die diese Steckdosen ansprechen etc.

Ich hab die Delock-Steckdose neugestartet, eine neue Firmware aufgespielt etc. die vielen Meldungen bleiben bzw. kommen immer wieder. Ich verstehe nicht ganz, wer den stat genau sendet. Die Meldungen laufen sogar auf, wenn die Steckdose grade neu startet.

Hat jemand eine Idee, warum das so ist?

Das einzige was ich im ioBroker mit der Steckdose mache ist folgendes Script, welches die Verbrauchsdaten in Datenpunkte einträgt.

on({id: 'mqtt.0.home.egw2.switch01.tele.SENSOR', change: 'any'}, function (obj) {
    var mqttSwitch01val = getState('mqtt.0.home.egw2.switch01.tele.SENSOR').val;
    var theValue;
    try {theValue = JSON.parse(mqttSwitch01val);
        var mqttSwitch01Power = theValue.ENERGY.Power;
        var mqttSwitch01GesamtW = theValue.ENERGY.Total;
    } catch (e) {
       console.error('Cannot parse: ' + getState('mqtt.0.home.egw2.switch01.tele.SENSOR').val);
    return;
}
    setState('0_userdata.0.Energie.mqtt.switch01.power', mqttSwitch01Power, true);
    setState('0_userdata.0.Energie.mqtt.switch01.Switch01VerbrauchGesamt', mqttSwitch01GesamtW, true);
});

Ich weiss zwar jetzt, wie ich die hohe Load des Raspberry runterbringe, aber nicht, was genau das Problem verursacht und vor allem nicht, warum das immer nur mit dem 4.0.7 mqtt-Adapter auftritt.

Bin für alle Anregungen dankbar!

[mickym]

@lakelounge Das Problem ist - dass Du sowohl publishen willst - also auch Daten sammelst - das ist bei Senden von Zuständen Endlosschleifen vorprogrammiert.

Ich empfehle Dir wenn Du einen mosquitto Broker hast - genauso wie ich 2 Instanzen zu nehmen - eine um quasi Zugriff auf den gesamten Inhalt des Brokers zu haben - und die 2. Instanz um zu publishen.

In dieser Instanz wird der mosquitto abgebildet und einzelne States gepublished - die es nicht in einem Adapter gibt:

So sieht meine Instanz aus, um quasi dem Inhalt meines gesamten mosquitto Brokers im iobroker zur Verfügung zu haben - damit kannst auch einzelne States publishen indem Du einfach Datenpunkte anlegst.

Die 2. Instanzen dient dazu um ganze Objekt Bäume eines Adapters zum Beispiel tr-064 unter einem Präfix wie bei Dir zu publishen. Es wird aber nicht mehr importiert - deswegen gibts da ein Dummy als Präfix

Man kann die Zustände schicken - wenn Du keine Änderungen publishst. Nachdem das unter einem eigenen Präfix erfolgt, sollten Deine Geräte nichts mitbekommen. Ich mache das bewusst nicht, da mich alte Zustände nicht interessieren von der FritzBox.

Also für die Zustände in der 2. Instanz geht das auch:

Die Instanz mit der Du aber nur den mosquitto abbilddest und einzelne States publishst die nicht von Adaptern stammen - ist nichts angehakt.

[lakelounge]

@mickym Wow! Herzlichen Dank für deine mega-ausführliche Antwort! Ich habe verstanden, um was es geht und werd das asap umsetzen.

Meine Lösung wäre jetzt so gewesen:

abonniert ist nur home/# - darauf senden alle Geräte, von denen ich Werte im ioBroker möchte
published wird vom ioBroker nur unter lakelounge-

Aber ich arbeite noch in Ruhe deine Anleitung durch ;-)

Danke nochmal und schönen Abend
.

[mickym]

@lakelounge Nei - das Prefix muss immer mit einen / enden und ich empfehle meine Konfig. So was ist gefährlich - das gibt nur ewig lange Strings - die Topics müssen immer mit dem Trenner / - sonst gibts keine Hierarchien. ;)

[lakelounge]

@mickym Verstehe! Und, Asche auf mein Haupt, dass ich den mqtt-Adapter verdächtigt habe! Hab einen Slash ans Ende gemacht … Deine Lösung mach ich die Tage … Man muss ja leider immer nebenbei auch noch was arbeiten :-)

[lakelounge]

@mickym hach … die Load ist wieder bei 0.14 … was ein Glück! :-)

[BananaJoe]

So, moin. Hab gerade mal alles gelesen ... und alles ist gesagt dank @mickym

[SRo769]

Hallo zusammen. Also ich habe seit 3 Tagen nach Update auf Adapter-Version 4.07 (MQTT Broker/Client) das gleiche Problem.
Konfiguration:
1x Raspberry-Pi (Dietpi) mit Node-Red und MQTT-Server
2x IOBroker auf 2 unterschiedlichen Proxmox-Systemen (Adapter im Client-Modus) (Proxmox-Systeme 2x Intel-NUC)

Konfiguration lief seit ca. 2 Jahren ohne Probleme. Seit 3 Tagen steigt nun zu unterschiedlichen Zeiten die Gesamtbelastung beider Proxmox-System bis Anschlag an und geht von allein nicht mehr runter. Das Stoppen und erneute Starten der beiden Adapter in den IOBrokern beendet den "Spuk" und alles ist wieder normal. Auf beiden System sind zusätzliche MQTT-Adapter sowohl im Server- als auch im Clientmodus aktiv. Diese verursachen die Belastung nicht.
Den Raspberry-Pi und seine Systeme sind bereits neugestartet und auf aktuellem Software-Stand.
Ich werde jetzt einen der beiden Server mal auf die biss dato laufende Version des MQTT-Adapters downgraden. Vielleicht hilft das ja erstmal.

Bin für weitere Ideen/Vorschläge sehr dankbar.

[Homoran]

@sro769 sagte in mqtt Adapter 4.0.7 Hohe CPU Load:

Bin für weitere Ideen/Vorschläge sehr dankbar.

Hast du die Konfiguration verglichen mit dem was hier besprochen wurde?