HM-SEC-SD-2 neu

Begonnen von martinp876, 21 März 2015, 17:28:26

Vorheriges Thema - Nächstes Thema

raspklaus

Es haben aber alle
IOgrp      vccu:CUL_800HM

Die die mit der Verschlüsselung klarkommen und der der es nicht schafft

Vielleicht kennt Martin das Problem

frank

genau, und deshalb tauschen, weil der cul schlechteres timing hat.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

mgernoth

Hallo,

Zitat von: raspklaus am 31 August 2016, 11:08:16
Hallo zusammen,
Er scheint irgendwie im Gegensatz zu den anderen nicht AES zu verstehen.

Wie testest Du das?

Nur eine Konfigurationsänderung der SD2 führt zu einem AES Challenge-Response (und damit zum Update des Readings). Ein Alarm oder Teamcall tut dies nicht (anderes AES-Verfahren ohne Rückmeldung vom Gerät)!
Und einmal fehlgeschlagene AES-Requests sind nicht ungewöhnlich und können z.B. durch kurzzeitige Funkstörungen verursacht worden sein.

Viele Grüße
  Michael

raspklaus

Was zB könnte ich an der Konfiguration des betroffenen SD ändern um es zu testen ?

Bytechanger

#334
Muss auch noch mal eine Frage nachstellen:

Bisher hat alles wunderbar funktioniert. Sogar bei einem Alarm hat alles so wie es soll geklappt.

Nun musste ich in FHEM einiges umstellen (Bezeichnung, etc) und der FHEM -Server war auch einige Zeit off.
Nun musste ich leider feststellen, dass die SD2 nicht mehr per TeamCall angesprochen werden von FHEM ??

Kann es sein, dass FHEM verschiedene Messages zwischen den SD2s nicht mitbekommen hat und dadurch mit der "Message count" in der AES-Sginierung durcheinander gekommen ist??
Wie kann ich das beheben??


Vermutlich liegt es doch am Reading "aesCBCCounter", oder??
@martin876: Wie war das noch. FHEM musste den Counter irgendwo speichern, sonst wurden die teamCalls ignoriert, wenn die ID tiefer war als der zuletzt gesendete.
                      Wo wird der Counter gespeichert? Im Reading aesCBCCounter?
                      Dieses könnte ich doch mit setreading beeinflussen... (höher setzen??)


Greets

Byte

martinp876

korrekt: Reading aesCBCCounter

Bytechanger

Also im TeamLead einen hohen wert einstellen?
Oder wie gehe ich am schlauesten vor?
Ist ein hex wert...

mgernoth

Hi,

Zitat von: Bytechanger am 03 September 2016, 17:55:03
Also im TeamLead einen hohen wert einstellen?
Oder wie gehe ich am schlauesten vor?
Ist ein hex wert...

Setze mal die Generation eins hoch (das sind die ersten zwei Bytes), also wahrscheinlich auf 000100.

Viele Grüße
  Michael

automatisierer

Stellt FHEM sich evtl. nach, wenn du einen TeamCall von einem anderen Rauchmelder aus sendest?

mgernoth

Hallo,

Zitat von: automatisierer am 03 September 2016, 19:23:33
Stellt FHEM sich evtl. nach, wenn du einen TeamCall von einem anderen Rauchmelder aus sendest?

Nein. Der Counter ist pro Geraet und die Rauchmelder merken sich alle Zaehlerstaende der anderen Geraete. Eigentlich sollte man diese Variable nie manuell anpassen muessen. Sollte sie jedoch verloren gehen (z.B. fhem.save korrupt/verloren), dann muss man sie per Hand setzen. Dabei passt man am besten die Generation an (die RM selbst inkrementieren die Generation nach jedem Reboot).

Viele Gruesse
  Michael

Bytechanger

Danke für die Info.
Was bedeutet "Generation"??

Bei mir ist genau das passiert. fhem.save ist defekt...
Habe in einem Backup den Wert 000006 gelesen.
Aber weder 000100 noch 000200 funktionieren...

Soll ich weiter hoch gehen?
Wenn ich es richtig verstanden habe, ist höher ja egal.

Aber was passiert am Ende, gehts dann wieder auf 0 ??
Und wenn "je Gerät" der Counter gespeichert wird, und alle Signale mit der Adresse des TeamLead gesendet werden, wird dann jeder Alarm (der ja mit der Adresse des TeamLead gesendet wird)
den Counter hochsetzen??

Greets

Byte

mgernoth

Hallo,

Zitat von: Bytechanger am 03 September 2016, 20:05:13
Was bedeutet "Generation"??

Das ist die "Generation", aus der das letzte Byte ist. Je höher, desto Jünger. In der Nachricht werden diese drei Bytes nicht direkt zusammen gesendet, das letzte Byte ist der normale HM Nachrichtenzähler.

