[GELÖST] - EventMap, Readings und Perl

[Beta-User]

So, jetzt habe ich eine Lösung für das Thema, das scheint auch ohne größere Probleme zu funktionieren, jedenfalls meckerte das Log in verbose 3 nicht rum; allerdings kann ich nicht sagen, ob das der Weisheit letzter Schluß ist:

Code Auswählen Erweitern

attr MQTT2_DVES_186A2F readingList DVES_186A2F:stat/DVES_186A2F/RESULT:.* { json2nameValue($EVENT) }\
DVES_186A2F:tele/DVES_186A2F/STATE:.* { json2nameValue($EVENT) }\
DVES_186A2F:tele/DVES_186A2F/LWT:.* LWT\
DVES_186A2F:cmnd/DVES_186A2F/POWER:.* POWER\
DVES_186A2F:tele/DVES_186A2F/INFO.:.* { json2nameValue($EVENT) }\
DVES_186A2F:stat/DVES_186A2F/POWER1:.* POWER1\
DVES_186A2F:stat/DVES_186A2F/POWER1:ON {{'state' => 'opening'}}\
DVES_186A2F:stat/DVES_186A2F/POWER2:.* POWER2\
DVES_186A2F:stat/DVES_186A2F/POWER2:ON {{'state' => 'closing'}}\
DVES_186A2F:tele/DVES_186A2F/SENSOR:.* { json2nameValue($EVENT) }\
DVES_186A2F:tele/DVES_186A2F/UPTIME:.* { json2nameValue($EVENT) }\
DVES_186A2F:stat/DVES_186A2F/SHUTTER1:.* state
Der Trick bei der Sache ist der, das Ergebnisreading für den Prozentwert direkt in state zu packen (kommt ohne JSON über den SHUTTER1-topic), und die ON-Ereignisse an den Relais doppelt zu verarbeiten (ob das opening/closing jetzt richtig rum ist, kann ich aber nicht sagen...).

Würde das noch (wie bei allen tasmotas in FHEM) erst via template noch auf Kleinschreibung umstellen, und zu dem erforderlichen Reboot mit Wartezeit usw. würde ich annehmen, dass man das mit einer "regulären" sleep-Anweisung und einer Trennung der beiden Konfigurationsanweisung in zwei getrennte publishes hinbekäme (alles in einer Zeile, aber das ist hier OT).

Wenn damit die Frage gelöst ist, wie wir die relevanten Infos Aktor=>FHEM in state bekommen, hier bitte als gelöst markieren und in dem anderen Thread weitermachen.

[87insane]

Guten Morgen zusammen,

...jetzt habe ich eine Lösung für das Thema...

Getestet -> Geht!

Hier würde ich gerne wissen, wie du das heraus gefunden hast. Um den Lösungsweg zu verstehen und mir in Zukunft selber zu helfen. Die Lösung ist so einfach, unglaublich

Markierung als Gelöst folgt gleich. Antwort auf den Rest dann wieder im eigentlichem Thread. Wobei die Antwort nicht sofort kommt, da ich mir erst sleep ansehen muss und die damit verbundenen Probleme :-P - Müsste es ja auch testen und dafür muss ich einen Schalter erstmal wieder zurück setzen und neu flashen. Sonst würde er die Infos schon haben und der Test wäre nicht komplett.

[Beta-User]

Hier würde ich gerne wissen, wie du das heraus gefunden hast.

Unbekannte Geräte schaue ich mir _immer_ erst mal "ohne" FHEM an. Hier habe ich den Weg über rawEvents und den Event-Monitor genommen (das ist zwar FHEM, aber erst mal nur "mitlesend"). Da sieht man u.a., was an Daten über MQTT _vom Aktor her_ kommt. Konzentriert man sich darauf, (ganz ohne dass über MQTT irgendwelche Anweisungen geschickt werden, damit alle Messages also nur durch die lokale Bedienung vor Ort (bzw. hier: das Web-Interface des ESP) ausgelöst werden. Hier war wichtig: Schaltet eines der Relais ein, bewegt sich der Rollladen, und es wird ggf. gemeldet, was die Zielposition ist. Hat der Rollladen das Ziel erreicht, kommt eine weitere Message.

Da gibt es dann zwei Varianten:
Entweder die Info kommt als direkt verwertbarer Reading-Inhalt, hier z.B. über das SHUTTER1-Topic, (was da kommt, solltest du btw. auch zusätzlich noch in "pct" schreiben!) oder es ist JSON. JSON muß man entweder "auspacken lassen", oder die Werte direkt selbst mit Perl-Methoden extrahieren (hier steckt die Zielposition in einem JSON; da wir aber über die Relais-Meldung schon wissen, in welche Richtung sich der Aktor bewegt, würde ich das in unserem Fall hier nicht weiter verwerten, ansonsten wäre das vermutlich ein Fall für $JSONMAP in json2nameValue(); für eine Lösung, die keine invertierte Logik nutzt, könnte aber "direction" interessant sein, da kam aber gefühlt immer "0"). Ein Beispiel für das eigene Extrahieren hatte ich jüngst zu dem "IrReceive" gepostet.
Wie dem auch sei: man kann am Ende jedes readingList-Eintrags eben entweder direkt den Reading-Namen angeben, oder Perl aufrufen (erkennbar an  den Klammern "{...}"). Ein Perl-Aufruf sollte wohl einen HASH zurückliefern (dazu siehe https://www.tutorialspoint.com/perl/perl_data_types.htm), das war jedenfalls meine Schlußfolgerung aus dem gestrigen IR-Experiment. Ob das 100% richtig ist, was die HASH-These angeht, kann ich nicht abschließend beurteilen, daher die Formulierung "scheint zu funktionieren...".