HM-SEC-SD-2 neu

[martinp876]

Das komplizierte Vorgehen kann ich nicht verstehen und denke es ist nicht notwendig. Das ganze Löschen und reseten.

Das erste ist immer das pairing - hier wie überall. Es ist hinreichend beschrieben. Beim SD kann man es prüfen indem man einen StatusRequest  ausführt. Der sollte beanwortet werden, alle Kommandos aus der Queue weg und ein CMDs_done in internals.  Ist nicht gepairt muss es wiederholt werden. Sollte es nicht klappten (device bereits gepairt mit einer anderen Zentrale) pairing wiederholen. Ein Löschen in FHEM ist unnötig - bestenfalls ein clear mshEvents.

Hat man gepairt und dies kontrolliert kann man peeren (teamen).
Team-mitglieder kennen nur einen Team-lead. Kennen sie diesen (reagieren auf TeamCall des Lead) ist alles prima. Am Device ist nichts mehr zu ändern - nicht löschen, nichts.
Reagiert es nicht ist es nicht im Team oder in einem anderen Team. Also getConfig und die peers kontrollieren. Steht etwas falsches drin muss der falsche Lead gelöscht werden!!! ein peering überschreibt den peer NICHT. Da nur einen eingetragen wird klappt ein peering also nicht. Es wird  nicht quitiert und es kommt zu Fehlermeldungen im Protokoll. Also - wie immer!!! - nach Konfigurationsaktionen einmal den Ablauf kontrollieren. get hm protoEvents ist dein Freund. set hm clearG msgEvents macht reinen tisch - könnte man vor dem Config testen.
Hat man mit getConfig kontrolliert dass der SD den korrekten Lead als peer eingetragen hat ist alles prima. Der SD solle auf teamCall reagieren  - ebenso reagieren andere Team-mitglieder auf "seinen" teamCall.

Virtueller Lead:
Der Virtuelle Lead kennt alle Mitglieder. Das macht die Kontrolle einfacher - hmInfo kann prüfen. ob alle gepeert sind (ich korrigiere es gerade noch einmal)
Natürlich muss man nach dem peeren en save machen. Ein virtueller Kanal speichert alles in Attributen (also die peers) - und die sind ohne save verloren.

Realer Lead:
der kennt keine TeamMember - nur den Lead (sich selbst). Kann auch nicht kontrollieren, wer da ist.

=> wildes löschen bei nicht-funktion ist nicht  notwendig. Man kann das sehr selektiv machen.
=> wenn einer nicht auf das Team hört liegt es an ihm. nicht am team (so dies funktioniert).

[M_I_B]

... ja, das sagst Du
Ich hatte den Vorgang ja mehrmals wiederholt, wie es allgemein bekannt ist und von Dir auch eben beschrieben wurde. Auch die Kontrollen waren erst einmal unauffällig, bis eben auf immer genau einen, nämlich der zuletzt gepairte RM, der zwar sauber gepairt war, aber ständig bei z.B. getConfig mit allen möglichen Fehlermeldungen um die Ecke kam. Das war in allen 4 Versuchsreihen reproduzierbar.
Das komplette Löschen habe ich auch aus dem Grund getan, um für alle Versuche exakt die gleiche Grundlage zu schaffen. das sehe ich zumindest als notwendig an, wenn man denn eben genau die gleichen Grundlagen für jeden Versuch schaffen möchte. Ist m.E. auch nicht so problematisch, da mit ein paar Klicks und Copy&Past gesichert. Dsa geht auf jeden Fall deutlich schneller als über FHEM ...

Warum das peering nicht im Attribut des Leaders gespeichert wird, kann ich nicht sagen. Aber ich denke, das liegt ganz einfach daran, das der nicht in der fhem.cfg steht, sondern per include eingebunden wird. Bei anderen per include eingebundenen Sachen, seien es nun Aktoren oder Sensoren oder z.B. auch das DashBoard, funktioniert das Eintragen der geänderten Attribute allerdings.

Na, wie dem auch sei: Es tut ja jetzt wie es soll und ich kann meine Zicken per Mausklick um Aufmerksamkeit resp. Gehörprobe bitten

