MQTT weiterleiten

[tomix]

Hallo zusammen

Ich habe ein ESP32 mit einem Touchscreen als MQTT Client. Aktuell sende ich bei einem entsprechende Klick auf das Display ein  client.publish("outTopic", "Springbrunnen 0"); bzw. ein "Springbrunnen 1". In FHEM dann ein entsprechendes notify:

Code Auswählen Erweitern

defmod MQTT2_arduinoClient_notify_2 notify MQTT2_arduinoClient:outTopic:.Springbrunnen.1 set DoseSchachtGarten on

Bei einem Gerät keine Sache. Nun frage ich mich aber wie ich das für die 11 Storen lösen soll. Auf dem Display habe ich eine Ansicht und kann dann alle Storen wählen oder die einzelnen Fenster anklicken und nachher runter-, hochfahren, stopp,... wählen.

Sinnvoll wäre direkt an die entsprechenden Aktuatoren eine Nachricht zu senden (ebenfalls MQTT-Geräte). Da habe ich allerdings keinen Plan wie das realisiert werden könnte, da der ESP32 via MQTT mit dem Server/FHEM verbunden ist.

Aktuell werde ich daher mal das senden einer Nachricht in der Form "Storen WELCHER WAS" für jeden Storen umsetzen. Dann ein notify auf Storen und versuchen ein set WELCHER WAS auszugeben. Schlaue Idee oder viel einfacher lösbar?

Gruss
tomix

[Beta-User]

Vermutlich wäre die stringenteste Lösung, direkt die Befehle durch einen Perl-Aufruf aus der readingList zu ermitteln. Du scheinst ja immer eine Gruppe von Geräten zu haben, die "gleich" behandelt werden soll (on/off-Geräte, die Storen), und gewisse "Sonderfälle" (wie "alle Storen").

Vielleicht vorab mal ein paar "Steinbrüche", in denen du dich umschauen könntest:
- Milight-Fernbedienung+Sidoh-Hub für direkte Ansteuerung von Rollläden etc.: https://forum.fhem.de/index.php/topic,103493.msg1098434.html#msg1098434 (da kommt aber JSON-Payload, was es etwas verkompliziert in der weiteren Verarbeitung)
- Zuordnung-Hash von übergebenem Wert auf ein Device (allerdings in einem notify) https://forum.fhem.de/index.php/topic,123886.msg1192757.html#msg1192757.

Ich würde so vorgegen:
- eine Funktion in myUtils definieren, in die übergibst du $EVENT und splittest das so auf, wie du das brauchst (anscheinend (!) nur Klartext-Name und 0/1?))
- Für jede "gleich" zu bedandelnde Gruppe von Devices jeweils den Hash $targets neu belegen. Gibt es dann $targets->{<übergebener Klartext-Name>}, wird der danach folgende Funktionsblock verwendet (und z.B. etwa 1 als "on" verstanden), wenn nicht, kommt der Test für die nächste Variante von $targets (die Storen), usw. usf.

(Schon klar, dass dir das vielleicht ziemlich fremd vorkommt, aber man gewöhnt sich schnell dran...).

[tomix]

Vermutlich wäre die stringenteste Lösung, direkt die Befehle durch einen Perl-Aufruf aus der readingList zu ermitteln. Du scheinst ja immer eine Gruppe von Geräten zu haben, die "gleich" behandelt werden soll (on/off-Geräte, die Storen), und gewisse "Sonderfälle" (wie "alle Storen").

Ich habe nicht gewisse Sonderfälle wie alle Storen, da beliebige «markiert» werden können.

Die aktuelle Lösung funktioniert wohl (kann es gerade nicht testen, der dummy mySwitch1 macht auf jeden Fall das was ich erwarte).

Auf dem ESP die Storen mal definiert:

Code Auswählen Erweitern


