mqtt2.template: bugs, Fragen, Anregungen

[87insane]

Wäre ne super Aktion in einem separaten Thread ein FAQ zu eröffnen. In einem anderen Forum habe ich damit auch mal begonnen.

Super idee! Danke! Was sagst du dazu?

Gesendet von meinem LM-G810 mit Tapatalk

[Beta-User]

Yep, ist spannend und immer wieder interessant, welche "schrägen" Varianten es gibt.

(Ich bin btw. auch immer froh, wenn ich mich nur aus Anwenderperspektive mit Modulen befassen kann  , von daher: gerne geschehen...)

Für den Stammtisch als Anregungen vielleicht:

Einstieg/Grundkurs:
Material:
Je einen "normalen" Shelly(-pm) und Tasmota (notfalls: 2 Tasmota oder Shelly) an einem Demo-FHEM

Ziel:
Einführung in die Basics zu MQTT2_SERVER, autocreate und MQTT2_DEVICE
- Vorher und danach kann man dann mit "set xy attrTemplate ?" anknüpfen: Da kommt nämlich die m.E. längste "Linkliste" an Projekten, die bereits erfolgreich mit FHEM+MQTT umgesetzt wurde... (Wenn ihr Verbesserungsvorschläge zu den desc haben solltet oder weitere Geräte, die da rein sollen: aufschreiben...).
- vorher/danach, um zu Erkennen, wie wegen passender "filter:" dann plötzlich weitere attrTemplate sichtbar werden, wenn man sie vielleicht benötigt;
- dann attrTemplate: Quelltext vom template vorher ansehen, darauf anwenden  und Ergebnis begutachten...
- jsonMap - Funktion (bei Tasmota, einschließlich "Ausknipsen" von unnötigen Zweigen/Teilinfos).

Aufbaukurs I:
Material:
2. FHEM, das mit MQTT2_CLIENT auf den MQTT2_SERVER am anderen FHEM lauscht
Ziel:
Unterschied, besondere Schwierigkeit bei MQTT2_CLIENT-Installationen kennenlernen, Lösungsansatz verstehen.
- "bridge-template" zum Vorsortieren wg. fehlender/irreführender CID ("Einheits-Sammeldevice" für "bekanntes" vermeiden)


Aufbaukurs II:
Material:
Ein (besser: Zwei) ESP32, geflasht als OpenMQTTGateway(s) (wenn 2: mit unterschiedlichen Namen), dazu ein, zwei gtags oä +  (mind.) einen "runden" BT-Xiaomi-Temp/Hum-Sensor (Summe Material: <30 Euro...)
Ziele:
- Funktionsweise/eigentliches Ziel von bridgeRegexp verstehen; (so ähnlich ticken auch weitere "bridge"-templates, insbes. für zigbee2mqtt, ebus, milight: Es gibt ein Zentraldevice, das dem jeweiligen ESP entspricht, der generiert dann ggf. weitere Devices, das OpenMQTTGateway hier dann sogar mehrstufig für die verschiedenen Sende-/Empfangswege...)
- am praktischen Beispiel nachzuvollziehen, wie man Topic-Strukturen mit Perl auswerten kann und daraus dann Reading-Namen etc. baut;
- "Spezialtemplates", die dann komplett neue Geräte generieren (für gtag bzw. den Temp-Sensor, der dann auch nur die passenden Readings bekommt).

Dann wißt ihr im Prinzip nach ca. 2 Stunden in etwa so viel wie ich, fehlt eigentlich nur noch das Nachladen von weiteren templates/myUtils-code (=> ebus, roborock)  .

Was im Wiki bzw. als gesammelte "Best-Practice" noch fehlt, wären neben dem publishen via script, das 87insane angesprochen hat, noch "asynchrone" FHEM2FHEM-Verbindungen über MQTT2, Doku über SSL-Absicherung von SERVER nach außen zum allg. INet - da fehlt mir auch die Erfahrung, dto. zu eigentlichen MQTT-Vorteilen wie QoS etc..


