mqtt2.template: bugs, Fragen, Anregungen

[johndoe]

Hallo zusammen,

Frage/Anregung allgemein zu Tasmota, nachdem ich so langsam aber sicher auch verstanden habe, wie das mit dem JSONMAPing funktioniert und das Thema hier hochkam:

Die Tasmota-Geräte verwenden in der Regel POWER1 für die Rückmeldung zum ersten Kanal. Häufig gibt der das Hauptreading wieder, sollte also optimalerweise nach "state" (entsprechend bei den mehrkanaligen "split"-Versionen dann für POWER2 usw.). Das wäre recht einfach mit JSONMAP zu machen, allerdings wäre das ein breaking change.
In der readingList wäre der Eintrag für RESULT zu ändern in

Code Auswählen Erweitern

stat/sonoff3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
und statt der stateFormat-Sache würde man

Code Auswählen Erweitern

attr DEVICE jsonMap POWER1:statesetzen.
Wer es weiter wie bisher haben will, müßte dann stateFormat beibehalten und das jsonMap-Attribut löschen.

Ich tendiere dazu, das bei allen Tasmotas dann bei Gelegenheit so umzusetzen (evtl. mit zwei Converter-templates zum vereinfachten Umstellen), aber wenn es große Einwände gibt, gilt wie immer: Ihr bekommt, was ihr bestellt...

Grüße, Beta-User

Also ich wäre dafür. Ohne diese Anpassung zeigte mein Sonoff S20 dauerhaft nur set_on bzw. set_off im state an.

[Beta-User]

Nachdem die letzten "tasmota"-jsonMap-Rückmeldungen positiv waren, anbei eine vollständige Version, wie das zukünftig @Tasmota aussehen könnte.

Wäre nett, wenn der eine oder andere die mal testen könnte und Rückmeldung geben, ob das soweit paßt. Ich habe "in der Basis" dazu bisher keine weiteren Tests gemacht, aber das json-Mapping an sich ist erprobt, wie oben geschildert. Fehler/fehlende interne Weiterleitungen in einzelnen Fällen sind daher allerdings auch nicht ganz auszuschließen. "Umstellungstemplates" wollten mir erst mal nicht glücken, daher muß es ohne gehen, wenn niemand sonst sich kümmern mag...

Bin noch unschlüssig, ob die "alten" noch bereitgehalten werden sollten oder nicht, ich tendiere aber zum "breaking change" (wer heute konfigurierte Devices hat, kann die ja weiter nutzen und bei Bedarf auch die bisherigen attrTemplate-Versionen aus dem svn holen! Und wer Testen will, kann einfach erst mal parallel mit einer Kopie seiner funktionierenden Devices arbeiten.).

Wenn ich kein feedback bekomme, checke ich das in ca. 2 Wochen so ein...

[87insane]

Hey zusammen,

anbei eine Idee um es bei dem Shelly 2.5 im Roller Mode einheitlich zu gestalten. Das Template fügt die "Ampel" mit allen Funktionen hinzu und die Icons werden in kürzerem Code abgefragt.
Hier handelt es sich rein um das Design bzw. devStateIcon.

Was haltet Ihr davon?


Normal (in meinen Augen) - (0% = Rollo ist oben - 100% = Rollo ist komplett unten/es ist dunkel im Innenraum :-P)

Code Auswählen Erweitern

{
my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;
my $con = ReadingsVal($name,"state","undef");;
my $pic = $con eq "opening" ? 'fts_shutter_up@red' : $con eq "closing" ? 'fts_shutter_down@red' : $con eq "100" ? 'fts_shutter_100' : $con =~ /(\d)\d/ ? 'fts_shutter_'.$1.'0' : $con =~ /\b\d\b/ ? 'fts_shutter_10' : 'fts_shutter_updown';;
my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";;
"<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." </div>"
}

Invertiert (0% = Rollo ist unten - 100% = Rollo ist oben)

Code Auswählen Erweitern

{
my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;
my $con = ReadingsVal($name,"state","undef");;
$con = 100 - $con if $con =~ /\d+/;;
my $pic = $con eq "opening" ? 'fts_shutter_up@red' : $con eq "closing" ? 'fts_shutter_down@red' : $con eq "100" ? 'fts_shutter_100' : $con =~ /(\d)\d/ ? 'fts_shutter_'.$1.'0' : $con =~ /\b\d\b/ ? 'fts_shutter_10' : 'fts_shutter_updown';;
my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";;
"<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." </div>"
}


Danke an Beta-User (Hat mir mal wieder was beigebracht)

