HM-WDS30-OT2-SM Missing Ack seit gestr. Update

Begonnen von franky08, 06 Oktober 2013, 09:10:03

Vorheriges Thema - Nächstes Thema

martinp876

Hallo Frank,

nach spec hat der mdir register und sollte auf wakeup reagieren. Wakeup sollte so alle paar minuten stattfinden.
Dennoch scheint es nicht zu funktionieren.

kannt du einmal rohmessages aufzeichnen, dann ein getConfig auslösen und warten - so nach keiner 10 min sollte der Fehler auftreten...
dann die Logs schicken...

Andere Frage: hast du schon getestet ob der mdir kommandos automatisch abholt - ohne config zu drücken?

Gruss Martin

franky08

Hallo Martin, der mdir hat auf jedenfall Register, ich hab nach einem getConfig motion Intervall z.B. runtergesetzt, da der Sensor sonst zu träge für die Steuerung war.
Ich weiß nicht genau was du mit Rohmessages meinst.
Ob Kommandos automatisch abgeholt werden, habe ich noch nicht getestet.

Ich nehme verbose jetzt auf 5 und mache ein getConfig.

Im Log ist nichts, hab jetzt 3x drübergeschaut.

DEF   
1A4F71
IODev
HMLAN1
NAME
IR_Sensor
NR
156
STATE
RESPONSE TIMEOUT:RegisterRead
TYPE
CUL_HM
autoRead
scheduled
Readings
Activity
unknown
2013-10-10 20:32:39
battery
ok
2013-10-10 20:31:43
brightness
33
2013-10-10 20:31:43
cover
closed
2013-10-10 20:31:43
motion
on (to broadcast)
2013-10-10 19:56:49
motionCount
116_next:4-15
2013-10-10 19:56:49
state
RESPONSE TIMEOUT:RegisterRead
2013-10-10 20:27:44
 IR_Sensor Attributes
actCycle
000:10
deleteattr
actStatus
unknown
deleteattr
autoReadReg
4_reqStatus
deleteattr
expert
2_full
deleteattr
firmware
1.0
deleteattr
model
HM-SEC-MDIR
deleteattr
peerIDs
deleteattr
room
Bad
deleteattr
serialNr
JEQ0155556
deleteattr
subType
motionDetector
deleteattr
Probably associated with
Bewegung_Bad
notify   
Daemmerung
notify   
FileLog_IR_Sensor
FileLog   

Nach einigen Minuten dann:

DEF   
1A4F71
IODev
HMLAN1
NAME
IR_Sensor
NR
156
STATE
RESPONSE TIMEOUT:RegisterRead
TYPE
CUL_HM
autoRead
scheduled
protCmdPend
3 CMDs_pending
protState
CMDs_pending
Readings
Activity
alive
2013-10-10 20:37:39
battery
ok
2013-10-10 20:37:26
brightness
33
2013-10-10 20:39:27
cover
closed
2013-10-10 20:37:26
motion
on (to broadcast)
2013-10-10 20:39:27
motionCount
117_next:4-15
2013-10-10 20:39:27
state
RESPONSE TIMEOUT:RegisterRead
2013-10-10 20:27:44
 IR_Sensor Attributes
actCycle
000:10
deleteattr
actStatus
unknown

deleteattr
autoReadReg
4_reqStatus
deleteattr
expert
2_full
deleteattr
firmware
1.0
deleteattr
model
HM-SEC-MDIR
deleteattr
peerIDs
deleteattr
room
Bad
deleteattr
serialNr
JEQ0155556
deleteattr
subType
motionDetector
deleteattr
Probably associated with
Bewegung_Bad
notify   
Daemmerung
notify   
FileLog_IR_Sensor
FileLog   

z.Zt. kann ich auch nicht viel testen, da der MDIR, nachdem er motion erkannt hat OK ist und das Bad jetzt ziemlich frequentiert ist und dauernd motion ausgelöst wird.
VG Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

martinp876

hi Frank,

die rohmessages gehen am "reinsten" mit
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1

Die ergebnisse stehen dann im allgemeinen logfile.

auch wenn motion kommt sollte die zyklische message gesendet werden.... hoffe ich.

evtl kannst du in einer ruhigen minute einmal einige Zeit aufeichnen
wäre gut, das kommando abzusetzen (noch einmal) und einige Zeit zu warten - min 10 minuten - wenn du Zeit hast auch über Nacht.
Gerne auch einmal eine "motion" zwischenrein...

