[Gelöst] HM-SEC-SC-2 und das Reading battery

[martinp876]

Hi Marcel

egal zu sein ob in Register 10 nun 01, C8 oder FF steht, alles != 0 passt

bei bool sollte es so sein. Leider scheint es die FW nicht immer und konsequent zu machen. Sicher ist, dass manchmal bei 'bool'  der größe 'Byte' ein '1' nicht funktioniert.
Ich hoffe jetzt, dass in diesem Fall 'C8' immer funktioniert.  Das hässliche ist, dass es (wenn man den Code sich sehen kann) selbst beim gleichen Datenfeld einmal so und einmal so reagieren könnte.

Bin aufs Ergebnis gspannt.
Gruss Martin

[MarcelK]

Hallo Martin.

Die Ergebnisse sind etwas durchwachsen, siehe Bild. Der Sensor mit 0xFF hat seither nichts mehr gesendet. Die Sensoren mit 0xC8 haben fast alle mal was gesendet, aber im Schlafzimmer auch seit 2 Tagen nichts mehr. Der Wohnzimmer Sensor mit 0x01 hat sich glaub erst eine Weile nicht geregt, aber jetzt anscheinend gestern doch noch ein Lebenszeichen von sich gesendet... alles etwas seltsam, ich lass es mal noch ne Weile weiter rennen.

Woher kommt die Zahl 200 eigentlich, das hört sich so arbiträr an?

Grüße, Marcel

[martinp876]

Hi Marcel,

HM gibt %-werte in 0.5% stufen an, int kodiert. Also ist 200 = 100%
Das wird dann an vielen stellen genutzt - Licht an = 200,  auch bei einem Schalter, der eh nur ein und aus kennt.

Probleme machen mir daher "bool". Wenn es 1 Bit ist, ist es klar. Wenn es aber ein Byte ist, und HM dies nicht im XML spezifiziert wird es problematisch. Es scheint leider nicht sauber durchgezogen zu sein. Das verhalten könnte von Device zu Device und auch mit der FW-version geändert werden.
An manchen Stellen bin ich sicher, dass 1 korrekt ist, an anderen ist es sicher eine 200. Und einige sind unklar.

Gruss Martin

[hauwech]

Update

Der Fensterkontakt liefert den Batteriestatus nur, solange das Fenster nicht geöffnet oder geschlossen wird. Die letzten Tage hat niemand das Fenster betätigt. Solange hat der Kontakt den Batteriestatus zum Zeitpunkt des letzten Anlernen-Drückens gemeldet. Jetzt, seitdem (Samstag) der betroffene Gebäudeteil wieder belegt ist - das Fenster also geöffnet und geschlossen wird - kommt kein Batteriestatus mehr.
Zwei meiner Kollegen bestätigen exakt dieses Verhalten bei ihren Fensterkontakten.
Diese Fensterkontakte nerven langsam. Den Ersten mußte ich zurückschicken, der hat gar nicht funktioniert, der zweite, der jetzt im Einsatz ist, meldet wenigstens die open/close events, aber er zickt immer wieder herum. Zwischendurch hat er beim Öffnen/Schließen auch einige Male wieder orange/rot angezeigt. Das war aber wenig später wieder in Ordnung. Das Vertrauen schwindet zusehends.
Wie gut, daß wir auf ein multilinguales System wie fhem gesetzt haben, da kann man sich auch mal nach alternativen Komponenten umschauen, auf die man sich möglicherweise verlassen kann.

Gruß Roland

[hauwech]

Refresh...
Der Fensterkontakt meldet den Batteriestatus nur, wenn man ihn durch Auslösen der Sabotagemeldung beim Entnehmen zum Erwachen zwingt.
- R-cyclicInfoMsg: on
- actStatus: alive
- autoReadReg: 5_readMissing

Zwei meiner Kollegen - auch Fhemisten - haben das gleiche Problem mit ihren Fensterkontakten. Wenn ich das richtig verstanden habe, deutet actStatus alive darauf hin, daß er sich schon regelmäßig meldet, sonst müßt dort "dead" stehen. Warum kommt der Batteriestatus nicht? Sendet er den nicht oder kommt der in fhem nicht an?

Gruß Roland

[martinp876]

Hallo Roland,