[Beta-User]

Ist eingecheckt, samt der Umrechnung der Werte im shelly 2.5 (shellies/DEVNAME/relay/1/energy:.* {'relay_1_energy' => sprintf("%.2f",$EVENT/60/1000)}\).

Bitte melden, wenn was nicht funktioniert oder die Formel einen Hau haben sollte...

[87insane]

Bitte noch stateFormat aus dem Template löschen. Ist hier ja nicht mehr notwendig...

[Beta-User]

Wenn ich kein feedback bekomme, checke ich das in ca. 2 Wochen so ein...

So, nun ist es zu spät für kritische Rückmeldungen zu der grundsätzlichen Entscheidung, die Weichen im svn stehen auf $JSONMAP...

Es gab noch ein paar kleinere Änderungen, bin mal gespannt auf euer weiteres feedback; wie immer bei solchen Umstellungen sind Fehler leider nicht auszuschließen, hoffe, es ist mir nicht zu viel "raus" .

Bitte noch stateFormat aus dem Template löschen. Ist hier ja nicht mehr notwendig...

Hmm, hatte mir das kurz angesehen, bin aber grad etwas ratlos gewesen, wie da im Moment stateFormat noch reinkommt?

[raiderxxl]

Hallo,

besteht die Chance für das WLED Template noch die Favoriten oder sogar die Effect inkl. Color-Palette einzubauen?

Gerne kann ich auch einen Meter WS2812B spendieren falls keine Hardware vorhanden ist...

Grüßle

Pascal

[Beta-User]

