mqtt2.template: Contributing

[mferstl]

- das homebridgeMapping ist jetzt "einzeilig"; kann sein, dass das eine der Sprachsteuerungslösungen nicht mag... Dann müsste man eventuell mal mit \n rumexperimentieren, sonst habe ich grade keine Idee, wie man das sauber in der Parameter-Form übergeben kann...

Ich glaube nicht, dass das so funktionieren kann. Das Attribut homebridgeMapping besteht i.A. aus mehreren Strings  (die durch Leerzeichen getrennt werden).
Wenn man das als par HOMEBRIDGEMAPPING an das Sprachsteuerungs-Template übergibt, dann wird nur der erste String übernommen.
Ich habe schon etwas rumprobiert aber keine Lösung gefunden.

[Beta-User]

Das Problem besteht mWn. häufiger bzw. allgemein, wenn man mehr Infos hat. Ich hatte eigentlich gedacht,  das mal während der Entwicklung des Konzepts ausgetestet zu haben, und dass es funktionieren sollte, wenn man den Gesamtstring in Anführungszeichen packt (und erforderlichenfalls andere nimmt als die, die man intern braucht).
Schade, dass es wohl nicht wie vorgeschlagen funktioniert.

(Muss mir dann dazu was überlegen, es müßte eigentlich irgendeinen Weg geben, das über den internen attrTemplate-Aufruf zu machen, denn das homebrideMapping-Thema will ich ungern in die mqtt2-File mit allen Verästelungen integrieren...)

[Otto123]

Hi,

es gibt ein Template für den Xiaomi RoboRock mit valetudo. https://forum.fhem.de/index.php/topic,104804.0.html
Ich habe meinen Gen 1 mit valetudo RE ausgestattet, die topics und Features sind etwas anders, deswegen erstmal ein neues Template dafür.
Beim ersteren Template wurde Wert auf die Karte gelegt, die habe ich hier weggelassen.

Code: [Auswählen]

# The rockrobo device for valetudo RE
name:roborockRE
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*valetudo[/].*
desc:use this for a rooted Xiamoni Vacuum / Roborock with valetudo RE installed. For details visit https://github.com/rand256/valetudo/wiki<br>NOTE: Only tested with Gen1, Forum Board MQTT<br>
order:X_04
par:BASE_TOPIC; is typically valetudo; {(split '/',ReadingsVal("DEVICE",'subscriptions','valetudo/rockrobo'))[0]}
par:DEV_ID;     is typically rockrobo; {(split '/',ReadingsVal("DEVICE",'subscriptions','valetudo/rockrobo'))[1]}
par:ICON;ICON as set defaults to vacuum_top;{ AttrVal("DEVICE","icon","vacuum_top") }
{ Svn_GetFile("contrib/AttrTemplate/99_roborockUtils.pm", "FHEM/99_roborockUtils.pm", sub(){CommandReload(undef, "99_roborockUtils")}) }
defmod DEVICE MQTT2_\DEVICE DEV_ID
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE alias DEV_ID
attr DEVICE readingList\
homeassistant/vacuum/BASE_TOPIC_DEV_ID/config:.* {}\
$\DEVICETOPIC/state:.* { json2nameValue($EVENT) }\
$\DEVICETOPIC/attributes:.* { json2nameValue($EVENT) }\
$\DEVICETOPIC/map_data:.* {}\
$\DEVICETOPIC/command_status:.* { json2nameValue($EVENT) }\
$\DEVICETOPIC/destinations:.* { valetudoREdest($EVENT) }
attr DEVICE setList\
charge:noArg $\DEVICETOPIC/command return_to_base\
fan_power:whisper,min,medium,high,max,mop $\DEVICETOPIC/set_fan_speed $EVTPART1\
locate:noArg $\DEVICETOPIC/command locate\
pause:noArg $\DEVICETOPIC/command pause\
spot:noArg $\DEVICETOPIC/command clean_spot\
start:noArg $\DEVICETOPIC/command start\
stop:noArg $\DEVICETOPIC/command stop\
get_dest:noArg { $\DEVICETOPIC.valetudoRE($EVENT) }\
goto:textField { $\DEVICETOPIC.valetudoRE($EVENT) }\
map:textField { $\DEVICETOPIC.valetudoRE($EVENT) }\
reset_consumable:main,side,filter,sensor { $\DEVICETOPIC.valetudoRE($EVENT) }\
zone:textField { $\DEVICETOPIC.valetudoRE($EVENT) }\
x_raw_payload:textField { $\DEVICETOPIC.valetudoRE($EVENT) }
attr DEVICE userReadings autoReturn:valetudo_state_name:.Idle {fhem("sleep $name:bin_in_time:.0 waitbin;set $name charge");return 'return'}
attr DEVICE setStateList charge fan_power get_dest goto locate map pause reset_consumable spot start stop zone x_raw_payload
attr DEVICE event-on-change-reading .*
attr DEVICE model roborockRE
setreading DEVICE attrTemplateVersion 20210510Es gibt ein paar nette Feature gegenüber der bisherigen FHEM Modul Lösung durch valetudo RE:
Aktuelle Karte speichern (auf dem Gerät) und falls die Karte "weg" ist wieder laden.
Verwendung der Zielpunkte und Zonen aus der Valetudo RE App. Beides lässt sich als Liste einlesen.
Man könnte die auch komplett mit json2nameValue einlesen, das waren mir aber zu viele Readings ohne wirklichen Nutzen, deswegen die eigene Routine, die nur die Namen aus dem json extrahiert. Vielleicht geht die eleganter?
Das Rausnehmen des dustbin wird registriert und gemeldet. Das userReading verwendet dies und fährt den Sauger vom Mülleimer in die Station nachdem der dustbin geleert wurde. Vielleicht ist das aus der Kategorie: das tut man nicht? Find ich aber viel eleganter als zwei extra notify 😄