Zitat
Bei mir ist genau das passiert. fhem.save ist defekt...
Habe in einem Backup den Wert 000006 gelesen.
Aber weder 000100 noch 000200 funktionieren...

Hmm, Fhem sollte nicht allzu schnell die Generation hochzählen eigentlich...
Passen die Peerings der einzelnen Teilnehmer noch?

Zitat
Soll ich weiter hoch gehen?
Wenn ich es richtig verstanden habe, ist höher ja egal.

Ja, das kannst Du mal probieren.

Zitat
Aber was passiert am Ende, gehts dann wieder auf 0 ??

Ja, er geht nach FFFFFF wieder auf 0. Aber wie die Teamteilnehmer reagieren hat bisher noch niemand probiert. Ich würde aber annehmen, dass dann die Adresse des TeamLead keine gültigen Nachrichten mehr senden kann und man sich eine neue Adresse suchen muss.

Zitat
Und wenn "je Gerät" der Counter gespeichert wird, und alle Signale mit der Adresse des TeamLead gesendet werden, wird dann jeder Alarm (der ja mit der Adresse des TeamLead gesendet wird) den Counter hochsetzen??

Nein, die einzelnen RM senden schon noch ihre eigene Adresse (allerdings im Empfängerfeld) mit. Und an dieser echten Adresse hängt der Counter in den RM.

Viele Grüße
  Michael

Bytechanger

Also ein getConfig auf den Rauchmelder geht.
Internals:
   DEF        48F0F8
   HMLAN1_MSGCNT 11
   HMLAN1_RAWMSG RF1583F99,0001,0A23E58C,FF,FFCF,04A01048F0F81DA462011111130100000000
   HMLAN1_RSSI -49
   HMLAN1_TIME 2016-09-03 20:38:27
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     11
   NAME       EG.bu.Buero.RM2
   NR         467
   NTFY_ORDER 50-EG.bu.Buero.RM2
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:04 - t:10 s:48F0F8 d:1DA462 011111130100000000
   peerList   Rauchmelder.RM2.grp,
   protLastRcv 2016-09-03 20:38:27
   protSnd    6 last_at:2016-09-03 20:38:27
   protState  CMDs_done
   rssi_HMLAN1 min:-41 cnt:1 max:-41 avg:-41 lst:-41
   rssi_at_HMLAN1 avg:-49 max:-49 cnt:6 min:-49 lst:-49
   Readings:
     2016-09-03 14:52:01   Activity        alive
     2016-09-03 13:16:51   D-firmware      1.0
     2016-09-03 13:16:51   D-serialNr      NEQ0243833
     2016-09-03 20:38:27   PairedTo        0x1DA462
     2016-08-29 20:24:08   R-devRepeatCntMax 0
     2016-08-29 20:24:08   R-pairCentral   0x1DA462
     2016-09-03 20:38:27   RegL_00.          02:01 0A:1D 0B:A4 0C:62 16:00 1F:00 00:00
     2016-09-03 14:52:24   alarmTest       ok
     2016-09-03 14:52:24   battery         ok
     2016-09-03 14:52:24   level           0
     2016-09-03 20:38:27   peerList        Rauchmelder.RM2.grp,
     2016-09-03 14:52:24   recentStateType info
     2016-09-03 20:38:27   sdRepeat        off
     2016-09-03 14:52:24   smokeChamber    ok
     2016-09-03 13:19:58   smoke_detect    none
     2016-09-03 14:52:24   state           off
     2016-09-03 20:02:47   teamCall        from TeamDevSD2:7
     2016-09-03 13:19:58   trigLast        Rauchmelder.RM2.grp:0
     2016-09-03 13:19:58   trig_Rauchmelder.RM2.grp 0
   Helper:
     HM_CMDNR   4
     cSnd       011DA46248F0F800040000000000,011DA46248F0F80103
     mId        00AA
     peerIDsRaw ,11111301,00000000
     rxType     6
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Io:
       newChn     +48F0F8,00,01,00
       nextSend   1472927907.88581
       rxt        0
       vccu       vccu
       p:
         48F0F8
         00
         01
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        04
       Io:
         HMLAN1     -47
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1472927907.81038
       ack:
         HASH(0x164bb90)
         0480021DA46248F0F800
     Rssi:
       Hmlan1:
         avg        -41
         cnt        1
         lst        -41
         max        -41
         min        -41
       At_hmlan1:
         avg        -49
         cnt        6
         lst        -49
         max        -49
         min        -49
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   099:00
   actStatus  alive
   alarmDevice Sensor
   alarmSettings alarm7,|EG.bu.Buero.RM2:.*smoke-Alarm.*|Rauch Büro|on
   autoReadReg 5_readMissing
   devStateIcon off:general_ok *:secur_alarm
   event-on-change-reading .*
   expert     251_anything
   firmware   1.0
   group      Rauchmelder EG
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11111301,
   room       CUL_HM,Rauchmelder
   serialNr   NEQ0243833
   subType    smokeDetector
   webCmd     statusRequest


