Fehlender Batteriestatus in Readings

[martinp876]

Hi,

das log ist nicht sehr lang.
Eine Ack-Info und eine status meldung kann man bei diesem aktor nicht unterscheiden(anhand der Events). Eine AckStatus kommt aber nach einer trigger-message... also sehe ich 2 status-messages die 'cyclic' gekommen sein sollten:

07ter 17:37:43
08ter 17:47:12

Gruss
Martin

[snoop]

Hallo Martin,

seltsam/interessant:

07ter 17:37:43

Der letzte cover: closed war am 2013-01-06_10:20:04 = viel länger als 24h.
Zwischendurch wurde mal die Tuer geöffnet (Das ist das interessante!).

08ter 17:47:12

Der letzte "contact: closed" war am 2013-01-07_17:56:04,
dann einige "Activity:unknown"s
Interessant hier ist aber (meine ich) das Zeitgleich das cover zugemacht wurde - kann sein, dass hier die Reihenfolge der Aktionen nicht stimmt (da zeitgleich)?

Eigentlich wäre (nach bisherigen Erkenntnissen - cover auf/zu triggert Bat-Status):
cover zu
batterie ok
contact closed
usw.

Ich teste(wollte noch :o( - bin noch nicht dazu gekommen) das Verhalten derzeit zu Hause auch - mal schauen.

Viele Grüße
Arthur

[martinp876]

Hi Artur,

vor dem 1.7. war das device nicht gepairt. Da kommen evtl keine cyclic messages...

Aktivity unknown  kommt eigentlich bei neustart von FHEM. Dass es so oft kommt... hm  ... ist event-on-change eingestellt? Wieviele neustarts hat es gegeben?

So gesehen lasse ich Activity einmal aussen vor, da es vom ActinDetector getrieben ist.
Es gibt 2 events: den trigger und die infos(status und ack)
Bei trigger kommt kein batterie und kein cover

Die Meldungen 'cover' am 6. kommen immer nach einem trigger.
Die Meldungen am 7. 17:37 kommt quasi direkt nach dem Batteriewechsel (denke ich... cover noch offen).

Anzumekren ist, dass vor dem 6. 10:20 mit jedem trigger auch eine info gekommen ist.
Was hat sich also hier getan?
Moegliche Parameter sind:
cyclic info message eingeschaltet?
mit der Zentrale gepairt?

denkbar: wenn cyclic info message dann keine info-message mehr bei triggern.

Gruss
Martin

[Rohan]

... Aktivity unknown  kommt eigentlich bei neustart von FHEM. Dass es so oft kommt... hm  ... ist event-on-change eingestellt? Wieviele neustarts hat es gegeben?

Ich werde heute Abend nochmals nach den Logs vorher schauen. Logs danach sind kein Problem, die hatte ich nur abgeschnitten, weil ich nicht wusste, dass die auch von Interesse sein können. Zahl der Neustarts kann ich im fhem.log nachschauen. Zum "event-on-change": keine Ahnung, ich habe zumindest nichts derartiges bewusst eingestellt gehabt.

Was ich noch weiß ist, dass ich am 6.1. ziemlich oft den Anlernknopf gedrückt habe, weil ich (HM-Sec-SC war ja erst ein paar Wochen in Betrieb gewesen) die Batterien erst zuletzt als Grund für die Störungen in Erwägung gezogen habe (seitdem messe ich auch alle mitgelieferten Batterien erst einmal nach).

Nachdem ich neue LR44 eingepflanzt habe (am 7.1.), habe ich den Sec-SC mit dem HM-CC-TC gepairt, hat aber iirc auch einige Versuche gebraucht (incl. Reset auf Werkseinstellung des HM-CC-TC).

Was hat sich also hier getan?
Moegliche Parameter sind:
cyclic info message eingeschaltet?

"Damals" wusste ich noch gar nichts von "cyclic info message".

mit der Zentrale gepairt?

hmmm... mal in den Notizen / Logs nachsehen.

Gruß
Thomas

P.S. beim nächsten Mal werde ich etwas methodischer vorgehen.

[snoop]

Hallo Thomas,

"Damals" wusste ich noch gar nichts von "cyclic info message".

Interesant wäre noch folgendes: Ist bei deinen (dem o.g. SC) die option "cyclic info message" on (default ist off - man muss es also aktiv ändern)?
Danke.

@Martin:
Wäre es denkbar, dass cyclic info message eingeschaltet wird wenn ich es mit dem TC pairt?

Viele Grüße
Arthur

[martinp876]

Hi Arthur,

nach XML ist cyclicInfo default off.
Kannst du aber nachsehen wenn du ein getConfig machst.
R_cyclicInfoMsg steht auch immer sichtbar in den Readings.

Wäre es denkbar, dass cyclic info message eingeschaltet wird wenn ich es mit dem TC pairt?

wie meinst du das?
- FHEM soll CyclicInfo einschalten wenn man mit TC peert-> ist nicht so/wird nicht so
- HM schaltet cyclic info ein wenn SC gepeert wird-> kann ich mir nicht vorstellen, warum auch. Macht keinen Sinn.

Ich empfehle hier einen autoRegRead 3 einzustellen. Dann werden die Daten aktuell gehalten. Tests mit wakeup siehe unten!

Cyclic info message heisst, dass Zyklisch eine Message kommt. Es heisst nicht, dass dies die einzige info message ist!

Welche Punkte sind eigentlich offen:
- cyclic info message erzeugt eine info message alle 88200sec oder 24,5h. Dies ist unabhaengig von Schalter-aktionen.
- cyclic-info message kommt, ob gepairt ist (Zentrale) oder nicht (alle 24h) richtig/falsch
- wann kommt eine ACK_Info.
  a) wenn device       gepairt, nicht gepeert, kontakt betaetigt
  b) wenn device       gepairt,       gepeert, kontakt betaetigt
  c) wenn device nicht gepairt, nicht gepeert, kontakt betaetigt
  d) wenn device nicht gepairt,       gepeert, kontakt betaetigt