In dem Zusammenhang:
Falls sich jetzt jemand mit ".ino"-Erfahrung angesprochen fühlt, sich ESP32 und BT näher anzusehen: Es gibt die Anfrage von Dominik betr. die Unterstützung der eQ-3-BT-Thermostate via ESP32@MQTT. Gerne bei Interesse da einklinken...
(Und falls jemand sich jetzt erfolgreich dran macht und die Integration der "eckigen" Xiaomi-Thermostate (LYWSD03MMC) ins OpenMQTTGateway hinbekommt: ein ganz besonderes Dankeschön von mir...! (Es gibt irgendwo ein Python-Script, mit dem das mit gattool zu gehen scheint, man müßte es "nur" portieren bzw. vorher vielleicht (?) die gattool-lib in den OMG-code einbauen, falls das jetzt noch nicht mit den vorhandenen libs abbildbar sein sollte...))


FAQ: Gerne, aber das kuratiert dann gerne jemand anderes...


Templates allgemein:
Ich wäre immer noch sehr froh, wenn sich jemand mit regex-Kenntnissen freiwillig melden würde, mit mir (oder ohne mich) den HTTPMOD-Teil zu betreuen  .

[DS_Starter]

@Beta-User ... wow, danke. Jetzt hast du mich aber versorgt !  Das wird mit Sicherheit mehr als ein Abend

@87insane
Sowas wie ein FAQ finde ich natürlich sehr hilfreich.
Bin mir nur nicht sicher, ob Forum-Thread als Plattform dafür geeignet ist. Das "zerbröselt" wahrscheinlich sehr schnell weil diskutierte Themen  dann plötzlich ein Eigenleben beginnen.
Wäre das Wiki für soetwas nicht besser geeignet ? Dort gibt es ja auch schon mindestens 3 Einführungsthemen ...
Und im Prinzip kann auch jeder mitarbeiten.

[87insane]

Ich glaube in regex nicht unbedingt mehr Kenntnisse zu haben wie du. Aber vllt. Bringt es ja was. Haste n Link?

Werde es die Tage mal eröffnen. Hab da so ne Vorstellung. Muss es eben nur pflegen.
Wenn fleißig fragen kommen, kann man sie immer oben sammeln nach Beantwortung. Dazu könnte man das Wiki ergänzen.

Gesendet von meinem LM-G810 mit Tapatalk

[Otto123]

@Beta-User ... wow, danke. Jetzt hast du mich aber versorgt !  Das wird mit Sicherheit mehr als ein Abend

@Beta-User Du willst die Qualität unserer Treffen ja durch die Decke gehen lassen. Wir werden wohl den Rest des Jahres ausgebucht sein

[DS_Starter]

  ... Otto

[Beta-User]

@Beta-User Du willst die Qualität unserer Treffen ja durch die Decke gehen lassen. Wir werden wohl den Rest des Jahres ausgebucht sein

Ihr könnt das gerne so halten, wie ihr wollt , auch in zeitlicher Hinsicht .

Ich wollte nur mal (auch für mich) aufschreiben, welche Themen dass es gibt, wo man sie findet und wie man sich das am besten "anarbeitet". Und ernsthaft: Wenn jemand zwei Test-Pi's (oder einen Pi+ein Laptop) hat (und die in einem Netzwerk unterbringen kann) (beide FHEM auf einem Rechner geht auch, aber das ist ziemlich abstrakt), und die Geräte geflasht, aber sonst "sauber" sind, ist man da wirklich in der Größenordnung in 2h durch, Grundkenntnisse in FHEM vorausgesetzt (FHEMWEB-Attribute sollte man schon jedenfalls der Spur nach verstehen).