der sc-2 sollte sich alle ~24h melden - wenn es eingeschaltet ist.
Der Batteriestatus kommt nur mit der Statusmessage, nicht mit dem Trigger.
Die Statusmessage kommt mit dem Sabotage-kontakt - passt also so weit.

Kannst du einmal die readings der Register (roh) schicken?

du solltest einmal rohmessages loggen. Setze
attr <hmlan> logIDs <SC2-hmid>
das reicht - lasse es die nächsten Tage mit laufen.
Der

Du kannst probieren:
set <sc2> regBulk RegL_0: 09:01
und es 24h laufen lassen.

set <sc2> regBulk RegL_0: 09:FF
und es 24h laufen lassen.

set <sc2> regBulk RegL_0: 09:C8
und es 24h laufen lassen.

Der ActionDetector erkennt auch, wenn das Device einen trigger sendet. Erst wenn du 28h nichts machst ist er dead.

Gruss Martin

[hauwech]

Hallo Martin,

der sc-2 sollte sich alle ~24h melden - wenn es eingeschaltet ist.
Der Batteriestatus kommt nur mit der Statusmessage, nicht mit dem Trigger.
Die Statusmessage kommt mit dem Sabotage-kontakt - passt also so weit.

soweit alles klar...

Der ActionDetector erkennt auch, wenn das Device einen trigger sendet. Erst wenn du 28h nichts machst ist er dead.

Aha... das hatte ich noch nicht auf'm Schirm. Das heißt, das "alive" kommt nicht unbedingt von einer zyklischen Statusmessage und könnte in dem Falle bedeuten, daß gar keine zyklische Message gesendet wird, wie ich bisher angenommen hatte.
list <FK> sieht jetzt so aus (oder gibt es noch eine andere Form für "readings der Register roh"?):

Code Auswählen Erweitern

Internals:
   DEF        24D474
   HMLAN1_MSGCNT 2
   HMLAN1_RAWMSG E24D474,0000,4C863AFE,FF,FFB8,1CA24124D474272DDE010EC8
   HMLAN1_RSSI -72
   HMLAN1_TIME 2014-05-05 11:07:16
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     2
   NAME       AnbauBadFenster
   NR         71
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:1C - t:41 s:24D474 d:272DDE 010EC8
   peerList   AnbauBadHeizung_WT_WindowRec,
   protCondBurst unknown
   protLastRcv 2014-05-05 11:07:16
   protSnd    1 last_at:2014-05-05 11:07:16
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-71 min:-72 max:-70 lst:-72 cnt:2
   Readings:
     2014-05-04 20:43:01   Activity        alive
     2014-05-02 21:32:45   CommandAccepted yes
     2014-05-02 21:32:44   D-firmware      2.2
     2014-05-02 21:32:44   D-serialNr      KEQ0950621
     2014-05-02 21:32:46   PairedTo        0x272DDE
     2014-05-02 21:32:47   R-AnbauBadHeizung_WT_WindowRec-expectAES off
     2014-05-02 21:32:47   R-AnbauBadHeizung_WT_WindowRec-peerNeedsBurst on
     2014-05-02 21:32:46   R-cyclicInfoMsg on
     2014-04-16 17:42:38   R-eventDlyTime  0 s
     2014-04-16 17:42:38   R-ledOnTime     0.5 s
     2014-05-02 21:32:46   R-msgScPosA     closed
     2014-05-02 21:32:46   R-msgScPosB     open
     2014-05-02 21:32:46   R-pairCentral   0x272DDE
     2014-05-02 21:32:46   R-sabotageMsg   on
     2014-05-02 21:32:46   R-transmDevTryMax 6
     2014-05-02 21:32:46   R-transmitTryMax 6
     2014-05-02 21:32:46   RegL_00:        02:01 09:C8 0A:27 0B:2D 0C:DE 10:01 14:06 00:00
     2014-05-02 21:32:46   RegL_01:        08:00 20:60 21:00 22:64 30:06 00:00
     2014-05-02 21:32:47   RegL_04:AnbauBadHeizung_WT_WindowRec 01:01 00:00
     2014-05-02 21:34:22   alive           yes
     2014-05-02 21:34:22   battery         ok
     2014-05-05 11:07:16   contact         open (to HMLAN1)
     2014-05-02 21:34:22   cover           closed
     2014-05-04 20:43:01   peerList        AnbauBadHeizung_WT_WindowRec,
     2014-05-02 21:34:22   recentStateType info
     2014-05-05 11:07:16   state           open
   Helper:
     mId        00B1
     rxType     12
     Io:
       newChn     +24D474,00,01,1E
       nextSend   1399280836.25053
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1399280836.16107
       ack:
         HASH(0x1d82ad8)
         1C8002272DDE24D4740101C800
     Rssi:
       At_hmlan1:
         avg        -71
         cnt        2
         lst        -72
         max        -70
         min        -72
