MQTT best current practice

[Beta-User]

dann ist das aber noch ein Schritt weiter

Nach meinem Verständnis geht es hier die ganze Zeit bereits eigentlich um diesen weiteren Schritt: Statt durch "Tonnen von (statisch gesetzten) Attributen" soll zumindest im Bereich von klar umrissenen "MQTT-Familien" ein framework _vorab_ die Aufgabe erledigen, anhand von wenigen Uservorgaben (Martins neue Attribute) "sinnvolle Standard-FHEM-Entities" (hier als MQTT2_DEVICE-Instanzen) zu bilden.

Was heute in attrTemplate (insbesondere, aber nicht nur (!) als "split"-Varianten) enthalten ist, verfolgt auch (allerdings in den heute möglichen Attributen statisch) den Ansatz: Das Ergebnis ist funktional identisch, egal, ob es z.B. ein schaltbarer Kanal aus einem Aktor mit vielen Relays ist, oder z.B. ein Thermostat, bei dem die Solltemperatur eben immer "desired-temp" als Readingnamen hat, egal, was dem "Übersetzer" aus der zigbee-, xy- oder z-Welt gerade eingefallen ist, wie das dort benannt werden könnte.

Ziel wäre es "nur", die Vorgehensweise zu ändern, und das ganze zu dynamisieren, damit man (automatisch) in einem Zug alles geändert bekommt, wenn sich z.B. bei zigbee2mqtt was grundlegendes ändern sollte.

[Prof. Dr. Peter Henning]

Alles nett. Aber bei den ganzen Templates fehlt mir vor allem eines: Eine Dokumentation. Warum etwas so gelöst worden ist, was man tun kann, um es zu ändern etc.

Ich habe das gemerkt, als ich ein neues ebusd-Interface eingebaut habe: Massig MQTT-Templates - aber keinerlei Erklärung. Ergo habe ich alles wieder von Hand gemacht.

LG

pah

P.S.: Ich votiere nach wie vor für eine Ontologie. Und zwar sowohl von Geräten, Gerätekombinationen - als auch von Nutzungsszenarien (Licht an, Licht aus, Licht an wenn..., Licht aus nach xxx Sekunden etc.).

[Guybrush]

ich hab das in er semantic map in grundzügen drin. Mach doch mal konkrete Vorschläge wie das definiert sein könnte.

[Beta-User]

Alles nett. Aber bei den ganzen Templates fehlt mir vor allem eines: Eine Dokumentation. Warum etwas so gelöst worden ist, was man tun kann, um es zu ändern etc.

Puh...

Also: Im Quellcode (klar: nicht optimal, aber im Wiki zu attrTemplate sollte es stehen...) steht fast immer (über dem betreffenden template) die (Foren-) Quelle drin, aus der man häufig auch die "immer gleichen" Diskussionen um gute Reading-Namen, den Nachrichtenkreislauf usw. nachvollziehen kann. Weil es mir irgendwann leid war, diese "immer gleiche" Diskussion zu führen, ist meine erste Reaktion auf die Anfrage für ein neues Gadget, man möge doch bitte zuerst den Weg gehen, wie er sich aus "Schritt für Schritt" ergibt, da ist in den Grundzügen erklärt, wie die Attribute aufeinander aufbauen. Die Transferleistung, das dann im eigenen Sinne anzuwenden, werde ich keinem abnehmen.
Falls du also Verbesserungsbedarf (v.a.) an der (zusammenfassenden) Doku siehst - feel free.

Teils finden sich in desc, teils in den betreffenden Foren dann auch Hinweise, wenn ich Dinge für nicht gut gelöst hielt, die betreffenden User aber nicht willens oder in der Lage waren, die notwendigen Infos beizubringen oder unbedingt an ihrer "Lösung" festgehalten haben.

ebusd-Interface eingebaut habe: Massig MQTT-Templates - aber keinerlei Erklärung.

Gerade das ist ein Beispiel für jemand, der bei der Mitarbeit "beratungsresistent" war (soweit es dieses dummy-spamming betrifft). Daher finden sich diese Teile auch nicht unmittelbar in mqtt2.template, und meine mühsamen Versuche, jemanden zu motivieren, das (endlich) besser zu machen, wirst du auch mühelos finden können... Also: feel free, es besser zu zeigen, auch an dieser Stelle!