Hier der TeamLead
Internals:
   DEF        11111301
   HMLAN1_MSGCNT 5
   HMLAN1_RAWMSG E2617F9,0000,0A033B75,FF,FFA0,B9865A2617F9000000A8FE33
   HMLAN1_RSSI -96
   HMLAN1_TIME 2016-09-03 20:02:47
   LASTInputDev HMLAN1
   MSGCNT     5
   NAME       Rauchmelder.RM2.grp
   NR         463
   NTFY_ORDER 50-Rauchmelder.RM2.grp
   STATE      off
   TESTNR     7
   TYPE       CUL_HM
   chanNo     01
   device     TeamDevSD2
   peerList   K.fl.Treppe.RM2,OG.kz.Anna.RM2,OG.kz.Linus.RM2,K.k2.Bastelkeller.RM2,OG.sz.Schlafzimmer.RM2,OG.kz.Maja.RM2,EG.ku.Kueche.RM2,EG.bu.Buero.RM2,EG.wz.Wohnzimmer.RM2,
   sdTeam     sdLead
   Readings:
     2016-09-03 20:01:58   aesCBCCounter   000200
     2016-09-03 13:19:58   eventNo         02
     2016-09-03 13:19:58   level           0
     2016-09-03 14:52:03   peerList        K.fl.Treppe.RM2,OG.kz.Anna.RM2,OG.kz.Linus.RM2,K.k2.Bastelkeller.RM2,OG.sz.Schlafzimmer.RM2,OG.kz.Maja.RM2,EG.ku.Kueche.RM2,EG.bu.Buero.RM2,EG.wz.Wohnzimmer.RM2,
     2016-09-03 13:19:58   smoke_detect    none
     2016-09-03 20:00:19   state           off
     2016-09-03 20:02:47   teamCall        from TeamDevSD2:7
     2016-09-03 13:19:58   trigger_cnt     2
   Helper:
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
Attributes:
   alarmDevice Sensor
   alarmSettings |Rauchmelder.RM2.grp:.*smoke-Alarm.*|RauchAlarm2|on
   devStateIcon off:general_ok *:secur_alarm
   group      Rauchmelder Teamleader
   icon       secur_smoke_detector
   model      virtual_1
   peerIDs    47316A01,47343701,487DB901,487EBB01,487F0B01,487F9B01,4882DA01,48F0F801,48FDC801,
   room       Rauchmelder
   webCmd     teamCall:alarmOn:alarmOff


Internals:
   DEF        111113
   HMLAN1_MSGCNT 5
   HMLAN1_RAWMSG E2617F9,0000,0A033B75,FF,FFA0,B9865A2617F9000000A8FE33
   HMLAN1_RSSI -96
   HMLAN1_TIME 2016-09-03 20:02:47
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     5
   NAME       TeamDevSD2
   NR         462
   NTFY_ORDER 50-TeamDevSD2
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Rauchmelder.RM2.grp
   protSnd    7 last_at:2016-09-03 20:02:07
   protState  CMDs_done
   Readings:
     2016-09-03 20:02:47   battery         ok
     2016-09-03 20:02:07   state           CMDs_done
   Helper:
     HM_CMDNR   8
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       vccu       vccu
       prefIO:
         HMLAN1
     Mrssi:
       mNo
       Io:
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   model      virtual_1
   subType    virtual
   webCmd     virtual


Vielleicht kann jemand einen Fehle rentdecken.

Was mich beunruhigt hat ist
ZitatJa, er geht nach FFFFFF wieder auf 0. Aber wie die Teamteilnehmer reagieren hat bisher noch niemand probiert. Ich würde aber annehmen, dass dann die Adresse des TeamLead keine gültigen Nachrichten mehr senden kann und man sich eine neue Adresse suchen muss.

... und man sich eine neue Adresse suchen muss-----> was bedeutet das?

Also ich soll jetzt mal von aesCBCCounter 000200 an hochzählen?? 00300 ?? oder 00201 ?

Ach ja, und im Augenblick ändert sich der aesCBCCounter nicht, sollte er nicht bei jeder Message hochzählen??


Greets

Byte

Bytechanger

So, habe doch noch ein Backup gefunden und zurückgespielt (Stand: Ende August).

Leider funktioniert es immer noch nicht.
aesCBCCounter ist 000006.
In dieser Zeit ist aber definitiv kein Kommando alarmOn / alarmOff / TeamCall von der Zentrale gesendet worden.

Da ich vermute, dass der Counter nur bei akzeptierten Kommandos hochzählt, sollte es doch damit funktionieren??

Bin etwas ratlos...

Greets

Byte

frank

vielleicht bringt ein vergleich mit den werten der anderen rm ein hinweis auf die aktuelle zahl.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html