HM-SEC-SD-2 neu

[Lix]

Nach ettlichen Versuchen bin ich jetzt endlich weiter gekommen. Für den Fall das jemand ebenfalls Probleme mit der DS und diesem Modul hat ein paar Hinweise.

Möchte man nur die Rauchmelder zum Laufen bekommen, funktioniert das am Besten mit der IPKG Perl Version. Dort klappt auch die Installation des Crypt::Rijndael Moduls.
Leider ist dieser Weg für mich nicht akzeptabel, da mit diesem Perl das DBLog nicht funktioniert. Die dazu benötigten Module lassen sich nicht installieren.

Das DS eigene Perl möchte ich nicht nutzen, da es von der Funktion sehr beschränkt ist und durch ein DSM Update möglicherweise wieder unbrauchbar wird.

Die für mich optimale Variante war bislang ActivePerl. Nur gibt es eben hierbei Probleme mit dem Modul Crypt::Rijndael, dass sich nicht so ohne weiteres installieren lässt.
Grund hierfür dürfte der Unterschied sein, dass das IPKG Perl ohne Threads und das ActivePerl mit der Threads Unterstützung compiliert ist.

Folgende Schritte habe ich ausgeführt bis es endlich geklappt hat.

• 
  ActivePerl herunterladen und per install.sh installieren
  
• 
  Folgende Module per IPKG installiert: ipkg install make gcc coreutils patch
  
• 
  Folgende Symlinks müssen gesetzt werden (und auch nach einem DSM Update wieder erneuert werden)
  cd /lib
  ln -s libm.so.6 libm.so
  ln -s libcrypt.so.1 libcrypt.so
  ln -s libdl.so.2 libdl.so
  cd /opt/i686-linux-gnu/lib
  ln -s /lib/libdl.so.2 libdl.so
  
• 
  Folgende Module per CPAN installiert werden:    Bundle::CPAN    inc::latest     Crypt::Rijndael
  Bei letzterem muss das MAKEFILE editiert werden, da sonst das make test fehlschlägt
  CCFLAGS=-fstack-protector  ==> CCFLAGS=-fno-stack-protector
  

Nachdem ich selbst das Ganze nur nach langem Try and Error Prinzip hinbekommen, bitte mit Vorsicht genießen und sich zunächst ausführlich in die ganze Thematik einlesen und ggf. das System vorher sichern.

[Lix]

Eine kurze Frage hätte ich noch.

Ich lese immer wieder, dass beim Teamcall die Rauchmelder für 10sek leise Piepsen sollen.
Die einzige Reaktion die ich bekomme ist, dass die LED des SD2 eine zeit lang grün blinkt. Aber keine akustische Rückmeldung.
Hat sich hier etwas geändert?

[FFHEM]

Ich lese immer wieder, dass beim Teamcall die Rauchmelder für 10sek leise Piepsen sollen.
Die einzige Reaktion die ich bekomme ist, dass die LED des SD2 eine zeit lang grün blinkt. Aber keine akustische Rückmeldung.
Hat sich hier etwas geändert?

Das Gleiche bei mir mit meinen neuen 3 SD2.

[Christian Uhlmann]

Hallo,

wie auch schon weiter oben mal beschrieben, es handelt sich bei dem TeamCall um den sog. Kommunikationstest. In der Anleitung ist dazu nichts von einem piepen beschrieben sondern nur von einem grünen blinken der LED für ich glaube 5 Minuten. Also alles wohl in Ordnung. Das piepen steht wohl bei dem alten SD dann auch so in der Anleitung.


Grüße Christian

[Lix]

Alles klar, dann gehört das bei den SD2 so.
Bei soviel Frust beim Einrichten hatte ich wohl zuwenig Nerven für die Anleitung übrig.

Danke für die Erklärung.

[Omega]

Du bist nicht der Einzige der mit der Einrichtung kämpft.
Mir ist z.B. einiges mit AES nocht nicht klar.

Rijndael-Perl-Modul ist installiert
attr vccu hmKey geheimerSchluessel wurde zugewiesen
neue Rauchmelder wurden in FHEM angelegt
bis dahin scheinbar alles ok, aber dann, mit
set RM_Werkzeugkeller assignHmKey kam keine Kommunikation mehr zustande.
   aesKeyNbr 00 ist allerdings vorhanden
   aesCommToDev steht auf ok

Das Peering hat dann auch nicht mehr funktioniert (wie auch, wenn keine Rückmeldung kommt).

Dann habe ich die RMs auf den Auslieferungsstand zurückgesetzt, die RMs in FHEM gelöscht, Neustart gemacht und von vorne begonnen.

Ausgelassen habe ich dabei die Anweisung

Code Auswählen Erweitern


set RM_Werkzeugkeller assignHmKey


