Folgende Frage zu Sonoff/Tasmota und MQTT2_Device

[Beta-User]

generell noch was.

Bei Tasmota lässt sich der on, off, toggle und hold Text konfigurieren. Standardmäßig ist das alles in Großbuchstaben. Bei set/cmnd Befehlen unterscheidet tasmota nicht zwischen Groß/Kleinschreibung. Es geht also nur um das zurückmelden.

Man könnte hier einfach SetText1 off, SetText2 on, SetText3 toggle und SetText4 hold per cmnd setzen und ein Tasmota Gerät meldet so zurück wie es FHEM intern überall erwartet. Keine eventmap mehr und keine Probleme mit ON/on etc.

Ich verwende das seit circa einem halben Jahr so und es macht die Sache viel einfacher und einheitlicher. Ob man sowas in die Templates einbauen sollte? Nur mal so als Denkanstoß.

Ohne jetzt näher über irgendwelche Nebenwirkungen nachgedacht zu haben, kommt mir das "richtige" Einstellen der Sendeoptionen am einzelnen Client wie "die" Lösung vor.

Vom Ansatz her ist das ja eine Einmal-Aktion, oder? Man müßte also nur die passenden publish-Anweisungen in ein template packen und über das passende IO an den ESP schicken?
Wenn ja: Dann wäre es m.E. das einfachste, 2-3 "Grund-" templates zu machen, die - sendeseitig nach dem Vorbild von A_01x_tasmota_prefix_clearing_and_reboot - entweder (je als einzelnes template)
a) alles auf "FHEM-Standard" setzen (Kleinschreibung und Verwendung von POWER1 für alle Geräte)
b) alles auf "Tasmota-Default" zurücksetzen (Großschreibung)
c) die einkanaligen auf POWER statt POWER1 zurücksetzen.
(ggf. und das Device dann hinterher wirklich rebooten, für den Fall, dass das notwendig ist, um die Änderungen wirksam werden zu lassen).

Im Ergebnis würde ich dann alle vorhandenen templates so umbauen, das immer erst a) durchläuft, eventMap usw. kann dann weg. Damit wären diese Geräte dann vollständig FHEM-konform, oder?

Wer dann Geräte hat, für die er die "alten" Tasmota-Defaults benötigt, schreibt dann nur noch b) (bzw. c), das intern b) aufruft) drüber. Kann dann zwar sein, dass diese Variante nicht zu so schönen Devices führt, die dann ggf. noch nachbearbeitet werden müssen (devStateIcon etc.?), aber dazu kann man entweder weitere Funktionalität bereitstellen oder im Wiki erläutern, was zu tun ist.

Meinungen?

[IngoF]

Das währe meiner Meinung nach eine sehr gute Lösung. Die mqtt Befehle hab ich auch gerade in Tasmota Wiki gefunden.
StateText1      Show current Off state text
StateText1   <text>   Set Off state text (10 chars max)
StateText2      Show current On state text
StateText2   <text>   Set On state text (10 chars max)
StateText3      Show current Toggle state text
StateText3   <text>   Set Toggle state text (10 chars max)
Dann hätten wir ein Standard der immer funktionieren sollte. Momentan ist das verhalten ja jedes mal anders, je nach Version der Vorlage.
Danke übrigens für die Arbeit mit den Templates. Vereinfacht das normalerweise schon erheblich für mich als halbwissenden  .

Gruß,
Ingo

[Beta-User]

Also, dann mal eine Trockenübung zum Testen (wenn das mit dem Backlog nicht funktioniert bzw. ein Reboot erforderlich wird, bitte ggf. die passenden Zeilen aktivieren und die erste auskommentieren bzw. für das 2. template dann entsprechend ändern):

Code: [Auswählen]

name:A_01z_tasmota_set_lowercase_texts_and_state1
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will change ON, OFF etc. sent from tasmota side to lowercase. <br>When applying the template the tasmota device is rebooted to get all readings
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/Backlog StateText1 off; StateText2 on; StateText3 toggle; SetOption26 1
#set IO_DEV publish cmnd/DEVNAME/StateText1 off#set IO_DEV publish cmnd/DEVNAME/StateText2 on
#set IO_DEV publish cmnd/DEVNAME/StateText3 toggle
#set IO_DEV publish cmnd/DEVNAME/SetOption26 1
#set IO_DEV publish cmnd/DEVNAME/Restart 1