Du beziehst dich auf das template "wled_controller" (für https://github.com/Aircoookie/WLED/wiki/MQTT)?

Sollte möglich sein, ist aber kein ganz einfaches Thema, weil dann die HTTP API Syntax irgendwie verarbeitet werden muß, und die kommt mir ziemlich kryptisch vor. Daher bitte dazu einen gesonderten Thread hier im MQTT-Bereich aufmachen, dann können wir auch ohne Hardware das eine oder andere Experiment machen..

In Schritt 1 könntest du die setList erweitern um einen setter nach diesem Schema

Code Auswählen Erweitern

api_call BASE_ID/DEVNAME/api $EVTPART1
Damit sollte sich dann der HTTP-Api-Call auch via MQTT versenden lassen, also z.B. "FX=73", um den entsprechenden Effect aufzurufen. Einzelne Dinge könnte man dann entweder dynamisch (mit Zahlenauswahl für den Effekt) oder statisch (einzelne bestimmte Effekte) in die setList einbauen.
Was "die Favoriten" sind, hat sich mir aus der API-Beschreibung nicht erschlossen, vielleicht schreibst du dann auch was dazu in dem separaten Thread.
(dto, wenn es sich um ein ganz anderes attrTemplate handeln sollte, um das es gehen soll).

[frankreed]

Hallo,

ich habe ein FHEM update gemacht und es wurde auch ein neues mqtt2.template heruntergeladen.
Dort habe ich mal reingeschaut und es stehen viele tasmota-Geräte drin.
Nur kann ich die attrTemplate weder einlesen noch werden sie mit attrTemplate ? angezeigt.
PS: shutdown restart und auch einen kompletten reboot habe ich natürlich auch schon gemacht aber? Nada....

Irgendwas stimmt mit dem Aufbau der Liste nicht bzw. Anzeige und Auswahl des entsprechenden Templates nicht.
Habe einen Sonoff Dual und will den jetzt als MQTT2-Device einrichten.

Hat jemand eine Idee?

Grüße Frank

[Beta-User]

Erscheinen die auch nicht in der Liste, die erscheint, wenn du set <irgendein MQTT2_DEVICE> attrTemplate ? ausführst?

In der Dropdown-Auswahl erscheinen eine ganze Anzahl der templates erst, wenn die jeweils den Filterkriterien entsprechen (idR. einen passenden readingList-Eintrag haben, der typischerweise zu autocreate@default-Einstellung der firmware passt).

Anwenden lassen sich die attrTemplates jeweils trotzdem (über die Kommandozeile), aber man muß manuell die entsprechenden Parameter-Abfragen beantworten...

[schwatter]

Ich habe hier einen HDMI-Switch, welcher mit einem Wemos D1 mini bestückt ist.
Das Projekt ist von Frank Enderle.

https://github.com/fenderle/esphome-vorke-hd41

Da ich denke, das der Personenkreis eher sehr klein ist, stelle ich hier meine "Raw definition" zur Verfügung.
Falls es interessant für ein Template ist, kann es gerne mit aufgenommen werden. Für Verbesserungsvorschläge
bin ich aber auch dankbar 

Code Auswählen Erweitern


defmod Vorke_HD41_HdmiSwitch MQTT2_DEVICE vorke_hd41_demo_2cf4321291b8
attr Vorke_HD41_HdmiSwitch IODev myFhembroker
attr Vorke_HD41_HdmiSwitch autocreate 0
attr Vorke_HD41_HdmiSwitch icon rc_HDMI
attr Vorke_HD41_HdmiSwitch oldreadings debug
attr Vorke_HD41_HdmiSwitch readingList vorke_hd41_demo_2cf4321291b8:vorke_hd41_demo/debug:.* { $EVENT =~ s/\033.*?m//g;; { debug=>$EVENT } }
attr Vorke_HD41_HdmiSwitch room 03.Wohnzimmer,MQTT2_DEVICE
attr Vorke_HD41_HdmiSwitch setList HDMI:input_1_source,input_2_source,input_3_source,input_4_source,auto_source vorke_hd41_demo/switch/$EVTPART1/command ON\
AUTOSOURCE:ON,OFF vorke_hd41_demo/switch/auto_source/command $EVTPART1\
AUDIO:stereo_20,dolbydts_51,hd_audio_71,auto_edid vorke_hd41_demo/switch/$EVTPART1/command ON\
ARC:ON,OFF vorke_hd41_demo/switch/arc/command $EVTPART1
attr Vorke_HD41_HdmiSwitch stateFormat {OldReadingsVal($name,"debug","undef")}
attr Vorke_HD41_HdmiSwitch webCmd HDMI:AUTOSOURCE:AUDIO:ARC

setstate Vorke_HD41_HdmiSwitch [D][switch:045]: 'Input 2 Source': Sending state ON
setstate Vorke_HD41_HdmiSwitch 2020-01-19 20:44:07 debug [D][switch:045]: 'Input 1 Source': Sending state OFF
setstate Vorke_HD41_HdmiSwitch 2020-01-19 20:44:07 state HDMI


2 Besonderheiten
-  das Topic debug wurde wegen Ansi Escape Sequenzen erweitert -> s/\033.*?m//g.
-  oldreadings, da das letzte Reading immer den State OFF vom vorherigen Input/Source ausgibt.

Code Auswählen Erweitern

2020-01-19 21:07:41 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:021]: 'Input 1 Source' Turning ON.
2020-01-19 21:07:41 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:045]: 'Input 1 Source': Sending state ON
2020-01-19 21:07:41 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:045]: 'Input 2 Source': Sending state OFF
2020-01-19 21:07:56 MQTT2_DEVICE Vorke_HD41_HdmiSwitch HDMI
2020-01-19 21:07:57 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:021]: 'Input 2 Source' Turning ON.
2020-01-19 21:07:57 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:045]: 'Input 2 Source': Sending state ON
2020-01-19 21:07:57 MQTT2_DEVICE Vorke_HD41_HdmiSwitch debug: [D][switch:045]: 'Input 1 Source': Sending state OFF

[frankreed]

Erscheinen die auch nicht in der Liste, die erscheint, wenn du set <irgendein MQTT2_DEVICE> attrTemplate ? ausführst?

Das hab' ich noch nicht versucht, mache ich aber mal.

In der Dropdown-Auswahl erscheinen eine ganze Anzahl der templates erst, wenn die jeweils den Filterkriterien entsprechen (idR. einen passenden readingList-Eintrag haben, der typischerweise zu autocreate@default-Einstellung der firmware passt).

Sorry das blick' ich nicht was Du meinst. Ich kann im Zusammenhang mit der Tasmota-Firmware nichts mit autocreate anfangen. Und wie kann ich denn die Filterkriterien setzen?

Ich dachte mir, ich gehe beim Anlegen so vor, dass ich ein MQTT2_Device so anlege:

1. define xyz MQTT2_DEVICE
2. Mir dann im angelegten Device in der Auswahlliste bei set xyz attrTemplate alle templates aus mqtt2.template angezeigt werden und ich dann nur noch das passende auswählen muss.

Aber irgendwie werden mir beim beschriebenen Weg nur einige templates angezeigt, sprich die Gesamtliste ist gefiltert. Aber einen Filter habe ich ja nicht gesetzt....
Wo ist mein Denkfehler?

PS: Achso, als Broker habe ich einen mosquitto-Server laufen, der über den MQTT2-Client eingebunden ist.

Grüße

[rudolfkoenig]

