FHEM Forum

Hallo Freunde,

ich habe ein sehr seltsames Problem. In meinem Haus habe ich ich mehrere Tür/Fensterkontakte HM-Sec-SCo installiert.
Diese Kontakte starten bei Betätigung ein Notifies, das wie folgt aussehen:

FK1_Esszimmer:open {Alarm_sofort()}

Jeder Kontakt hat sein eigenes Notify.

Nun wird dieses Notify aber immer wieder getriggert, obwohl keiner der Kontakte geöffnet wurde.
Es fällt auf, dass immer genau zu dem Zeitpunkt des Fehlalarms in der Logfile von einem der Kontakte eine solche Meldung steht:

2016-02-14_18:32:39 FK1_Esszimmer Activity: alive

Kann es sein, dass das notify von einem Statuswechsel von alive nach dead getriggert wird?
Oder gib es eine andere Erklärung für dieses Phänomen?
Für Tipps wäre ich sehr dankbar.

Gruß

Kurt

Hallo,

was ist bei cycleInfoMsg eingestellt ? Damit meldet sich der Kontakt regelmäßig und sollte nicht dead sein / werden. Es wurden bei dem CSo schon mal Fehler gemeldet, die durch Reflektionen auf dem Sensor ausgelöst werden. Wenn das immer zu annähernd gleichen Zeit passiert, könnte das von Sonneneinstrahlung her kommen.

Gruß Christoph

Hallo Christopdh,

diese Register kann ich nicht finden. Wie kann ich es anzeigen?
Derf Fehler tritt sporadisch und bei unterschiedlichen Kontakten auf.
Warum wird das notify getriggert, obwohl der Kontakt nicht geöffnet wird. Ein Öffnen wird auch in der LOG file nicht angezeigt.
Kannst Du mir vielleicht nich verraten, was hinter den Stati alive und dead steckt.

Gruß

Kurt

Hallo,

also über das Attribut Expert kann man einstellen, wieviele der Register angezeigt werden sollen. Das alive bzw. dead - normalerweise melden sich batteriebetriebene Geräte regelmäßig. Martin (Entwickler) hat das schon entsprechend eingestellt. Wenn ein Gerät sich nicht in dieser Zeit meldet, geht der Status von alive auf dead. Bei den Fensterkontakten gibt es ein Register das auf on gestellt werden sollte, damit sich der Kontakt, auch wenn das Fenster nicht geöffnet wurde, alle 24 h meldet. Die SCo messen optisch und sind somit anfällig gegen Streulicht von außen. Deshalb habe ich die "alten" Magnetkontakte lieber. Nicht umsonst arbeiten die VDS Anlagen mit Reedkontakten.

Gruß Christoph

R-cyclicInfoMsg steht auf "on".
Es stört mich auch nicht, dass sich der Kontakt regelmässig meldet.
Aber ich habe noch keine Erkläring dafür, dass notifys getriggert werden, ohne dass ein Kntakt betätigt wird.
An Fremdlicht kann es nicht liegen, weil die Kontkate innen montiert sind und vor Sonneneinstrahlung geschützt ist.
Ich werde die Sache weiter untersuchen, bin aber für Tipps sehr dankbar.

Gruß

Kurt

Das notify wird getriggert, falls das Geraet FK1_Esszimmer ein Event open (genau dieses Wort) erzeugt. Ob das vom Geraet direkt oder vom Modul generiert wird, oder womoeglich ein Bug im Zusammenspiel Modul/fhem.pl vorliegt kann ich nicht sagen. FileLog muesste das Event (bei passenden Regexp) auch protokollieren, da sie die Events genauso prueft wie notify.

Ich wuerde als erstes pruefen, ob dieser Funktionsaufruf wirklich nur von diesem Notify erfolgen kann, danach ein FileLog passend konfigurieren, und nach einem "Problemfall" den Log untersuchen.  Wenn du danach einen Bug in FHEM vermutest, dann brauche ich zum Untersuchen einen Log-Mitschnitt mit "attr CUL/HMLAN log verbose 5".

Obwohl ich immer noch im Trüben fische, ist es mir zumindest mal gelungen den Fehler zu provozieren. Offensichtlich hat es etwas mit der Funktion von "actCycle" zu tun.
Wenn ich den Wert dieses Reg in irgend einem Kontakt von 1:05 auf 0:10 ändere, dann tritt der Fehler sofort auf.
Dann wird das Notify offensichtlich getriggert.
Ich habe versucht ein solches Ereignis in der Logfile mit Verbose 5 und im Event Monitor einzufangen.
Die Auszüge findest Du in der angehängten .pdf Datei.
Der Fehler beginnt irgendwo in Zeile 6 des Logs mit :

2016.02.15 18:21:31 3: Device TK1_Wohnzimmer added to ActionDetector with 000:10 time

Vielleicht ist noch wichtig zu wissen, dass ich meine Alarmanlage im Großen und Ganzen in einem Python Programm steuere. Von dort werden die Kontakte auch über Telnet abgefragt.

