HM-LC-SW2-FM: level C8 instead of 00

[DC]

Hallo zusammen,

Nach ein paar FHEM Updates spinnt jetzt ein Lichtschalter (HM-LC-SW2-FM):

- Der Schaltvorgang von gepeerten Sensoren funktioniert.
- Der Schaltvorgang via FHEM / HMLAN funktioniert nicht - State: MISSING ACK
- Das Status-Icon hat ein "?"

Schalte ich über einen gepeerten Sensor, werden die Befehle aus der Pipeline abgearbeitet (an - aus - an -aus -> Dico-Feeling   )

Im Log steht :
2016.06.25 19:00:01 3: CUL_HM /Gerätename/ repeat, level C8 instead of 00

Was habe ich übersehen ? Es hat bis vor ca. 6 Wochen funktioniert und außer FHEM-Updates gab es keine Veränderungen.

Danke im Voraus,
DC

[martinp876]

Bin die naechsten wochen nicht am geraet
Kannst du ein log schicken?
Hintergrund ist, dass der aktor msnchmal nicht korrekt schaltet und fhem ggf. Das kommando wiederholt. Eigentlich schon lange eingebaut und problemlos. Schauen wir einmal.

[DC]

Lösung: HMLAN neu starten.

[Pfriemler]

Das hat aber gedauert. Donnerwetter ...

[Pfriemler]

Ich holfe das Ding mal frisch hoch.

Hintergrund ist, dass der aktor msnchmal nicht korrekt schaltet und fhem ggf. Das kommando wiederholt. Eigentlich schon lange eingebaut und problemlos. Schauen wir einmal.

Schon lange stelle ich mir die Frage, wie lange genau FHEM das Kommando zwischenspeichert.

Ich habe bei einem HM-LC-Sw2-FM (ist eher zufällig das gleiche Gerät, aber dennoch), der schon offline in meiner Grabbelkiste lag, irgendwann mal vor Wochen in FHEM-WEB einen Einschaltvorgang ausgelöst --> (set_on) im Status.
Seither gab es mindestens einen Neustart von FHEM, aber "set_on" dürfte ja im statefile überlebt haben.
Soeben habe ich - das alles längst vergessen - den Aktor aus der Grabbelkiste kurz eingestromt. Er schaltete sich anschließend ein (Kanal 1).
Als ich soeben "powerUpMode" checken wollte, stand es auf "off". Im LogFile

Code Auswählen Erweitern

2021.01.08 12:33:01 3: CUL_HM HM_42A296_Sw_01 repeat, level 00 instead of C8
Natürlich gibt es keinerlei mit dem Aktor verbundene Routinen, die jetzt "frisch" gefeuert haben.

Offensichtlich war CUL_HM mit der Rückmeldung des Aktors (level 00 = aus) nicht einverstanden und hat ein C8 (=ein) repeated.
Für mich sieht das so aus, als ob der einst ausgesendete Befehl erst jetzt verifziert und nachkorrigiert wurde.
Der Aktor war seit Wochen offline!

Das Verhalten lässt sich gerade beliebig reproduzieren. Der einmal erfolgreich eingeschalteter Aktor, der durch einen "Stromausfall" wieder aus ist, wird nicht reaktiviert. Der "offline" eingeschaltete Aktor geht nach dem Einstromen sofort wieder an. Das habe ich eben mal nach drei Minuten probiert, jetzt warte ich mal bis morgen ...

Liebe Leuts, DAS darf echt nicht sein. Was kann da schiefgelaufen sein?

[frank]

bin nicht sicher, aber gibt es nicht für levelMissed ggf ein reading?
das würde das lange überleben, auch nach restart, erklären.

die sicherste und einfachste methode für "vorübergehend inaktive" devices war, bis vor kurzem, nach meinen erfahrungen attr ignore=1.
ansonnsten musste man mindestens autoreadreg=0 und falls vorhanden actcycle=000:00 setzen, um regelmässige messages an das device zu verhindern.
nun werden leider diverse daten "vernichtet" wie peers/register, obwohl eigentlich ignored. also nach wiederinbetriebnahme erst wieder alles auslesen.

eventuell probiere ich mal attr dummy=1.

[Pfriemler]

levelMissed kenne ich nicht. Das Gerät will ich auch gar nicht ignorieren. Es gehört zu mir und ich will es irgendwann mal verwenden.
Ich finde es nur absolut seltsam, wenn Schaltbefehle an Geräte eine so lange Lebensdauer haben.
Ob das Sinn oder Unsinn ist, hatten wir zuletzt ja in der Diskussion um Ralphs Frage wie man den Zustand von Geräten nach einem (kurzen) Stromausfall wiederherstellen kann.

Die Idee, Befehle an ein Gerät für eine begrenzte Zeit zwischenzuspeichern und später nachzureichen, ist ja an sich sinnvoll, aber hier wird doch deutlich über das Ziel hinausgeschossen. Mich beängstigt es nachgerade, wenn (möglicherweise gewollt) offline gewesene Geräte plötzlich ein Eigenleben entwickeln.

Übrigens vernichtet nicht einmal ein "clear msgEvents" den Befehlscache. Nur ein zwischenzeitliches "set off" verhindert eine Aktion am Aktor.