name:A_01z_tasmota_set_uppercase_texts_and_state1
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will change on, off etc. sent from tasmota side to uppercase. NOTE: this  template only exists for compability reasons to older MQTT implementations; not recommended for other user groups
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/Backlog StateText1 OFF; StateText2 ON; StateText3 TOGGLE; SetOption26 1

name:A_01z_tasmota_set_power1_state_to_power
filter:TYPE=MQTT2_DEVICE
desc:Applies to single relay tasmota devices <br>NOTE: this  template only exists for compability reasons to other HA solutions; not recommended for usage in FHEM context
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/SetOption26 0

[Omega]

Ich meine irgendwo gelesen zu haben, dass für ein dauerhaftes Umstellen auf Kleinbuchstaben zuerst ein "savedata 1" und abschließend ein "savedata 0" benötigt wird.
Der Vollständigkeit halber setzte ich auch immer gleich "StateText4 hold" ein, um konsistent zu sein.

LG
Holger

[Beta-User]

Ich meine irgendwo gelesen zu haben, dass für ein dauerhaftes Umstellen auf Kleinbuchstaben zuerst ein "savedata 1" und abschließend ein "savedata 0" benötigt wird.
Der Vollständigkeit halber setzte ich auch immer gleich "StateText4 hold" ein, um konsistent zu sein.

Danke für den Hinweis.
Da ich bekennendermaßen keine Tasmota-Geräte habe, kann ich sowas immer schlecht selbst testen und will - möglichst - auch nicht andere User zum Tester machen.

Könntest du den template-Vorschlag entsprechend erweitern und dann ein getestetes Ergebnis hier posten?

Das kann ich dann gerne wieder versuchen, in die allgemeine Systematik einzubauen.

Und aus dem hier würde mich noch interessieren, ob sowas (ggf. verbessert) funktioniert:

Code: [Auswählen]

attr DEVICE eventMap { dev=>{'^IPAddress(.?): (\d+)\.(\d+)\.(\d+)\.(\d+)$'=>'<html><a href=http://$1.$2.$3.$4/>IPAddress</a></html>', } }

[Omega]

Könntest du den template-Vorschlag entsprechend erweitern und dann ein getestetes Ergebnis hier posten?

Ist mir leider momentan nicht möglich. Musste mein System nach dem letzten Update wg. Problemen bei Homematic auf einen älteren Stand zurücksetzen und "kämpfe" da noch mit den Nachwirkungen.

[IngoF]

Ich meine irgendwo gelesen zu haben, dass für ein dauerhaftes Umstellen auf Kleinbuchstaben zuerst ein "savedata 1" und abschließend ein "savedata 0" benötigt wird.
Der Vollständigkeit halber setzte ich auch immer gleich "StateText4 hold" ein, um konsistent zu sein.

LG
Holger

SaveData ist per default eingeschaltet. Sollte eigentlich kein Problem sein wenn das nicht explizit umgestellt wurde.

SaveData   1 / on   (default) Save parameter changes every second

Ich habe das bei meinem Sonoff Basic Testgerät umgestellt (auf on off POWER1) die setList angepasst und dann die eventmap und stateFormat Attibute gelöscht.
Fuktioniert prima und vereinfacht das doch ganz erheblich.

Grüße,
Ingo

[Beta-User]

Danke euch für die Rückmeldungen!

Das mit dem Rückgriff auf das Backup bei @omega tut mir leid

Versuch, das soweit zusammenzufassen:

Code: [Auswählen]

name:A_01z_tasmota_set_lowercase_texts_and_state1
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will change ON, OFF etc. sent from tasmota side to lowercase. <br>After applying the template you might consider to delete or change stateFormat, eventMap and/or userReadings attribute values
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SetOption26 1; SaveData 1