Mein Nachbar hat auch einige Homatic Komponenten im Einsatz, von denen ich Datenpakte empfange.
Die sehen so aus:
2016-02-15 18:45:32 CUL CUL_0 UNKNOWNCODE A0C6386701CE71B00000000CA37::-109.5:CUL_0
2016-02-15 18:45:52 CUL CUL_0 UNKNOWNCODE A0B63A1581CE71B1CEEF4000D::-103:CUL_0
2016-02-15 18:45:52 CUL CUL_0 UNKNOWNCODE A0E6382021CEEF41CE71B01010A0036::-103.5:CUL_0
2016-02-15 18:45:52 CUL CUL_0 UNKNOWNCODE A1064A0011CE71B1CEEF401051CE71B0105::-106:CUL_0
2016-02-15 18:45:52 CUL CUL_0 UNKNOWNCODE A0A6480021CEEF41CE71B00::-104:CUL_0
2016-02-15 18:45:52 CUL CUL_0 UNKNOWNCODE A0A6580021CEEF41CE71B00::-100.5:CUL_0
2016-02-15 18:45:52 CUL CUL_0 UNKNOWNCODE A0B66A0011CE71B1CEEF40106::-104:CUL_0
2016-02-15 18:45:53 CUL CUL_0 UNKNOWNCODE A0A6680021CEEF41CE71B00::-100:CUL_0
2016-02-15 18:48:12 CUL CUL_0 UNKNOWNCODE A0B64A2581CE71B1D6174000D::-105:CUL_0
2016-02-15 18:50:18 CUL CUL_0 UNKNOWNCODE A0E6582021CEEF41CE71B01010A0038::-101.5:CUL_0

Ich glaube aber nicht, dass das etwas mit meinem Problem zu tun hat.

Vielen Dank im Voraus für die Unterstützung.

Gruß

Kurt

Bitte kein Word->PDF mir bauen, damit habe ich Probleme, da ich ich den Text analysieren und nicht lesen will.
Lieber .txt aus Notepad.

Es kommt mir so vor, dass der ActionDetector fuer den ersten Aufruf verantwortlich ist, und den von Alarm_sofort() ausgeloesten Befehle (set Output1 on?) fuer den zweiten Aufruf, und das wiederholt sich.

Wg. UNKNOWNCODE: das ist ein Bug in 10_CUL_HM.pm, da es bei unbekannten Housecode die Verarbeitung an weitere Module weitergibt, anstatt es zu Protokollieren/Verschweigen/etc. Da es keine weiteren Module gibt, die HM verstehen, gibt fhem.pl diese Fehlermeldung aus.

Hier die Logfile im gewünschten Format.

Hi Kurt,

hatte vor Ewigkeiten das gleiche Problem. Setze für den Fensterkontakt zunächst:

attr meinFK event-on-change-reading state

Das Problem ist, dass der FK bei der alive-meldung, die du ja haben willst, den letzten Status (offen/geschlossen) nochmal mit sendet. Dadurch sollte dann auch das Event gefeuert werden. Mit event-on-change-reading verhinderst du ein Event, wenn sich der Status gar nicht geändert hat (wenn die alive Meldung kommt wird ja bei geschlossenen Fenster der state von "closed" nochmal auf "closed" gesetzt - das verhinderst du so).

Zusätzlich habe ich meine Notifies noch folgendermaßen gegen Fehlalarme "gesichert":

FK1_Esszimmer:open {
    if (InternalVal($NAME,"TYPE","unknown") eq "CUL_HM") {Alarm_sofort();}
}

Das sorgt dafür, dass das Event von einem "echten" Homematic-Device kommen muss.

Auf diese Weise Fehlalarmfrei seit 2014 (tm) ;-)

Vielen Dank für den interessanten Hinweis.
Allerdings ist das für mich in meinem Fall nicht ganz plausibel.
Ich habe schon gesehen, dass der Kontakt den Status nochmals meldet. Allerdings meldet er immer den state: "closed".
Mein notify lautet aber:

FK1_Esszimmer:open {Alarm_sofort()}

sollte also bei geöfnetem Kontakt getrigegrt werden.
Leider geschieht das aber auch im Zustand: closed
Ich werde deinen Vorschlag aber auf jeden Fall  testen.

Gruß

Kurt

Leider konnte ich den Fehler noch nicht beheben, aber etwas einkreisen.
Ein Fehlalarm (trigger des notify, ohne Betätigung eines Kontaktes) passiert in 2 Fällen.

1.
Ändern des Attributes actCycle
Siehe dazu Logfile 1 im Anhang

2.
Eingang eines unbekannten BiCods Paketes
Siehe dazu Logfile 2 im Anhang


Ich habe die beiden Ereignisse in der Logfile mit Verbose 5  eingefangen. Siehe Anhänge
Hat jemand dazu eine gute Erklärung?

Grüße

Kurt

Setze bei dir event-on-change und es werden nur Events bei Änderung des entsprechenden Readings erzeugt.

Hallo Freunde,

ich habe nun einige Tage mit der Fehlersuche verbracht.
Da ich jede Menge Meldungen "Unknown Code ...:" bekommen habe, müsste ich diese erst mal mit