Ich bitte um eine kleine um Qualitätskontrolle.
Ich war mir unsicher bei der Verwendung der Platzhalter BASE_TOPIC DEV_ID - welche sind zu bevorzugen? In den Templates werden unterschiedliche verwendet. Bei der Verwendung der Sortierung war ich auch unsicher -> order:X_04

Es wird eine 99_Utils Datei verwendet / nachgeladen:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/AttrTemplate/99_roborockUtils.pm

Ich würde das Template als zweites zu RockRobo nach dem Ok einchecken?
Ich würde die Verwendung und Einrichtung dann mal noch separat vorstellen.

Gruß Otto

[Beta-User]

[...]
 deswegen die eigene Routine, die nur die Namen aus dem json extrahiert. Vielleicht geht die eleganter?

Die Routine schau ich mir bei Gelegenheit an.

Das Rausnehmen des dustbin wird registriert und gemeldet. Das userReading verwendet dies und fährt den Sauger vom Mülleimer in die Station nachdem der dustbin geleert wurde. Vielleicht ist das aus der Kategorie: das tut man nicht? Find ich aber viel eleganter als zwei extra notify 😄

Separate Devices anlegen finde ich auch die schlechtere Lösung für unseren speziellen Anwendungsfall.

Spontaner Eindruck (=muss nicht zielführend oder richtig sein): Der Reading-Name ist ziemlich "verschachtelt".
- Eventuell wäre es eine Idee, die Readings auch in einer eigenen Routine auszupacken (neben den Namen: eocr-Vorbehandlung?)
- die Routine zur Rückkehr könnte dort besser "versteckt" werden?
- Ob dann der Weg in die Ladestation angetreten werden soll, könnte ggf. der User (per userattr) entscheiden?

Ich bitte um eine kleine um Qualitätskontrolle.

(Das übernehmen in der Regel dann schon auch die User )

Ich war mir unsicher bei der Verwendung der Platzhalter BASE_TOPIC DEV_ID - welche sind zu bevorzugen? In den Templates werden unterschiedliche verwendet.

Ist teilweise historisch gewachsen. Tendenz: BASE_TOPIC kann mehrere Elemente des Topic-Trees umfassen, (die Benennung ist häufig in der jeweiligen firmware etc. auch "base" oder ähnlich), DEV_ID ist eigentlich immer nur ein "Zweig" (zwischen "/"), der das jeweilige Gerät eindeutig bezeichnet.

Ich würde das Template als zweites zu RockRobo nach dem Ok einchecken?

Bei der Verwendung der Sortierung war ich auch unsicher -> order:X_04

Wenn es schon was (ähnliches) gibt, am besten "irgendwie" dazusortieren. Ich habe da keine zwingende Logik; das ursprüngliche Nummernsystem hatte ich irgendwo mal erläutert, aber wenn es z.B. ein Kaufsystem mit MQTT(-Erweiterung) und eine freie firmware-Variante gibt, würde ich eher dazu tendieren, das untereinander zu bringen (mit einem "a" Index oä.; ggf. etwas "Platz" lassen, damit man erforderlichenfalls Varianten noch dazwischensortieren kann. Notfalls kann man aber einfach auch die Nummern ändern, falls sich dazu eine Notwendigkeit ergibt, die man nicht anders in den Griff bekommt).
Wichtiger finde ich, dass man das als User irgendwie (wieder-) findet, wenn man einfach so (in FHEMWEB) mal schaut, was es so alles gibt...

[Otto123]

Die Routine schau ich mir bei Gelegenheit an.

