HM-SEC-SC MissingAck

[Samsi]

Hallo,

ich habe es schon mal im HM-CC-RT-DN thread angesprochen, denke aber das es ja nichts mit dem Thermostat zu tun, auch wenn Stefan P. dort ein ähnliches Problem hat, deshalb der neue Thread.
Nach einem Update vom 26.10. habe ich lauter Missing Acks bei meinen Fensterkontakten (HM-SEC-SC ) bekommen .

Ich habe alle (mehr als 10) Kontakte mal genauer untersucht, bei allen stand  1CMD Pending. Wenn ich den Kontakt dann öffne ist das 1CMD Pendig weg und es steht Command Error:1  (oder so ähnlich) und außerdem Missing Ack.

Ich denke das 1CMD Pending kommt von dem neuen autoReadReg, denn ich habe selbst keine CMDs an die Kontakte gesendet.

Am nächsten Tag hatten die Kontakte dann wieder ein Command Pending, ich denke das kommt dann wieder von dem autoReadReg ?

[betateilchen]

das aufgezwungene autoReadReg_4... die Wurzel allen Übels. Aber mir glaubt ja keiner...

Stelle das autoReadReg bei den Sensoren auf 0 dann gibts auch keine Fehlermeldungen mehr. Das autoReadReg macht bei diesen Sensoren keinen Sinn.

[Samsi]

Hallo,

ja ich hab es heute morgen auf 0 gestellt, weil ich auch vermute das es irgendwie daran liegt. Mal sehen was passiert wenn ich heute abend zu hause bin.

Allerdings ist das Problem dann vermutlich eher das das regRead dann bei denen Sensoren vielleicht nicht richtig funktioniert. Kann es vielleicht sein das FHEM, bevor es dem Sensor das Ack sendet, versucht die CMDs abzusenden, die Sensoren aber gar nix empfangen wollen?

EDIT: Weil die Sensoren akzeptieren eigentlich keine Commands, nur wenn man die Anlerntaste drückt. Wäre schön wenn Sie es täten, dann könnte ich mir das sparen jedes mal auf den Stuhl zu klettern um die Dinger abmontieren wenn ich mal was ändern will.

[martinp876]

Hallo Samsi,

das autoReadReg stellt wohl die Abfrage in die Q. Da sollte aber sonst nichts weiter passieren, bis der SC sich meldet und das Kommando ab arbeitet. Der SC ist laut xml (und meiner lesart) in der lage nach dem aufwachen Kommandos zu verarbeiten.
Da ich keinen SC habe kann ich dies nicht testen.
Sollte der SC dazu nicht in der Lage sein ist das kein Problem von autoReadReg sondern von der Konfiguration des SC.

Der SC sollte neben dem "Config" auch "wakeup" können, wenn auch nur einmal täglich.
Falls du in der Lage bist einen roh-log des SC zu erstellen - und dessen register zu posten kann ich einmal nachsehen. Wenn nicht werde ich das wakeup aus der SC-Config streichen dann ist die Funktion eben doch nicht unterstützt.

Gruss Martin

[Samsi]

Hallo Martin,

seit dem cih das autoRegRead ausgeschaltet habe, gibt es bei mir auch keine MissingAcks mehr.

Der SC ist laut xml (und meiner lesart) in der lage nach dem aufwachen Kommandos zu verarbeiten.

Vielleicht nur wenn er von sich aus zyklisch aufwacht (Wakeup)? Oder vielleicht braucht er auch erst mal das Ack nachdem er gesendet hat, bevor er Kommandos entgegen nimmt.

Falls du in der Lage bist einen roh-log des SC zu erstellen - und dessen register zu posten kann ich einmal nachsehen.

Gibts da irgendwo eine Anleitung?

Grüße

[martinp876]

Hallo Samsi,

klar - so lange keine Kommandos gesendet werden gibt es keine missing acks. autoReadReg hat das Problem hier nur offen gelegt, gelöst werden muss es an der Wurzel.
Und ja ein Sendeversuch wird gemacht, wenn sich das Device entsprechend meldet, so wie es bei allen wakeup-devices ist. Wenn es hier nicht funktioniert ist entweder das Verfahren falsch oder die Beschreibung/interpretation. In beiden Fällen wird es aus FHEM entfernt. Nur wenn wir es zum klappern bekommen wird es eingebaut.
Das Device wird ansonsten auf "config" gesetzt.
Bei Config-devices ist autoReadReg nicht auto-gesetzt. Dennoch empfehle ich es auch - und gerade - hier. Grund ist, dass wenn einmal config gedrückt wird auch gleich die Register gelesen werden. Das gilt auch bei Änderungen im Device. Zum einen erspart es das nochmalige config - drücken(und den Weg zum device), zum anderen kommt so etwas in aller regel sehr entzerrt - jedenfalls nicht beim reboot (da drückt man nicht immer config).

Die Rohmessages kannst du aufzeichnen mit
attr global verbose 1
attr global mseclog 1
attr <hmlan> logleve 1

du kannst, sollte keine message  im stack stehen , ein statusRequest oder ein getConfig auslösen und warten - bis zu 24h

Gruss Martin