mqtt2.template: bugs, Fragen, Anregungen

[Beta-User]

So, habe eben mal ein update dazu ins svn geschoben, da ist drin:
- OMG - kleinere Änderungen betr. v.a. das gtag-BT-Dongle. Hoffe mal, da fühlt sich jemand wg. Doku angesprochen...
- owntracks - Klammern und $DEVICETOPIC (hoffentlich; ungetestet)
- ein erster stub für diese Thermostat-Geschichte (da ist aber nur das drin, was ich in dem anderen Thread angedeutet hatte, muss nicht funktionieren, nur, dass man mal eine gemeinsame Basis hat...)

[Otto123]

Das owntracks-device sieht komisch aus ($\DEVICETOPIC), aber lass mal ich teste das morgen mal durch und liefere einen Vorschlag.

Die bridgeRegexp  CLIENT_general_bridge habe ich mal sortiert, normiert und zusammen gefasst. Schau Dir das mal an - aber vielleicht lieg ich völlig daneben:

Code Auswählen Erweitern

(tele|stat|shellies|valetudo|Advantech)/([^/]+)/.*:.* "$2"
  (zigbee2mqtt)/bridge/.*:.* "$1"
  (ESPClient_[^/]+)/.*:.* "$1"
  (ebusd)/global/.*:.* "$1"
  [^/]+/(ems-esp[^/]+)/start:.* "$1"
  (sonos)/connected.* "$1"
  (tvheadend)[/][^/:]+.* "$1"
  (mygateway[\d]+)-(in|out)/.* "$1"
  (milight)/LWT:.* "$1"
  (wallpanel|wled)/([^/]+)/.*:.* "$1_$2"
  (go-eCharger)/([^/]+)/.*:.* "go_eCharger_$2"
  (owntracks)/([^/]+)/([^/]+).*:.* "$1_$2$3"
  (home)/(O[^/]*M[^/]*G[^/]*)/LWT:.* "$2"
  homeassistant/.*/config:.* ""


[Beta-User]

Der backslash sieht in der Tat komisch aus, ist aber erforderlich, um die Ersetzung für DEVICE zu verhindern .

CLIENT_general_bridge ist "aufgeräumt", bei der Gelegenheit habe ich dann gleich nochmal weiter vereinfacht bzw. Teile dann auch in "Klartext" notiert, ist vielleicht einfacher zu lesen bzw. zu verstehen?

[Otto123]

CLIENT_general_bridge sieht gut aus. Ich bin ja gestern erstmal den anderen Weg gegangen -> alles in match groups, dann sortiert. Dabei habe ich gesehen wie viel da gleich ist und habe zusammengefasst.
Aber Du hast recht, so ist es besser lesbar und man sieht eher was eigentlich passiert. Muss man in Zukunft schauen wo man neues "einsortiert"
Ich denke die Muster sind jetzt konsistent und man kann anhand derer auch schnell was Neues einbauen.

[Beta-User]

Das mit dem Zusammenfassen war eine gute Idee!

Am Anfang habe ich halt schlicht mal gesammelt und das ganze - mangels eigener Nutzung und fehlender Rückmeldung von anderen - halt einfach "irgendwie" vertemplatet, ohne neben der reinen Funktionalität groß andere Aspekte zu beachten. Da war auch noch nicht so recht klar, dass das Prinzip "ändere (also user) nichts an der Topic-Struktur" als Standard in FHEM gelten kann/wird, aber der Fisch ist wohl zwischenzeitlich in diese Richtung geputzt.

Da zwischenzeitlich genug User da sind, die wissen, wie bridgeRegexp funktioniert (und wo es wie hilft), kann es m.E. zusammengefaßt bleiben, wer es anders haben will, findet dann vermutlich einen kundigen Helfer, der dann eine passende Einzelzeile beisteuern kann...

[Otto123]

