[GELÖST] - EventMap, Readings und Perl

87insane · 19 März 2019, 13:33:14

Hallo zusammen,

da im Wiki (in meinen Augen) zu wenig steht und auch über google kaum Beispiele zu finden sind, richte ich meine Frage mal in die Runde.

Wie kann ich über EventMap in state schreiben? Es geht darum, dass ein Trigger (z.B. POWER1/2) in state etwas schreiben soll. Von einem der guten Kollegen hier bekam ich z.B.:

Code Auswählen

{ dev=>{'^(.*)POWER1: on'=>'state: opening', '^(.*)POWER2: on'=>'state: closing', '^(.*)SHUTTER-1_position: ([\d]+)$'=>'state: $2'} }

Im Wiki finde ich immer nur Beispiele, die auf das reine Event bezogen sind. Also on/off oder sonst was. Ich würde aber gerne zusätzlich den Readingnamen mit abfragen.
Aus dem Beispiel oben, kann man in meinen Augen erkennen was passieren soll. Mir geht es nun darum, dieses Thema komplett zu verstehen.

- Was genau kann hier alles Trigger sein? Nur das was passiert, also on/off/toggle.... oder auch Readings?
- Kann es ohne setreading, wie oben im Beispiel überhaupt was schreiben?
- Habt ihr ggf. noch weitere Beispiele, die es jemandem beim googlen einfacher macht das Prinzip zu verstehen?

Danke und einen sonnigen Tag noch

JoWiemann · 19 März 2019, 13:51:51

Hallo,

grundsätzlich gehört "state" dem Modul und darf nicht beschrieben werden, oder meinst Du "STATE"?

Und bitte, poste doch in Code Tags ein List der Devices.

Grüße Jörg

87insane · 19 März 2019, 13:58:30

Hi,

es geht hier grundsätzlich darum dieses Thema zu verstehen. Mir sind die Trigger anscheinend nicht ganz klar, die genutzt werden können.

state ist doch ein reading. Wenn ich z.B. eine setList setze, wird natürlich open/close was auch immer man dort hinterlegt, auch in state angezeigt.
STATE soll am Ende natürlich alles anzeigen. Das ist aber das kleinere Thema.

Es geht um das Thema von hier: https://forum.fhem.de/index.php/topic,98366.msg917091.html#msg917091

EDIT: An dieser Stelle erwähne ich nochmal - es geht um das generelle Verständnis! Ich denke das viele Anfänger hier zu wenig Beispiele haben.
Über das EventMap wird z.B. auch im EventMonitor "MQTT2_DEVICE MQTT2_Test01 state: opening" angezeigt. Bedeutet ja, der Trigger geht. Nur das Beschreiben nicht von state. Dazu sagte @JoWiemann ja bereits etwas.
Wie kann man state denn ohne setList beschreiben? Es soll (Beispiel oben) wenn POWER1: on, dann setze state: opening. Wie würdet ihr das bewerkstelligen?

Hänge trotzdem mal ein list an:

Code Auswählen

CFGFN      
   CID        Test01
   DEF        Test01
   DEVICETOPIC MQTT2_Test01
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 271
   MQTT2_FHEM_Server_TIME 2019-03-19 14:25:54
   MSGCNT     271
   NAME       MQTT2_Test01
   NR         621
   STATE      ???
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-03-19 14:25:54   DeepSleep       0
     2019-03-19 14:25:54   Heap            20264
     2019-03-19 14:00:23   LWT             Online
     2019-03-19 14:25:54   LoadAvg         9
     2019-03-19 14:00:23   POWER           
     2019-03-19 14:25:54   POWER1          OFF
     2019-03-19 14:25:54   POWER2          OFF
     2019-03-19 14:25:54   SHUTTER-1_direction 0
     2019-03-19 14:25:54   SHUTTER-1_position 0
     2019-03-19 14:25:34   SHUTTER1        0
     2019-03-19 14:25:54   Sleep           100
     2019-03-19 14:25:54   SleepMode       Dynamic
     2019-03-19 14:25:54   Time            2019-03-19T14:25:53
     2019-03-19 14:25:54   Uptime          0T02:53:55
     2019-03-19 14:25:54   Vcc             3.116
     2019-03-19 13:52:58   shutterposition1 0
Attributes:
   IODev      MQTT2_FHEM_Server
   eventMap   { dev=>{'^(.*)POWER1: ON'=>'state: opening', '^(.*)POWER2: ON'=>'state: closing', '^(.*)SHUTTER-1_position: ([\d]+)$'=>'state: $2'} }
   readingList Test01:tele/Test01/LWT:.* LWT
Test01:cmnd/Test01/POWER:.* POWER
Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) }
Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) }
Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) }
Test01:stat/Test01/RESULT:.* { json2nameValue($EVENT) }
Test01:stat/Test01/POWER1:.* POWER1
Test01:stat/Test01/POWER2:.* POWER2
Test01:tele/Test01/STATE:.* { json2nameValue($EVENT) }
Test01:tele/Test01/SENSOR:.* { json2nameValue($EVENT) }
Test01:stat/Test01/SHUTTER1:.* SHUTTER1
Test01:tele/Test01/RESULT:.* { json2nameValue($EVENT) }
Test01:tele/Test01/UPTIME:.* { json2nameValue($EVENT) }
Test01:stat/Test01_fb/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE

Beta-User · 19 März 2019, 14:52:57

Zitat von: JoWiemann am 19 März 2019, 13:51:51
grundsätzlich gehört "state" dem Modul und darf nicht beschrieben werden, oder meinst Du "STATE"?