- der SC ist ein wakeup-device. Man kann also Nachrichten schicken, wenn es aufwacht. Das haben wir ncicht im Griff und bedarf voraussichtlich einiger testreihen. Hier ein paar tests - wer will:
+ messages im rohformat loggen
+ nachricht absetzen, z.B. statusRequest
+ anlernen druecken -> nachricht sollte verarbeitet werden (sanity-test)
+ nachricht absetzen, z.B. statusRequest
+ Kontakt betaetigen => wird der commandStack  gesendet?
Logs schicken.

[snoop]

Hallo Martin,

wie meinst du das?
- FHEM soll CyclicInfo einschalten wenn man mit TC peert-> ist nicht so/wird nicht so
- HM schaltet cyclic info ein wenn SC gepeert wird-> kann ich mir nicht vorstellen, warum auch. Macht keinen Sinn.

zu P.1) Nein, das meine ich nicht
zu P.2) Ja das meinte ich, im nachhinein aber auch eher unsinn, da der TC ja nichts mit der Info(s) anfangen kann!?!

Viele Grüße
Arthur

P.S:Tests folgen, leider (vermutlich) nicht vor WE.

[snoop]

 Hallo Martin,

Test 1:
####################

- der SC ist ein wakeup-device. Man kann also Nachrichten schicken, wenn es aufwacht. Das haben wir ncicht im Griff und bedarf voraussichtlich einiger testreihen. Hier ein paar tests - wer will:
+ messages im rohformat loggen
+ nachricht absetzen, z.B. statusRequest
+ Kontakt betaetigen => wird der commandStack gesendet?

Rahmenparameter:
- SC gepairt mit HMLAN
- CyclicInfo = on

SC Log:
2013-03-19_17:39:36 WZ_TerassenSensor Activity:: alive
2013-03-19_17:51:49 WZ_TerassenSensor auf
2013-03-19_17:51:49 WZ_TerassenSensor contact: auf (to HMLANAMA)
2013-03-19_17:52:15 WZ_TerassenSensor zu
2013-03-19_17:52:15 WZ_TerassenSensor contact: zu (to HMLANAMA)

Sonst siehe HMLAN Log.

Antwort: NEIN

Viele Grüße
Arthur

P.S:Reicht das? Habe das gefühl es fehlt was!

Edit: Ach, ja Status in FHEM: protCmdPend = 1 CMDs_pending | protState = CMDs_pending
So darf jetzt babysitten. ;o)

[martinp876]

Hi Arthur

was war um 2013-03-19_17:39:36 WZ_TerassenSensor Activity:: alive
?

da kam irgend eine andere message.
der statusrequest haengt also noch in der Queue -logisch.
Wir koennen versuchen uns an den wakeup zu haengen oder an den trigger.
Ich werden eine test-version bauen, mal sehen ob wir es schaffen. Dauert noch etwas

Gruss
Martin

[snoop]

Hallo Martin,

vorher hat der SC geschlafen und das mehr als 24 Stunden.
Kurz vor 2013-03-19_17:39:36 habe ich log File angelegt mit

Code: [Auswählen]


define FileLog_WZ_TerassenSensor FileLog ./log/WZ_TerassenSensor-%Y.log WZ_TerassenSensor
attr FileLog_WZ_TerassenSensor logtype text
attr FileLog_WZ_TerassenSensor room Server