const char storenname[MAX_STOREN][MAX_LENGTH] {
  {"MQTT2_Shelly25_2OG_SUED_D315B0"}, // Fenster DG
  {"MQTT2_Shelly25_1OG_Zimmer_OST_D30D75"}, // Fenster 1. OG Südost
  {"OGSuedwest"}, // Fenster 1. OG Südwest
  {"MQTT2_Shelly25_EG_Kueche_6B0284"}, // Fenster EG Küche
  {"MQTT2_Shelly25_EG_ESSTISCH_SUED_6B00C0"}, // Fenster EG Süd
  {"EGSuedwest"}, // Fenster EG Südwest
  {"OGSuedwest"}, // Fenster 1. OG Südwest
  {"OGNordwest"}, // Fenster 1. OG Nordwest
  {"EGSuedwest"}, // Fenster EG Südwest
  {"EGWest"}, // Fenster EG West
  {"mySwitch1"}, // Fenster EG Nordwest   
};

und ein Array für die «aktiven»

Code Auswählen Erweitern

bool storenaktiv[MAX_STOREN] {
  false, // Fenster DG
  false, // Fenster 1. OG Südost
  false, // Fenster 1. OG Südwest
  false, // Fenster EG Küche
  false, // Fenster EG Süd
  false, // Fenster EG Südwest
  false, // Fenster 1. OG Südwest
  false, // Fenster 1. OG Nordwest
  false, // Fenster EG Südwest
  false, // Fenster EG West
  false, // Fenster EG Nordwest   
};


Touch auf ein Fenster setzt den entsprechenden entsprechend Array Eintrag von storenaktiv auf true. Wird dann auf wippzu geklickt, wird folgende Schlaufe durchlaufen:

Code Auswählen Erweitern


void sendcmd(const char* cmd) {
  Serial.println("Send Command");
  for (int i = 0; i < MAX_STOREN; i++) {
    if (storenaktiv[i]) {
      snprintf (msg, MSG_BUFFER_SIZE, "Storen %s %s", storenname[i], cmd);
      Serial.printf("Storen Command: %s", msg);
      Serial.println("");
      client.publish("outTopic", msg);
    }
  }
}

MSG_BUFFER_SIZE ist noch zu klein und wippzu auch noch kein sinnvoller Befehl (aber close würde zu close führen;-) ).

FHEM seitig kommt dann folgendes an:

Code Auswählen Erweitern


... MQTT2_DEVICE MQTT2_arduinoClient outTopic: Storen mySwitch1 wippzu
... MQTT2_DEVICE MQTT2_arduinoClient outTopic: Storen MQTT2_Shelly25_2OG_SUED_D315B0 wippzu
... MQTT2_DEVICE MQTT2_arduinoClient outTopic: Storen MQTT2_Shelly25_1OG_Zimmer_OST_D30D75 wippz
... MQTT2_DEVICE MQTT2_arduinoClient outTopic: Storen OGSuedwest wippzu
...


Dazu ein notify wie folgt:

Code Auswählen Erweitern


defmod MQTT2_arduinoClient_notify_5 notify MQTT2_arduinoClient:outTopic:.Storen.* set $EVTPART2 $EVTPART3;


Ich habe zuerst $EVTPART0. set mySwitch1 $EVTPART0 brachte dann die Erleuchtung, als dort ein outTopic ankam.

wippzu wäre «x_configuration ShutterTiltChange1 -18», also $EVTPART4 und 5 anhängen und den langen String senden oder könnte das auch elegant umgeschrieben werden falls ein wippzu ankommt?

Gruss
tomix

[Beta-User]

Vorab: Hut ab, du hast da was nettes zusammengebaut!

Ich habe nicht gewisse Sonderfälle wie alle Storen, da beliebige «markiert» werden können.
[...]
wippzu wäre «x_configuration ShutterTiltChange1 -18», also $EVTPART4 und 5 anhängen und den langen String senden oder könnte das auch elegant umgeschrieben werden falls ein wippzu ankommt?

Wenn du den ankommenden Payload eh' untersuchen musst (z.B. ist $EVTPART4 vorhanden?), brauchst du "sowieso" Perl (oder irgendwelche trigger-regexp-Klimmzüge).