Hier geht es tatsächlich darum, bei einem MQTT2_DEVICE festzulegen, was in "state" rein soll, weil zu unterschiedlichen Zeiten unterschiedliche Infos über sich unterscheidende topics rein kommen und - im Prinzip - dann auch auf jeweils andere Readings verteilt werden.

Ziel der Aktion ist es also tatsächlich, im Gesamtablauf der eingehenden Messages diejenigen rauszufiltern, die wirklich was über den aktuellen "Zustand" des Aktors selbst was aussagen, und genau das soll in "state" landen (der bei MQTT an sich schon ziemlich willkürlich ist).

@87insane:
JoWiemann könnte vielleicht besser helfen, wenn du uns die Rohdaten liefern würdest, also die Infos, die nacheinander über das MQTT-Protokoll an FHEM bzw. an den Aktor geschickt werden.
Und nach meiner Kenntnis sind auch die beiden Relais-Readings in der eventMap Readings und nicht irgendwas anderes, oder? (Es wird nur nicht jede Änderung erfaßt, sondern eben nur der jeweilige Einschaltvorgang. Das macht es schwerer zu durchschauen, aber genau deswegen suchen wir das richtige Reading für's Ausschalten...).

Was mir auch nicht ganz klar ist, ist die eigentliche eingangs gestellte Frage, an welcher Stelle genau eventMap eingreift; ich bin bisher von der Annahme ausgegangen, dass es bei der Verarbeitung der Readinginhalte (fhem.pl-Funktionen readings.*Update()) stattfindet (@87insane: ohne dass dafür ein Event ausgelöst werden müßte, das passiert rein intern). Aber die Regex habe ich deswegen so vorgeschlagen, dass sie auf das Reading passen müßte, das vom Aktor gesendet wird, wenn er jeweils den Rollladenmotor ausgeschaltet hat, das scheint der aktuelle Schließgrad in % zu sein.

@87insane: Funktioniert das denn in der Praxis?

(Du wirst kaum komplexe Beispiele auch einschließlich der anderen Richtung (FHEM->device, eingeleitet mit "usr=>{<mappings>}") finden, eben weil JoWiemann zurecht darauf hingewiesen hat, dass sowas in der Regel das Modul selbst lösen sollte...).
Es ist deswegen eigentlich auch in den Anfängerfragen falsch aufgehoben, das ist ein Thema für Experten, und thematisch gehört es in dem MQTT-Bereich; da kommt sowas häufiger vor, sonst sollte es besser der jeweilige Modulautor fixen...

87insane · 19 März 2019, 15:19:22

ZitatJoWiemann könnte vielleicht besser helfen, wenn du uns die Rohdaten liefern würdest, also die Infos, die nacheinander über das MQTT-Protokoll an FHEM bzw. an den Aktor geschickt werden.
Und nach meiner Kenntnis sind auch die beiden Relais-Readings in der eventMap Readings und nicht irgendwas anderes, oder? (Es wird nur nicht jede Änderung erfaßt, sondern eben nur der jeweilige Einschaltvorgang. Das macht es schwerer zu durchschauen, aber genau deswegen suchen wir das richtige Reading für's Ausschalten...).

Wie macht man das mit den Rohdaten? Leider war in unseren PMs nur die Frage danach aber keine Erklärung, wie man das macht. Würde ich dann nachholen...
Bin mir nicht sicher (mehrmaliges lesen) was du damit meinst. Aber wenn die Frage war ob POWER1/2 die Relays spiegeln - Dann ist die Antw: Ja. POWER1/2 liefern jeweils ON / OFF. Wenn POWER1 (hoch fahren) eingeschaltet wird, läuft es bis zur gewünschten Position (PCT) oder bei STOP bleibt es eben sofort stehen. In dem Moment wird der PCT Wert gesendet und POWER1 geht OFF. Hoffe ich konnte das beantworten

PS: Im EventMonitor ist das auch alles der Fall. POWER1/2 werden nicht mehr angezeigt sondern opening/closing. Der PCT Wert aus SHUTTER-1_position wird auch angezeigt im EventMonitor. Der Schließgrad in %, ja! Das ist korrekt - Doof nur das er bei Zahlen <10 einstellig angezeigt wird. Das ist aber kein Problem in meinen Augen, nur ein Hinweis.

Zitat@87insane: Funktioniert das denn in der Praxis?

Kann ich nicht beantworten, da ich nicht weiß worauf du dich beziehst....

ZitatDu wirst kaum komplexe Beispiele auch einschließlich der anderen Richtung (FHEM->device, eingeleitet mit "usr=>{<mappings>}") finden...

Wäre aber sicherlich interessant für den ein oder Anderen. Alleine um diese Dinge zu verstehen wäre es schon gut. Ich hänge immer wieder fest aufgrund von, nennen wir es mal Doko-Problemen. Viele "interne" Dinge sind kaum einen bekannt, da es kaum oder keine oder zu wenig Doku gibt. Sicherlich könnte mein komplettes FHEM neu gemacht werden, wenn ich so viel wüsste wie ihr

EDIT: Bringt ggf. der Verkehr aus dem EventMonitor etwas, wenn das Gerät sich ganz neu meldet? Wenn ja - anbei:

Code Auswählen

2019-03-19 15:22:43 Global global UNDEFINED MQTT2_Test01 MQTT2_DEVICE Test01
2019-03-19 15:22:43 Global global DEFINED MQTT2_Test01
2019-03-19 15:22:43 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 LWT: Online
2019-03-19 15:22:43 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 POWER: 
2019-03-19 15:22:43 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) }
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 GroupTopic: sonoffs
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 FallbackTopic: cmnd/Test01_fb/
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 Version: 6.4.1.9 stb-1.1(sonoff)
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 Module: Sonoff T1 2CH
2019-03-19 15:22:43 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) }
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 IPAddress: 192.168.xxx.xxx
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 Hostname: Test01
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 WebServerMode: Admin
2019-03-19 15:22:43 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) }
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 RestartReason: Software/System restart
2019-03-19 15:22:43 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) } Test01:stat/Test01/RESULT:.* { json2nameValue($EVENT) }
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 15:22:43 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) } Test01:stat/Test01/RESULT:.* { json2nameValue($EVENT) } Test01:stat/Test01/POWER1:.* POWER1
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 15:22:43 MQTT2_DEVICE MQTT2_Test01 POWER2: OFF
2019-03-19 15:22:44 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) } Test01:stat/Test01/RESULT:.* { json2nameValue($EVENT) } Test01:stat/Test01/POWER1:.* POWER1 Test01:stat/Test01/POWER2:.* POWER2
2019-03-19 15:22:44 MQTT2_DEVICE MQTT2_Test01 POWER2: OFF
2019-03-19 15:23:02 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) } Test01:stat/Test01/RESULT:.* { json2nameValue($EVENT) } Test01:stat/Test01/POWER1:.* POWER1 Test01:stat/Test01/POWER2:.* POWER2 Test01:tele/Test01/STATE:.* { json2nameValue($EVENT) }
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 SleepMode: Dynamic
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Wifi_BSSId: HIER STEHT DIE MAC
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Wifi_AP: 1
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 POWER2: OFF
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Vcc: 3.116
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Uptime: 0T00:00:30
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Time: 2019-03-19T15:23:02
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Wifi_RSSI: 100
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 LoadAvg: 10
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Heap: 20592
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 DeepSleep: 0
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Wifi_SSId: HIER STEHT DIE SSID
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Wifi_Channel: HIER STEHT DER WLAN CHANNEL
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Sleep: 100
2019-03-19 15:23:02 Global global ATTR MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT Test01:cmnd/Test01/POWER:.* POWER Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) } Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) } Test01:stat/Test01/RESULT:.* { json2nameValue($EVENT) } Test01:stat/Test01/POWER1:.* POWER1 Test01:stat/Test01/POWER2:.* POWER2 Test01:tele/Test01/STATE:.* { json2nameValue($EVENT) } Test01:tele/Test01/SENSOR:.* { json2nameValue($EVENT) }
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 SHUTTER-1_direction: 0
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 Time: 2019-03-19T15:23:02
2019-03-19 15:23:02 MQTT2_DEVICE MQTT2_Test01 SHUTTER-1_position: 0