und Fhem neugestartet.

"2013-03-19_17:39:36 WZ_TerassenSensor Activity:: alive" hat wohl der ActionDetector angelegt - kann das sein?

Viele Grüße
Arthur

[snoop]

Hallo Martin,

anbei der Beweis ;o)

Gruß
Arthur

Edit:

vorher hat der SC geschlafen und das mehr als 24 Stunden.

Gut gelogen.... aber aus meiner Sicht nicht relevant und daher zu vernachlässigen.

[Rohan]

Hallo Arthur,

so... sorry, aber mit weiteren Logs kann ich nicht mehr dienen. Und ja, am 6./7.1.13 waren einige FHEM-Restarts, weil ich neue Geräte in Betrieb genommen habe.

... Interesant wäre noch folgendes: Ist bei deinen (dem o.g. SC) die option "cyclic info message" on (default ist off - man muss es also aktiv ändern)?

Nein:

'list EG.WZ.Tuerkontakt'

Code: [Auswählen]

Internals:
   DEF        1CFBB0
   IODev      HMLAN1
   NAME       EG.WZ.Tuerkontakt
   NR         119
   STATE      closed
   TYPE       CUL_HM
   Readings:
     2013-03-19 19:47:35   Activity:       alive
     2013-03-19 08:57:38   alive           yes
     2013-03-19 08:57:38   battery         ok
     2013-03-19 14:49:31   contact         closed (to EG.WZ.Heizung)
     2013-03-19 08:57:38   cover           closed
     2013-03-19 14:49:31   state           closed
   Helper:
     mId        002F
     rxType     12
Attributes:
   actCycle   028:00
   actStatus  alive
   expert     2_full
   firmware   2.0
   fp_GrundrissEG 465,1077,1,Terrassentüre
   model      HM-SEC-SC
   peerIDs
   room       EG.WohnZ
   serialNr   JEQ0248383
   subType    threeStateSensor

 
nach set ... getConfig und Anlernknopf kurz drücken erneut

'list EG.WZ.Tuerkontakt'

Code: [Auswählen]

Internals:
   DEF        1CFBB0
   EVENTS     3
   HMLAN1_MSGCNT 3
   HMLAN1_RAWMSG E1CFBB0,0000,7C6EB0B2,FF,FFC1,B184001CFBB000000020002F4A45513032343833383380810101
   HMLAN1_RSSI -63
   HMLAN1_TIME 2013-03-19 20:37:33
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     3
   NAME       EG.WZ.Tuerkontakt
   NR         119
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:B1 - t:00 s:1CFBB0 d:000000 20002F4A45513032343833383380810101
   protCmdDel 3
   protLastRcv 2013-03-19 20:37:33
   protResnd  2 last_at:2013-03-19 20:37:33
   protResndFail 1 last_at:2013-03-19 20:37:36
   protState  CMDs_done_events:3
   rssi_at_HMLAN1 avg:-67.33 min:-77 max:-62 lst:-63 cnt:3
   Readings:
     2013-03-19 20:37:33   Activity:       alive
     2013-03-19 20:37:23   alive           yes
     2013-03-19 20:37:23   battery         ok
     2013-03-19 20:37:24   contact         open (to EG.WZ.Heizung)
     2013-03-19 20:37:23   cover           open
     2013-03-19 20:37:36   state           MISSING ACK
   Helper:
     burstEvtCnt 3
     getCfgList all
     getCfgListNo 4
     mId        002F
     rxType     12
     Rssi:
       At_hmlan1:
         avg        -67.3333333333333
         cnt        3
         lst        -63
         max        -62
         min        -77
Attributes:
   actCycle   028:00
   actStatus  alive
   expert     2_full
   firmware   2.0
   fp_GrundrissEG 465,1077,1,Terrassentüre
   model      HM-SEC-SC
   peerIDs
   room       EG.WohnZ
   serialNr   JEQ0248383
   subType    threeStateSensor

Nun ein:

'set EG.WZ.Tuerkontakt regSet cyclicInfoMsg on' => 3 CMDs pending
'set EG.WZ.Tuerkontakt getConfig' => X CMDs pending

Anlernknopf kurz gedrückt, Browser refresh, alle CMDs abgearbeitet

ein 'list EG.WZ.Tuerkontakt' bringt:

Code: [Auswählen]

