Fensterkontakt 433MHz - SignalESP - Unknowncode - DOIF

[mosen85]

Hallo liebe FHEMler,

um den Öffnungszustand meiner Fenster zu erfassen günstige 433 MHz-Reedkontakte gekauft, welche ich über einen SignalESP auslesen möchte. Der Zustand soll dann per MQTT veröffentlicht werden.

Nun habe ich das Problem, dass die Reedkontakte nicht "out-of-the-box" in FHEM integriert sind, sondern bei Änderung des Zustands jeweils nur ein UNKNWONCODE im Eventmonitor sichtbar ist (offen: i2E020A; geschlossen: i2E020E). Ich habe mir nun eine DOIF-Funktion erstellt, welche aufgerufen werden soll, sobald der vordere Teil des UNKNOWNCODE (i2E02) empfangen wird. Im Anschluss soll über UserReadings eine Variable z.B. "Reedcontact" der Zustand gespeichert werden und per MQTTpublish veröffentlicht werden. Grundsätzlich funktioniert das ganze auch.

Damit der Zustand in regelmäßigen Abständen zum MQTT-Broker gesendet wird habe ich noch ein "event-on-change-reading" und "event-min-interval" hinzugefügt. Sobald ich die beiden Attribute hinzufüge funktioniert die Übertragung nach MQTT nicht mehr. Könnt ihr mir bitte sagen, was ich falsch mache?
Nachstehend findet ihr den Code für einen Fensterkontakt "Ankleide". Danke für eure Hilfe schon mal im Voraus!

Code Auswählen Erweitern

[code]define FK_Ankleide DOIF ([signalESP:&DMSG] =~ "i2E02")
attr FK_Ankleide do always
attr FK_Ankleide event-min-interval .*:600
attr FK_Ankleide event-on-change-reading .*
attr FK_Ankleide mqttPublish Reedcontact|Tampercontact|BatteryState:topic={"Fensterkontakte/Ankleide/$name"}
attr FK_Ankleide room Fensterkontakte
attr FK_Ankleide userReadings tmp_Reedcontact:e_signalESP_DMSG.*0A {return "open"},\
tmp_Reedcontact:e_signalESP_DMSG.*0E {return "close"},\
Reedcontact {ReadingsVal("FK_Ankleide", "tmp_Reedcontact", 0)},\
\
tmp_Tampercontact:e_signalESP_DMSG.*07 {return "open"},\
tmp_Tampercontact:e_signalESP_DMSG.*08 {return "close"},\
Tampercontact {ReadingsVal("FK_Ankleide", "tmp_Tampercontact", 0)},\
\
tmp_BatteryState:e_signalESP_DMSG.*06 {return "LOW"},\
tmp_BatteryState:e_signalESP_DMSG.*09 {return "OK"},\
BatteryState {ReadingsVal("FK_Ankleide", "tmp_BatteryState", 0)}
#   DEF        ([signalESP:&DMSG] =~ "i2E02")
#   FUUID      659497cd-f33f-b082-16cb-c14c07de594cf62d
#   FVERSION   98_DOIF.pm:0.268510/2022-12-13
#   MODEL      FHEM
#   NAME       FK_Ankleide
#   NOTIFYDEV  global,signalESP
#   NR         252
#   NTFY_ORDER 50-FK_Ankleide
#   STATE      cmd_1
#   TYPE       DOIF
#   VERSION    26851 2022-12-13 18:45:56
#   eventCount 49
#   OLDREADINGS:
#   READINGS:
#     2024-01-07 21:32:07   BatteryState    OK
#     2024-01-07 21:32:07   Device          signalESP
#     2024-01-07 21:32:07   Reedcontact     open
#     2024-01-07 21:32:07   Tampercontact   close
#     2024-01-07 21:32:07   cmd             1
#     2024-01-07 21:32:07   cmd_event       signalESP
#     2024-01-07 21:32:07   cmd_nr          1
#     2024-01-07 21:32:07   e_signalESP_DMSG i2E020A
#     2024-01-05 21:51:32   mode            enabled
#     2024-01-07 21:32:07   state           cmd_1
#     2024-01-05 15:13:29   tmp_BatteryState OK
#     2024-01-07 21:32:07   tmp_Reedcontact open
#     2024-01-07 17:02:05   tmp_Tampercontact close
#   Regex:
#     accu:
#     collect:
#     cond:
#       signalESP:
#         0:
#           &DMSG      ^signalESP$
#   attr:
#     cmdState:
#     wait:
#     waitdel:
#   condition:
#     0          ::InternalDoIf($hash,'signalESP','DMSG') =~ "i2E02"
#   do:
#     0:
#       0         
#     1:
#   helper:
#     NOTIFYDEV  global,signalESP
#     event      UNKNOWNCODE i2E020A
#     globalinit 1
#     last_timer 0
#     sleeptimer -1
#     timerdev   signalESP
#     timerevent UNKNOWNCODE i2E020A
#     triggerDev signalESP
#     timerevents:
#       UNKNOWNCODE i2E020A
#     timereventsState:
#       UNKNOWNCODE i2E020A
#     triggerEvents:
#       UNKNOWNCODE i2E020A
#     triggerEventsState:
#       UNKNOWNCODE i2E020A
#   internals:
#     all         signalESP:DMSG
#   readings:
#   trigger:
#   uiState:
#   uiTable:
#
setstate FK_Ankleide cmd_1
setstate FK_Ankleide 2024-01-07 21:32:07 BatteryState OK
setstate FK_Ankleide 2024-01-07 21:32:07 Device signalESP
setstate FK_Ankleide 2024-01-07 21:32:07 Reedcontact open
setstate FK_Ankleide 2024-01-07 21:32:07 Tampercontact close
setstate FK_Ankleide 2024-01-07 21:32:07 cmd 1
setstate FK_Ankleide 2024-01-07 21:32:07 cmd_event signalESP
setstate FK_Ankleide 2024-01-07 21:32:07 cmd_nr 1
setstate FK_Ankleide 2024-01-07 21:32:07 e_signalESP_DMSG i2E020A
setstate FK_Ankleide 2024-01-05 21:51:32 mode enabled
setstate FK_Ankleide 2024-01-07 21:32:07 state cmd_1
setstate FK_Ankleide 2024-01-05 15:13:29 tmp_BatteryState OK
setstate FK_Ankleide 2024-01-07 21:32:07 tmp_Reedcontact open
setstate FK_Ankleide 2024-01-07 17:02:05 tmp_Tampercontact close

