Fensterkontakt gleichzeitig offen und zu -> Bug ?

[gadget]

Hallo,

ich habe mehrere Eltako Tür/Fensterkontakte im Einsatz. Empfänger ist ein Enocean Pi. Die Kontakte werden bei Abwesenheit auch für die Alarmierung verwendet. Funktioniert seit Monaten problemlos. Ich hatte jetzt allerdings einen nächtlichen Fehlalarm auf den ich mir keinen Reim machen kann.
Normalerweise sendet der Kontakt - wenn sonst nichts los ist - so ca. alle 20 Minuten seinen aktuellen Status (closed).

Als der Fehlalarm aufgetreten ist kam aber GLEICHZEITIG (siehe timestamp)  zu nachtschlafender Zeit "closed" "open" und "teach". Das ist eigentlich nicht möglich. Ich tippe auf einen Bug im Empfängermodul. Ich habe die Logs aller anderen Kontakte überprüft und so ein Verhalten sonst noch nie gesehen. Das fehlerhafte "open" hat dann letztendlich meine Alarmanlage aktiviert ....

Das "teach" ist auch unmöglich - der Empfänger wurde natürlich zur fraglichen Zeit nicht in den Lernmodus gesetzt (es sei denn durch irgend einen internen Bug).

Ideen wie man hier weiter kommen könnte ? Ich möchte ungern erneut die Nachbarn versehentlich mit einer Sirene mitten in der Nacht beschallen ...

Evtl. eine zusätzliche modulinterne Plausibilitätsprüfung ?

Grüße, gadget

Code Auswählen Erweitern


2016-04-30_21:43:56 EnO_019AB243 closed
2016-04-30_22:01:16 EnO_019AB243 closed
2016-04-30_22:18:37 EnO_019AB243 closed
2016-04-30_22:35:58 EnO_019AB243 closed
2016-04-30_22:53:18 EnO_019AB243 closed
2016-04-30_23:10:38 EnO_019AB243 closed
2016-04-30_23:27:59 EnO_019AB243 closed
2016-04-30_23:45:19 EnO_019AB243 closed
2016-05-01_00:02:39 EnO_019AB243 closed
2016-05-01_00:19:59 EnO_019AB243 closed
2016-05-01_00:37:19 EnO_019AB243 closed
2016-05-01_00:54:40 EnO_019AB243 closed
2016-05-01_01:12:00 EnO_019AB243 closed
2016-05-01_01:12:00 EnO_019AB243 open
2016-05-01_01:12:00 EnO_019AB243 teach: 1BS teach-in accepted EEP D5-00-01 Manufacturer: no ID
2016-05-01_01:29:20 EnO_019AB243 closed
2016-05-01_01:46:39 EnO_019AB243 closed
2016-05-01_02:03:59 EnO_019AB243 closed
2016-05-01_02:21:19 EnO_019AB243 closed
2016-05-01_02:38:39 EnO_019AB243 closed
2016-05-01_02:55:59 EnO_019AB243 closed


[gadget]

Hallo,

ich antworte mal auf mich selbst:

Heute Nacht hatte ich das gleiche wieder mal bei einem anderen Kontakt:

Code Auswählen Erweitern


2018-06-13_23:50:00 EnO_019D1BBF closed
2018-06-13_23:50:02 EnO_019D1BBF open
2018-06-13_23:50:02 EnO_019D1BBF teach: 1BS teach-in accepted EEP D5-00-01 Manufacturer: no ID


Kommt (zum Glück) nur alle paar Monate vor, löst bei mir aber halt einen hausinternen Alarm aus ....

Über eine zusätzliche Plausibilitätsabfrage im Code würde ich mich sehr freuen, auch wegen des WAF.

Grüße, gadget

[gadget]

Heute hatte ich das gleiche bei einem Wassermelder Eltako FSM60B, Betriebsart 4 (EEP A5-30-01).
Meldet gleichzeitig open und closed.

Code Auswählen Erweitern


2018-07-29_17:32:46 EnO_019AA924 battery: ok
2018-07-29_17:32:46 EnO_019AA924 contact: open
2018-07-29_17:32:46 EnO_019AA924 open
2018-07-29_17:32:46 EnO_019AA924 battery: ok
2018-07-29_17:32:46 EnO_019AA924 contact: closed
2018-07-29_17:32:46 EnO_019AA924 closed


List:

Code Auswählen Erweitern


