Geisterevents nach FHEM Crash / Restart (Welche leider unsere Tür aufschließen)

[Thyraz]

Hallo zusammen,

Bei mir löst nach FHEM Crash + zugehörigem automatischem Restart ein DOIF aus, welches auf einen Taster lauscht und die Eingangstür aufschließt.
Der Taster wird zu dem Zeitpunkt aber nicht gedrückt.

Glücklicherweise war ich Zuhause und hab es bemerkt.

Konstellation:
- Nuki Lock an der Tür
- Ikea Tradfri Shortcut Button über Conbee II und Huebridge Modul in Fhem
- DOIF, welches auf den Event des Shortcut Buttons lauscht und dann das Nuki Schloss öffnet.

Der Sinn des Ganzen ist, dass bei uns der Knopf am Nuki dekativiert ist, damit der Nachwuchs nicht abhauen kann (wegen dem gibt es immerhin das automatische Abschließen).
Der Shortcut Button überhalb der Reichweite unseres Kleinsten dient dann für uns zum "Komfort"-Öffnen.

In FHEMWeb hab ich dann nach dem Status vom DOIF geschaut und das stand tatsächlich nicht auf Initialized sondern auf cmd1 mit Zeitstempel 15:15 (Direkt nach dem Restart von FHEM).
Die Tür wurde also definitiv von FHEM geöffnet.

Danach dann in das FHEM-Device vom Tradfri Button geschaut und auf den Zeitstempel vom state Reading (welches das DOIF triggert) geschaut.
Hier ist der Zeitstempel noch ca. 2h vor dem Crash, als ich den Knopf wirklich gedrückt habe.
Der behauptet also kein Event ausgelöst zu haben.

Der Auslöser vom DOIF ist ja als Eventtrigger formatiert. Dass das state Reading beim Restart immer noch auf "1002" steht, erklärt also nicht warum das DOIF auslöst.

Kann da jemand Licht ins Dunkel bringen? 

Das DOIF ist jetzt jedenfalls erstmal deaktiviert...

[Damian]

Nach einem Crash werden ja nicht die zuletzt aktuellen Zustände angezeigt, sondern diejenigen, die mit save vor dem Crash gesichert wurden.
Ein Screenshot ist auch nicht besonders aussagefähig, sondern die Ausgabe von list des Devices.
Vielleicht findest du im Log irgendwelche Hinweise kurz vor dem Crash, sonst wird eine Analyse sehr schwierig.

[Thyraz]

Hi Damian,

ich kann das auf alle Fälle nachstellen.
Das passiert nach jedem Crash von Fhem wenn das letzte Event vom Tradfri Button ein Single-Press war (also state noch auf "1002" steht mit Zeitstempel vom letzten Betätigen).

Z.B. indem ich einen InternalTimer mit einer nicht existierenden Funktion als Callback starte und dann warten bis Fhem nach dem Absturz wieder neu gestartet ist. Dann feuert das DOIF sofort.
Ich bin mir aber eben nicht sicher ob es am DOIF selbst liegt, oder FHEM selbst denkt hier einen Event generieren zu müssen.

Was ich weiß:
- Ich starte deconz zu dem Zeitpunkt nicht neu (also die Software vom Conbee II Zigbee Stick).
Das läuft auf einer anderen Maschine als FHEM.

- Meine Automatisierungen mit anderen Zigbee Geräte als Auslöser entwickeln kein Eigenleben beim FHEM Neustart.

- Der Tradfri Taster wird in dem Zeitraum definitiv nicht gedrückt, da außer mir niemand Zuhause war als ich das vorhin ein paarmal getestet habe.

- Beende ich FHEM sauber und starte es neu tritt der Fehler nicht auf. Nur beim Start nach einem Crash.

Was wäre denn hilfreich um der Sache auf die Spur zu kommen oder zumindest DOIF selbst ausschließen zu können?
Ein List vom DOIF und dem Tradfri Button direkt nachdem es ausgelöst hat?

Danke dir.

[Damian]

Du schreibst:

Hier ist der Zeitstempel noch ca. 2h vor dem Crash, als ich den Knopf wirklich gedrückt habe.
Der behauptet also kein Event ausgelöst zu haben.

Der Auslöser vom DOIF ist ja als Eventtrigger formatiert. Dass das state Reading beim Restart immer noch auf "1002" steht, erklärt also nicht warum das DOIF auslöst.

Wenn Fhem unverhofft crasht, dann wird ja nichts mehr gespeichert seit dem letzten sauberen Beenden oder Absetzen von "save".

D.h. Du kannst aus den Readings nicht erkennen, was in den letzten Stunden passiert ist. Beim DOIF wird nach einem Neustart intern alles neu aufgesetzt - interne Inkonsistenzen, wegen eines Crashes, würde ich eher ausschließen. Es bleiben natürlich alle Readings im DOIF, die zuletzt noch gesichert wurden, das müssen, wie oben schon ausgeführt, nicht die letzten vor dem Crash sein.

Da musst du dir evtl. eine Hilfskonstruktion bauen, z. B. ein DOIF, welches auf das gleiche Event triggert und dieses Ereignis im Log protokolliert, diese Information überlebt ja einen Crash.

[Otto123]

was passiert wenn Du den Trigger schärfst? Bei Dir reagiert das DOIF wenn irgendwas mit 1002 kommt, so reagiert es nur bei 1002:
"^1002$"

Und schreib doch einfach einen Eintrag ins Log? Ergänzung im Ausführungsteil:

Code Auswählen Erweitern

{Log 1, "Das Device $DEVICE hat ausgeloest, der Event sah so aus: $EVENT"}

Gruß Otto