Dennoch scheint die Kommunikation zu funktionieren (nachdem missing ack endlich verschwunden ist und nach mehreren getConfig). Peering wurde jetzt auch erfolgreich durchgeführt.
Hier noch ein list eines der Rauchmelder

Code Auswählen Erweitern


Internals:
   DEF        4C8157
   HMLAN1_MSGCNT 2
   HMLAN1_RAWMSG R42DA3C48,0001,00362B38,FF,FFD3,03A6104C8157272E570601000024
   HMLAN1_RSSI -45
   HMLAN1_TIME 2016-09-19 16:29:42
   HMLGW_MSGCNT 1
   HMLGW_RAWMSG 0500002103A6104C8157272E570601000024
   HMLGW_RSSI -33
   HMLGW_TIME 2016-09-19 16:29:42
   HMUSB_MSGCNT 1
   HMUSB_RAWMSG E4C8157,0000,48EBC1AD,FF,FFC8,03A6104C8157272E570601000024
   HMUSB_RSSI -56
   HMUSB_TIME 2016-09-19 16:29:42
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     4
   NAME       RM_Werkzeugkeller
   NOTIFYDEV  global
   NR         879
   NTFY_ORDER 50-RM_Werkzeugkeller
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:03 - t:10 s:4C8157 d:272E57 0601000024
   peerList   Rauchmelder_2_Team,
   protCmdDel 3
   protIOerr  1 last_at:2016-09-19 15:29:51
   protLastRcv 2016-09-19 16:29:42
   protResnd  1 last_at:2016-09-19 15:59:20
   protResndFail 1 last_at:2016-09-19 15:59:25
   protSnd    3 last_at:2016-09-19 16:29:42
   protState  CMDs_done
   rssi_HMLAN1 avg:-36 min:-36 max:-36 lst:-36 cnt:1
   rssi_at_HMLAN1 avg:-45 min:-45 max:-45 lst:-45 cnt:2
   rssi_at_HMLGW avg:-33 min:-33 max:-33 lst:-33 cnt:1
   rssi_at_HMUSB avg:-56 min:-56 max:-56 lst:-56 cnt:1
   Readings:
     2016-09-19 15:27:55   Activity        alive
     2016-09-19 14:39:15   CommandAccepted yes
     2016-09-19 14:33:31   D-firmware      1.0
     2016-09-19 14:33:31   D-serialNr      NEQ0446516
     2016-09-19 14:39:16   PairedTo        0x272E57
     2016-09-19 14:33:33   R-devRepeatCntMax 0
     2016-09-19 14:33:33   R-pairCentral   0x272E57
     2016-09-19 14:39:16   RegL_00.        02:01 0A:27 0B:2E 0C:57 16:00 1F:00 00:00
     2016-09-19 14:39:15   aesCommToDev    ok
     2016-09-19 14:39:15   aesKeyNbr       00
     2016-09-19 16:29:42   alarmTest       ok
     2016-09-19 16:29:42   battery         ok
     2016-09-19 16:29:42   level           0
     2016-09-19 15:27:55   peerList        Rauchmelder_2_Team,
     2016-09-19 16:29:42   recentStateType info
     2016-09-19 14:39:16   sdRepeat        off
     2016-09-19 16:29:42   smokeChamber    ok
     2016-09-19 16:29:42   state           off
   Helper:
     HM_CMDNR   3
     cSnd       01272E574C8157010E,01272E574C8157010E
     mId        00AA
     rxType     6
     Ack:
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Io:
       newChn     +4C8157,00,01,00
       nextSend   1474295382.63707
       rxt        0
       vccu       vccu
       p:
         4C8157
         00
         01
         00
     Mrssi:
       mNo        03
       Io:
         HMLAN1     -43
         HMLGW      -33
         HMUSB      -56
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLGW
       flg        A
       ts         1474295382.44559
       ack:
         HASH(0x308e028)
         038002272E574C815700
     Rssi:
       Hmlan1:
         avg        -36
         cnt        1
         lst        -36
         max        -36
         min        -36
       At_hmlan1:
         avg        -45
         cnt        2
         lst        -45
         max        -45
         min        -45
       At_hmlgw:
         avg        -33
         cnt        1
         lst        -33
         max        -33
         min        -33
       At_hmusb:
         avg        -56
         cnt        1
         lst        -56
         max        -56
         min        -56
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon off:general_ok *:secur_alarm
   expert     251_anything
   firmware   1.0
   icon       secur_smoke_detector
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,11000201,
   room       Rauchmelder
   serialNr   NEQ0446516
   subType    smokeDetector
   webCmd     statusRequest


Irgendwelche Tests werde ich jetzt (Uhrzeitbedingt) jetzt nicht mehr durchführen.