Anbei auch die Roh-Definition, wenn diese gemeint ist...:

Code Auswählen

defmod MQTT2_Test01 MQTT2_DEVICE Test01
attr MQTT2_Test01 IODev MQTT2_FHEM_Server
attr MQTT2_Test01 readingList Test01:tele/Test01/LWT:.* LWT\
Test01:cmnd/Test01/POWER:.* POWER\
Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) }\
Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) }\
Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) }\
Test01:stat/Test01/RESULT:.* { json2nameValue($EVENT) }\
Test01:stat/Test01/POWER1:.* POWER1\
Test01:stat/Test01/POWER2:.* POWER2\
Test01:tele/Test01/STATE:.* { json2nameValue($EVENT) }\
Test01:tele/Test01/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_Test01 room MQTT2_DEVICE

setstate MQTT2_Test01 2019-03-19 15:30:27 DeepSleep 0
setstate MQTT2_Test01 2019-03-19 15:22:43 FallbackTopic cmnd/Test01_fb/
setstate MQTT2_Test01 2019-03-19 15:22:43 GroupTopic sonoffs
setstate MQTT2_Test01 2019-03-19 15:30:27 Heap 17864
setstate MQTT2_Test01 2019-03-19 15:22:43 Hostname Test01
setstate MQTT2_Test01 2019-03-19 15:22:43 IPAddress 192.168.xxx.xxx
setstate MQTT2_Test01 2019-03-19 15:28:22 LWT Online
setstate MQTT2_Test01 2019-03-19 15:30:27 LoadAvg 9
setstate MQTT2_Test01 2019-03-19 15:22:43 Module Sonoff T1 2CH
setstate MQTT2_Test01 2019-03-19 15:28:22 POWER 
setstate MQTT2_Test01 2019-03-19 15:30:27 POWER1 OFF
setstate MQTT2_Test01 2019-03-19 15:30:27 POWER2 OFF
setstate MQTT2_Test01 2019-03-19 15:22:43 RestartReason Software/System restart
setstate MQTT2_Test01 2019-03-19 15:30:27 SHUTTER-1_direction 0
setstate MQTT2_Test01 2019-03-19 15:30:27 SHUTTER-1_position 0
setstate MQTT2_Test01 2019-03-19 15:30:27 Sleep 100
setstate MQTT2_Test01 2019-03-19 15:30:27 SleepMode Dynamic
setstate MQTT2_Test01 2019-03-19 15:30:27 Time 2019-03-19T15:30:27
setstate MQTT2_Test01 2019-03-19 15:30:27 Uptime 0T00:07:55
setstate MQTT2_Test01 2019-03-19 15:30:27 Vcc 3.116
setstate MQTT2_Test01 2019-03-19 15:22:43 Version 6.4.1.9 stb-1.1(sonoff)
setstate MQTT2_Test01 2019-03-19 15:22:43 WebServerMode Admin
setstate MQTT2_Test01 2019-03-19 15:30:27 Wifi_AP 1
setstate MQTT2_Test01 2019-03-19 15:30:27 Wifi_BSSId xx:xx:xx:.....
setstate MQTT2_Test01 2019-03-19 15:30:27 Wifi_Channel xx
setstate MQTT2_Test01 2019-03-19 15:30:27 Wifi_RSSI 100
setstate MQTT2_Test01 2019-03-19 15:30:27 Wifi_SSId NAME DES WLANs