Attributes:
   IODev      HMLAN1
   actCycle   028:00
   actStatus  alive
   autoReadReg 5_readMissing
   burstAccess 1_auto
   devStateIcon open:fts_window_1w_open@red open closed:fts_window_1w@green
   expert     2_full
   firmware   2.2
   fp_Anbau   130,220,1,Fenster
   group      Fenster-Türen
   model      HM-SEC-SC-2
   peerIDs    00000000,2702B303,
   room       Übersicht
   serialNr   KEQ0950621
   subType    threeStateSensor

R-cyclicInfoMsg ist in der Anzeige von "undef lit:200 wieder auf "on" gewechselt, ich nehme an, Du hast den code entsprechend angepaßt.

Ich hatte am 16.04. das Register auf 200 (C8) gesetzt. Daraufhin hat er die Folgetage brav alle 24 Stunden den Batteriestatus gemeldet. Offenbar aber nur, weil niemand da war, der das Fenster betätigt hat. Als wir wieder zuhause waren und das Fenster geöffnet/geschlossen haben, hat er die Meldung für den Batteriestatus eingestellt. Sobald ein Trigger gesendet wird, kommt anschließend bis zur nächsten Sabotage/Anlernen kein Batteriestatus mehr.
Das logging habe ich jetzt mit

Code Auswählen Erweitern

attr <hmlan> logIDs 24D474eingestellt, ich werde jetzt zwei Tage beobachten und dann den Wert auf 255 setzen.

Gruß Roland

[martinp876]

Hallo Roland,

Register sind ok.

Daraufhin hat er die Folgetage brav alle 24 Stunden den Batteriestatus gemeldet. Offenbar aber nur, weil niemand da war, der das Fenster betätigt hat.

Glaube ich nicht. Beim Betätigen wird ein trigger gesendet, da ist kein Batteriestatus drin. Ob dabei auch ein Status an die Zentrale gemeldet wird ist möglich, aber nicht sicher - kannst du aber testen... dann wäre da auch ein neuer Batteriestatus dabei.

Bei 1 Byte Bool ist mir schlicht nicht 100% klar, was hm hier sehen will.
Wir werden erst nach dem Loggen und dem Experimentieren mit den Werten wissen, welcher funktioniert.

Gruss Martin

[JanS]

Hab gestern einen Test aufgesetzt, HM-SEC-SC-2 Firmware 2.4
RegL_00: 02:01 09:01 0A:26 0B:33 0C:B6 10:01 14:06 00:00
RegL_01: 08:01 20:60 21:00 22:64 30:06 00:00

Statusmeldung kam nach 23Stunden und 51 Minuten. Inkl. Batteriestatus. Aktualisiert wurden battery, cover und contact.
Damit wäre zumindest geklärt, dass Register 09 auf 01 stehen kann.
   

[hauwech]

Meine Fensterkontakte und die meiner beiden Kollegen haben Firmware Version 2.2 drauf. Damit ist leider noch nicht geklärt, ob das in der Version 2.2 auch so ist. Möglicherweise hat der Hersteller nachgebessert, weil da was faul war... Immerhin interessant zu erfahren, daß hier zwei subversions weiter ausgeliefert wird.
Wann hast Du Deine denn gekauft?

Gruß Roland

[hauwech]

... Glaube ich nicht. Beim Betätigen wird ein trigger gesendet, da ist kein Batteriestatus drin. Ob dabei auch ein Status an die Zentrale gemeldet wird ist möglich, aber nicht sicher - kannst du aber testen... dann wäre da auch ein neuer Batteriestatus dabei.

Für mich sieht es derzeit so aus, als ob ein gesendeter Trigger die zyklische Statusmeldung deaktiviert.
Ich bin derzeit eigentlich bei der Sanierung unseres Hauses und habe nicht genügend Zeit, umfangreiche Testreihen aufzusetzen... Aber es wurmt mich halt, wenn ein Stück Technik nicht so funktioniert, wie es soll.