(Ähnliches gilt für Shelly-rpc, aber da gibt es für "normale on/off-Devices wenigstens einen Vorschlag von betateilchen. Muss mal schauen, ob ich das schon eingecheckt habe, das ständige Gemaule hat mich zugegebenermaßen einigermaßen demotiviert).

Nochmal zurück zu dem Vorschlag, aus MQTT2_DEVICE nicht direkt SetExtensions aufzurufen.

Die aktuelle Lösung von Guybrush sieht vor, setList in etwa so zu befüllen:

Code Auswählen Erweitern

attr shelly1g4_********* setList switch_0:on,off { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_773c31e37677a16e', $EVENT) }

Das wäre "überflüssig, wenn man statt (aktuell Zeilen 409f des M2D-Codes)

Code Auswählen Erweitern

  my $cmd = $sets->{$cmdName};
  return SetExtensions($hash, $cmdList, @a) if(!$cmd);
sowas machen würde:

Code Auswählen Erweitern

  my $cmd = $sets->{$cmdName};
  if(!$cmd) {
    return MQTT2_DISCOVERY_SetExtensions($hash, $cmdList, @a) if defined MQTT2_DISCOVERY_SetExtensions;
    return SetExtensions($hash, $cmdList, @a);
  }
Kann MQTT2_DISCOVERY_SetExtensions() nicht mit den Infos anfangen, wird das einfach dann an das "normale" SetExtensions weitergereicht. Hoffe, der Gedanke ist jetzt klarer?

[Guybrush]

ja ist er. ich schau mir das mal an. das wäre dann aber optional als attribut umzusetzen. mit setExtensions hab ich selbst jedenfalls noch nicht so viel gemacht.

[Beta-User]

ich schau mir das mal an. das wäre dann aber optional als attribut umzusetzen.

Nope: wenn es die Funktion gibt (und setList den Befehl nicht enthält), wird immer deine Zwischenfunktion aufgerufen, wenn diese vorhandenen ist, also das Modul auch geladen.

Dann kannst du intern prüfen, ob das ein gültiger set-command (ggf. für den "Channel") ist, oder nicht. Wenn nein: Argumente durchreichen, das ist schon alles.

Zum Testen: mal in $cmdList zusätzlichen was reinschreiben, dann weiterreichen und schauen, was du in fhemweb an Kommando auswählen kannst...

[Beta-User]

So, jetzt hat Guybrush es geschafft, hier läuft jetzt auch eine (modifizierte) Fassung von MQTT2_DISCOVERY.

Das liefert dann für einen zigbee2mqtt-Bewegungsmelder (ohne setList-Attribut) auf die Frage:

Code Auswählen Erweitern

{getAllSets('Bewegungsmelder_Eingang')}

funnyTesting:a,b attrTemplate:?,General_Info,MQTT2_CLIENT_general_bridge, [...]

@martinp876 und Guybrush
Bitte um Rückmeldung, ob Interesse an einem intensiveren gemeinsamen review besteht, um das in der hier gezeigten Richtung auszubauen, damit man z.B. für ein "einfaches Shelly-Licht" weder ein readingList-Attribut anlegen muss, noch ein setList-Attribut benötigt?

(Anm: Die MQTT2_DISCOVERY funktioniert vermutlich nicht "solo", man benötigt auch die anderen Dateien aus dem github repo)

[Guybrush]

ich schau mir das am WE mal in Ruhe an. Und ja, natürlich besteht Interesse. Ich hab das Modul ja für die Allgemeinheit rund gemacht. Sieht man doch schon an der umfassendsten Doku  Also sollte es auch so komfortabel wie möglich werden um die Akzeptanz zu steigern und dem einen oder anderen aus dem Attributjungle verhelfen.

[Beta-User]

@Rudi:

a) Der Plan wäre, über dieses Modul ggf. dann auch ein paar "generische setter" zu ergänzen. Manches ginge sicher auch direkt über das MQTT2_DEVICE-Modul, anderes wäre ggf. dann nur vorhanden, wenn tatsächlich das MQTT2_DISCOVERY-Modul geladen wäre. Dementsprechend wäre es hilfreich, die Doku zu den betreffenden set-Befehlen anzeigen zu können, was derzeit nicht geht, weil eben (so mein Verständnis) nur jeweils die commandref zum TYPE durchsucht wird.
Eventuell wäre es möglich, einen "versteckten" allgemeinen Teil der commandref zu generieren, bei dem das jeweilige Modul dann angeben kann, für welche Ziel-TYPE(s) der set-Befehl wäre? Also ähnlich wie das heute bei der Attribut-Hilfe schon umgesetzt ist...

b) Ich hatte gestern ein paar harte Abstürze beim Versuch, "reload MQTT2_DEVICE" abzusetzen. Dachte erst, es läge am coding (was zunächst auch teils der Fall war), die im log zu findende Ursache ist aber wohl anderer Natur und hat sich dann später bei "reload MQTT2_DISCOVERY" wiederholt:

Code Auswählen Erweitern

2026.09.17 20:46:44 1: PERL WARNING: Use of uninitialized value in regexp compilation at fhem.pl line 4195.
Can't use an undefined value as a subroutine reference at fhem.pl line 4203.
Bei reload wird wohl die ParseFn() der Module gelöscht. Wenig hilfreich für das kommende Testen, wenn man FHEM jedes Mal neu starten muss.

@Guybrush:
Als Fingerübung wäre mein Vorschlag, zunächst mit "clearReadings" (als set-Befehl am Zieldevice) anzufangen, und dann mit "rebuildDevice", wobei ich dazu gleich funktional die Frage hätte, warum du da nicht die "devicetopic"-Variante ziehst, mehre Zuweisungen zu machen:

if the value does contain an equal sign (, then it is interpreted as

    Var1=Var1Value Var2="Value with space" Var3=...

and $Var1,$Var2,$Var3 are replaced in the readingList, setList and getList attributes with the corresponding value.

Das würde imo das Nebeneinander von neuer und alter Welt beim "rebuild" eventuell vereinfachen?

Ansonsten wäre noch die Frage, was man ggf. sinnvollerweise als gemeinsames Testgerät hernehmen könnte. Im Keller hier liegt noch ein Tasmota-Ding rum, was interessant sein könnte: Ein Steckdosen-Zwischenstecker mit eingebautem Nachtlich - zwei "channels", der eine ein einfaches on/off-Device, der andere ein rgb-Licht. Falls du nichts vergleichbares hast: bitte melden, hier sind zwei vorrätig (weiß aber nicht, ob beide Tasmota-geflasht sind).

Ach so: Den Code habe ich noch nicht angeschaut, muss erst mein Perl etwas auffrischen (und in dem Zug zunächst ein paar andere Hausaufgaben erledigen). Das sieht mir aber nach ziemlich umfangreichem rework aus, eventuell wäre es einfacher, zunächst das "Basismodul" als gepackagtes Modul aufzusetzen, und dann die ganzen Erweiterungen nach und nach da reinzuziehen. Alles auf einmal wird vermutlich schwierig...