Beta-User · 19 März 2019, 15:48:56

MQTT-Rohdaten:
Gibt mehrere Wege. Der offizielle: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#MQTT2_SERVER_und_MQTT2_CLIENT_f.C3.BCr_Debugging_nutzen
Du mußt dann also eine passende Regex setzen, um das in den Event-Monitor zu bekommen (evtl. zu weitgehend: ".*"). Dann im Event-Monitor entsprechend filtern...
Alternative: beliebigen MQTT-Client nutzen (ich nehme gerne mosquitto_sub - bitte aber nur das "clients"-Paket installieren, NICHT den Server!), und dann aus einer Konsole rauskopieren, auch dort mit MQTT-Mitteln nur die Dinge filtern, die dieses Gerät betreffen ("+/Test01/#" könnte passen).

Zu POWER1/2 bitte beachten: im Moment sprechen wir in der eventMap NUR von der Richtung Aktor=>FHEM. Solltest du von einem Auslösen von FHEM aus ausgehen, bringt uns das nicht weiter, erst mal brauchen wir nur die direkte Bedienung am Aktor (wenn ich von Aktor spreche, dann meine ich direkt die Hardware, hier also z.B. einen physischen Rollladenschalter, der direkt per Kabel an dem Sonoff-Gerät angeschlossen ist; wenn es das nicht gibt, bitte Info, ob du über das WEB-Interface des Tasmotas schaltest (immer noch ohne FHEM!)).

"Funktioniert das?" war genau darauf bezogen: Wenn du den Aktor direkt mit dem Schalter schaltest, hast du dann korrekte Infos in "state"?

Und lasse bitte alle Formatierungsfragen (einstellig, linksbündig usw.) völlig außen vor, darum kömmern wir uns als letztes.

Was das Doku-Dingens angeht: Es ist ein Sonderfall, den wir hier diskutieren. In der Regel beschäftigen sich mit sowas nur Leute, die Expertenwissen haben und in fhem.pl schauen, wenn sie es genau wissen wollen. Die Alternative ist Beispiele zu kopieren, das betrifft aber dann in der Regel auch nur "spezielle" Devices wie die tasmotas (und da gibt es Beispiele, und da habe ich auch das POWER-Ding her, nur eben abgewandelt und die regexp so eingeschränkt, dass nur das Einschalten in state landet, wie bereits erläutert...). Will heißen: Doku kann hier spärlich ausfallen, der normale User braucht sowas nicht (und sollte besser die Hände davon lassen! Ich werde das jedenfalls - im Unterschied zu vielen anderen Dingen - nicht im Wiki näher erläutern).

87insane · 19 März 2019, 16:01:15

Code Auswählen

MQTT-Rohdaten
Kommen dann gleich ....

Code Auswählen

Zu POWER1/2...
Ich habe aufgrund von Abwesenheit via VPN das Webinterface des Schalters genommen. Um das auch nochmal zu sagen. Das sind fertige Sonoff T1 EU 2-Gang Schalter.
Zuhause kann ich natürlich auch die Tasten am Schalter nutzen.

Code Auswählen

"Funktioniert das?" war genau darauf bezogen: Wenn du den Aktor direkt mit dem Schalter schaltest, hast du dann korrekte Infos in "state"?

Habe ich noch nicht drauf geachtet. Info kommt gleich mit den Rohdaten.

Code Auswählen

Und lasse bitte alle Formatierungsfragen (einstellig, linksbündig usw.) völlig außen vor, darum kömmern wir uns als letztes.

War nur zur Info. Schrieb ja selber schon, das ist nur Kleinkram.

Thema Wiki:
Natürlich ist das wie beim flashen oder sonst was. Entweder man hat Test HW oder man weiß genau was man macht. Ich persönlich denke, man kann ruhig zu viel Info als zu wenig liefern. Wer sich was zerschießt, hat Backups oder eben Test HW. Wer anders handelt, ist selber schuld! Aber so sieht das jeder anders....

Beta-User · 19 März 2019, 16:12:15

Zitat von: 87insane am 19 März 2019, 16:01:15
Code Auswählen Erweitern
MQTT-Rohdaten
Kommen dann gleich ....

Sofern bereits der state (auf Basis der geratenen Angabe in eventMap) stimmt, können wir uns das zwischenzeitlich vermutlich schenken, denn was von FHEM dann rausgeht, kann man an der setList ablesen

. Da ist dann "nur noch" interessant, wie das Wechselspiel zwischen FHEM und dem Aktor ist und was wir dann ggf. in setStateList schreiben.

Aber schau dir das trotzdem an (auch wenn wir weiterbasteln), dann wird dir vermutlich klarer, was der Unterschied zwischen den einzelnen Verarbeitungsebenen ist.

87insane · 19 März 2019, 16:38:55

Bei physikalischem Tastendruck wird weder STATE noch state geschrieben. Das kann ich schon sagen. Werde nun mal eben lesen wie ich die Daten RAW bekomme und gleich nachsenden.

Anbei noch ein EventMonitor vom Tastendruck:

Code Auswählen

2019-03-19 16:37:58 MQTT2_DEVICE MQTT2_Test01 state: opening
2019-03-19 16:37:58 MQTT2_DEVICE MQTT2_Test01 state: opening
2019-03-19 16:38:16 MQTT2_DEVICE MQTT2_Test01 SHUTTER1: 0
2019-03-19 16:38:16 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 16:38:16 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 16:38:17 MQTT2_DEVICE MQTT2_Test01 state: 0
2019-03-19 16:38:17 MQTT2_DEVICE MQTT2_Test01 SHUTTER-1_direction: 0