FHEM hat jedenfalls einmal zu senden begonnen - der start-trigger kam also

Gruss Martin

martinp876

Hi Frank,

probiere es einmal mit Version 4030. Das gefällt auch dem VD besser. Vielleicht ist dies das Problem.

Gruss Martin

franky08

Zitat von: martinp876 schrieb am Do, 10 Oktober 2013 23:26Hi Frank,

probiere es einmal mit Version 4030. Das gefällt auch dem VD besser. Vielleicht ist dies das Problem.

Gruss Martin
OK, habe jetzt noch die 4028, denke die 4030 ist im heutigen update? Heute nach der Arbeit.

Gruss Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

martinp876


franky08

hallo Martin

Habe gerade, über VPN, mal das heutige Update eingespielt. Aber wie es aussieht bringt der MDIR nach einem Neustart von fhem immer noch RESPONSE TIMEOUT:RegisterRead.
Bis Motion erkannt wurde, dann ist alles OK.
Schicke dir heute Nachmittag mal die Rohmessages.

VG Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

martinp876

Hi Frank,

hast du auch HMLAN mitgenommen? Wichtig.

Ansonsten - kann ich logs bekommen? HMLAN traces

attr global mseclog 1
attr globalverbose 1
attr <hmlan> loglevel 1


Gruss Martin

franky08

ja, HMLAN und CUL_HM. Wenn ich auf CUL_HM 3993 zurück gehe, ist der Fehler auch weg. log im Anhang:

VG Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

franky08

Und Hier noch das Log über 10 min, dann MDIR ausgelöst.
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

martinp876

Hallo Frank,

da sind mehrere Dinge unklar - ich werden mehrere Schritte brauchen.

zum ersten kommt ein Ack, was  glaube ich - unötig ist.
kannst du einmal das File im Anhang einbauen und noch einmal aufzeichnen?
Der Fehler kommt wahrscheinlich immer noch... oder das Kommando bleibt hängen - aber egal. Das log hätte ich gerne für Schritt 1

du kannst das File einfach reinkopieren und
reload 10_CUL_HM
eingeben danach ein
set <mdir> getConfig
und warten...

Gruss Martin

franky08

Hallo Martin, im Anhang das neue Logfile, mit der 10_CUL_HM aus deinem Anhang. Die Meldung RESPONSE TIMEOUT:RegisterRead scheint nicht mehr zu kommen. Während des loggens wurde der MDIR ausgelöst (Frau im Bad :-)
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

martinp876

Hallo Frank,

Teil 1 sieht gut aus - der eingebaute ACK (historisch) war falsch.

Zum aktuellen Verhalten:
der MDIR sendet seinen Status alle 6 min  - ich gehe davon aus, dass dieser Abstand regelmässig ist.

Es werden trigger an broadcast gesendet. Meine Frage:
- Der channel ist nicht gepeert?
- eine Reaktion auf die Trigger ist nicht zu sehen


so nun zum getConfig
- falls du vorher einen abgesetzt hast ist dieser sicher noch in der Queue - korrekt?
- der nächste Schritt ist, zu testen ob der MDIR 'ansprechbar' ist, wenn er des Status sendet. daher hier die nächste Version, die dies testet. Bitte beide Dateien laden.

Du musst 2 varianten testen: den trigger und die regelmässige status-Nachricht.
- getConfig senden
-> ins Bad gehen
(sicherheitshalber 2 mal machen - nicht dass der status-report überholt hat...)

und einmal getConfig und 10min warten

bin gespannt.
Gruss Martin




franky08

Hallo Martin,

der channel ist NICHT gepeert nur pairing mit HMLAN. Reaktion auf die Trigger kommt erst wenn der Sensor "dunkel" liefert, so wie jetzt im Log.
Der MDIR scheint anprechbar zu sein, wenn er Status sendet. Anbei Log 1.Teil, server shutdown, getConfig und dann Motion ausgelöst.
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

franky08

Hier der 2. Teil, getConfig und 10min gewartet. Jetzt ständig missing Ack. Der OT2 bringt jetzt auch wieder missing Ack.

Nach motion erkannt ist die missing Ack Message beim MDIR weg. Nach shutdown restart missing Ack beim OT2 auch weg.
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1