name:A_01z_tasmota_set_uppercase_texts_and_state1
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will change on, off etc. sent from tasmota side to uppercase. NOTE: this  template only exists for compability reasons to older MQTT implementations; not recommended for other user groups
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/Backlog StateText1 OFF; StateText2 ON; StateText3 TOGGLE; StateText4 HOLD; SetOption26 1
attr DEVICE userReadings state:POWER1:.* { lc(ReadingsVal("DEVICE","POWER1","")) }

name:A_01z_tasmota_set_power1_state_to_power
filter:TYPE=MQTT2_DEVICE
desc:Applies to single relay tasmota devices <br>NOTE: this  template only exists for compability reasons to other HA solutions; not recommended for usage in FHEM context
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/SetOption26 0
attr DEVICE userReadings state:POWER:.* { lc(ReadingsVal("DEVICE","POWER","")) }

name:A_01z_tasmota_test_IPAdress_to_http
filter:TYPE=MQTT2_DEVICE
desc:Applies to single relay tasmota devices <br>NOTE: this  template changes existing eventMap attribute
attr DEVICE eventMap { dev=>{'^IPAddress.?: (\d+)\.(\d+)\.(\d+)\.(\d+)$'=>'<html><a href=http://$1.$2.$3.$4/>IPAddress</a></html>', } }

Anmerkung zu SaveData:
Das scheint ja auch nur eine Einmalaktion zu sein und unschädlich, wenn man es auf default (1) setzt. Ist also jetzt v.a. "sicherheitshalber" drin, falls es jemand ausgeschaltet haben sollte, aber in der Regel eigentlich nicht nötig.

@IngoF:
Darf ich Dich bitten, auch die anderen Templates alle mal zu testen?
Ohne eine abgesicherte Rückmeldung zu den ersten drei würde ich ungern auf der Basis einen grundlegenderen Umbau vornehmen. Man sollte das auf den Devices wenigstens definiert wieder rückgängig machen können, für den Fall, dass es doch irgendwo Auswirkungen hat, die man nicht haben will...

@all:
Wenn niemand rechtzeigit widerspricht, gehe ich davon aus, dass die Änderung auf Kleinschriebung der Tasmota-Messages als neuem Default allseits begrüßt wird!

[Beta-User]

@all:
Wenn niemand rechtzeigit widerspricht, gehe ich davon aus, dass die Änderung auf Kleinschriebung der Tasmota-Messages als neuem Default allseits begrüßt wird!

Nanu?
Gar keine Rückmeldung? Heißt das: Einchecken?!?
(Wenn ich nichts höre, mach ich das voraussichtlich morgen, laß aber den IPAdress-Teil weg).

[IngoF]

So jetzt bin ich endlich zu testen gekommen.
Ich habe meinen Sonoff Basic komplett zurückgesetzt. Die drei Templates zum anpassen der MQTT Parameter funktionieren einwandfrei.
Danach habe ich dann das A01 und A01a Template angewendet.
Das attibut eventMap habe ich dann gelöscht. userReadings müssen auf jeden Fall drin bleiben damit der Status direkt vom Gerät ausgewertet wird. Schalten direkt am Sonoff oder wenn das Gerät nicht erreichbar ist wird zuverlässig zurückgemeldet.
Die Anpassung der Tasmota-Messages würde ich auf jeden Fall begrüßen.

Für was das vierte Template nötig ist erschließt sich mir leider nicht.

Gruß, Ingo

[Beta-User]

Für was das vierte Template nötig ist erschließt sich mir leider nicht.

Das ist ein Wunsch aus dem link unten: Es soll die IP klickbar machen... (ich finde da auch c&p ausreichend, aber wenn es gewünscht wird ). Ich kann's nur nicht testen oder verbessern, da muß was vom Gerät kommen, und mosquitto_pub mit JSON ist nicht so meine Spezialität...

Und aus dem hier würde mich noch interessieren,

[IngoF]