Es sollte halt jemand demonstrieren, der "das Zeug" kennt, aber (@Otto) für dich sollte es kaum mehr als die 2h Vorbereitung sein (flashen der ESP32 und austesten inclusive, unterstellt, du hast ein paar Tasmota-ESP's ungenutzt rumliegen und Funktion von bridgeRegexp ist "der Spur nach" bekannt). Für MQTT-Noobs (ohne bridgeRegexp-Erfahrungen) ist der direkte OMG-Einstieg wahrscheinlich sehr steil, hier würde ich für eine Einarbeitung im Selbststudium min. 3-4 h veranschlagen, wer z.B. zigbee2MQTT kennt, wird direkt loslegen , also <2h im Selbststudium.

(Vielleicht sollte ich einen OMG-ESP32 und das Laptop nach KA mitnehmen, falls es da jemanden interessiert?).

Ich glaube in regex nicht unbedingt mehr Kenntnisse zu haben wie du. Aber vllt. Bringt es ja was. Haste n Link?

Link wäre hier: https://forum.fhem.de/index.php/topic,97694.0.html

Wäre natürlich nett, wenn du die diversen Templates einfach mal austesten könntest (sind ja in der Regel allg. zugängliche Quellen), aber es ist schon so, dass ich in der regex-Sprache nicht tief genug drin bin und auch die HTTPMOD-Syntax nur unzureichend kenne. Wenn du dich da erst einarbeiten mußt, ist das vermutlich für dich noch frustrierender wie für mich (ich hatte mir das auch vorher nicht so komplex vorgestellt ). Aber patche bzw. vollständigen template code (! ) nehme ich da gerne auch entgegen, klar, feel free!

Aber gerade @HTTPMOD ist "best practice sharing" eigentlich besonders hilfreich. Zum Glück und zu meiner großen Freude gibt es auch einige templates, die sich größerer Beliebtheit erfreuen und einige Unterstützer, die super-konstruktive Beiträge geliefert haben! Es ist nur (noch) nicht so wie hier bei MQTT2, dass (fast) alles durchgängig "einfach so" funktioniert, die Qualität ist m.E. einfach noch zu wechselhaft.
Wenn sich also jetzt jemand von denen angesprochen fühlt, die mir da qualitativ über sind: Bitte, Bitte!!!

[DS_Starter]

Ich stelle unserem Stammtisch immer eine kleine Testumgebung auf VMWare FHEM-Instanzen bereit, eine Datenbankmaschine und eine FHEM-Maschine. Die sind gesichert und wir können die nach Herzenslust zerspielen, nach der Session stelle ich die Instanzen aus einem Backup neu her.
Ein paar MQTT-Devices kann ich auch bereitstellen zum Spielen. Nur ist die Gesamtumgebung nicht vor uns "auf dem Tisch", sondern remote zugreifbar. Aber für die ersten "Mannschaftsschritte" sollte es ausreichen.

[v1nc3nt]

Hallo,

da es doch mal passiert, dass man ein Topic bei Zigbee2mqtt umbenennen muss, ist dann das ändern des Topics in allen Attributen von dem Gerät relativ aufwändig. Die Alternative ist löschen und neuanlegen, was man bei größeren Änderung auch nicht immer will.
Deswegen habe ich mir überlegt, dass man mit dem Internal und Attribut Devicetopic eine schnelle Änderung möglich wäre. Damit müsste man nur an einer Stelle eine Änderung vornehmen und es überträgt sich auf alle anderen Attribute. Den dazugehörigen Patch habe ich angehängt als konkreten Vorschlag.

Gruß Vincent

[Beta-User]

THX, hab's eingecheckt. Bin mal gespannt, was da für Rückmeldungen kommen, das macht das ganze halt nochmal eine Spur komplexer...


Ansonsten gab's noch ein paar weitere Kleinigkeiten, vorrangig wieder um das Thema Sprachsteuerung rum. Es wäre v.a. nett, wenn sich jemand das Mapping am
zigbee2mqtt_ContactSensor ansehen könnte, das war etwas sehr "auf Verdacht"...

Wenn das da klappt, dürft ihr mir gerne weitere mappings nach diesem Beispiel liefern, dabei gilt aber weiter: Bitte nur das, was unbedingt benötigt wird, damit es funktioniert - so wie ich das verstanden hatte, hat justme1968 da in jüngerer Vergangenheit einiges verbessert, so dass heute vieles automatisch paßt, ohne dass man groß was einstellen müßte.

Diskussion dazu ggf. dann aber bitte in einem gesonderten Thread, TomLee hat hier schon mal angefangen: https://forum.fhem.de/index.php/topic,108999.0.html, da könnt ihr auch verfolgen, was es an "Spezialitäten" rund um alexa gibt...

Viel Spaß damit,

Beta-User

[87insane]

Hallo zusammen,

die Shelly Jünger unter uns kennen es. Immer wieder nach einem Neustart ist der Gesamt Energie Wert weg. Das liegt an der original FW, die die Daten eben nicht wie z.B. bei Tasmota im Flash vorhält.
Macht es aus Euren Augen nicht Sinn, ein Reading mit dem wirklichem Total im Shelly zu haben? Anbei mal, wie ich das löse.

Code Auswählen Erweitern

attr GERÄTENAME userReadings relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}