Ich poste Dir mal hier einen patch weil owntracks_device aus meiner Sicht wirklich derzeit buggy ist
Die Erkennung der Tracker und Device ID ging bei mir nicht und war mM nach auch  wirklich falsch - die regExe geändert und so geprüft - vielleicht habe ich noch nicht alle Varianten bedacht
Das raw Reading eingefügt, wobei ich mit der Lösung final nicht glücklich bin
Das textField bei den settern ergänzt, sonst mach es mM nach keinen Sinn

[Beta-User]

Danke. Macht m.E. Sinn - genauso, wie die JSON für die Waypoints zu erhalten...
Vielleicht kannst du dazu noch Code liefern, Rudi hatte das ja sehr kompakt gefasst? (Evtl. sollte man aber die alten Readings vorneweg löschen?)

(Diskussion kann aber gerne in dem anderen Thread geführt werden; ich werde den Tag über mal wieder einsammeln, was mir so vor die Flinte läuft...
Z.B. in OMG habe ich eben auch noch "geschraubt", und bin mir auch nicht mehr so sicher, ob es nicht einfacher wäre, via RADIO-option abzufragen, ob der ESP BT kann und dann setList und readingList "je nachdem" zu verändern....
Vielleicht magst du dich in die Diskussion mit einklinken? => [Gelöst] OpenMQTTGateway + Gigaset Keeper, letzte MAC abfragen )

[Otto123]

Also nur ganz kurz:
Ich mache für owntracks zwei neue Template Vorschläge mit meinen neuen Erkenntnissen
owntracks_device - da will ich nur "Android/Basis-Umfang" reinpacken. Die Android Version hat viel weniger Umfang/Readings/Features
owntracks_device_IOS - als "AddOn" da kann ich erstmal nur den existierenden Umfang theoretisch betrachtet dazu packen. Das muss dann ein Apfel testen
Das mach ich aber im anderen Thread    und OMG häng ich mich noch mit rein - mal sehen was ich da kann

[Otto123]

Schau Dir das mal an - aber vielleicht lieg ich völlig daneben:

Zumindest für das owntracks regExp lag ich daneben 

Code Auswählen Erweitern

owntracks/([^/]+)/([^/:]+).*:.* "owntracks_$2"
wichtig ist [^/:] sonst sehen die erzeugten Geräte gruselig aus. Ich glaube bei den anderen "Kürzungen" war das ok soweit ich das beurteilen kann.
Ich wäre auch dafür, den Namen der Geräte nicht zu kompliziert zu machen. Es reicht doch wenn da owntracks_Meingerät steht. Wozu ist der Zwischenteil gut?
Dann könnte man auch so schreiben

Code Auswählen Erweitern

owntracks/[^/]+/([^/:]+).* "owntracks_$1"

Beim owntrack_device Template ist gewaltig was schief gegangen. Es ist patch Text im Template und ich hatte Fehler im regExp der DeviceID
Ist es kontraproduktiv wenn ich einen patch liefere? Soll es lieber einfach der template Abschnitt sein?

Code Auswählen Erweitern

###############
#OwnTracks
# an OwnTracks device
#contributed by Loredo
#source post: https://forum.fhem.de/index.php/topic,99666.msg1019884.html#msg1019884
# modified by Otto123
name:owntracks_device
desc:A device tracked by OwnTracks, Basics supported for Android
filter:TYPE=MQTT2_DEVICE:FILTER=CID~owntracks.*
order:O_01
par:TRACKER_ID;TrackerID;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,/([^/]+)/, ? $1 : undef }
par:DEV_ID;DeviceID;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,/[^/]+/([^/:]+), ? $1 : undef }
par:WHICHROOM;Actual room of the device, defaults to OwnTracks; {AttrVal("DEVICE","room","OwnTracks" )}
attr DEVICE room WHICHROOM
attr DEVICE icon location_sign
attr DEVICE devicetopic owntracks/TRACKER_ID/DEV_ID
attr DEVICE jsonMap\
  acc:accuracy alt:altitude batt:batteryPercent lat:latitude lon:longitude vac:accuracyVertical vel:velocity