So bald ich Zeit habe, werde ich FHEM eh auf einen 19" XEON verlagern, die hier noch auf Einbau ins Rack warten (die haben natürlich noch anderes zu tun; wäre sonst etwas überdreht ^^). Dann werde ich ja sehen, ob die doch manchmal unerklärlichen Probleme bei mir an meiner FHEM/RaspBian/RPi/SCC- Installation liegen, oder ob die dann in dieser oder ähnlicher Form auf dem "richtigen" Server auch auftreten...

PS: Ich meine mit Leader natürlich immer einen virtuellen Lead in FHEM; wir waren uns ja einig, das ein Hardware-Lead in der Konstrellation unschlau wäre ...

[automatisierer]

Moin,
hab mir grad die neu 10_CUL_HM aus dem SVN geladen und meine 6 neuen SD2 gepairt und mit einem Virtuellen TeamLead gepeert. Hat alles tip top funktioniert.

Mir ist nur aufgefallen, das der zuerst gepairte SD2 ein weiteres Device angelegt hat und das LOG voll mit diesen Meldungen war. Das Device hat den Namen 4C6CF9, der SD2 hat den Namen HM_4C6CF9. Nachdem ich 4C6CF9 gelöscht habe waren die LOG-Meldungen weg.

Code Auswählen Erweitern


2016.05.27 22:56:06 2: CUL_HM Unknown device HM_4C6CF9 is now defined
2016.05.27 22:56:06 2: autocreate: define HM_4C6CF9 CUL_HM 4C6CF9
2016.05.27 22:56:06 2: autocreate: define FileLog_HM_4C6CF9 FileLog ./log/HM_4C6CF9-%Y.log HM_4C6CF9
2016.05.27 22:56:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:00 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:11 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:57:22 1: Error: 4C6CF9 has no TYPE
2016.05.27 22:57:37 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 7067.
2016.05.27 22:57:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:58:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:58:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:58:11 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.
2016.05.27 22:58:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4518.


Gruß
Ingo

[automatisierer]

Nachdem der TeamCall vom virtuellen Team-Lead aus nicht funktioniert, habe ich alle SD2's nochmal auf Werkseinstellungen zurück gesetzt und die Dev's in FHEM gelöscht. Dann alles nochmal neu gepairt... getConfig... und dann mit dem virt. Team-Lead gepeert... getConfig... alles ist so wie es soll. Der TeamCall vom virt.Team-Lead aus geht immer noch nicht. Zumindest zeigen die SD2's keine Reaktion - in den Readings der SD2's steht unter teamCall der virt.Team-Lead.


Der TeamCall von einem SD2 aus (Kommunikationstest laut Bed.Anleitung) funktioniert - alle anderen SD2's blinken grün.

Habe das ganze mal gesnifft:

erst mal der TeamCall von einem SD2 aus, mit anschließendem zurücksetzen:

Code Auswählen Erweitern


2016.05.28 18:20:26.696 0: HMLAN_Parse: HMLANingo2 R:E4C6CF9   stat:0000 t:03FDBF57 d:FF r:FFB1     m:91 8400 4C6CF9 000000 1000AA4E455130343439373233CE000100
2016.05.28 18:20:31.778 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDD211 d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:32.118 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDD4CC d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:32.812 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDD787 d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:33.517 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDDA43 d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:34.215 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDDCFE d:FF r:FFB1     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:20:35.026 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDDFB9 d:FF r:FFB0     m:08 1441 191919 4C6CF9 01089600000156B59D7C
2016.05.28 18:21:25.808 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEA4EA d:FF r:FFB6     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:26.087 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEA7A5 d:FF r:FFB0     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:26.786 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEAA60 d:FF r:FFB7     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:27.486 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEAD1B d:FF r:FFB8     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:28.184 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEAFD6 d:FF r:FFB8     m:09 1441 191919 4C6CF9 010900000001316F54AE
2016.05.28 18:21:28.883 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FEB291 d:FF r:FFB8     m:09 1441 191919 4C6CF9 010900000001316F54AE


und dann ein teamCall von dem virt.TeamLead aus mit anschließendem alarmOff:

Code Auswählen Erweitern