Internals:
   DEF        019AA924
   IODev      TCM_ESP3_0
   LASTInputDev TCM_ESP3_0
   MSGCNT     50
   NAME       EnO_019AA924
   NR         542
   NTFY_ORDER 50-EnO_019AA924
   STATE      closed
   TCM_ESP3_0_DestinationID FFFFFFFF
   TCM_ESP3_0_MSGCNT 50
   TCM_ESP3_0_PacketType 1
   TCM_ESP3_0_RSSI -89
   TCM_ESP3_0_ReceivingQuality bad
   TCM_ESP3_0_RepeatingCounter 1
   TCM_ESP3_0_SubTelNum 1
   TCM_ESP3_0_TIME 2018-07-29 17:32:46
   TYPE       EnOcean
   READINGS:
     2018-07-29 17:32:46   battery         ok
     2018-07-29 17:32:46   contact         closed
     2018-07-29 17:32:46   state           closed
     2016-12-02 15:32:53   teach           4BS teach-in accepted EEP A5-30-01 Manufacturer: Eltako
   helper:
Attributes:
   IODev      TCM_ESP3_0
   alias      WassersensorHobbyraum
   devStateIcon open:weather_thunderstorm@green closed:weather_thunderstorm@red
   eep        A5-30-01
   group      contact
   manufID    00D
   room       EnOcean
   subType    digitalInput.01
   teachMethod 4BS


[gadget]

Hallo,

Auch heute mal wieder bei einem anderen Wassermelder in einer anderen FHEM Installation, die ich betreue:

Code Auswählen Erweitern


2019-09-24_09:56:26 EnO_019AC53E battery: ok
2019-09-24_09:56:26 EnO_019AC53E contact: open
2019-09-24_09:56:26 EnO_019AC53E open
2019-09-24_10:29:30 EnO_019AC53E battery: ok
2019-09-24_10:29:30 EnO_019AC53E contact: open
2019-09-24_10:29:30 EnO_019AC53E open
2019-09-24_11:35:38 EnO_019AC53E battery: ok
2019-09-24_11:35:38 EnO_019AC53E contact: open
2019-09-24_11:35:38 EnO_019AC53E open
2019-09-24_11:35:38 EnO_019AC53E battery: ok
2019-09-24_11:35:38 EnO_019AC53E contact: closed
2019-09-24_11:35:38 EnO_019AC53E closed
2019-09-24_12:08:42 EnO_019AC53E battery: ok
2019-09-24_12:08:42 EnO_019AC53E contact: open
2019-09-24_12:08:42 EnO_019AC53E open


-> Um 11:35 Uhr gleichzeitig (!) open und close. Das "close" hat gewonnen und einen (Fehl-) Wasseralarm erzeugt. Wäre echt super wenn es da eine Plausi gäbe, die sowas verwirft.



Grüße,

gadget

[krikan]

-> Um 11:35 Uhr gleichzeitig (!) open und close. Das "close" hat gewonnen und einen (Fehl-) Wasseralarm erzeugt. Wäre echt super wenn es da eine Plausi gäbe, die sowas verwirft.

Zwei bzw. mehrere Zustände und damit Telegramme in einer Sekunde sind doch gut möglich.
Die Telegramme sind per Checksumme abgesichert, so dass durchkommende fehlerhafte Telegramme weitgehend ausgeschlossen sein sollten; wenn die Checksumme nicht passt, steht das auch im Log. Wenn so etwas bei Dir im Log steht, würde ich mir Gedanken machen. Selbst kann ich mich an festgestellte fehlerhafte Telegramme in meinen Installationen nicht erinnern.

Ich würde also erst einmal davon ausgehen, dass FHEM genau das empfängt, was der Sensor schickt. Die Plausibilitätsprüfung musst Du in Deinen Alarmcode einbauen. Wie soll FHEM entscheiden, was für Dich/in Deiner Installation plausibel sein kann? Für mich sind, wie oben geschrieben mehrere Meldung in einer Sekunde plausibel.

Vielleicht schaust Du Dir mal die Empfangsbedingungen an. Bei dem gezeigten list steht TCM_ESP3_0_ReceivingQuality auf bad bei einem Repeater. Das ist nicht ideal;habe ich nirgends. Evtl. hat das Einfluß.

Gruß , Christian

[gadget]

Hi,

bei den letzten Fehl-Alarmen  war die Receiving Quality immer excellent, aber halt zum jeweiligen Repeater. Und die Fehlalarme kamen teilweise mitten in der Nacht wo niemand ein Fenster geöffnet hatte (und schon gar nicht innerhalb der gleichen Sekunde wieder zu). Wenn es immer der gleiche Sensor wäre würde ich den in die Tonne kloppen, aber ich hab das jetzt schon bei mehreren Fensterkontakten und Wassermeldern in zwei verschiedenen fhem Installationen beobachtet.

Das mit einer zusätzlichen fhem Logik abzufangen ist auch schwierig. Der Sensor Status ist ja dann erst wieder beim nächsten zyklischen Telegramm in Ordnung und das dauert dann bis zu 30 Minuten. Oder übersehe ich da was offensichtliches ?