Ich habe jetzt noch den Sonoff Dual getestet. Dabei ist mir aufgefallen das beim Anwenden des A02 Template zwei Geräte erzeugt werden aber beim zweiten Kanal steht in der setList wieder DEVNAME statt dem Gerätenamen drin. Schalten geht dann natürlich nicht.
Beim umbenennen eines Gerätes wird das userReadings Attribut nicht mit angepasst. Muss das manuell gemacht werden oder gibts da eine andere Lösung.

Gruß,
Ingo

[Beta-User]

So, Änderungen sind eingecheckt. Da es insgesamt etwas größere Umbauten waren, wäre ich für nochmaliges kritisches Durchsehen aller Tasmota-Sachen dankbar (bzw. eigentlich die user, die die templates dann später verwenden...)
Damit wäre lowercase der neue Standard, die ESP's werden entsprechend konfiguriert. Zwar erschließt sich mir nicht, warum man die userReadings neben stateFormat noch braucht, aber ihr könnt das besser beurteilen.

Ich habe jetzt noch den Sonoff Dual getestet. Dabei ist mir aufgefallen das beim Anwenden des A02 Template zwei Geräte erzeugt werden aber beim zweiten Kanal steht in der setList wieder DEVNAME statt dem Gerätenamen drin. Schalten geht dann natürlich nicht.
Beim umbenennen eines Gerätes wird das userReadings Attribut nicht mit angepasst. Muss das manuell gemacht werden oder gibts da eine andere Lösung.

Das Dual sollte jetzt auch im zweiten Kanal gehen, die Attribute sind insgesamt auf den Standard "$name" gestellt (das war noch gemischt). Damit sollte das auch Umbenennungen überleben.

Dann gab es auch an ein paar anderen Stellen (die 4-kanaligen) noch die Schreibweise $NAME. Das ist jetzt da auch geändert, wenn es Probleme machen sollte, bitte melden...

[IngoF]

Schläfst du auch mal irgendwann

Zwar erschließt sich mir nicht, warum man die userReadings neben stateFormat noch braucht, aber ihr könnt das besser beurteilen.

Wenn ich die die userReadings und stateFormat lösche und dann direkt am Gerät schalte ändert dich zwar das reading "Power1" aber aber "state" nicht. Sehe also nicht den aktuellen Zustand.
Wenn ich nur stateFormat lösche dann sieht erst mal alles normal aus. Wenn das Gerät aber nicht antwortet dann ändert sich das Lampen Symbol trotzdem obwohl das Gerät nicht schaltet. Mit stateFormat ist dann in diesem Fall die Lampe mit Ausrufezeichen zu sehen.
Wenn ich userReadings lösche und stateFormat nicht das steht im "state" "set_on" oder "set_off".

Nachdem ich jetzt die neuen Templates getestet habe ist mir aufgefallen das bei den vorherringen Tests stateFormat=POWER1 nicht gesetzt war. Wenn das nämlich gesetzt ist kann man sich tatsächlich userReadings, und setStateList sparen und alle funktioniert wir erwartet außer das die Lampe mit Ausrufezeichen bei nicht erfolgreichen Schalten nicht angezeigt wird. Macht also durchaus Sinn die drin zu lassen.

[Beta-User]

Nachdem ich jetzt die neuen Templates getestet habe ist mir aufgefallen das bei den vorherringen Tests stateFormat=POWER1 nicht gesetzt war. Wenn das nämlich gesetzt ist kann man sich tatsächlich userReadings, und setStateList sparen und alle funktioniert wir erwartet außer das die Lampe mit Ausrufezeichen bei nicht erfolgreichen Schalten nicht angezeigt wird. Macht also durchaus Sinn die drin zu lassen.

Hmmm, also im Kern spricht vieles eher für Löschen wenn ich das richtig verstehe.
Den von dir bemängelten Übergangszustand sollte man mit einem passenden setStateList abfangen können.

Kannst du mal für die "einkanaligen" folgendes testen (bei ansonsten gelöschten Attributen)?

Code: [Auswählen]

attr DEVICE setStateList on off(für die mehrkanaligen habe ich grade keine weiterführende Idee, aber vermutlich würde dasselbe als "fake" auch gehen).