Internals:
   CHANGED
   DEF        1CFBB0
   EVENTS     11
   HMLAN1_MSGCNT 15
   HMLAN1_RAWMSG R842D4EED,0001,7C73E9F4,FF,FFC1,9FA0101CFBB0123ABC0201010000
   HMLAN1_RSSI -63
   HMLAN1_TIME 2013-03-19 20:43:14
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     15
   NAME       EG.WZ.Tuerkontakt
   NR         119
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:9F - t:10 s:1CFBB0 d:123ABC 0201010000
   protCmdDel 3
   protLastRcv 2013-03-19 20:43:14
   protResnd  2 last_at:2013-03-19 20:37:33
   protResndFail 1 last_at:2013-03-19 20:37:36
   protSnd    7 last_at:2013-03-19 20:43:14
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-58.66 min:-77 max:-50 lst:-63 cnt:15
   Readings:
     2013-03-19 20:43:11   Activity:       alive
     2013-03-19 20:43:12   CommandAccepted yes
     2013-03-19 20:43:13   PairedTo        0x0
     2013-03-19 20:43:14   R-EG.WZ.Heizung_WindowRec-expectAES off
     2013-03-19 20:43:14   R-EG.WZ.Heizung_WindowRec-peerNeedsBurst on
     2013-03-19 20:43:13   R-cyclicInfoMsg on
     2013-03-19 20:43:14   R-eventDlyTime  0 s
     2013-03-19 20:43:13   R-intKeyVisib   invisib
     2013-03-19 20:43:14   R-ledOnTime     0.5 s
     2013-03-19 20:43:14   R-msgScPosA     closed
     2013-03-19 20:43:14   R-msgScPosB     open
     2013-03-19 20:43:13   R-pairCentral   0x0
     2013-03-19 20:43:13   R-sabotageMsg   on
     2013-03-19 20:43:13   R-transmDevTryMax 6
     2013-03-19 20:43:14   R-transmitTryMax 6
     2013-03-19 20:43:13   RegL_00:          02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
     2013-03-19 20:43:14   RegL_01:          08:00 20:60 21:00 22:64 30:06 00:00
     2013-03-19 20:43:14   RegL_04:EG.WZ.Heizung_WindowRec   01:01 00:00
     2013-03-19 20:37:23   alive           yes
     2013-03-19 20:37:23   battery         ok
     2013-03-19 20:37:24   contact         open (to EG.WZ.Heizung)
     2013-03-19 20:37:23   cover           open
     2013-03-19 20:43:13   peerList        EG.WZ.Heizung_WindowRec,
     2013-03-19 20:37:36   state           MISSING ACK
   Helper:
     mId        002F
     peerIDsRaw ,1AD94103,00000000
     rxType     12
     Rssi:
       At_hmlan1:
         avg        -58.6666666666667
         cnt        15
         lst        -63
         max        -50
         min        -77
     Shadowreg:
Attributes:
   actCycle   028:00
   actStatus  alive
   expert     2_full
   firmware   2.0
   fp_GrundrissEG 465,1077,1,Terrassentüre
   model      HM-SEC-SC
   peerIDs    00000000,1AD94103,
   room       EG.WohnZ
   serialNr   JEQ0248383
   subType    threeStateSensor

Jetzt aber ;)

Und nicht wundern, der HM-Sec-SC liegt gerade offen neben der Tastatur.

Gruß
Thomas

[snoop]

Hallo Thomas,

ohjee, ok.... wo soll ich anfangen? ;o)

Ich intepretiere es so - die HM Untiefen sind eher an Martin gerichtet und nicht an mich. ;o)
Mein Anliegen ist auf "high level" Ebene zu verstehen was da (technisch) passiert.
Dies nur zu klärung der Ausgangssituation nun aber zu deinen Infos:

'list EG.WZ.Tuerkontakt'

Aus der Information kann ich folgendes entnehmen:
- Infos sind unvollständig (da vorher kein getConfig erfolgt ist...)
- Heute um 08:57:38 hast du das Gehäuse geöffnet, was dazu geführt hat, dass
- Um 2013-03-19 08:57:38 ein Status der Batterie übermittelt wurde - also: battery:ok

Ergebnis: Eigentlich keine verwertbaren Informationen ausser das hiermit wieder bestättigt ist, dass bei öffnen des Gehäuses der Batterie Status übermittelt wird!

ok weiter....

nach set ... getConfig und Anlernknopf kurz drücken erneut

'list EG.WZ.Tuerkontakt'

Aus der Information kann ich folgendes entnehmen:
- es ist das Ergebinis das ich erwartet habe..... also Readings werden aufgelistet etc.
- zugleich macht mir der Status: "2013-03-19 20:37:36 state MISSING ACK" sorgen -> dies ist aber eher ein Thema für Martin. Ich vermute das es mit seinen (angeforderten Tests) bzw. mit den nachvolgenden Tests behoben wird. Ich vermute, dass es was damit zu tun hat, dass du dein SC auch mit dem TC gepairt(hmm also, devicepairt -> also gepeert) hast.