2016.05.28 18:22:11.048 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF5752 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:11.684 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF59C7 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:12.304 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF5C3B d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:12.932 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF5EAF d:FF r:FFB5     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:13.561 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF6124 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:14.190 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF6399 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9
2016.05.28 18:22:55.773 0: HMLAN_Send:  HMLANingo2 S:SF82CF370 stat:  00 t:00000000 d:01 r:F82CF370 m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:55.879 0: HMLAN_Send:  HMLANingo2 S:SF82CF3DA stat:  00 t:00000000 d:01 r:F82CF3DA m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:55.985 0: HMLAN_Send:  HMLANingo2 S:SF82CF445 stat:  00 t:00000000 d:01 r:F82CF445 m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:56.091 0: HMLAN_Send:  HMLANingo2 S:SF82CF4AF stat:  00 t:00000000 d:01 r:F82CF4AF m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:56.597 0: HMLAN_Send:  HMLANingo2 S:SF82CF6A9 stat:  00 t:00000000 d:01 r:F82CF6A9 m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:56.604 0: HMLAN_Parse: HMLANingo2 R:RF82CF370 stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:56.703 0: HMLAN_Send:  HMLANingo2 S:SF82CF713 stat:  00 t:00000000 d:01 r:F82CF713 m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:57.038 0: HMLAN_Parse: HMLANingo2 R:RF82CF445 stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:57.668 0: HMLAN_Parse: HMLANingo2 R:RF82CF6A9 stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:58.204 0: HMLAN_Parse: HMLANingo2 R:RF82CF4AF stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:58.924 0: HMLAN_Parse: HMLANingo2 R:RF82CF713 stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD
2016.05.28 18:22:59.307 0: HMLAN_Parse: HMLANingo2 R:RF82CF3DA stat:0002 t:00000000 d:FF r:7FFF     m:0C 1441 191919 191919 010900000000760AD9AD


hier noch ein list von dem virt. TeamLead:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        19191901
   NAME       RM_TeamDev_Btn1
   NR         1509
   STATE      off
   TESTNR     9
   TYPE       CUL_HM
   chanNo     01
   device     RM_TeamDev
   peerList   Garage_SD2,Charly_Sz_SD2,Buero_SD2,Flur_og_SD2,Flur_eg_SD2,Flur_dg_SD2,
   sdTeam     sdLead
   Readings:
     2016-05-28 18:22:55   aesCBCCounter   00000C
     2016-05-28 18:22:56   eventNo         09
     2016-05-28 18:22:56   level           0
     2016-05-28 17:50:30   peerList        Garage_SD2,Charly_Sz_SD2,Buero_SD2,Flur_og_SD2,Flur_eg_SD2,Flur_dg_SD2,
     2016-05-28 18:22:56   smoke_detect    none
     2016-05-28 18:22:56   state           off
     2016-05-28 18:22:11   teamCall        from RM_TeamDev:08
     2016-05-28 18:10:37   trigger         Long_1
     2016-05-28 18:22:56   trigger_cnt     9
   Helper:
     BNO        1
     BNOCNT     1
     count      1
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
     Shadowreg:
     Tmpl:
Attributes:
   model      virtual_1
   peerIDs    4C6C3701,4C6CBC01,4C6CDE01,4C6CED01,4C6CF901,4C6FB901,
   room       __Geraete,__System
   webCmd     press short:press long