Meine eigentlichen Fragen betrifft die AES-Kommunikation:
-   Besteht überhaupt eine AES-Kommunikation?
-   Mit welchem Schlüssel? Meiner oder HM-Standard?
-   Oder bleibt der Schlüssel im RM erhalten trotz Rücksetzen auf den Werkszustand?

Falls schon einer eine Lösung für die Kopplung zweier Rauchmelder_Teams hat – bitte einstellen.

Danke
Holger

[Edi77]

Ich beschäftige mich auch gerade mit dem Thema Rauchmelder.

Ich hatte schon mal einen HM-SEC-SD den ich aber wegen zu vieler Fehlalarme wider stillgelegt habe.
Gibt es beim HM-SEC-SD-2 auch viele Fehlalarme?
Den HM-SEC-SD konnte ich noch mit meinem CUNO ohne AES einfach die Statussignal empfangen, geht das mit dem HM-SEC-SD-2 auch noch? Oder benötige ich dann ein HMLAN?

[xsasx]

Hey, auf welchem Betriebssystem sollen bei dir die SD2 laufen? Ich nutze auch den HMLAN mit FHEM und zumindest das Einbinden funktioniert problemlos.

FHEM Läuft in einer VM unter Ubuntu- sollte ja aber keine Rolle Spielen auf welchem OS Fhem läuft oder ?

[Lix]

FHEM Läuft in einer VM unter Ubuntu- sollte ja aber keine Rolle Spielen auf welchem OS Fhem läuft oder ?

Meine Frage zielte eher auf paralellitäten bei der Einrichtung ab. Aber zumindest sollten dich dann nicht die Perl Probleme in Verbindung mit Synology belasten 

[Lix]

Ich bin mir nicht 100%ig sicher, aber soweit ich den Hilfeseiten entnehmen konnte:

• - empfangen die SD2 ausschließlich AES verschlüsselte Befehle. (Alarm on/off teamcall) und das unterstützen derzeit HMLAN und CUL
• - der System Sicherheits KEY kann durch einen Werksreset nicht gelöscht werden.
• - es wird die höchste Version des in der VCCU eingetragenen Schlüssels verwendet. wenn du einen Befehl an den SD2 schicken kannst und
    dieser ausgeführt wird, dann hat dein erster Schlüsselaustausch funktioniert
• - ich hatte beim 1. Anlernen auch das Problem mit MISSING ACK nach getConfig beim 2. Mal nach Reset hats dann aber geklappt

[Omega]

dann müsste theoretisch bzgl. AES eigentlich alles ok sein.
Ein Teamcall bringt allerdings folgende Meldung im Log:

Code Auswählen Erweitern

2016.09.20 15:46:21 3: CUL_HM set Rauchmelder_2_Team teamCall
2016.09.20 15:46:21 1: Adding peer 110002 failed! You have probably forced an unknown aesKey for this device.
Schade, dass die Meldung nicht sagt, welches "this device" denn ist. Hab' ja mehrere. Und lt. den Peerings (und hm configCheck) ist auch alles ok.

Ich versuche jetzt erst noch einmal, den aesKey erneut zuzuweisen. Mal sehen, mit welchem Erfolg.

Nachtrag:
Ein erneutes set <rm> assignHmKey bei allen RM ging diesmal problemlos über die Bühne. Auch der Teamcall und Alarm (meine Ohren klingeln jetzt noch, da alle 3 SD quasi neben mir liegen) funktionieren jetzt.

Fehlt jetzt nur noch die Verbindung zwischen beiden Teams. So langsam bekomme ich meine FHEM-Probleme wieder in den Griff.

LG
Holger

[Edi77]

Wenn ich das richtig verstehe müsste ich dann entweder einen zusätzlichen CUL/CUNO betreiben der im HM Modus läuft und die AES Verschlüsselung läuft dann über Linux, oder ich nehme den HMUSB oder HMLAN der dann die AES Verschlüsselung übernimmt?

[Joker]

Was nimmt man am besten nun da es den HMLAN ja nicht mehr offiziell gibt?

Der HMUARTLGW kann mit den neuen Rauchmeldern ja nicht reden oder?

[Edi77]

Hallo,

Habe noch mal etwas gelesen.
Wenn ich das richtig verstanden habe muss ich trotz HM-LAN AES auf dem FHEM System installieren.
Also könnte ich auch einen RPi1 als FHEM Slave mit einem HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi versehen und hätte somit eine Verbindung zur HomeMatic.
Natürlich muss dort dann auch AES installiert werden, allerdings ist das HM-MOD-RPI-PCB noch käuflich zu erwerben.
Oder habe ich da was falsch verstanden?

[martinp876]

Warum geht ein lgw nicht mit sds? Um aes der tramcalls usw. zu betreiben muss fhem aes rechnen, unabhaengig von io.
Hmlan unterstützt aes fuer "normale" kommunikation.das trifft hier eh nicht zu. Wo ist der knackpunkt?