Beta-User · 19 März 2019, 16:43:00

Hmm,
also: es ist offen (0%), du drückst den "Öffnen"-Button im WEB-IF des Aktors und am Ende steht wieder eine "0" im state?
Wenn das so richtig ist, wäre das in der Richtung nach oben schon mal ok.
Wie sieht es nach unten aus?
Wie, wenn du von unten nach oben fährst?

(EDIT: das gilt aber nur, wenn die Anweisung state so zu schreiben aus der eventMap kommt und nicht z.B. daher, dass die readingList das state-Reading füllt, indem darüber "pct" nach "state" umgepackt wird!)

87insane · 19 März 2019, 17:23:57

Anbei mal die "Rohdaten". Allerdings funktioniert bei verbose 5 im MQTT Server, in meinem EventMonitor Regex nicht sauber. Ich kann sonst immer alles filtern aber hier will es nicht. Es kommen diverse andere Dinge obwohl diese nicht matchen. Aber egal... Anbei mal eine Runde nach oben (POWER1 on bis zum abschalten nach eingestellten 17 Sekunden. Ist kein Rollo hinter, nur der Schalter.):

Code Auswählen

2019.03.19 17:04:34 5 : PUBLISH: 0#(0)(18)stat/Test01/RESULT{"POWER1":"ON"}
2019.03.19 17:04:34 4 : MQTT2_FHEM_Server_192.168.20.108_12426 Test01 PUBLISH stat/Test01/RESULT:{"POWER1":"ON"}
2019.03.19 17:04:34 5 : MQTT2_FHEM_Server: dispatch autocreate=simple\000Test01\000stat/Test01/RESULT\000{"POWER1":"ON"}
2019-03-19 17:04:34 MQTT2_DEVICE MQTT2_Test01 state: opening
2019.03.19 17:04:34 5 : PUBLISH: 0(22)(0)(18)stat/Test01/POWER1ON
2019.03.19 17:04:34 4 : MQTT2_FHEM_Server_192.168.20.108_12426 Test01 PUBLISH stat/Test01/POWER1:ON
2019.03.19 17:04:34 5 : MQTT2_FHEM_Server: dispatch autocreate=simple\000Test01\000stat/Test01/POWER1\000ON
2019-03-19 17:04:34 MQTT2_DEVICE MQTT2_Test01 state: opening
2019-03-19 17:04:38 MQTT2_SERVER MQTT2_FHEM_Server nrclients: 6
2019.03.19 17:04:46 4 : MQTT2_FHEM_Server_192.168.20.108_12426 Test01 PINGREQ
2019.03.19 17:04:52 5 : PUBLISH: 0(23)(0)(20)stat/Test01/SHUTTER10
2019.03.19 17:04:52 4 : MQTT2_FHEM_Server_192.168.20.108_12426 Test01 PUBLISH stat/Test01/SHUTTER1:0
2019.03.19 17:04:52 5 : MQTT2_FHEM_Server: dispatch autocreate=simple\000Test01\000stat/Test01/SHUTTER1\0000
2019-03-19 17:04:52 MQTT2_DEVICE MQTT2_Test01 SHUTTER1: 0
2019.03.19 17:04:52 5 : PUBLISH: 0$(0)(18)stat/Test01/RESULT{"POWER1":"OFF"}
2019.03.19 17:04:52 4 : MQTT2_FHEM_Server_192.168.20.108_12426 Test01 PUBLISH stat/Test01/RESULT:{"POWER1":"OFF"}
2019.03.19 17:04:52 5 : MQTT2_FHEM_Server: dispatch autocreate=simple\000Test01\000stat/Test01/RESULT\000{"POWER1":"OFF"}
2019-03-19 17:04:52 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019.03.19 17:04:52 5 : PUBLISH: 0(23)(0)(18)stat/Test01/POWER1OFF
2019.03.19 17:04:52 4 : MQTT2_FHEM_Server_192.168.20.108_12426 Test01 PUBLISH stat/Test01/POWER1:OFF
2019.03.19 17:04:52 5 : MQTT2_FHEM_Server: dispatch autocreate=simple\000Test01\000stat/Test01/POWER1\000OFF
2019-03-19 17:04:52 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019.03.19 17:04:52 5 : PUBLISH: 0?(0)(18)tele/Test01/RESULT{"SHUTTER-1":{"position":0, "direction":0}}
2019.03.19 17:04:52 4 : MQTT2_FHEM_Server_192.168.20.108_12426 Test01 PUBLISH tele/Test01/RESULT:{"SHUTTER-1":{"position":0, "direction":0}}
2019.03.19 17:04:52 5 : MQTT2_FHEM_Server: dispatch autocreate=simple\000Test01\000tele/Test01/RESULT\000{"SHUTTER-1":{"position":0, "direction":0}}
2019-03-19 17:04:52 MQTT2_DEVICE MQTT2_Test01 SHUTTER-1_direction: 0
2019-03-19 17:04:52 MQTT2_DEVICE MQTT2_Test01 state: 0

Ich habe Test01 mit 0 Infos versehen. Der hat keine setList oder sonst was.
Der ist quasi nur via autocreate rein gelaufen und hat eine readinglist erstellt. (Außer EventMap natürlich)

Offen= 0%
Geschlossen 100%

state wird NICHT geschrieben! Das ist nur im EventMonitor so angezeigt da im EventMap "state:" steht. Wenn ich da "kleineLaterne" rein schreibe, steht eben das da. Oder andersrum - Das reading state gibt es noch nicht. Wird auch nicht angelegt durch EventMap. Oder passiert das hier aus einem mir unbekanntem Grund nicht automatisch?

