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...