Aber einen Filter habe ich ja nicht gesetzt....
Wo ist mein Denkfehler?

Der Filter wird im template gesetzt, damit Geraete nichts "irrelevantes" angeboten bekommen.

Normalerweise veroeffentlicht ein MQTT Geraet nach der Verbindung mit dem Server ein Topic, autocreate legt ein Device an, und aus der Nachricht wird auch sofort ein Reading erstellt. attrTemplate kann anhand reading/readingList raten, was fuer ein Geraet das ist, und das Angebot filtern.

[Beta-User]

...etwas zu langsam, aber ausführlicher:

PS: Achso, als Broker habe ich einen mosquitto-Server laufen, der über den MQTT2-Client eingebunden ist.

Ok, "the hard way"...

Wenn du keine MQTT_GENERIC_BRIDGE am Start hast und dein Broker nur Daten verwaltet, die du letztlich in FHEM haben willst, kannst du am CLIENT auch "autocreate" auf "simple" stellen und dann so vorgehen, wie im Wiki zu MQTT2_CLIENT beschrieben (das "Sortierdevice" konfigurieren).

Ansonsten:

Ich kann im Zusammenhang mit der Tasmota-Firmware nichts mit autocreate anfangen. Und wie kann ich denn die Filterkriterien setzen?

autocreate bezieht sich dabei (fast) immer auf das MQTT2-IO in FHEM, das ist völlig unabhängig von der Frage, wie der externe Client (z.B. die Tasmota-firmware) tickt...
Du brauchst für "autocreate" also ein aktives "autocreate-Device" (TYPE=autocreate), und das Attribut "autocreate" am IO (hier MQTT2_CLIENT).

Ich dachte mir, ich gehe beim Anlegen so vor, dass ich ein MQTT2_Device so anlege:

1. define xyz MQTT2_DEVICE
2. Mir dann im angelegten Device in der Auswahlliste bei set xyz attrTemplate alle templates aus mqtt2.template angezeigt werden und ich dann nur noch das passende auswählen muss.

Aber irgendwie werden mir beim beschriebenen Weg nur einige templates angezeigt, sprich die Gesamtliste ist gefiltert. Aber einen Filter habe ich ja nicht gesetzt....

Die Filter definiere ich als Maintainer der template-File. Indem du nicht autocreate nutzt, profitierst du eben nicht davon, dass jeweils nur das angezeigt wird, was grade relevant ist, sondern hast "das Problem", dass das meiste weggefiltert wird.
Wie geschrieben: Anwenden kann man die "nur gefilterten" templates trotzdem, nur dann eben über die Kommandozeile, wobei man dann eben die weiteren Angaben (v.a. betreffend die Topic-Struktur) in dem Dialogfeld eingeben muß, das man dann angezeigt bekommt.
Es ist mAn. aber einfacher, erst mal wenigstens einen readingList-Eintrag (nämlich bei Tasmota den "LWT") manuell zu setzen (TELETOPIC/LWT:.* LWT), was da für "TELETOPIC" steht, ist nämlich der Topic-Tree-Eintrag, der für die automatische Parametrierung verwendet wird. Da kannst du auch gleich sehen, ob die Verbindung an sich klappt...

PS: demnächst wird es ein update geben, das das prereq:-feature nutzt, dann sind manche templates gar nicht mehr ausführbar, da schon nicht geladen! Das wird z.B. die MiLight- und OpenMQTTGateway-templates betreffen, bei denen Voraussetzung ist, dass man erst mal eine Bridge definiert hat, wähl- und ausführbar bleibt dann erst mal nur das Bridge-Template...

[Beta-User]

Da ich denke, das der Personenkreis eher sehr klein ist, stelle ich hier meine "Raw definition" zur Verfügung.
Falls es interessant für ein Template ist, kann es gerne mit aufgenommen werden.

Der Personenkreis ist sicher beschränkt, aber der Code ist mMn. wegen dem OldReadings-Teil auch für andere interessant; es wird damit ein "allgemeines" Problem gelöst, nämlich die "falsche" Reihenfolge eingehender Nachrichten. Muß mal überlegen, ob ich das vertemplate oder ggf. einfach im Wiki einarbeite...

Für Verbesserungsvorschläge bin ich aber auch dankbar 

Evtl. wäre eine eventMap hifreich, um die eher technische Namensgebung der setter und Readings "anwenderfreundlicher" anzuzeigen (sonst müßte man auf Perl ausweichen). Vermutlich läuft das Ding aber eh' eher im Hintergrund, und Eventhandlern ist das egal...