Von daher würde ich das weiter ohne notify und dafür eben mit einem myUtils-Code lösen. Was spricht denn aus deiner Sicht gegen dieses Vorgehen?
Damit kannst du dir auch die mapping-Klimmzüge auf der ESP-Seite sparen.

"x_configuration" als Kommando kommt mir komisch vor. Scheint Tasmota mit Venetian-blind-Option zu sein? Es gibt dafür auch ein attrTemplate, mit dem man den Drehwinkel gesondert ansteuern können sollte.

[tomix]

Von daher würde ich das weiter ohne notify und dafür eben mit einem myUtils-Code lösen. Was spricht denn aus deiner Sicht gegen dieses Vorgehen?

Das KISS-Prinzip, der notify ist aktuell brutal simple, den kapier sogar ich.

Damit kannst du dir auch die mapping-Klimmzüge auf der ESP-Seite sparen.

Auf irgendeiner Seite muss ich es mappen. Der Traffic ist halt so etwas grösser .

"x_configuration" als Kommando kommt mir komisch vor. Scheint Tasmota mit Venetian-blind-Option zu sein? Es gibt dafür auch ein attrTemplate, mit dem man den Drehwinkel gesondert ansteuern können sollte.

Ich weiss, ich weiss . Aber aktuell gibt es nur die Befehle für eine bestimmte Position anfahren, ganz zu, auf oder halb. Da sollte ich auch nochmals ran.

Gruss
tomix

[Beta-User]

KISS - gutes Argument...

Wenn du den C-Code verstehst, würdest du das auch als Perl-Code verstehen, unabhängig von der Frage, ob du ein paar Byte mehr oder weniger übermittelst . Auf der FHEM-Seite ist es halt schneller geändert, weil du nicht umflashen musst .

Was das attrTemplate angeht, dämmert mir da was... Aber war es nicht so, dass zwar das devStateIcon feste Stufen hat, aber im Prinzip auch der Drehwinkel beliebig zwischen den min- und max-Werten liegen kann? (Es müßte eigentlich einen slider in der Detailansicht des Geräts geben, oder über das FHEM-Kommandofeld einzugeben sein).

[tomix]

Auf der FHEM-Seite ist es halt schneller geändert, weil du nicht umflashen musst .

Ich gehe davon aus, dass ich eh umflashen muss, wenn ich etwas ändern will, da es sich dann kaum, um den auszuführenden Befehl handeln wird.

Aber war es nicht so, dass zwar das devStateIcon feste Stufen hat, aber im Prinzip auch der Drehwinkel beliebig zwischen den min- und max-Werten liegen kann? (Es müßte eigentlich einen slider in der Detailansicht des Geräts geben, oder über das FHEM-Kommandofeld einzugeben sein).

Es gibt ein Slider. Nützt mir aber nichts, wenn ich etwas zu oder auf kippen will, da das Bedienteil (der ESP mit dem TFT) nicht weiss, bei welchem Wert der Storen steht. Wenn ich dann wirklich mal zu viel Zeit habe, könnte das natürlich auch noch je Fenster visualisiert werden (also die Werte an das Bedienteil übermittelt werden). Aber abgesehen davon, dass es cool aussehen würde, sehe ich da keinen nutzen.

Gruss
tomix

[tomix]

Mal ein paar Bilder. Hauptzweck ist eigentlich nur eine Temperaturanzeige für Innen und Aussen. Ich dachte dann ich werte gleich noch den Regensensor vom Dachfenster aus (Wolke mit Regen), gebe die aktuelle Leistung der PV-Anlage aus usw.

Da ein Touchdisplay kam ich dann auf die Idee auf einer weiteren Seite (unten links oder rechts klicken zum Blättern) eine Storensteuerung zu realisieren. Der Befehl wird dann jeweils an die grünen Fenster gesendet. Umschalten Grün/Rot durch Fenster anklicken oder keine (Kreuz) bzw. alle (Hacken).

Gruss
tomix

[tomix]