und von einem SD2:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        4C6CF9
   HMLANingo1_MSGCNT 38
   HMLANingo1_RAWMSG E4C6CF9,0000,007D63DC,FF,FFC2,9184004C6CF90000001000AA4E455130343439373233CE000100
   HMLANingo1_RSSI -62
   HMLANingo1_TIME 2016-05-28 18:20:26
   HMLANingo2_MSGCNT 31
   HMLANingo2_RAWMSG E4C6CF9,0000,03FDBF57,FF,FFB1,9184004C6CF90000001000AA4E455130343439373233CE000100
   HMLANingo2_RSSI -79
   HMLANingo2_TIME 2016-05-28 18:20:26
   IODev      HMLANingo1
   LASTInputDev HMLANingo2
   MSGCNT     69
   NAME       Flur_eg_SD2
   NR         1726
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:91 - t:00 s:4C6CF9 d:000000 1000AA4E455130343439373233CE000100
   peerList   RM_TeamDev_Btn1,
   protEvt_AESCom-ok 4 last_at:2016-05-28 17:50:14
   protLastRcv 2016-05-28 18:20:26
   protResnd  1 last_at:2016-05-28 17:50:14
   protSnd    23 last_at:2016-05-28 17:55:34
   protState  CMDs_done
   rssi_HMLANingo1 avg:-47 min:-47 max:-47 lst:-47 cnt:1
   rssi_at_HMLANingo1 avg:-52.39 min:-66 max:-48 lst:-62 cnt:30
   rssi_at_HMLANingo2 avg:-78.78 min:-82 max:-73 lst:-79 cnt:23
   Readings:
     2016-05-28 18:20:26   Activity        alive
     2016-05-28 17:50:14   CommandAccepted yes
     2016-05-28 18:20:26   D-firmware      1.0
     2016-05-28 18:20:26   D-serialNr      NEQ0449723
     2016-05-28 17:55:33   PairedTo        0x355867
     2016-05-28 17:52:26   R-pairCentral   0x355867
     2016-05-28 17:55:33   RegL_00.          02:01 0A:35 0B:58 0C:67 16:00 1F:00 00:00
     2016-05-28 17:50:14   aesCommToDev    ok
     2016-05-28 17:50:14   aesKeyNbr       00
     2016-05-28 17:33:19   alarmTest       ok
     2016-05-28 18:21:25   battery         ok
     2016-05-28 17:33:19   level           0
     2016-05-28 17:55:33   peerList        RM_TeamDev_Btn1,
     2016-05-28 17:33:19   recentStateType info
     2016-05-28 17:55:33   sdRepeat        off
     2016-05-28 17:33:19   smokeChamber    ok
     2016-05-28 18:22:56   smoke_detect    none
     2016-05-28 18:22:56   state           off
     2016-05-28 18:22:11   teamCall        from RM_TeamDev:08
     2016-05-28 18:21:25   trigLast        RM_TeamDev_Btn1:0
     2016-05-28 18:21:25   trig_RM_TeamDev_Btn1 0
   Helper:
     HM_CMDNR   145
     alarmNo    09
     cSnd       013558674C6CF900040000000000,013558674C6CF90103
     mId        00AA
     peerIDsRaw ,19191901,00000000
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4C6CF9,00,02,00
       nextSend   1464452426.71408
       prefIO
       rxt        0
       vccu
       p:
         4C6CF9
         00
         02
         00
     Mrssi:
       mNo        91
       Io:
         HMLANingo1 -60
         HMLANingo2 -79
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       Hmlaningo1:
         avg        -47
         cnt        1
         lst        -47
         max        -47
         min        -47
       At_hmlaningo1:
         avg        -52.4
         cnt        30
         lst        -62
         max        -48
         min        -66
       At_hmlaningo2:
         avg        -78.7826086956522
         cnt        23
         lst        -79
         max        -73
         min        -82
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLANingo1
   IOgrp      vccu:HMLANingo1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,19191901,
   room       CUL_HM
   serialNr   NEQ0449723
   subType    smokeDetector
   webCmd     statusRequest


[mgernoth]

Hallo,

erst mal der TeamCall von einem SD2 aus, mit anschließendem zurücksetzen:

Code Auswählen Erweitern


2016.05.28 18:20:31.778 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FDD211 d:FF r:FFB2     m:08 1441 191919 4C6CF9 01089600000156B59D7C


Die Nachricht ist mit dem Standardkey signiert.

und dann ein teamCall von dem virt.TeamLead aus mit anschließendem alarmOff:

Code Auswählen Erweitern


2016.05.28 18:22:11.048 0: HMLAN_Parse: HMLANingo2 R:E191919   stat:0000 t:03FF5752 d:FF r:FFB4     m:0B 1441 191919 191919 010896000000BC568FC9


Die mit einem unbekannten Schluessel. Ist ein eigener Schluessel aktiv, wurde aber evtl. nicht per assignHmKey auf die SD2 uebertragen?

Viele Gruesse
  Michael

[automatisierer]

Tjo, dass wars... nu läufts!

Danke!!

Hoffe ich hab das nicht im Thread überlesen... hab extra 2x gelesen, bevor ich gepostet hab...
gehört nicht hier her, aber es lässt mir nu keine Ruhe: Warum habe ich das bei anderen Device die auch AES nutzen (z.B. HM-SEC-KEY) nicht machen müssen?

Gruß
Ingo

[mgernoth]

Hi,

gehört nicht hier her, aber es lässt mir nu keine Ruhe: Warum habe ich das bei anderen Device die auch AES nutzen (z.B. HM-SEC-KEY) nicht machen müssen?