Define Nachbar 1(2) CUL_HM 1CE71B
attr Nachbar1(2) ignore 1


eliminieren.
Mein Fehler war damit immer noch nicht behoben. Ich habe immer noch "Fehlalarme", die in der Logfile (Verbose 5) wie folgt aussehen.

2016.02.18 16:58:36 4: CUL_Parse: CUL_0 A 0E E4 8202 1D6174 1CE71B 0101180038D5 -95.5
2016.02.18 16:58:36 5: CUL_0 dispatch A0EE482021D61741CE71B0101180038::-95.5:CUL_0
2016.02.18 17:00:27 5: Triggering FK1_Esszimmer (1 changes)
2016.02.18 17:00:27 5: Notify loop for FK1_Esszimmer Activity: dead
2016.02.18 17:00:27 4: Device FK1_Esszimmer is dead
2016.02.18 17:00:27 5: Triggering ActionDetector (2 changes)
2016.02.18 17:00:27 5: Notify loop for ActionDetector alive:7 dead:1 unkn:0 off:0
2016.02.18 17:00:27 5: Triggering FK1_HR
2016.02.18 17:00:27 4: FK1_HR exec {Alarm_sofort()}
2016.02.18 17:00:27 5: Cmd: >{Alarm_sofort()}<
!!! hallo Fehlalarm !!!  2016.02.18 17:00:27 5: Triggering FK1_HR
2016.02.18 17:00:27 4: FK1_HR exec {Alarm_sofort()}
2016.02.18 17:00:27 5: Cmd: >{Alarm_sofort()}<
!!! hallo Fehlalarm !!!  2016.02.18 17:00:32 5: CUL/RAW: /A0CE586701CE71B00000000C835C4

Der Fehler hat offensichtlich irgend etwas mit dem Statuswechsel (dead/alive) meiner Kontakte zu tun.
Als nächstes werde ich mal versuchen "event-on-change-reading" auf 1 zu setzen.
Allerdings würde mich interessieren, warum ein klar definiertes Notify getriggert wird, obwohl der Kontakt nicht geöffnet wird.
Auslöser ist die Zeile:      Triggering HK1_HR
Wenn mir hier jemand helfen könnte, wäre ich sehr dankbar.

Grüsse

Kurt

Hast du in das Notify mal den Code, den ich dir geschickt habe reingeschrieben?

Also die Zeile:

Log 1, "Event: $EVENT Device: $NAME";

Würde die Fehlersuche evtl. etwas erleichtern!

Zitat von: kurtklaiber am 18 Februar 2016, 17:30:23

Als nächstes werde ich mal versuchen "event-on-change-reading" auf 1 zu setzen.

Das ist keine gute Idee. Bitte die Doku lesen.

BTW: Warum enthalten deine Themen immer Umfragen?

Zitat von: kurtklaiber am 18 Februar 2016, 17:30:23
Allerdings würde mich interessieren, warum ein klar definiertes Notify getriggert wird, obwohl der Kontakt nicht geöffnet wird.
Auslöser ist die Zeile:      Triggering HK1_HR
Wenn mir hier jemand helfen könnte, wäre ich sehr dankbar.

Wenn event-on-change-reading nicht entsprechend gesetzt, löst jedes setzen eines Readings ein Event aus. Egal ob sich dabei der Wert ändert oder nicht.

stromer on tour

Hallo Forum,

ich habe nun sehr viel Zeit mit experimentieren verbracht. Leider gelingt es mir immer noch nicht so richtig eine systematische Fehlersuche zu betreiben.
Folgendes habe ich herausgefunden:

1.
Ein Großteil der "UNKNOWNCOMMANDS" stammen tatsächlich von meinem Nachbarn. Man kann sie unterdrücken, indem man aus dem BiCod die HMID des Senders herausfindet und dann folgenden Code eingint:

Define Nachbar1 CUL_HM HMID
attr Nachbar1 ignore 1


2.
Meine Fehlalarme werden vermutlich durch den "Actiondetector" ausgelöst. (Obwohl ich klar definiert habe, dass das notify nur getriggert werden soll, wenn ein Kontakt geöffnet) wird.
Dies versuche ich nun wie folgt zu verhindern:

if (($alarmflag eq "1") and ($obj ne "ActionDetector")) {
{fhem ("set S_Alarm  on")};# Alarmsirene ein
print "Alarm ok ";

"$obj" enthält zu diesem Zeitpunkt den $NAME des auslösenden Aktors.
Ich bin nun sehr gespannt ob das hilft. Ich werde in einiger Zeit, wenn ich sicher sein kann noch darüber berichten.
Vielen Dank noch für die Unterstützung, das hat mir sehr geholfen.

Gruß

Kurt

Nach einigen Tagen Test kann ich feststellen, dass die Maßnahmen wirken. In der LOG kann ich sehen, dass die notify immer noch getriggert werde, aber durch die Bedingungen ein Alarm verhindert werden.
Deshalb kann ich dieses Kapitel schließen.
Dank an allle die geholfen haben.


Gruß

Kurt