Anbei, nochmal ein EventMonitor. Dieser zeigt eine Fahrt hoch und danach wieder runter (Hoch ab Anfang / Runter ab 17:19:06):

Code Auswählen

2019-03-19 17:18:42 MQTT2_DEVICE MQTT2_Test01 state: opening
2019-03-19 17:18:42 MQTT2_DEVICE MQTT2_Test01 state: opening
2019-03-19 17:19:00 MQTT2_DEVICE MQTT2_Test01 SHUTTER1: 0
2019-03-19 17:19:00 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 17:19:00 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 17:19:00 MQTT2_DEVICE MQTT2_Test01 SHUTTER-1_direction: 0
2019-03-19 17:19:00 MQTT2_DEVICE MQTT2_Test01 state: 0
2019-03-19 17:19:06 MQTT2_DEVICE MQTT2_Test01 state: closing
2019-03-19 17:19:06 MQTT2_DEVICE MQTT2_Test01 state: closing
2019-03-19 17:19:23 MQTT2_DEVICE MQTT2_Test01 SHUTTER1: 100
2019-03-19 17:19:23 MQTT2_DEVICE MQTT2_Test01 POWER2: OFF
2019-03-19 17:19:23 MQTT2_DEVICE MQTT2_Test01 POWER2: OFF
2019-03-19 17:19:23 MQTT2_DEVICE MQTT2_Test01 SHUTTER-1_direction: 0
2019-03-19 17:19:23 MQTT2_DEVICE MQTT2_Test01 state: 100

Ein wenig Spaß muss auch mal sein...(Eine Fahrt nach oben mit "angepasstem" EventMap):

Code Auswählen

2019-03-19 17:26:04 MQTT2_DEVICE MQTT2_Test01 kleineLaterne: opening
2019-03-19 17:26:04 MQTT2_DEVICE MQTT2_Test01 kleineLaterne: opening
2019-03-19 17:26:22 MQTT2_DEVICE MQTT2_Test01 SHUTTER1: 0
2019-03-19 17:26:22 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 17:26:22 MQTT2_DEVICE MQTT2_Test01 POWER1: OFF
2019-03-19 17:26:22 MQTT2_DEVICE MQTT2_Test01 kleineLaterne: 0
2019-03-19 17:26:22 MQTT2_DEVICE MQTT2_Test01 SHUTTER-1_direction: 0

Beta-User · 19 März 2019, 17:38:18

Hmmm,
sehr seltsam. Wenn du bisher im STATE "opening" oder "closing" sehen konntest, müßte da im geschlossenen Zustand jetzt "100" stehen, das zeigt ja eigentlich auch das was in den Rohdaten steht; {"SHUTTER-1":{"position":0, "direction":0}} wird m.E. ausgepackt zu SHUTTER-1_direction: 0 UND
SHUTTER-1_position: 0, aber SHUTTER-1_position wird sofort durch die eventMap stattdessen nach state geschoben.

Wenn du die Readings nicht siehst und das ein "neues" Device ist: Hast du das Browserfenster mal neu geladen? (Neue Readings werden erst danach sichtbar; aber das abgeleitete STATE müßte es eigentlich auch schon direkt auch zeigen...)

87insane · 19 März 2019, 17:53:20

Sind wir wieder bei TeamViewer oder sonst was...

In den "alten" Schaltern, die auch bis auf das Thema laufen. Kann ich zwar kurz sehen opening beim aktualisieren aber am ende stehen immer die set Befehle drin. Bei denen ist aber auch x Zeugs (siehe Template) eingetragen. Das ist bei dem "neuen" nicht der Fall, da er wirklich jungfräulich ist. Ja, natürlich habe ich das Fenster aktualisiert. Habe x Fenster auf und den Rechner auch zwischenzeitlich gewechselt.

Es wird nichts nach STATE oder state geschoben. Soweit ich die Doku las, müsste alles von state nach STATE geschoben werden. Denke, darauf wolltest du hinaus. Da aber state nicht existiert oder erstellt wird, wird auch nichts nach STATE geschoben. Kann es sein, dass die Ausgabe im EventMonitor über EventMap einfach nur so angezeigt wird da EventMap bzw. der Trigger reagiert, so sber kein reading wirklich schreiben kann? (siehe "KleineLaterne") - Ein solches Reading erstellt er ja auch nicht in der Form.

Alter Schalter List (EventMap aktuell rauß, da es ja nicht ging.):

Code Auswählen

Internals:
   CFGFN      ./FHEM/Tasmota.cfg
   CID        az_rollo
   DEF        az_rollo
   DEVICETOPIC az_rollo
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 21
   MQTT2_FHEM_Server_TIME 2019-03-19 17:41:40
   MSGCNT     21
   NAME       az_rollo
   NR         61
   STATE      Online