Da musst Du es auch machen, es "funktioniert" aber trotzdem, da die Geraete angeben, welchen Schluessel sie benutzen. Die KeyMatic fordert einfach immer Signaturen mit dem Standardschluessel an und HMLAN bzw. Fhem beantwortet die Signaturanfrage passend (siehe aesKeyNbr nach einer Schaltaktion/Configaenderung, wenn da 0 steht, wird der Standardkey verwendet).
Wenn Du einen eigenen Schluessel benutzt, muss dieser per assignHmKey bzw. HM-Software auf das Geraet uebertragen werden.

Viele Gruesse
  Michael

[pataya]

Moin,

klappt alarmOn/Off nun oder ist das seitens EQ3 nicht realisierbar?
Wäre sonst fast dazu geneigt die HM-SEC-SD zu nehmen, allerdings haben die kein Fliegengitter, bzw. AES 

Gruß

[automatisierer]

Moin,

klappt alarmOn/Off nun oder ist das seitens EQ3 nicht realisierbar?
Wäre sonst fast dazu geneigt die HM-SEC-SD zu nehmen, allerdings haben die kein Fliegengitter, bzw. AES 

Gruß

das klappt!

[pataya]

super, dann steht der Bestellung ja nichts im Wege

[Bytechanger]

Hi,

ich würde jetzt gerne auch mal die Geschichte über die FHEM Zentrale testen.
Kann ich über diese "Fremdbefehle" etwas kaputt machen? Habe hier irgendwo gelesen, wenn der Counter falsch steht, werden Feuermeldungen von den anderen Geräten ignoriert?
Welche Gefahren bestehen, bestehen überhaupt welche?
Zumindest TeamCall und AlarmOff wollte ich über die Zentrale nutzbar machen...

AlarmOff um den Alarm generell zu deaktivieren, hab ihn auf einen Taster gelegt, und wenn nun im virtuellen Leader das Reading level > 198 ist, wird alarmOff gesendet....


Zusatzfrage: kann ich meinen eigenen AES-Key übertragen, oder gibt es dann Probleme??

Ich gehe davon aus, dass alle Neuerungen nun im "normalen" Update drin sind, oder muss ich sie mir von der Entwicklungsumgebung/SourceSafe ziehen??


Greets

Byte

[automatisierer]

Hi,

ich würde jetzt gerne auch mal die Geschichte über die FHEM Zentrale testen.
Kann ich über diese "Fremdbefehle" etwas kaputt machen? Habe hier irgendwo gelesen, wenn der Counter falsch steht, werden Feuermeldungen von den anderen Geräten ignoriert?
Welche Gefahren bestehen, bestehen überhaupt welche?

So wie ich das sehe, sind das alte Geschichten, die SD2 sind nun eingebunden und funktionieren.

Zumindest TeamCall und AlarmOff wollte ich über die Zentrale nutzbar machen...

TeamCall und AlarmOff funktionieren.

AlarmOff um den Alarm generell zu deaktivieren, hab ihn auf einen Taster gelegt, und wenn nun im virtuellen Leader das Reading level > 198 ist, wird alarmOff gesendet....

Den SD2 bei einem echten Alarm automatisch abzuschalten, wiederspricht meiner Meinung nach dem eigentlichen Sinn eines Rauchmelders!

Zusatzfrage: kann ich meinen eigenen AES-Key übertragen, oder gibt es dann Probleme??

Du solltest bei HM einen eigenen AES-Key nutzen und nicht den vom Werk aus voreingestellten, der ist ist nämlich quasi der ganzen Welt bekannt und daher relativ sinnlos. Probleme gibt es meines Wissens nach nur, wenn du deinen neuen Schlüssel verlierst - also am besten auch außerhalb von FHEM sichern.

Ich gehe davon aus, dass alle Neuerungen nun im "normalen" Update drin sind, oder muss ich sie mir von der Entwicklungsumgebung/SourceSafe ziehen??

jo, ist normaler Bestandteil von FHEM

[Bytechanger]

Danke für die Antwort.

Bezog die Counterprobleme u.a. auf dieses Post:
https://forum.fhem.de/index.php/topic,35298.msg453091.html#msg453091

Wenn also ein SD resettet wird oder der Leader durch Neustart wieder bei 0 beginnt, werden die Befehle ignoriert!
Das Problem mit dem Counter besteht meines Wissens nach immer noch?! (martinp876) ??

Vielleicht könnte martin876 die noch möglichen Probleme/Risiken darstellen??


Muss ich eigenlich SIGN ON schalten, oder nutzt der SD2 immer den AES Key??

