Tasmota Timer Werte im FHEM verändern / Ein Aus Schalten / Anzeigen?

[Beta-User]

Lesestoff dazu:
https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt

Der setter/Reading-Name ist noch nicht gut, Stichwort wäre jsonMap.

Ansonsten: Keine Ahnung, was man von dem json wirklich braucht, er sollte halt syntaktisch richtig sein .Und DetlevR hat dahingehend recht, dass es sinnvoll ist, den setter ggf. so zu benennen, dass es klar ist, was er macht (und das ist hier mAn. eben keine verallgemeinerungsfähige Lösung, sondern spezieller Code für einen speziellen Anwendungfall)...

json2nameValue

[DetlefR]

Schön das es funktioniert.

Nur für mich mal zum Verständnis.

Code Auswählen Erweitern

<ftui-timeset [(value)]="Aquariumlampe:Timer1_Time" has-buttons>Uhr</ftui-timeset>

<ftui-button @click="sendFhem('set Aquariumlampe Timer1_Time:time')" popup-close>set</ftui-button>

Löst eine Änderung der Uhrzeit (erste Zeile) nicht schon eine MQTT-Nachricht aus oder das zweite Widget dazu notwendig.

[Konfusius]

Oha, Du hast recht, der Blick in die Tasmota Konsole sagt, dass schon das einstellen die Meldung absetzt.
Dann brauche ich den Button eigentlich gar nicht, es sei denn zum Schließen des Popups.

[Konfusius]

@Beta-User

json2nameValue

Also damit ich das richtig verstehe:
Damit sollen Readings wie "Timer1_Time", die irgendwann mal schwer zu deuten sind in z.B. "Aquariumlampe1_on"  umgemappt werden?

Ich stehe noch auf dem Schlauch den Sinn der Übung zu verstehen.
"Gute Reading-Namen" > ist das damit gemeint?

[Beta-User]

Unter einem "guten" Reading-Namen verstehe ich
- was "übliches" für allgemein gebräuchliche setter usw. (desired-temp bzw. temperature für Soll- und Ist-Temperaturen, volume für Lautstärken, pct für Helligkeit mit 100-er Skala/brightness für 255-er Skala)
- was internationalisiertes ("temperature" statt "Temperatur")

Den Namen des Devices zu doppeln, halte ich nicht für besonders hilfreich für den "Leser".

Würde hier "on_time1" vorschlagen.

Hier: "on" für die Aktion, "time" für "das Sachgebiet" und "1" für den Index.

Sind aber nur meine 2ct...

(PS: Es ist nur bedingt spaßig, dauernd dasselbe zu schreiben; ich versuche das so zu machen, dass es sich meistens lohnt, die bereits gegebenen Hinweise nochmal genauer zu lesen, sobald der Groschen anfängt zu fallen).

[Konfusius]

Ok, ich habe zum Test nun erstmal im jsonMap das ergänzt

Code Auswählen Erweitern

Timer1_Time:on_time1

und in der readingList das eingetragen:

Code Auswählen Erweitern

tele/tasmota_2CA303/Timer1:.* { json2nameValue($EVENT, 'Timer1_', $JSONMAP) }

Damit habe ich die Einschaltzeit der Lampe unter "on_time1"  als reading in der Readings-Liste vorliegen.


Ahh, jetzt kann ich in der setList statt "Timer1_Time:time cmnd...."  auch "on_time1 cmnd..." verwenden! cool! Das ist also der Sinn des Ganzen hoffe ich..

[DetlefR]

Hallo,

mal abgesehen davon, dass ich mir das "schön machen" der Readings Namen für später aufheben würde.
Bist du sicher, dass irgendwann mal eine MQTT Nachricht mit

Code Auswählen Erweitern

tele/tasmota_2CA303/Timer1 kommt.
Tasmota antwortet auf einen Befehl mit

Code Auswählen Erweitern

stat/tasmota_2CA303/RESULT und einem als Json verpacktem Ergebnis (Power mal ausgenommen).
"tele" ist eigentlich für den allg. Status und evt. angeschlossene Sensoren.

Oder es gibt was neues das ich noch nicht kenne

[Konfusius]

Was soll ich sagen, so funktioniert das mit dem neuen reading /setter Namen ohne Probleme.
Auch mit dem FTUI3.
Kommt auch im Tasmota Device alles richtig an.

[DetlefR]

Die Frage ist ja nicht ob im Tasmota was ankommt.
Das funktioniert mit "cmnd/tasmota_2CA303/Timer1".

Ich habe den MQTT Explorer benutzt und mir den Verkehr zwischen FHEM und dem Tasmota Device angesehen.

Schau mal ob da jemals "tele/tasmota_2CA303/Timer1" erscheint.

Schöne Pfingsten

[Konfusius]

Beim Einrichten des Devices sind im FHEM nach dem Neustart des Tasmota Devices alle Timerwerte automatisch erschienen. Da wurde ja noch keine Anfrage abgesetzt. Daher ging ich davon aus, das die unter " tele" reinkommen. Wenn ich wieder zu Haus bin prüfen ich das nochmal genau.

[Beta-User]

mal abgesehen davon, dass ich mir das "schön machen" der Readings Namen für später aufheben würde.