0
<br>
<a href="http://192.168.xxx.xxx" target="_blank">Webinterface</a>
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-03-19 17:41:40   DeepSleep       0
     2019-03-16 14:36:43   FallbackTopic   cmnd/az_rollo_fb/
     2019-03-16 14:36:43   GroupTopic      Rollos
     2019-03-19 17:41:40   Heap            21232
     2019-03-16 14:36:43   Hostname        az_rollo
     2019-03-19 17:00:35   LWT             Online
     2019-03-19 17:41:40   LoadAvg         9
     2019-03-16 14:36:43   Module          Sonoff T1 2CH
     2019-03-19 17:00:35   POWER           
     2019-03-19 17:41:40   POWER1          off
     2019-03-19 17:41:40   POWER2          off
     2019-03-16 14:36:43   RestartReason   Software/System restart
     2019-03-19 17:41:40   SHUTTER-1_direction 0
     2019-03-19 17:41:40   SHUTTER-1_position 0
     2019-03-19 17:41:40   Sleep           100
     2019-03-19 17:41:40   SleepMode       Dynamic
     2019-03-19 17:41:40   Time            2019-03-19T17:41:40
     2019-03-19 17:41:40   Uptime          3T03:05:07
     2019-03-19 17:41:40   Vcc             3.148
     2019-03-16 14:36:43   Version         6.4.1.9 stb-1.1(sonoff)
     2019-03-16 14:36:43   WebServerMode   Admin
     2019-03-19 17:41:40   Wifi_AP         1
     2019-03-19 14:26:10   pct             0
     2019-03-19 12:44:25   shutterclose1   100
     2019-03-18 15:23:00   shutteropen1    0
     2019-03-19 14:25:52   shutterposition1 0
     2019-03-18 15:18:18   shutterstop1    54
     2019-03-18 15:23:00   state           set_open
     2019-03-18 15:18:18   stop            set
Attributes:
   IODev      MQTT2_FHEM_Server
   alexaName  Arbeitszimmer Rollo
   alias      Arbeitszimmer Rollo
   autocreate 1
   cmdIcon    open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
   comment    SHUTTEROPENDURATION: Time for a complete shutter up. SHUTTERCLOSEDURATION: Time for a complete shutter down.
   devStateIcon set_open:fts_shutter_up@red set_close:fts_shutter_down@red Online:10px-kreis-gruen@green Offline:10px-kreis-rot@red 100:fts_shutter_100 0:fts_shutter_10 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 \b\d\b.*:fts_shutter_10 set_.*:fts_shutter_updown
   model      A_02b_tasmota_2ch_shutter
   readingList tele/az_rollo/LWT:.* LWT
   cmnd/az_rollo/POWER:.* POWER
   stat/az_rollo/RESULT:.* { json2nameValue($EVENT) }
   stat/az_rollo/POWER1:.* POWER1
   stat/az_rollo/POWER2:.* POWER2
   stat/az_rollo/SHUTTER1:.* pct
   tele/az_rollo/RESULT:.* { json2nameValue($EVENT) }
   tele/az_rollo/STATE:.* { json2nameValue($EVENT) }
   tele/az_rollo/SENSOR:.* { json2nameValue($EVENT) }
   tele/az_rollo/INFO1:.* { json2nameValue($EVENT) }
   tele/az_rollo/INFO2:.* { json2nameValue($EVENT) }
   tele/az_rollo/INFO3:.* { json2nameValue($EVENT) }
   tele/az_rollo/UPTIME:.* { json2nameValue($EVENT) }
   tele/az_rollo_fb/LWT:.* LWT
   cmnd/az_rollo_fb/POWER:.* POWER
   stat/az_rollo_fb/RESULT:.* { json2nameValue($EVENT) }
   stat/az_rollo_fb/POWER1:.* POWER1
   stat/az_rollo_fb/POWER2:.* POWER2
   stat/az_rollo_fb/SHUTTER1:.* pct
   tele/az_rollo_fb/RESULT:.* { json2nameValue($EVENT) }
   tele/az_rollo_fb/STATE:.* { json2nameValue($EVENT) }
   tele/az_rollo_fb/SENSOR:.* { json2nameValue($EVENT) }
   tele/az_rollo_fb/INFO1:.* { json2nameValue($EVENT) }
   tele/az_rollo_fb/INFO2:.* { json2nameValue($EVENT) }
   tele/az_rollo_fb/INFO3:.* { json2nameValue($EVENT) }
   tele/az_rollo_fb/UPTIME:.* { json2nameValue($EVENT) }
   room       Alexa,Arbeitszimmer,Tasmota
   setList    close:noArg cmnd/az_rollo/SHUTTERCLOSE
   open:noArg cmnd/az_rollo/SHUTTEROPEN
   half:noArg cmnd/az_rollo/shutterposition 50
   pct:slider,0,1,100 cmnd/az_rollo/shutterposition1 $EVTPART1
   stop:noArg cmnd/az_rollo/SHUTTERSTOP
   resetClose:noArg cmnd/az_rollo/SHUTTERSETCLOSE
   x_configuration cmnd/az_rollo/$EVTPART1 $EVTPART2
   x_invert:select,0,1 cmnd/az_rollo/SHUTTERINVERT $EVTPART1
   setStateList open close
   stateFormat LWT
SHUTTER-1_position
<br>
<a href="http://192.168.xxx.xxx" target="_blank">Webinterface</a>
   webCmd     :open:close:half:stop:pct

Neuer Schalter List:

Code Auswählen

 Internals:
   CID        Test01
   DEF        Test01
   DEVICETOPIC MQTT2_Test01
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 57
   MQTT2_FHEM_Server_TIME 2019-03-19 17:40:47
   MSGCNT     57
   NAME       MQTT2_Test01
   NR         339
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-03-19 17:40:47   DeepSleep       0
     2019-03-19 15:22:43   FallbackTopic   cmnd/Test01_fb/
     2019-03-19 15:22:43   GroupTopic      sonoffs
     2019-03-19 17:40:47   Heap            21248
     2019-03-19 15:22:43   Hostname        Test01
     2019-03-19 15:22:43   IPAddress       192.168.xxx.xxx
     2019-03-19 17:00:35   LWT             Online
     2019-03-19 17:40:47   LoadAvg         9
     2019-03-19 15:22:43   Module          Sonoff T1 2CH
     2019-03-19 17:00:35   POWER           
     2019-03-19 17:40:47   POWER1          OFF
     2019-03-19 17:40:47   POWER2          OFF
     2019-03-19 15:22:43   RestartReason   Software/System restart
     2019-03-19 17:40:47   SHUTTER-1_direction 0
     2019-03-19 17:40:47   SHUTTER-1_position 0
     2019-03-19 17:26:22   SHUTTER1        0
     2019-03-19 17:40:47   Sleep           100
     2019-03-19 17:40:47   SleepMode       Dynamic
     2019-03-19 17:40:47   Time            2019-03-19T17:40:47
     2019-03-19 17:40:47   Uptime          0T02:18:15
     2019-03-19 17:40:47   Vcc             3.116
     2019-03-19 15:22:43   Version         6.4.1.9 stb-1.1(sonoff)
     2019-03-19 15:22:43   WebServerMode   Admin