Sonst kann ich keine, für mich verwertaberen Information entnehmen.

so weiter....

Nun ein:

'set EG.WZ.Tuerkontakt regSet cyclicInfoMsg on' => 3 CMDs pending
'set EG.WZ.Tuerkontakt getConfig' => X CMDs pending

Anlernknopf kurz gedrückt, Browser refresh, alle CMDs abgearbeitet

ein 'list EG.WZ.Tuerkontakt' bringt:

Aus der Information kann ich folgendes entnehmen:
- "regSet" hat wie erwartet funktioniert
- bei deinen Sensor ist nun "R-cyclicInfoMsg on"
- "2013-03-19 20:37:36 state MISSING ACK" macht mir weiterhin sorgen (siehe Punkt zuvor -> da muss Martin ran.)

Sorry Martin ;o)

Und nicht wundern, der HM-Sec-SC liegt gerade offen neben der Tastatur.

Ja, das sieht man "2013-03-19 20:37:23 cover open"
KANNST DIE TÜR RUHIG WIEDER ZUMACHEN ES WIRD SONST KALT ;o) UUUND DANKE.

Viele Grüße
Arthur

[Rohan]

Hallo Arthur,

... Ich vermute, dass es was damit zu tun hat, dass du dein SC auch mit dem TC gepairt(?) hast.

Der VD war bis gerade nur mit dem TC gepeert, jetzt ist er auch mit dem HMLAN gepairt (die anderen kommen dann noch).

Sonst kann ich keine, für mich verwertaberen Information entnehmen.

Da geht es dir wie mir! ;) Ich bin halt (in Sachen FHEM) Anwender, also in der Regel erst einmal Layer 8 *gg

Und der VD ist wieder closed. Bis jetzt war mir nur die Temperatursteuerung (Absenkung bei Tür offen) wichtig und das funktioniert(e). Der Rest (bezüglich evtl. Alarmfunktion) hat Nachrang bei mir. Dafür kommt demnächst die Zeit. Jetzt weiß ich ja, wie es geht.

Danke für diesen Thread.

Gruß
Thomas

[martinp876]

Hi,

Zum Protokol:
nach dem ersten getConfig sind 3 messages nicht verarbeitet worden
 

 protCmdDel 3
   protLastRcv 2013-03-19 20:37:33
   protResnd  2 last_at:2013-03-19 20:37:33
   protResndFail 1 last_at:2013-03-19 20:37:36
   protState  CMDs_done_events:3

 

Wichtig fuer den User ist nicht die 3 sondern das etwas nicht korrekt gelaufen ist.
Da kommt auch das missing-ack her.

Immer, wenn der Stack leer ist und neue Nachrichten gesendet werden sollen beginnt die Zaehlung neu
Es kam ein regSet und ein getConfig. Da es sein 'config' device ist werden also alle kommandos im Stack angehaeufelt bis das Device Empfangsbereitschaft signalisiert
=>

X CMDs pending

soll heisen Kommandos vom User abgesetzt aber nicht verarbeitet.

Dann Anlernen, als der Trigger, los gehts

Danach:

  protState  CMDs_done

=> alle Kommandos dieser Sequenz korrekt ausgefuehrt

Die Fehlerzaehler sind immer noch vorhanden. Die zaehlen ewig, erleben aber keinen Restart.

  protCmdDel 3
   protResnd  2 last_at:2013-03-19 20:37:33
   protResndFail 1 last_at:2013-03-19 20:37:36

Geaendert haben sich diese Zaehler, dies sind aber keine Fehler
 

  protLastRcv 2013-03-19 20:43:14
   protSnd    7 last_at:2013-03-19 20:43:14

Wenn man hier aufraeumen will kann man ein set name clear msgEvents ausfuehren. Das bereinigt das Protokoll, Zaehler und den command-stack

Fehler haben immer ein Fail am Ende. Ein "resend" ist noch kein Fehler, koennte ja noch klappen.

Und schliesslich das 'MISSING ACK' - unschoen. Es wird erst ueberschrieben, wenn ein neues Ereigniss eintritt. Da 'state' nicht dediziert dem protokoll gehoert schreiben ich auch kein 'send successful' rein - das waere dann quasi immer drin. In state stehen also immer die wichtigen device-zustaende (on,off,...) und eben auch ein missing ack.
der state bereinigt sich erst mit dem naechsten tuer-oeffnen oder einem statusRequest.

Gruss
Martin