2 Rauchmelder zeigen an, dass sie mit der Zentrale geapairt sind, reagieren auchauf getConfig, aber bei assignAES laufen sie mit ERROR gegen die Wand??
Soll ich sie reseten und neu einbinden??

Code Auswählen Erweitern


Internals:
   CUL0_MSGCNT 3
   CUL0_RAWMSG A0D83A61048F0F81DA46206010000::-59.5:CUL0
   CUL0_RSSI  -59.5
   CUL0_TIME  2016-06-03 12:56:43
   DEF        48F0F8
   HMLAN1_MSGCNT 27
   HMLAN1_RAWMSG R1A13E15F,0001,08EFC219,FF,FFC0,91A01048F0F81DA462011111130100000000
   HMLAN1_RSSI -64
   HMLAN1_TIME 2016-06-04 08:22:38
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     30
   NAME       EG_Buero_RM2
   NR         532
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:91 - t:10 s:48F0F8 d:1DA462 011111130100000000
   peerList   Rauchmelder_Team2,
   protCmdDel 2
   protLastRcv 2016-06-04 08:22:38
   protResnd  1 last_at:2016-06-04 08:23:05
   protResndFail 1 last_at:2016-06-04 08:23:10
   protSnd    5 last_at:2016-06-04 08:23:03
   protState  CMDs_done_Errors:1
   rssi_HMLAN1 cnt:1 lst:-53 min:-53 avg:-53 max:-53
   rssi_at_CUL0 max:-47.5 avg:-51.5 min:-59.5 cnt:3 lst:-59.5
   rssi_at_HMLAN1 lst:-64 cnt:23 min:-69 avg:-62.82 max:-61
   Readings:
     2016-06-02 23:02:40   Activity        alive
     2016-06-04 08:08:34   CommandAccepted yes
     2016-05-12 19:54:56   D-firmware      1.0
     2016-05-12 19:54:56   D-serialNr      NEQ0243833
     2016-06-04 08:22:37   PairedTo        0x1DA462
     2016-05-08 22:44:01   R-pairCentral   0x1DA462
     2016-06-04 08:22:37   RegL_00.          02:01 0A:1D 0B:A4 0C:62 16:00 1F:00 00:00
     2016-06-04 08:08:34   aesCommToDev    ok
     2016-06-04 08:08:34   aesKeyNbr       00
     2016-06-03 12:56:43   alarmTest       ok
     2016-06-03 12:56:43   battery         ok
     2016-06-03 12:56:43   level           0
     2016-06-04 08:22:38   peerList        Rauchmelder_Team2,
     2016-06-03 12:56:43   recentStateType info
     2016-06-04 08:22:37   sdRepeat        off
     2016-06-03 12:56:43   smokeChamber    ok
     2016-06-04 08:23:10   state           MISSING ACK
   Helper:
     HM_CMDNR   146
     cSnd       011DA46248F0F800040000000000,011DA46248F0F80103
     mId        00AA
     peerIDsRaw ,11111301,00000000
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +48F0F8,00,00,00
       nextSend   1465021358.58842
       rxt        0
       vccu       vccu
       p:
         48F0F8
         00
         00
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        91
       Io:
         HMLAN1     -62
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1465021358.50547
       ack:
         HASH(0x37d4208)
         9180021DA46248F0F800
     Rssi:
       Hmlan1:
         avg        -53
         cnt        1
         lst        -53
         max        -53
         min        -53
       At_cul0:
         avg        -51.5
         cnt        3
         lst        -59.5
         max        -47.5
         min        -59.5
       At_hmlan1:
         avg        -62.8260869565217
         cnt        23
         lst        -64
         max        -61
         min        -69
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon off:general_ok *:secur_alarm
   event-on-change-reading .*
   expert     2_raw
   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




Greets

Byte

[automatisierer]

Hast du ein

Code Auswählen Erweitern


set <SD2> assignHmKey

gemacht?

[mgernoth]

Hallo,

Wenn also ein SD resettet wird oder der Leader durch Neustart wieder bei 0 beginnt, werden die Befehle ignoriert!
Das Problem mit dem Counter besteht meines Wissens nach immer noch?! (martinp876) ??

Die SD haben einen 16bit Generationenzähler, der Teil des Counters ist und bei jedem Reboot erhöht wird. Er überlebt auch einen Factory-Reset. Wenn man einen SD allerdings 65536 mal bootet ist wahrscheinlich Schluss.

Viele Grüße
  Michael