attr DEVICE readingList\
  $\DEVICETOPIC.* raw\
  $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $\DEVICETOPIC/event:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $\DEVICETOPIC/waypoints:.* { my (%h,$cnt); $EVENT=~ s/(\{[^[]*?})/$h{"waypoint_".++$cnt}=$1/ge; \%h }
attr DEVICE getList\
  location:noArg raw $\DEVICETOPIC/cmd {"_type":"cmd","action":"reportLocation"}\
  waypoints:noArg raw $\DEVICETOPIC/cmd {"_type":"cmd","action":"waypoints"}
attr DEVICE setList\
  config:textField $\DEVICETOPIC/cmd {"_type":"cmd","action":"setConfiguration","configuration":$EVTPART1}\
  waypoints:textField $\DEVICETOPIC/cmd {"_type":"cmd","action":"setWaypoints","waypoints":{"_type":"waypoints","waypoints":[$EVTPART1]}}\
  mode:1Quite,2Manual,3Significant,4Move {$EVTPART1=~/(\d)/;my $pl=$1-2;fhem("set $NAME config ".qq({"_type":"configuration","monitoring":$pl}));return undef}\
  x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //; qq($\DEVICETOPIC/cmd $payload)}
attr DEVICE userReadings\
  location:lat.* {ReadingsNum($name,'latitude',0).','.ReadingsNum($name,'longitude',0)},\
  connection:conn.* {my %h=(m=>'mobil',w=>'wifi',o=>'offline'); return $h{ReadingsVal('MQTT2_owntracks_mi6','conn','error')}},\
  place:event.* {ReadingsVal($name,'event','') eq 'leave'?'away':(ReadingsVal($name,'desc','nowhere'))}
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model owntracks_device
attr DEVICE comment https://owntracks.org/booklet/tech/json/
setreading DEVICE attrTemplateVersion 20201210

[Beta-User]

Das mit patches ist an sich schon ok, ich hatte das aber manuell eingepflegt, weil ich zeitgleich ein paar andere Änderungen hatte.

Aber kompletter Code ist auch völlig ok, wenn ich den Bezugspunkt identifizieren kann, ich sehe dann ja vor dem Einchecken, was Sache ist... ( jedenfalls, wenn ich nicht zu viel gleichzeitig schraube).

[Otto123]

Ok,
Blöd jetzt von mir, ich habe hier jetzt nicht nur die Fehler sondern gleich das komplett überarbeitete Template gepostet. Wollte ich eigentlich im anderen Thread machen 

[betonkelle]

Hallo zusammen,

ich habe einen Shelly 2.5 mit Tasmota 8.5.1 geflashed.
Im Fhem läuft MQTT2.
Wenn ich den Shelly mit dem MQTT2 Server verbinde, wird das device gefunden.
Wenn ich dann das Template
tasmota_2ch_shutter_invert_0
auswähle bekomme uch die Fehlermeldung
"Please define Interlock first", zweimal.
Dann drücke ich es mit Ok weg.
Das Device heißt dann komischerweise
Interlock DVES_.......
Wenn ich dann nochmal auf das Attr gehe will er undefjnierte Parameter füllen die fhem nicht genauer spezifiziert.

Bei dem Invert_1 Template gibt es die Probleme nicht, nur stellt Alexa dann das Rollo verkehrt herum.

Hat jemand eine Idee woran die Fehlermeldung liegt?
Danke
Martin

[Beta-User]

Vermutlich habe ich bei der jüngsten Umstellung (für die Option mit 4 relays) einen Bug reingebastelt. Wäre nett, wenn du nachher ein update machen könntest und checken, ob es jetzt wieder geht.
(Am besten dann nochmal mit einem "frischen" Device starten, also löschen und dann den Tasmota-"Shelly" neu starten)

[betonkelle]

Hi Beta-User,

kann ich gerne machen, sag nur ab wann du die Änderungen eingearbeitet hast.

[Beta-User]

Kommt mit dem regulären update, ist also seit ca. 7:45 Uhr verfügbar...