Darauf könnte man auch wieder Statistics anwenden usw.

Beta-User sagte das man dies ggf. auch als "optional" einfügen könnte. Also über RADIO (wie bei den Sprachsteuerungen). Kenne ich noch nicht aber gerne nehme ich Lektüre entgegen

Gruß,
87insane

[Beta-User]

Vielleicht keine direkte Lektüre, aber was zum testen... (ggf. erst mal einen anderen Namen verwenden, unter diesem Namen gibt's das template schon):

Code Auswählen Erweitern

name:shelly1_w_energy_meassuring
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
order:A_10b
desc:Applies to single relay Shelly devices offering energy meassuring like Shelly 1PM or Shelly Plug S
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
par:RADIO_SETUSERREADING;Set userreading for total energy consumption;{ undef }
par:RADIO_DONOTSETUSERREADING;Do not set userreading for total energy consumption;{ undef }
par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old =  AttrVal("DEVICE","userReadings",undef);; !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old.', relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}'  }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : undef }\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* relay_0_energy\
  shellies/DEVNAME/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/DEVNAME/longpush/0:.* longpush_0
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $total = ReadingsVal($name,"relay_0_kWh","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch: $cons / Total: $total/ Temp: $temp °C</div>"}
attr DEVICE comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr DEVICE webCmd :
deletereading -q DEVICE (?!associatedWith).*
set DEVICE x_mqttcom announce
set DEVICE attrTemplate speechcontrol_type_switch
attr DEVICE model shelly1_w_energy_meassuring
option:{ RADIO_SETUSERREADING }
attr DEVICE userReadings NEWUSERREADINGS


[87insane]

Lese ich das richtig?

Code Auswählen Erweitern

par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old =  AttrVal("DEVICE","userReadings",undef);; !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old.', relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}'  }
Er liest (wenn vorhanden) alte userReadings ein. Sollten alte vorhanden sein, werden diese mitgenommen und das eine hinzugefügt. Wenn keine alten vorhanden sind, dann nur das eine Reading einfügen.

Wieso steht es denn im Template dann nochmal ganz unten unter userReadings?

Code Auswählen Erweitern

attr DEVICE userReadings NEWUSERREADINGS relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}

Nur mal um die Nachwelt und auch mich auf den aktuellen Stand zu bringen was die "optionalen" Setter angeht....

[Beta-User]

Mist, die letzte Zeile war ein Kopierrest, die muß weg (ich editiere das gleich nochmal)...

Ansonsten ist das korrekt: Es sollten eventuelle andere vorhandene userreadings nicht angetastet werden...

(die Namensgebung ist übrigens nicht sooo super, m.E. wäre was kürzeres hier besser, oder nicht?)

[87insane]

Geht soweit ohne die letzte Zeile. Ich werde gefragt (echt cool!) und dann kann ich auswählen.

Danach kommt aber noch "Unknown template_entry_name speechcontrol_type_switch".... Also mal eben erst die aktuellen Template Dateien gezogen (falls jemand das mal haben sollte).
Erneut getestet, nun alles super.

Nur ggf. wegen Copy&Paste ist in devStateIcon anstatt °C ein ?C (ASCII Fragezeichen, kein normales). Da müsste wie im 1pm Template dann stehen: °C

Da es nun wie in einem Wizard klickbar ist, kann man ja quasi alles so aufbauen. Also nochmal alles neu machen... :-P

Das gleiche muss auch noch für relay 1 existieren. Der Shelly 2.5 hat z.B. zwei Relays. Dazu ist der Name der Relays abhängig davon ob er im Schalt oder Roller Modus ist (roller_0_energy/relay_0_energy / im Roller Mode hat der Shelly2.5 auch nur roller0 und keinen roller1). Willst du das als "sub Template" einfach aufrufen lassen? Wenn ja, wäre der Name dann sowas wie shelly_total_energy_fix

Für mich das nur ein Workaround. Shelly selber wird das aber auch erstmal nicht ändern.