Ich zolle Leuten, die so viel Zeit, KnoffHoff und Engelsgeduld in solche Projekte einbringen, höchsten Respekt!

Gruß Roland

[JanS]

Code Auswählen Erweitern

Meine Fensterkontakte und die meiner beiden Kollegen haben Firmware Version 2.2 drauf. Damit ist leider noch nicht geklärt, ob das in der Version 2.2 auch so ist.
Ja, leider. Das grundlegende Verhalten scheint allerdings dahingehend identisch zu sein, dass eine Statusmeldung nur nach 24h Inaktivität gesendet wird.
Ich werde bei Gelegenheit an einem etwas besseren Labornetzteil mal testen, ob evtl. bei sinkender Spannung auch unabhängig von Aktivität eine Statusmeldung getriggered wird.

Code Auswählen Erweitern

Wann hast Du Deine denn gekauft?

Vor ein paar Tagen bei ELV bestellt.

Code Auswählen Erweitern


Aber es wurmt mich halt, wenn ein Stück Technik nicht so funktioniert, wie es soll.
Geht mir genauso, das ist auch der Grund weswegen meine HM-RC-4-2 nicht mehr mit eQ-3 Firmware laufen, allerdings auch mit eigenem Protokoll und starker Crypto (Twofish) also eine gnaz andere Nummer. Beim HM-SEC-SC-2 geht das leider nicht, zum Einen wechselt eQ-3 die Microcontroller Familien(AVR,ST8,MSP340, Silabs C8051F9x0 etc.) wie ich die Unterwäsche, zum Anderen scheint in den SC-2 ein ASIC verbaut zu sein.

[hauwech]

Der letzte gemeldete Batteriestatus ist vom 02.05. 21:34 Uhr. Ich habe jetzt das Register auf FF gesetzt und zweimal anlernen gedrückt. Beim ersten Anlernen protestiert er immer mit gelb blinken und Rot, beim zweiten anlernen geht's immer. Beim Wiedereinsetzen hat er lange gelb geleuchtet, dann rot, dann wieder gelb und dann grün. Allerdings stehen im Log KEINE Rohmessages, obwohl das attr logIDs des HMLAN immer noch auf "AnbauBadFenster" steht. Ich habe heute morgen ein fhem update +  restart gemacht. Hat das etwa das loggen der Rohmessages verhindert?

Gruß Roland

[MarcelK]

Also meinen Tests nach macht es keinen Unterschied ob 200 oder 1 im Register steht. 255 geht definitiv nicht, der Test-Sensor hat sich seit 2 Wochen nicht gemeldet (Esszimmer im Bild) Ansonsten sind die Ergebnisse schwer zu interpretieren, aber die "schick nur eine Status Message wenn in den letzten 24 Stunden keine Öffnung war" könnte zu den Beobachtungen ganz gut passen: Schlafzimmer wird regelmässig gelüftet und die letzte Batterie Meldung war von vor 5 Tagen. Die restlichen Fenster hängen normal auch ein paar Tage nach, nur heute war die Family unterwegs und hat praktisch kein Fenster bewegt -> fast alle Batterie Meldungen sind aktuell.
Interessant ist noch das Bad-Fenster, da es vor 4 Tagen auf Battery-Low gewechselt hat obwohl es sicherlich nie 24 Stunden am Stück zu geblieben ist. Evtl sendet der Sensor im Notfall also doch und hält nur die Füsse still wenn es nichts zu sagen gibt... keine Ahnung, schwer zu testen.

[hauwech]

Interessant ist noch das Bad-Fenster, da es vor 4 Tagen auf Battery-Low gewechselt hat obwohl es sicherlich nie 24 Stunden am Stück zu geblieben ist. Evtl sendet der Sensor im Notfall also doch und hält nur die Füsse still wenn es nichts zu sagen gibt... keine Ahnung, schwer zu testen.

Das ist eine wichtige Beobachtung, wir haben schon gerätselt, wie sich der Sensor in diesem Falle verhalten würde. Man macht ja schließlich die Batterieüberwachung nur deshalb, um mitzubekommen, wenn sich die Batteriespannung dem Ende nähert. Zumindest DAS wäre also abgesichert.

Gruß Roland