[/code]

[Ralf9]

Wenn ich das bei mir mit dem dummysduino simuliere bekomme ich kein UNKNOWCODE im Eventmonitor

Code Auswählen Erweitern

define IT_1527x2e020 IT 1527x2e020 1010 1110

Code Auswählen Erweitern

2024.01.07 22:53:00.399 4: sduinoD/msg get dispatch: i2E020E
2024.01.07 22:53:00.399 5: sduinoD: dispatch i2E020E
2024.01.07 22:53:00.399 4: sduinoD IT: message "i2E020E" (7)
2024.01.07 22:53:00.399 4: sduinoD IT: msgcode "" (0) bin = 001011100000001000001110
2024.01.07 22:53:00.399 5: sduinoD IT: EV1527 housecode = 1527x2e020  onoffcode = 1110
2024.01.07 22:53:00.399 3: sduinoD IT: IT_1527x2e020 off->off
2024-01-07 22:53:00.403 IT IT_1527x2e020 off

2024.01.07 22:53:37.885 4: sduinoD/msg get dispatch: i2E020A
2024.01.07 22:53:37.885 5: sduinoD: dispatch i2E020A
2024.01.07 22:53:37.885 4: sduinoD IT: message "i2E020A" (7)
2024.01.07 22:53:37.885 4: sduinoD IT: msgcode "" (0) bin = 001011100000001000001010
2024.01.07 22:53:37.885 5: sduinoD IT: EV1527 housecode = 1527x2e020  onoffcode = 1010
2024.01.07 22:53:37.885 3: sduinoD IT: IT_1527x2e020 off->on
2024-01-07 22:53:37.886 IT IT_1527x2e020 on
Gruß Ralf

[mosen85]

Hallo Ralf,

vielen Dank für deine Rückmeldung! Ich habe jetzt bei diesen Fensterkontakt für die einzelnen Eigenschaften (Reed/Tamper/Battery) jetzt eine eigene "def" erstellt. Kann man das auch zusammenfassen, damit die Readings in einem Device aufgelistet werden?

Ich wollte jetzt für meine anderen Fensterkontakte genauso vorgehen. Im Schlafzimmer erhalte ich je nach Schaltzustand den UNKNOWNCODE "i55FC0A"/"i55FC0E"/"i55FC06"/"i55FC07"/i55FC08"/i55FC09". Nun habe ich analog zur Ankleide folgende defs angelegt:

Code Auswählen Erweitern

def Schlafzimmer_Reed IT 1527x55FC0 1110 1010
def Schlafzimmer_Tamper IT 1527x55FC0 1000 0111
def Schlafzimmer_Battery IT 1527x55FC0 0110 1001
Hier ist es jetzt aber so, dass die UNKNOWNCODEs das Device nicht triggern. Kannst du mir sagen, woran das liegt?

Nochmal zurück zu meiner ursprünglichen Vorgehensweise von meinem ersten Post: War mein Vorgehen falsch? Hast du eine Idee, warum das MQTTpublish nicht getriggert wird, sobald ich die Attribute "event-min-interval" und "event-on-change" setze?

Vielen Dank und Grüße!

Flo

[Ralf9]

Es gibt das Attribut userV1setCodes
https://fhem.de/commandref_DE.html#userV1setCodes

Mit dem MQTTpublish kann ich nicht weiterhelfen

[Beta-User]

Nochmal zurück zu meiner ursprünglichen Vorgehensweise von meinem ersten Post: War mein Vorgehen falsch? Hast du eine Idee, warum das MQTTpublish nicht getriggert wird, sobald ich die Attribute "event-min-interval" und "event-on-change" setze?

"Falsch" war das Vorgehen vielleich nicht, wenn es mal funktioniert hat, aber dieses Konstrukt sieht für mich "sehr komisch" aus und ich würde immer den Weg über separate HW-Definitionen gehen, wenn es irgend geht.
"Komisch" meint: mehrfache identische userReadings-Namen, "Zwischenverpacken" eines Teilergebnisses, dann kein einschränkender trigger mehr zur "Endauswertung"...
Wenn es unbedingt ein "Einheitsdevice" sein soll, würde ich den Code so universell machen, dass jeder userReadings-Name nur einmal auftaucht, sauber getriggert wird und dann der Code gleich "open" oder "closed" in das Endergebnis schreibt.

Jedenfalls: Wenn ein (passendes) Event geworfen wird, reagiert auch die MQTT_GENERIC_BRIDGE, die da im Hintergrund definiert zu sein scheint. Du hast es mit den (an sich nicht falschen) Attributen (an einem zwischengeschalteten Logikdevice) halt geschafft, die trigger zu verhindern.