Pfuscht FHEM in Schaltbefehle von Peers?

[Pfriemler]

Seltsam. Eben gehe ich ins Bad, mache das Arbeitslicht an ... und stehe 10 Sekunden später im Dunkeln.

Im Log finde ich das:

Code Auswählen Erweitern

2018.12.11 22:48:49 3: CUL_HM KellerbadArbeitslicht repeat, level C8 instead of 00
2018.12.11 22:48:55 3: CUL_HM set KellerbadLueftung statusRequest
2018.12.11 22:48:57 3: CUL_HM KellerbadArbeitslicht repeat, level C8 instead of 00


Zur Situation:
- als Lichtschalter funktionert ein Bewegungsmelder mit Tasten
- Schaltaktor ist ein HM-LC-Sw4-DR, sowohl für Licht als auch für Lüftung
- ein langer Tastendruck schaltet die Lüftung ein
- beide Funtionen sind direkt gepeert und funktionieren ohne Dazwischenfunken von FHEM
- es gibt ein DOIF zur Beleuchtungssteuerung, aber das war Stunden zuvor letztmals aktiv (die Bewegung von mir wurde nicht erkannt)
- wegen temporärer Untersuchungen zur Stabilität von FHEM ist ein HM-Interface "dead"
- rssi_at_HMUART cnt:377 min:-88 max:-77 avg:-82.25 lst:-85
- Bewegungsmeldungen werden regelmäßig von FHEM ignoriert, d.h. kommen nicht an

Es hat für mich den Anschein, FHEM hätte hier einen long-Trigger statt eines short-Triggers gelesen. Weil der Lüfter nicht reagiert, fragt FHEM den Status des Aktors ab. Das KellerbadArbeitslicht hingegen meldet zweimal einen unerwarteten Einschaltlevel an FHEM, nämlich C8 (=200, eingeschaltet) - was ja auch der Wahrheit entspricht. Überhaupt liest FHEM den Sender aktuell schlecht, obwohl die RSSI gar nicht soooo grottig sind.

Nun die Frage: Kann FHEM hier einen Korrekturbefehl geschickt haben, d.h. dem KellerbadArbeitslicht einen Ausschaltbefehl, weil nach Lesart von FHEM der Aktor ja nicht eingeschaltet worden sein dürfte? Im Log ist natürlich nichts, außer das DOIF schaltet.

Ich habe das noch nie erlebt, das war Premiere.

[misux]

Hi! Lass doch mal das DOIF sehen... Die können nämlich schon eingreifen, je nach def.

[Pfriemler]

Das DOIF kann ich sicher ausschließen. Der letzte ausgeführte Pfad (cmd_nr?) wird ja mit Zeitstempel gespeichert, und der lag Stunden zurück. Außerdem hinterlassen seine Schaltbefehle stets Einträge im Log (zum Glück noch testweise aktiviert) - auch da nix.

edit: das spontane Ausschalten eines anderen Aktors hat damit nichts zu tun.

[martinp876]

Werde ich prüfen. Die Logik ist nach einem Setzen durch die Zentrale auf eine stausinfo zu warten. Sollte diese nicht dem level entsprechen wird noch einmal gesendet. Es wird nur einmal probiert.
Ein direkter trigger wird nicht geprüft.

Mögliches Szenario: du schaltest off und es klappt. Viel später ein trigger des bm. Das licht geht an und sendet statusinfo on. Fhem prüft noch auf das off ( nicht timer überwacht) und schaltet aus.
Ich glaube eingebaut zu haben, dass nach einem trigger eines Peers das handling abgeschaltet wird. Hm, muss ich prüfen.
Falls fhem diesen allerdings nicht sieht.....

[Pfriemler]

Mögliches Szenario: du schaltest off und es klappt. Viel später ein trigger des bm. Das licht geht an und sendet statusinfo on. Fhem prüft noch auf das off ( nicht timer überwacht) und schaltet aus.
Ich glaube eingebaut zu haben, dass nach einem trigger eines Peers das handling abgeschaltet wird. Hm, muss ich prüfen.
Falls fhem diesen allerdings nicht sieht.....

Zum Mitmeißeln für mich:
Was ich verstehen könnte wäre, dass ein von FHEM initiierter Ausschaltbefehl (hier DOIF noMotion-getriggert) "hängenbleibt" und später von FHEM nachgearbeitet wird, wenn der Aktor wieder "in Reichweite" ist. Glaube ich aber hier kaum, weil die Funktstrecke zu den Aktoren eigentlich - auch mit nur einem IO am Raspberry - nie ein Problem war. Aber man weiß es natürlich nicht. Wenn FHEM selbst hängengeblieben Schaltbefehle für einen Aktor killt, wenn es wie von Dir beschrieben Trigger eines Peers erkennt, wäre das natürlich optimal. Relativ sicher dürfte sein, dass zum Zeitpunkt des Fehlers (als nur ein IO in Betrieb war) diese Trigger regelmäßig nicht in FHEM ankamen, u.a. weil das motion-auswertende DOIF nur in gefühlt 10% der Fälle funktionierte.

In diesem Fall wäre also strenggenommen das eigentliche Problem, dass Befehle für das Gerät in FHEM hängengeblieben sind und FHEM die Trigger des peers nicht gesehen hat, stattdessen beim Melden des Aktors die Befehle nachgereicht hat, ohne dass dies nochmals irgendwo geloggt wurde und ich deswegen nichts fand.