Ein if mit elsif und es funktioniert mit einem notify:

Code Auswählen Erweitern


defmod MQTT2_arduinoClient_notify_5 notify MQTT2_arduinoClient:outTopic:.Storen.* {\
if ($EVTPART3 eq "wippauf") {\
  fhem("set $EVTPART2 x_configuration ShutterTiltChange1 18");;\
} elsif ($EVTPART3 eq "wippzu") {\
  fhem("set $EVTPART2 x_configuration ShutterTiltChange1 -18");;\
} else {\
fhem("set $EVTPART2 $EVTPART3");;\
}\
}

und sogar das funktioniert:

Code Auswählen Erweitern


attr Velux_3 eventMap on:Auf off:Zu on:open off:close

und dann klappt es auch mit dem Rolladen der Dachfenster mit open und close. Was wäre da die richtige Lösung?

Die Dachfenster müsste ich dann noch zeichnen usw. Nun muss zuerst mal eine Lösung her um das schön einbauen zu können. Danach wird dann schon noch der eine oder andere Wunsch kommen.

Gruss
tomix

[Beta-User]

Sieht nach ganz schön viel Arbeit aus, die da in dem Display steckt! Hut ab!

Da du jetzt eh' schon bei Perl im notify angekommen bist, wäre der Weg nach myUtils (direkt aus MQTT2_DEVICE heraus) übrigens auch nicht mehr weit. Falls du Fragen hast (z.B. wie man an die Info kommt, die im notify unter $EVTPART2 zu finden ist), kannst du dich ja melden.

(Das mit dem eventMap sieht mir etwas "von hinten durch die Brust ins Auge" aus. Ich bin eigentlich immer froh, wenn ich das nicht brauche).

[tomix]

Da du jetzt eh' schon bei Perl im notify angekommen bist, wäre der Weg nach myUtils (direkt aus MQTT2_DEVICE heraus) übrigens auch nicht mehr weit. Falls du Fragen hast (z.B. wie man an die Info kommt, die im notify unter $EVTPART2 zu finden ist), kannst du dich ja melden.

Da gibt es noch ein paar andere wichtigere Baustellen in FHEM beim mir.

(Das mit dem eventMap sieht mir etwas "von hinten durch die Brust ins Auge" aus. Ich bin eigentlich immer froh, wenn ich das nicht brauche).

Bis jetzt habe ich das nur gebraucht um etwas deutsch darzustellen bzw. beim Storen vom Dachfenster, da on und off dort einfach keinen Sinn gibt.

Gruss
tomix

[Beta-User]

Bis jetzt habe ich das nur gebraucht um etwas deutsch darzustellen bzw. beim Storen vom Dachfenster, da on und off dort einfach keinen Sinn gibt.

Nun ja, so hatte ich das auch mal - und bin froh, dass ich das in großen Teilen jetzt wieder auf den (englischen) Standardwerten habe. Für FHEMWEB-Darstellung sind eh' Symbole (cmdIcon ist bekannt?) und v.a. dynamische devStateIcons besser. Gibt weniger "Hackel", wenn es darum geht, Code zu tauschen/übernehmen und bei Sprachsteuerung etc.. (Anders gesagt: einen Teil des Aufwands für "wichtigere Baustellen" kannst du dir vermutlich sparen, wenn du bestimmte defaults nicht anfasst...)

Dieses "doppelte Lottchen"-Beispiel von dir ist nach meiner Auffassung nur eine (auswertemäßig) komplizierte Variante einer "gerichteten" eventMap und wäre effizienter zu schreiben als Hash (wenn man es unbedingt so haben will).

Just my2ct.

[tomix]

Dieses "doppelte Lottchen"-Beispiel von dir ist nach meiner Auffassung nur eine (auswertemäßig) komplizierte Variante einer "gerichteten" eventMap und wäre effizienter zu schreiben als Hash (wenn man es unbedingt so haben will).

Gefällt mir auch gar nicht. Hab das damals direkt nach der Erstinstallation gemacht.

Gruss
tomix