Grüße,

gadget

[krikan]

bei den letzten Fehl-Alarmen  war die Receiving Quality immer excellent, aber halt zum jeweiligen Repeater.

War auch nur ein Strohhalm meinerseits. Bei EnO habe ich -anders als bei ZWave- keine kaputten durchkommende Telegramme in Erinnerung.

Das mit einer zusätzlichen fhem Logik abzufangen ist auch schwierig. Der Sensor Status ist ja dann erst wieder beim nächsten zyklischen Telegramm in Ordnung und das dauert dann bis zu 30 Minuten. Oder übersehe ich da was offensichtliches ?

Eine Logik fällt mir auch nicht ein. Es könnte eben auch ein realer Alarm sein und welches Telegramm ist das Richtige, wenn eines wirklich falsch ist? Für FHEM sind beides "technisch" richtige Telegramme. Wenn man die EnO-Sensoren wenigstens aktiv abfragen könnte...

Wenn es nur Fenstersensoren sind, könnte man noch auf Windeinfluß bei älteren Fenstern tippen. Aber bei Wassermelder und Fenstersensoren !?

Mich würde interessieren, ob andere solche Merkwürdigkeiten auch haben. Da Dein Thread aber schon lange existiert und Du ihn immer wieder belebst, sollte er schon auffallen.

Gruß, Christian

[gadget]

Es könnte eben auch ein realer Alarm sein und welches Telegramm ist das Richtige, wenn eines wirklich falsch ist? Für FHEM sind beides "technisch" richtige Telegramme.

Ich habe leider keine Ahnung, wie die Luftschnittstelle bei Enocean aussieht und ob es insbesondere eine 1:1 Beziehung zwischen Funktelegrammen und Messages in fhem gibt (insbesondere wenn dann noch Repeater im Spiel sind und das Telegramm i.d.R. mehrfach beim Empfänger ankommt).  Meine Theorie ist:

• Ein Enocean Sensor kann mit einem Telegramm mehrere Dinge gleichzeitig übertragen (z.B. Temperatur und Luftfeuchte oder Beleuchtung und "Bewegung erkannt")
• In fhem erhält man dann einen Update mehrerer Readings mit dem gleichen Timestamp
• Weil Enocean Sensoren auf minimalen Energieverbrauch hin entwickelt sind, kann der Rechenaufwand zur Prüfsummenbildung nicht allzu hoch sein. Es wird also (wenn überhaupt) nur ein sehr einfaches Verfahren zum Einsatz kommen, das Übertragungsfehler nicht 100%ig ausschließen kann. Evtl. ist die Prüfsumme auch nur optional und wird bei sehr einfachen Sensoren nicht genutzt.
• Man kann  Encean-Telegramme empfangen, die für einen eigentliche binären Wert GLEICHZEITIG 0 und 1 enthalten und die eine gültige Prüfsumme haben
• Das fhem Modul reicht dies 1:1 durch und man bekommt zum gleichen Timestamp zwei Reading-Updates eines binären Wertes mit wiederspüchlichen Werten.
• Hier könnte man in der Modul-Programmierung ansetzten und (ggf. optional) den Update eines binären Readings in fhem komplett verwerfen.

Mich würde interessieren, ob andere solche Merkwürdigkeiten auch haben. Da Dein Thread aber schon lange existiert und Du ihn immer wieder belebst, sollte er schon auffallen.

Das muss ja nicht notwenigerweise auffallen. Wenn man einen Fensterkontakt z.B. für die Steuerung der Terassenbeleuchtung verwendet, geht halt mal Nachts das Licht für ein paar Minuten an und niemand merkt, das da grad ein Fehler war.

Grüße, gadget

[krikan]

Man kann  Encean-Telegramme empfangen, die für einen eigentliche binären Wert GLEICHZEITIG 0 und 1 enthalten und die eine gültige Prüfsumme haben

Die einzelnen Funktelegramme kommen nacheinander an. Gleichzeitig geht nicht; führt zudem zur Funktelegrammkollision.

Der Telgramm-Aufbau für D5-00-01 (subType contact = Tür/Fenstersensor) laut https://www.enocean-alliance.org/wp-content/uploads/2018/02/EEP268_R3_Feb022018_public.pdf lässt kein GLEICHZEITIGES open und closed zu. Entweder ist das Bit gesetzt oder nicht.

Soweit ich das anhand des Codes in 10_EnOcean.pm nachvollziehen kann, wird ein D5-00-01 - Standard-Telegramm (nicht Teach-In) auch nur einmal analysiert und das Reading/Event erzeugt. Irrtümliche Doppelinterpretation eines Telegrammes schließe ich damit aus.