Attributes:
   IODev      MQTT2_FHEM_Server
   eventMap   { dev=>{'^(.*)POWER1: ON'=>'kleineLaterne: opening', '^(.*)POWER2: ON'=>'kleineLaterne: closing', '^(.*)SHUTTER-1_position: ([\d]+)$'=>'kleineLaterne: $2'} }
   readingList Test01:tele/Test01/LWT:.* LWT
Test01:cmnd/Test01/POWER:.* POWER
Test01:tele/Test01/INFO1:.* { json2nameValue($EVENT) }
Test01:tele/Test01/INFO2:.* { json2nameValue($EVENT) }
Test01:tele/Test01/INFO3:.* { json2nameValue($EVENT) }
Test01:stat/Test01/RESULT:.* { json2nameValue($EVENT) }
Test01:stat/Test01/POWER1:.* POWER1
Test01:stat/Test01/POWER2:.* POWER2
Test01:tele/Test01/STATE:.* { json2nameValue($EVENT) }
Test01:tele/Test01/SENSOR:.* { json2nameValue($EVENT) }
Test01:tele/Test01/UPTIME:.* { json2nameValue($EVENT) }
Test01:stat/Test01/SHUTTER1:.* SHUTTER1
Test01:tele/Test01/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE

EDIT:
Vorhin war ja nur eine Fahrt aber ggf. ist das auch für jemanden wichtig. Die Schalter mit der FW senden auch ihren Status:

Code Auswählen

2019.03.19 17:05:44 5: PUBLISH: 0(153)(2)(0)(17)tele/Test01/STATE{"Time":"2019-03-19T17:05:44","Uptime":"0T01:43:12","Vcc":3.116,"SleepMode":"Dynamic","Sleep":100,"LoadAvg":9,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"NAME/SSID des WLANS","BSSId":"MAC ADRESSE","Channel":WLAN Channel,"RSSI":100},"DeepSleep":0,"Heap":21248}
2019.03.19 17:05:44 4: MQTT2_FHEM_Server_192.168.xxx.xxx_12426 Test01 PUBLISH tele/Test01/STATE:{"Time":"2019-03-19T17:05:44","Uptime":"0T01:43:12","Vcc":3.116,"SleepMode":"Dynamic","Sleep":100,"LoadAvg":9,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"","BSSId":"","Channel":,"RSSI":100},"DeepSleep":0,"Heap":21248}
2019.03.19 17:05:44 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000Test01\000tele/Test01/STATE\000{"Time":"2019-03-19T17:05:44","Uptime":"0T01:43:12","Vcc":3.116,"SleepMode":"Dynamic","Sleep":100,"LoadAvg":9,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"","BSSId":"","Channel":,"RSSI":100},"DeepSleep":0,"Heap":21248}
2019.03.19 17:05:44 5: PUBLISH: 0\(0)(18)tele/Test01/SENSOR{"Time":"2019-03-19T17:05:44","SHUTTER-1":{"position":0, "direction":0}}
2019.03.19 17:05:44 4: MQTT2_FHEM_Server_192.168.xxx.xxx_12426 Test01 PUBLISH tele/Test01/SENSOR:{"Time":"2019-03-19T17:05:44","SHUTTER-1":{"position":0, "direction":0}}
2019.03.19 17:05:44 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000Test01\000tele/Test01/SENSOR\000{"Time":"2019-03-19T17:05:44","SHUTTER-1":{"position":0, "direction":0}}

Beta-User · 19 März 2019, 19:32:27

Zitat von: 87insane am 19 März 2019, 17:53:20
Sind wir wieder bei TeamViewer oder sonst was...

...du hast es geschafft. Ich gebe mich geschlagen, ich muß das live sehen...
Also habe ich vorhin meinen Ersatz-Wemos gesucht und geflasht!

Ergebnis: Gibt es ein state-Reading, wird dieses "irgendwie" auch aktualisiert (ganz wie es nach dem Event-Monitor-Auszug sein müßte). ABER: man sieht das nur daran, dass der passende Inhalt auch in FHEMWEB angezeigt wird, weswegen und das dann auch rot wird. Es findet aber keine Aktualisierung des eigentlichen Readings statt, das nimmt nämlich wieder den ursprünglichen Wert an, den es vorher hatte, sobald man das Browserfenster neu lädt

.

Da muss ich erst mal noch drüber nachdenken, dazu fällt mir vorläufig nix sinnvolles ein

87insane · 20 März 2019, 07:47:14

Außer der Befehl kommt aus der setList. Dann bleibt er stehen. Ggf. hilft der Hinweis beim nachdenken.
Die Readings werden nicht angelegt über das EventMap. Weder "state" noch "KleineLaterne" wurden angelegt.

Beta-User · 20 März 2019, 07:51:02

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

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 · 20 März 2019, 08:53:32

Guten Morgen zusammen,

Zitat...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 · 20 März 2019, 09:51:04

Zitat von: 87insane am 20 März 2019, 08:53:32
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...".