Sowas macht man erfahrungsgemäß gleich oder gar nicht....

Da das kein Hexenwerk ist, wenn man mal kapiert hat, wie es geht, MUSS man das m.E. GLEICH machen, alle anderen Tipps sind UNNÜTZ!

Ob "der Kreis geschlossen" ist, sieht man (mit gesetzter setStateList) eigentlich ganz gut. Erscheint da kurz ein "set" im Reading-Wert, der dann verschwindet, wenn die Rückmeldung kommt (über welchen Topic auch immer), ist dieser Teil "sauber" .

Den Verkehr kann man optional mit den aktuellen Fassungen von MQTT2_(SERVER|CLIENT) auch direkt dort mitverfolgen.

[Konfusius]

@DetlefR
Da hast Du wieder recht! Auf tele/tasmota_2CA303/ kommt niemals was mit Timer an.
Das kommt auf stat/tasmota_2CA303/RESULT an, wie Du schon richtig festgestellt hast.

Wieso das nun trotzdem funktioniert weiß ich noch nicht. Egal, wo ich Timerwerte des Tasmota Devices verändere,
ob im FHEM, im Tasmota WebUI oder im FTUI3, alle haben sofort synchron den selben richtigen neuen Wert.

Und zum und vom das FTUI3 werden diese Werte mit dem neuen Reading / Setting Namen in beiden Richtungen übertragen.

Ich habe das Reading aus der  ReadingList komplett rausgelöscht und es geht immer noch.
anscheinend decken die vorgegebenen Readings das mit ab, so das die jsonMap greift
Das sind die vorhandenen ohne meine zusätzlichen:

Code Auswählen Erweitern

tele/tasmota_2CA303/LWT:.* LWT
  tele/tasmota_2CA303/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/tasmota_2CA303/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/tasmota_2CA303/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/tasmota_2CA303/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
  stat/tasmota_2CA303/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
  stat/tasmota_2CA303/RESULT:.* { $EVENT =~ m,HSBColor...(\d+)\,(\d+)\,(\d+), ? $2 eq ReadingsVal($NAME,"saturation","unknown") ? return : { "saturation"=>$2 } : return }
  stat/tasmota_2CA303/POWER1:.* state
DVES_2CA303:cmnd/tasmota_2CA303/POWER:.* POWER
DVES_2CA303:tasmota/discovery/3C71BF2CA303/config:.* { json2nameValue($EVENT) }
DVES_2CA303:tasmota/discovery/3C71BF2CA303/sensors:.* { json2nameValue($EVENT) }


Das Reading in Zeile 6 wird das machen

@Beta-User
genau, vor meinen Readings "on_time1" usw. steht  im Fhem bei Änderungen kurz "set" vor.
Danke für den Tipp zur Kontrolle.
Ich habe alle anderen TIMER readings, die automatisch erstellt wurden gelöscht, da die neuen das ja nun übernehmen.
Ich freue mich über jeden Tipp vom Profi, auch wenn ich nicht gleich alles verstehe.

[DetlefR]

Das Reading in Zeile 6 wird das machen

Genau richtig. Und da dort auch $JSONMAP drin steht passt die Umsetzung auch.

Vielleicht kann Beta-User Dir noch einen Tipp geben, ob sich

Code Auswählen Erweitern

Timer1_Time:on_time1 so umsetzen läßt, dass man das nicht für alle 16 Timer schreiben muss. Damit kennt er sich besser aus.

[Beta-User]

Vielleicht kann Beta-User Dir noch einen Tipp geben, ob sich

Code Auswählen Erweitern

Timer1_Time:on_time1 so umsetzen läßt, dass man das nicht für alle 16 Timer schreiben muss. Damit kennt er sich besser aus.

Das Setzen von jsonMap ist leider so (relativ) umständlich.

Man könnte natürlich "ein bißchen Perl" basteln, um das hier umzusetzen:

Für "Zeitpläne" mit on/off könnte man dafür auch weekprofile nutzen, das dann auch mit MQTT2_DEVICE umgehen kann, aber zum einen ist mir unbekannt, ob es dafür ein FTUI-Widget gäbe, und zum anderen ist das Umwandeln (und empfangende Auswerten) von Zeitplänen relativ aufwändig. Vermutlich würde es sich für Tasmota aber lohnen, da was zu basteln. Ist doch relativ weit verbreitet...
Falls jemand vorhandenen Code dafür sucht: im Ebus-attrTemplate-Paket ist was zu finden.

Der dortige Code baut dann ein "Zeitplan-Reading" (An/Aus-Zeiten) für jeden Tag zusammen, wenn ich das richtig im Kopf habe... Hier könnte man die Daten vielleicht auch unausgepackt im JSON-Format behalten.

[Konfusius]

Man könnte natürlich "ein bißchen Perl" basteln, um das hier umzusetzen:

Puhh, das ist mir zu viel. Ich bin froh, dass ich grundsätzlich das verstanden habe, was ihr mir bislang erklärt habt.
Aber ich werde mich trotzdem weiter mit Weekprofile beschäftigen.
Ich brauche zwar nur 4 Timer, aber wer weiß, wie es mal weiter geht.
Das für mich wichtigste ist der Lerneffekt.