Wäre eine Erklärung und in diesem Fall eine vertretbare Verkettung unglücklicher Umstände. Allerdings frage ich mich: wie lange bleiben denn solche Befehle überhaupt hängen? Hier müssen es Stunden gewesen sein. Für die Übermittlung von Befehlen an nicht burstfähige und nur sporadisch aufwachende Geräte wie den RT-DN oder auch lazyconfig-urierte Sensoren könnte ich maximal 10 Minuten verstehen, aber alles was älter ist, müsste doch irgendwann eine sinnvolle time-to-live überschritten haben. Gibt es da derzeit ein Timeout und wo ist es?

[martinp876]

Also - bekannt ist, dass FHEM (die Zentrale) korrekte Level an Dimmer, Rollo-Aktoren aber auch schalter gesendet hat, diese es bestätigen und dann aber nicht den Korrekten Level anfahren.
=> hat alles nichts mit RSSI, reichweite oder sonstigem zu tun.
Wenn du jetzt mitmeißeln willst:
Sendet FHEM ein "set level" (also auch ein 'on') an einen aktor wird dieser "notiert". Wird eine andere Aktion erkannt, welche den Befehl überschreiten KÖNNTE wird die Notitz verworfen.
Nur wenn der Aktor sagt "fertig - neuer Level xx" und FHEM hatte sich level yy notiert wird das kommando EINMALIG wiederholt. (die Aktoren melden gerne auch "bin unterwegs, aktueller level xx". darauf wird nicht reagiert)
Dieser Mechanismuss ist notwendig da es schon hinreichend fehlfunktionen gegeben hat. Lässt sich nicht anders lösen.
Um auch mit Dimmern und Rollos zurecht zu kommen wird zyklisch der Status abgefragt. Der Rollo kann minutenlang fahren.

In jeden Fall ist es nicht die Idee, Minuten oder Stunden nach dem Kommando den Level noch einmal zu setzen, wenn das Device wieder auftaucht. Das ist gefährlich. So lange der Rollo fährt sehe ich das anders.

Du könntest bei deinem Licht einmal nach Schalten den Eintrag "helper->dlvl" suchen. Wenn der vorhanden ist, wartet FHEM auf einen Status.

Zusammenfassend: Wenn FHEM ein set level schickt (also on oder off) und kein Status hierzu bekommt wird das Merken nicht gelöscht.

Wenn das dlvl nach dem Abschalten nicht verschwindet bitte einmal das Abschalten sniffen.

[Pfriemler]

Wir reden hier derzeit doch ausschließlich über korrigierende Eingriffe von FHEM, wenn von FHEM aus gesendete Befehle offenbar nicht ordnungsgemäß ausgeführt wurden? Denn der eigentlich Aufhänger war ja ein spontanes und unerwartetes (Zurück-)Schalten eines gepeerten Aktors nach einer gewünschten Peer-Aktion, ohne dass es einen erkennbaren Einfluss von FHEM gegeben hat.

...
Nur wenn der Aktor sagt "fertig - neuer Level xx" und FHEM hatte sich level yy notiert wird das kommando EINMALIG wiederholt.

Das macht für mich völlig Sinn. Diese Korrekturen bleiben aber auch nicht im Cache und werden nachgeholt? Oder bleiben sie so lange aufgehoben, bis der Aktor ein ACK sendet?
Ich hätte noch gemutmaßt, dass andere hängengebliebene Befehle an den Aktor (etwa ein getConfig o.ä.) die Aussendung dieser Korrektur verhindern - aber das ist ja auch Quatsch, denn dann wäre der erste Stellbefehl vermutlich auch nicht herausgegangen.

In jeden Fall ist es nicht die Idee, Minuten oder Stunden nach dem Kommando den Level noch einmal zu setzen, wenn das Device wieder auftaucht. Das ist gefährlich.

Ganz mein Reden. Die Frage ist dennoch: Wann sind die Schaltbefehle verloren? Unmittelbar nach der Aussendung, wenn kein ACK in der gewünschten Zeit kommt? (=NACK)

Du könntest bei deinem Licht einmal nach Schalten den Eintrag "helper->dlvl" suchen. Wenn der vorhanden ist, wartet FHEM auf einen Status.

ich finde in "helper" nur "dlvlCmd    ++A0111411AB3E46A10202C80000" - nach einem Einschaltbefehl aus FHEM. Der state steht aber nicht mehr auf "set_on", also muss es eine Rückmeldung gegeben haben. Ist bei anderen regulär schaltenden Dimmern/Aktoren auch so, also vermute ich dass das normal ist.

Zusammenfassend: Wenn FHEM ein set level schickt (also on oder off) und kein Status hierzu bekommt wird das Merken nicht gelöscht.

Hm. Also doch. Anders gesagt konstriert:
1. FHEM schickt um 18 Uhr einen Ausschaltbefehl. Es kommt keine Rückmeldung bei FHEM an =  FHEM weiß nicht, ob der Aktor reagiert hat.
2. Um 22:38 schalte ich das Licht manuell ein.
3. FHEM sieht das Telegramm des Tasters nicht (schlechter Empfang)
4. Der Dimmer meldet einen Einschaltlevel.
5. FHEM erkennt die Rückmeldung des Dimmers (C8), erwartet aber von 18 Uhr noch 00 - und schickt den Ausschaltbefehl von 18 Uhr erneut. Ich stehe im Dunkeln.
Denkbar?

zu 1. Wenn es keine Rückmeldung vom Aktor über den Schaltbefehl gibt, bleibt doch üblicherweise ein "set_..." im Status, oder?