Das fhem Modul reicht dies 1:1 durch und man bekommt zum gleichen Timestamp zwei Reading-Updates eines binären Wertes mit wiederspüchlichen Werten.

Der "gleiche" Timestamp kommt afaik aus zeitlich nacheinanderkommenden Telegrammen und ist in der ungenauen Sekundenauflösung des Timestamps geschuldet. Wenn Du ein Log mit den Attributen

Code Auswählen Erweitern

attr <TCM> verbose 5
attr global mseclog 1
hättest würde man das auch besser erkennen.

Ich bleibe Ideenlos, wie FHEM

Hier könnte man in der Modul-Programmierung ansetzten und (ggf. optional) den Update eines binären Readings in fhem komplett verwerfen.

so etwas umsetzen bzw. überhaupt feststellen soll, aber vielleicht hat ja sonst jemand Ansatzpunkte.

Gruß, Christian

[gadget]

Der Telgramm-Aufbau für D5-00-01 (subType contact = Tür/Fenstersensor) (...) lässt kein GLEICHZEITIGES open und closed zu. Entweder ist das Bit gesetzt oder nicht.
(...)

Hmm. Der Wassermelder ist ein A5-30-01. Aber da sieht es ähnlich aus, wenn ich die Doku richtig lese..

Trotzdem natürlich ein großes Danke für die Analyse. Da ist dann eine Plausibilitätsprüfung wirklich chancenlos und ich werde wohl mit den gelegentlichen Fehlalarmen leben müssen.

Grüße, gadget.

[MadMax-FHEM]

Ein generelles Verhindern halte ich auch für unmöglich weil es könnte ja tatsächlich stimmen

Aber du könntest ja für dich etwas tun (wenn es wirklich nur "kurz falsch toggelt"):

on/off open/closed kommt, dann ein notify dort ein at auf einige Sekunden (oder wie lange der falsche Wert max. anstehen kann) anlegen...
im at dann noch mal prüfen, ob es tatsächlich ein Alarm geben soll (also ob wirklich on/off open/closed ist) -> Alarm (also das was bislang direkt im Notify etc. war), wenn nicht, dann eben nix machen...

Ich habe ähnliches bei meiner Wohnungstür, weil beim Schließen geprüft wird, ob ich da bin (present).
Wenn ich da bin: keine Nachricht. Wenn ich nicht da bin: Telegram-Nachricht.
Wenn ich aber heimkomme, bin ich manchmal noch nicht gleich "present", will aber auch keine Meldung, dass die Tür aufging/zuging.

Daher definiere ich ein at auf 5min und prüfe, ob ich dann jetzt da bin...
...wenn ja: passt.
...wenn nein: Nachricht

Ja klar, im Falle eines Alarms kommt der halt verzögert (bei dir wie ich so gelesen habe reicht ja fast schon eine Sekunde)...
...aber dafür eigentlich keine Fehlalarme mehr...

Statt einem at ginge auch:

notify auf Wertänderung -> sleep 2s (oder wie lange auch immer) -> prüfen -> Alarm oder auch nicht...

Gruß, Joachim

[gadget]

Ein generelles Verhindern halte ich auch für unmöglich weil es könnte ja tatsächlich stimmen

Aber du könntest ja für dich etwas tun (wenn es wirklich nur "kurz falsch toggelt"):

on/off open/closed kommt, dann ein notify dort ein at auf einige Sekunden (oder wie lange der falsche Wert max. anstehen kann) anlegen...

Es toggelt ja bis zu einer halben Stunde lang falsch. Im Besipiel oben:

open = Normalzustand (kein Wassereinbruch)
closed = Alarmfall

2019-09-24_11:35:38 EnO_019AC53E battery: ok
2019-09-24_11:35:38 EnO_019AC53E contact: open
2019-09-24_11:35:38 EnO_019AC53E open
2019-09-24_11:35:38 EnO_019AC53E battery: ok
2019-09-24_11:35:38 EnO_019AC53E contact: closed
2019-09-24_11:35:38 EnO_019AC53E closed

Den Alarm triggert das "closed".

Erst beim nächsten regulären Update nach über 30 min kommt wieder ein "open":

2019-09-24_12:08:42 EnO_019AC53E contact: open

Den Alarm um 40 Minuten zu verzögern macht auch keinen Sinn. Bis dahin ist im Keller schon Feuchtbiotop bzw. der Einbrecher schon über die Landesgrenze.

Grüße, gadget.

[MadMax-FHEM]

Ah, ok.
Ich dachte es wäre (alarmtechnisch andersrum bzw. eben nur kurz mal "falsch")...

Dann macht das ja (auch hier) keinen Sinn...

Gruß, Joachim