MQTT2_Client und MQTT2_DEVICE Subsciptions

[joergi]

Mein MQTT-Server ist über die Jahre gewachsen und hat mittlerweile jede Mege Topics.
Die Last meines FHEM wurde immer höher und damit langsamer.

Ich habe dann mit ChatGPT analysiert woran es liegt.

Ergebnis: Durch fehlende attr subscription Definitionen in den MQTT2 Clients wurden alle Topics aboniert. Dies führte natürlich auch zu hoher Last im Netzwerk und auf dem MQTT-Server.

ChatGPT hatte vorgeschlagen alle Topics die ich wirklich brauche über attr subscription in dem Clients zu definieren. Default werden nähmlich alle aboniert (#).

Da ist natürlich unheimlich aufwendig und fehlerträchtig. Deshalb wurde zusammen mit ChatGPT folgende Lösung eintwickelt:

Über eine Erweiterung in 99_myUtils.pm werden alle Topics der MQTT2 Devices gescannt und in attr subscription eingefügt.
Vorraussetzung ts das die Syntax stimmt (:.* am Ende des Topics) und der MQTT2 Client im attr IODev im MQTT2 Device richtig definiert ist.

Zusätzlich zu der 99_myUtils.pm Erweiterung wurde noch eine manuelle Testmöglichkeit entwickelt welche als Ergebniss im fhem log die Auswertung bereitstellt.

In der Datei ist die Erweiterung für 99_myUtils.pm, und die Definitionen in fhem.

Mein FHEM ist jetzt um Größenornungen schneller mit der Web Oberfläche und die Last halbiert.

Vielleicht hilft es ja auch Anderen.
Danke an ChatGPT

Jörg

[joergi]

Noch zu Ergänzung: attr setByTheProgram hat bei mir nicht funktioniert-

[Beta-User]

Magst du das nach MQTT (Forenbereich) verschieben (unten links) und kurz erläutern, wie deine Landschaft drumherum aussieht?

setByTheProgramm funktioniert übrigens v.a. mit MQTT_GENERIC_BRIDGE durchaus.

[joergi]

Ich habe vier FHEM installationen mit unterschiedlichen Aufgaben. Einer davon ist auch der MQTT Server mit Mosquitto aufgesetzt. Alle vier FHEM publishen und subscriben hierhin. Alle haben eine eindeutige clientId.

[Beta-User]

Vielleicht hilft es ja auch Anderen.

Danke zunächst mal für's Teilen (und Verschieben).

Ich würde das mal auf meine ToDo-Liste bzgl. des Projekts "MQTT2_Utils" setzen, siehe um diesen Beitrag herum: https://forum.fhem.de/index.php?msg=1369192.

Wiederfinden des Code-Schnippsels wäre ggf. für andere noch einfacher, wenn auch der Titel noch etwas sprechender wäre.

OT:
Woher kommt eigentlich dieser "Trend" zu "unless"-Statements in allen KI-generierten Codes, die grade so durch das Forum geistern?
Grade noch lesbar ist sowas wie

Code Auswählen Erweitern

return unless $init_done;Aber warum nimmt man da "eq" statt "ne", um das besch... "unless" zu vermeiden:       

Code Auswählen Erweitern

     foreach my $device (keys %defs) {

            next unless ($defs{$device}{TYPE} // "") eq "MQTT2_DEVICE";
            next unless AttrVal($device, "IODev", "") eq $client;
Inhaltliche Anmerkungen:
Das wäre
a) mit devspec2array() einfacher zu lösen, und
b) IODev muss bei dieser Variante zwingend als Attribut hinterlegt sein, was nicht immer der Fall sein dürfte.

Hier eine (ungetestete) Alternative, die das Reading "IODev" auswertet und gleich die "foreach-Folklore" mit beseitigt:

Code Auswählen Erweitern

     my @devices = devspec2array("TYPE=MQTT2_DEVICE:FILTER=IODev=$client");
     for my $device (@devices) {

Zu "setByTheProgram" noch: Wenn man das sowieso beim Start neu zusammenstellt, ist es m.E. sinnvoll, das genau über dieses Attribut auch so kenntlich zu machen, und dann IOWrite() aufzurufen, ähnlich wie es MQTT_GENERIC_BRIDGE macht:

Code Auswählen Erweitern

if(isIODevMQTT2_CLIENT($hash)) {
    # MQTT2 Subscriptions
    IOWrite($hash, "subscriptions", join(" ", @new));
  }

Das schreibt das Zwischenergebnis dann in ein (verstecktes) Internal.

(Das sind zum Teil auch Notizen an mich selbst...)