da war mein erster Versuch und die Messlatte die leicht abgeänderte Routine von Rudi. Die extrahiert immerhin von innen die interessanten json Objekte nach außen.

Code: [Auswählen]

{ my (%h,$cnt); $EVENT=~ s/(\{[^{]*?})/$h{"SpotZone_".++$cnt}=$1/ge; \%h }Aber dann hab ich es anders gemacht.

Spontaner Eindruck (=muss nicht zielführend oder richtig sein): Der Reading-Name ist ziemlich "verschachtelt".
- Eventuell wäre es eine Idee, die Readings auch in einer eigenen Routine auszupacken (neben den Namen: eocr-Vorbehandlung?)

Die Original payloads sind schon so valetudo_state das ist dann wieder ein json und json2nameValue macht das draus valetudo_state_name
Da habe ich dann das mentale Problem: Packt man das json Objekt formatiert in ein Reading - oder lässt man es lieber den Sack mit Readings?
Insgesamt finde ich die Readings in dem Device noch übersichtlich.
eocr .* habe ich schon drin!

Wenn einer das userReading mit Rückkehr nicht haben will, kann er es ja einfach löschen? Ich kann den Code auch inaktiv in den Kommentar packen?

Hast Du an andere Stelle schon mal was eingebaut um die Utils Datei (aus dem contrib) zu aktualisieren? Quasi ein update des Device Codes? Sollte man das machen?

Ich sortiere das Template als X_03a ein - Edit: eingecheckt

[Beta-User]

Da habe ich dann das mentale Problem: Packt man das json Objekt formatiert in ein Reading - oder lässt man es lieber den Sack mit Readings?
Insgesamt finde ich die Readings in dem Device noch übersichtlich.
eocr .* habe ich schon drin!

Ging eher darum, das ggf. samt "Umbenennung" in der myUtils unterzubringen; es gibt dazu einen "Master" mit diesem go-echarger, zu finden über https://forum.fhem.de/index.php/topic,116162.msg1109103.html#msg1109103.

Wenn einer das userReading mit Rückkehr nicht haben will, kann er es ja einfach löschen? Ich kann den Code auch inaktiv in den Kommentar packen?

Ist m.E. kein echtes Problem, das so zu lösen.

Hast Du an andere Stelle schon mal was eingebaut um die Utils Datei (aus dem contrib) zu aktualisieren? Quasi ein update des Device Codes? Sollte man das machen?

Einen "update-Buttom"? Nicht, soweit ich mich spontan entsinne.
Wer ein update haben will, kann ja das attrTemplate nochmal anwenden, das ist das einfachste...
Für alle anderen könnte man was in comment (z.B.) einbauen, damit die den Befehl c&p finden können? Und/oder Wiki/erster Beitrag im "Hauptthread"?...
(oder über die cref von der myUtils!)

[Haus-Andi]

Hallo zusammen

Gibt es irgendwo eine Übersicht welches Template für welche Hardware verwendet werden kann?

Ich habe folgendes Problem: wir haben meinen Kindern ein billiges LED-Strip Set in China gekauft, da sind die einfachen Magic-Home mit dem ESP8266 drin. Nun habe ich da ein aktuelles Tasmota (2.7.4.9) drauf gespielt, bis hierhin alles ok. Über die Web-Seite direkt auf dem Controller läuft alles ok. Welches Template muss ich nun verwenden (ich denke irgend eines mit dem "tasmota_.......)?

Das mit dem "tasmota_rgbw...." macht bei mir nicht das was es eigentlich sollte: zb. "on" -> setzt auf rot, "off" -> blau.
da ich mich mit json überhaupt nicht auskenne, kann ich auch nicht einfach ein eigenes Template erstellen.

Ach ja: auf dem Magic-Home (tasmota) habe ich natürlich auf "Magic-Home(34)" eingestellt.

was mache ich falsch



 

[Beta-User]

1. Im falschen Thread fragen!
2. (vermutlich) das falsche Tasmota-Template zur (ESP-) Konfiguration nutzen.
Bitte erst mal checken, ob der ESP über das Webinterface zu bedienen ist, und wenn ja, einen eigenen Thread dafür aufmachen. Wenn nein: blakadder konsultieren.

[Haus-Andi]

danke für die überaus hilfreiche Antwort, es ist mir absolut bewusst das ich nicht die teuerste Hardware und die beste Software nutze

[Beta-User]

danke für die überaus hilfreiche Antwort, es ist mir absolut bewusst das ich nicht die teuerste Hardware und die beste Software nutze

Den ersten Beitrag in diesem Thread hier kann man ganz kostenlos lesen; dauert auch nicht lange...

[Haus-Andi]

nur einfach zur Info: genau das habe ich gemacht und genau darum habe ich hier versucht zu erfragen ob es im ganzen System irgendwo irgend eine Tabelle oder übersicht über die template gibt.
Ist ja auch egal die Tage mit fhem sind bei mir eh angezählt, werde die Sache halt mal etwas zur Seite legen und zuerst das neue System aufbauen müssen.

Gruss

[Beta-User]

[...] Bitte nutzt möglichst diesen Thread, wenn ihr neue (im Prinzip ausentwickelte) templates für mqtt2.template vorschlagen wollt.
Für Fehlermeldungen, Diskussionen zu Verbesserungsvorschlägen zu vorhandenen und zum Anfragen von support für neue Devices ist ein weiterer Thread gedacht, dieser hier sollte möglichst übersichtlich bleiben und sich auf das Wesentliche beschränken.
[...]
- tasmota: https://forum.fhem.de/index.php/topic,94434.0.html

Wenn du das _genau_ gemacht hättest, dann wäre diese Frage _nicht hier_ gelandet, sondern entweder bei "tasmota" oder bei "Fragen/bugs...".

Jedenfalls enthält dein Beitrag KEINEN attrTemplate-Vorschlag, oder?

Ansonsten: Wenn das rgbw-template nicht passt, müsste das Teil entweder einen Kanal mehr oder weniger haben. Dann ist es entweder das rgb-led-controller Teil, oder eben mit cct-Anteil. Mehr wie die 4 bzw. 5 light-Varianten, die direkt untereinder gelistet sind, gibt es afaik derzeit nicht, und wenn der Controller die Befehle missinterpretiert, dann liegt das entweder an der Zahl der Kanäle oder es ist ein genereller Bug, evtl., weil sich bei Tasmota was geändert hat (meine laufen seit neuestem auf 9.irgendwas, btw.).

[hydrotec]

Hallo Beta-User,

bezüglich den Posts #32, #33 und #36
habe ich das mqtt2_siedle.template (siehe Anhang) noch einmal etwas angepasst.

Das Template ist soweit funktionstüchtig.

Deine Änderungen

... mit denselben Reading-Namen wie aus dem Modul bekannt ...

habe ich mir erlaubt zu übernehmen.

Könntest du bitte noch einmal kurz drüber schauen, ob man es so verteilen kann?
Dankeschön

Gruß, Karsten

[Beta-User]

thx, hab's eingecheckt, passt; (jedenfalls, soweit ich das im Moment beurteilen kann).

Habe dann noch den logging-Pfad bei der zigbee2mqtt-Bridge (siehe hier) ergänzt (mit Prefix) und bei Tasmota dieses "Info-feature" über den regex-Weg auf einen einheitlichen Stand gebracht (jedenfalls hoffe ich, alle relevanten Stellen erwischt zu haben).

Bitte (im "bugs-" Thread) melden, wenn jemand das nicht gut findet bzw. bessere oder ergänzende Vorschläge hat.

[hydrotec]

thx, hab's eingecheckt, passt; (jedenfalls, soweit ich das im Moment beurteilen kann).

Erste Tests sind positiv 

Was noch nicht geht

- Aktualisierung des Readings result (geöffnetet Device in der WEB-Oberfläche)
Wenn an der Gegensprechanlage/Türklingel ein cmnd gesendet wird, aktualisieren sich die Readings bezüglich result sofort.
Wenn mit "set <DEVICE> light/open" ein Kommando an die Anlage gesendet wird,
funktioniert es zwar das light/open ausgeführt werden, doch die Readings bezüglich result aktualisieren sich nicht.
Erst wenn das Device erneut in der WEB-Oberfläche geöffnet wird.
In MQTT.fx werden die Topics in der richtigen Reihenfolge sauber erkannt.
Ist eventuell die Zeit zwischen den Topics zu kurz?

An ein Zeitproblem glaube ich nicht, da müßte man mal den MQTT-Verkehr auswerten. Seltsam ist, dass scheinbar die Werte ankommen, (sonst wären sie beim Neu laden der Detailansicht nicht da) aber nicht triggern. Sowas passiert eigentlich afaik nur dann, wenn man am Dispatch-Mechanismus vorbei was aktualisiert. (Musst du nicht verstehen, ich habe aber auch im Moment keine Erklärung, wo das herkommen könnte).

ist in dem Fall nicht weiter schlimm, wer hat schon die Detailansicht dauerhaft offen
Edit 2021_05_16:
Geht doch, Thema erledigt.

... Habe dann noch den logging-Pfad bei der zigbee2mqtt-Bridge (siehe hier) ergänzt (mit Prefix) ...

Funktioniert jetzt auch, ohne das ein weiteres Device angelegt wird.
Jeder Erstling wird es dir danken 

Dankeschön für deine Unterstützung

Schönen Sonntag noch 
Gruß, Karsten