HM-SEC-SD Rauchmelder: Unterschied zwischen den Versionen

Aus FHEMWiki
(Infobox und Bild eingefügt)
K (Link auf HMInfo angepasst)
 
(41 dazwischenliegende Versionen von 15 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite
|HWProtocol=HomeMatic
|HWProtocol=HomeMatic
|HWType=Aktor
|HWType=[[HomeMatic Type smokeDetector|smokeDetector]]
|HWCategory=HomeMatic
|HWCategory=HomeMatic
|HWComm=868MHz
|HWComm=868MHz
Zeile 15: Zeile 15:
}}
}}
== Features ==
== Features ==
Das Gerät ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter.
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD]] ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter.  
 
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD-2]] (ca. 50€) ist die neue Version seit 2016. Auch dieser Melder wird in FHEM unterstützt. ''Das Gerät kann ausschließlich in Gruppen mit Rauchwarnmeldern des gleichen Typs (HM-Sec-SD-2) und nicht in einer Gruppe mit anderen Rauchwarnmeldern (z. B. HM-Sec-SD) genutzt werden.''<ref>[http://www.eq-3.de/produkte/homematic/sicherheit-und-ueberwachung/homematic-funk-rauchwarnmelder-293.html#beschreibung "Highlights" bei der Produktbeschreibung auf der EQ3-Site]</ref>
 
 
[[Datei: HM-SEC-SD-2.jpg|300px|thumb|right|HM-SEC-SD-2]]


== Hinweise zum Betrieb mit FHEM ==
== Hinweise zum Betrieb mit FHEM ==
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit <u>[[HMLAN Konfigurator]]</u> oder mit <u>[[CUL]]</u> möglich.
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit [[HMLAN Konfigurator]] oder mit [[CUL]] möglich. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.
Das Pairing sollte wie in <u>[[HomeMatic Devices pairen]]</u> beschrieben durchgeführt werden.


===Teams===
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!
Rauchmelder können/sollen in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst Teamen.
 
=== Teams ===
Rauchmelder können mittels [[Peering (HomeMatic)|Peering]] in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst peeren.


Beispiele:
Beispiele:
nutzt man einen SD und will diese nicht mit anderen in einem team haben peert man ihm mit sich selbst. Damit ist der SD sein eigener teamLead.  
nutzt man einen SD und will diesen nicht mit anderen in einem Team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead.  
<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code>.
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code>
 
Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden.
<pre>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor </pre>
 
Nutzt man einen virtuellen TeamLead - (siehe [[#Virtueller_TeamLead|virtueller TeamLead]]) - werden alle realen SDs mit diesem gepeert
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor
</pre>
 
Ein SD kann aus einem Team mittels unset entfernt werden.
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor </code>
 
Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit ''unset'' aus dem Team entfernen, dann mit ''set'' in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt.
 
Die korrekte Gruppierung sollte nach der Konfiguration durch einen Teamcall geprüft werden.
 
Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.
 
=== TeamLead ===
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu [[#virtueller TeamLead|virtueller TeamLead]].


Hat man mehrere SDs, die in einem Team zusammenfassen will wird der teamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden.  
Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst peeren.
<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor
 
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor
=== Kommandos ===
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor
Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen Teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor
 
...
Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.
</code>.


Nutzt man einen virtuellen TeamLead - siehe Kapitel - werden alle realen SDs mit diesem gepeert
Die Kommandos können von der Zentrale getriggert werden. Da sie unter der Team-ID gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.
<code>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor
...
</code>.
entfernen eines SDs aus dem team geht mit unset. Um einen SD von einem Team in ein anderes zu transferieren muss man ihn erst mit unset aus dem Team entfernen, dann mit set in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen team-mitgliedern entfernt.  


Die korrekte Gruppierung sollte nach der Konfiguration durch einen teamCall geprüft werden. <br>
Dazu gehören teamCall, teamCallBat, alarmOn und alarmOff.
Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen muss man ihn erste aus dem ersten Team entfernen (unset) und dann in das Neue aufnehmen.


===TeamLead===
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs.
Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuelen SD als teamLead  nutzen. Siehe hierzu virtual TeamLead.<br>
Nutzt man nur einen einzelnen SD sollte man diesen mit sich selbst teamen.
===Kommandos===
Es gibt Team-Nachrichten die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf. <br>
Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können. <br>
Die Kommandos können von der Zentrale getriggert werden. Da sie unter der TeamId gesendet werden stehen sie nur bei der Komponente des Teamleads zu Verfügung.<br>
Dazu gehören teamCall, alarmOn und alarmOff. <br>
Sie stehen nur für die Entity des TeamLeads zu Verfügung.
Sie stehen nur für die Entity des TeamLeads zu Verfügung.
<pre>set EurerTeamLeader alarmOn
set EurerTeamLeader alarmOff
set EurerTeamLeader teamCall
set EurerTeamLeader teamCallBat ## nur für alte SDs
</pre>
'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen. '''teamCallBat''' erzeugt einen kürzeren Teamcall mit anderer Signalfolge, wie er bei schwacher Batterie eines Melders automatisch ausgelöst wird.


  <code>set EurerTeamleader alarmOn
Einzelne SDs kann man mit "statusRequest" abfragen.
  set EurerTeamleader alarmOff
  set EurerTeamleader teamCall</code>


'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen.
== Virtueller TeamLead ==
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine Team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine Team-ID verloren.


Einzelne SDs kann man mit "statusRequest" abfragen.
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als Lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine bessere Struktur, da dieser virtuelle Aktor nicht verloren gehen kann.
 
Erzeugen eines virtuellen TeamLeads könnte so aussehen. Es wird ein virtuelles Gerät und ein virtueller Kanal definiert und mit einem sprechenden Namen versehen. Dieser Code ist z.B. für die Raw Definition:
{{Randnotiz|RNText=Bitte beachten
die HMID (Beispiel 111111) '''muss''' für das gesamte System einmalig sein und es darf '''nur''' Btn1 (HM Channel ID xxxxxx01) als TeamLead verwendet werden!
Insbesondere darf bei der Definition eines neuen virtuellen Devices '''nicht''' die HMID der [[Virtueller Controller VCCU|VCCU]] oder eines IO verwendet werden. Man '''kann''' aber anstatt eines virtuellen Gerätes auch den '''ersten''' Kanal einer VCCU verwenden, falls der noch nicht anderweitig genutzt wird (nicht empfohlen).
 
}}
<pre>define TeamDev CUL_HM <sechstellige selbstgewählte einmalige hmId>
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team</pre>
 
Nach der Definition bitte '''unbedingt''' überprüfen, dass TeamDev das Attribut ('''attr''') '''IODev''' bzw. '''IOgrp''' gesetzt hat! (das sollte normalerweise automatisch passieren)


==virtueller TeamLead==
Fehlt IODev (und bei Arbeit mit einer VCCU IOgrp) muss man dieses Attribut per Hand setzen, den richtigen Syntax/Inhalt findet man bei einem funktionierenden Homematic Gerät.
Nutzt man einen SD kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen Teamlead um eine team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt hat man allerdings seine team-ID verloren.<br>
Wenn man mit Zentrale (FHEM) arbeitet gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams) einen der SDs als lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine sauberere Struktur.<br>
Erzeugen eines virtuellen TeamLeads könnte so aussehen:


<code>define TeamDev CUL_HM 111111
Am Besten die Konfiguration mit HMInfo '''configCheck''' prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team</code>


Bitte beachten: '''die HMID muss für die gesamte Installation einmalig sein'''.<br>
Anschließend muss man noch einen Homematic-Kanal für das Peering definieren.<br>
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor
...
save</pre>
Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.
Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der [[Konfiguration]] zu sichern.


<code>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set
Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set
...
save</code>


Hierbei ist "Rauchmelder_Team" der Name des virtuellen Teamleaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders. <br>
Das "save" ist notwendig um auch die Einstellungen des virtuellen SDs im Config file zu sichern. <br>
Bei jedem Rauchmelder sollte den Name des virtuellen Teamleaders in der peerList stehen und beim virtuellen Teamleader jeder Rauchmelder.<br>
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.


==Variablen==
== Variablen ==
===Internals===
=== Internals ===
keine Spezifischen
Keine Spezifischen.
===Readings===
 
=== Readings ===
==== Einzelne SDs ====
Für '''jeden''' SD sind folgende Readings relevant:
Für '''jeden''' SD sind folgende Readings relevant:
   teamCall from <name>:<count>
   teamCall from <name>:<count>
   state:[off|smoke-Alarm_<count>]
   state:[off|smoke-Alarm_<count>]
Zeile 100: Zeile 129:
   battery:[ok|low]
   battery:[ok|low]
   level:<0..200>
   level:<0..200>
*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterschieden zu können
  sdRepeat:[on|off]
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.
 
*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.
*'''sdRepeat''' ist ein Flag ob der SD als Reapeater für Nachrichten anderer SDs arbeitet. Das kann nötig sein, wenn nicht jeder SD jeden anderen empfängt. Das Flag kann über die Taste am SD eingestellt werden (siehe Gebrauchsanleitung). Es dürfen maximal 3 SDs in einer Gruppe als Reapeater konfiguriert sein. Ansonsten kann es zu verzögerten Alarmmeldungen kommen.
 
==== TeamLead ====
Beim '''TeamLead''' laufen alle Alarme auf:


Beim '''Teamlead''' laufen alle Alarme auf
   teamCall: from <name>:<count>
   teamCall: from <name>:<count>
   recentAlarm:<von_name>
   recentAlarm:<von_name>
Zeile 111: Zeile 145:
   smoke_detect:<von_name>
   smoke_detect:<von_name>
   SDteam:[add_<name>|remove_<name>]
   SDteam:[add_<name>|remove_<name>]
*'''von_name''' ist der Name des SD, der gemeldet hat.  
*'''von_name''' ist der Name des SD, der gemeldet hat.  
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.


===Attribute===
=== Attribute ===
besondere Attribute
Besondere Attribute
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms.  
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-Kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms.  
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.
* '''msgRepeat'''  1
* '''msgRepeat'''  1
Allgemein vorgeschlagen
Allgemein vorgeschlagen
'''IODev''' [HMLAN/HMUSB/CUL]
:'''IODev''' [HMLAN/HMUSB/CUL]
'''autoReadReg''' 5_readMissing
:'''autoReadReg''' 5_readMissing
'''event-on-change-reading''' .*
:'''event-on-change-reading''' .*
Optional, nur als Anregung zu verstehen
Optional, nur als Anregung zu verstehen
  '''devStateIcon off''' general_ok *:secur_alarm
:'''devStateIcon''' off:general_ok .*:secur_alarm
  '''group''' smokeDetect
:'''group''' smokeDetect
  '''icon''' secur_smoke_detector
:'''icon''' secur_smoke_detector
Ebenfalls optional, jedoch nützlich für Homebridge-/Homekit-Anbindung:
:'''genericDeviceType''' security


==Alarme==
== Alarme ==
Meldet ein SD einen Alarm wird dieser in dem SD und im TeamLead angezeigt.<br>
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.
Nutzt man HMIinfo wird ein Rauchalarm auch hier als "Error" gemeldet. In HMInfo wird dies für alle SD-teams im System gemacht.
 
Nutzt man [[HMInfo]], wird ein Rauchalarm auch hier als "Error" gemeldet. In HMInfo wird dies für alle SD-Teams im System gemacht.
 
== Probleme beim SD-2 ==
Das Senden von TeamCall-/Alarmkommandos an die SD2 ist leider fragil. Bei jedem Befehl muss entweder der MessageCounter der Nachricht größer sein als der letzte oder (falls dies nicht der Fall ist) der Generationenzähler inkrementiert werden. Beide Werte werden in dem Reading aesCBCCounter des Teamleads abgelegt:
 
<pre>
aesCBCCounter  GGGGMM
</pre>
 
Hierbei ist GGGG der Generationenzähler in Hex und MM der Messagecounter in Hex. Sollte dieses Reading gelöscht werden, reagieren die SD2 nicht mehr, da sie denken, eine alte Nachricht empfangen zu haben. Leider kann man die aktuellen Werte auch nicht mehr aus den SD2 auslesen...
 
Falls die SD2 also nicht mehr reagieren, kann man mal probieren den Generationenzähler per Hand zu inkrementieren und den MessageCounter auf 0 zu setzen (aesCBCCounter hier vorher 0000XX):
 
<pre>
setreading TeamLead aesCBCCounter 000100
</pre>
 
Falls das Reading komplett gelöscht wurde, bitte langsam rantasten und den Generationenzähler immer nur um 1 erhöhen, denn was passiert, wenn der Generationencounter nach FFFF überläuft hat bisher noch niemand ausprobiert...


== Nützliche Notifies ==
== Nützliche Notifies ==
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein.  
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein.  
* Bei Alarm email schicken und Licht im Flur anschalten
* Bei Alarm E-Mail schicken und Licht im Flur anschalten
   define sd.nf.report notify sdTeam:.*smoke-Alarm.* {\
<pre>
   define sd.nf.report notify Rauchmelder_Team:.*smoke-Alarm.* {\
     <Mail versenden>;;
     <Mail versenden>;;
     fhem("set LichtTreppenhaus on");;
     fhem("set LichtTreppenhaus on");;
   }\
   }\
</pre>


* Bei Alarm alle SDs des Team stumm schalten durch stumm Schalten eines einzelnen
* Bei Alarm alle SDs des Teams stumm schalten durch Stummschalten eines einzelnen
  define sd.nf.quiet notify sdTeam:.*level:.199 set sdTeam alarmOff
:<code>define sd.nf.quiet notify Rauchmelder_Team:.*level:.199 set Rauchmelder_Team alarmOff</code>


== Links ==
== Links ==
Anleitung [http://www.eq-3.de/Downloads/eq3/pdf_produkte/83454_HM-Sec-SD_GE_V1.4_20131011.pdf] PDF
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD_GE_UM_V1.5_150407.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf Montage- und  Inbetriebnahmeanleitung HM-SEC-SD-2 (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/pdb/Funk-Rauchwarnmelder_131408_Produktdatenblatt_V1.7.pdf Produktdatenblatt HM-SEC-SD-2 (PDF)]
 
== Quellen ==
<references />


[[Kategorie:HomeMatic Components]]
[[Kategorie:HomeMatic Components]]
[[Kategorie:Rauchmelder]]
[[Kategorie:Rauchmelder]]

Aktuelle Version vom 3. Dezember 2021, 12:04 Uhr

HM-SEC-SD Rauchmelder
HomeMatic HM-SEC-SD Rauchmelder Oberseite
Allgemein
Protokoll HomeMatic
Typ smokeDetector
Kategorie HomeMatic
Technische Details
Kommunikation 868MHz
Kanäle
Betriebsspannung 9V
Leistungsaufnahme W im Standby
Versorgung 3 x 1,5 V LR6/AA
Abmessungen 120x44mm
Sonstiges
Modulname CUL_HM
Hersteller ELV / eQ-3

Features

Der HM-SEC-SD ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter.

Der HM-SEC-SD-2 (ca. 50€) ist die neue Version seit 2016. Auch dieser Melder wird in FHEM unterstützt. Das Gerät kann ausschließlich in Gruppen mit Rauchwarnmeldern des gleichen Typs (HM-Sec-SD-2) und nicht in einer Gruppe mit anderen Rauchwarnmeldern (z. B. HM-Sec-SD) genutzt werden.[1]


HM-SEC-SD-2

Hinweise zum Betrieb mit FHEM

Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit HMLAN Konfigurator oder mit CUL möglich. Das Pairing sollte wie in HomeMatic Devices pairen beschrieben durchgeführt werden.

Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!

Teams

Rauchmelder können mittels Peering in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst peeren.

Beispiele: nutzt man einen SD und will diesen nicht mit anderen in einem Team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead.

set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor

Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden.

set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor 
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor 
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor 
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor 

Nutzt man einen virtuellen TeamLead - (siehe virtueller TeamLead) - werden alle realen SDs mit diesem gepeert

set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor

Ein SD kann aus einem Team mittels unset entfernt werden.

set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor

Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit unset aus dem Team entfernen, dann mit set in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt.

Die korrekte Gruppierung sollte nach der Konfiguration durch einen Teamcall geprüft werden.

Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.

TeamLead

Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu virtueller TeamLead.

Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst peeren.

Kommandos

Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen Teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden nicht von einem SD zum anderen weitergereicht. Auch der TeamLead hat keine Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.

Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.

Die Kommandos können von der Zentrale getriggert werden. Da sie unter der Team-ID gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.

Dazu gehören teamCall, teamCallBat, alarmOn und alarmOff.

Sie stehen nur für die Entity des TeamLeads zu Verfügung.

set EurerTeamLeader alarmOn
set EurerTeamLeader alarmOff
set EurerTeamLeader teamCall
set EurerTeamLeader teamCallBat ## nur für alte SDs 

teamCall testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen. teamCallBat erzeugt einen kürzeren Teamcall mit anderer Signalfolge, wie er bei schwacher Batterie eines Melders automatisch ausgelöst wird.

Einzelne SDs kann man mit "statusRequest" abfragen.

Virtueller TeamLead

Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine Team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine Team-ID verloren.

Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als Lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine bessere Struktur, da dieser virtuelle Aktor nicht verloren gehen kann.

Erzeugen eines virtuellen TeamLeads könnte so aussehen. Es wird ein virtuelles Gerät und ein virtueller Kanal definiert und mit einem sprechenden Namen versehen. Dieser Code ist z.B. für die Raw Definition:

Info green.pngBitte beachten

die HMID (Beispiel 111111) muss für das gesamte System einmalig sein und es darf nur Btn1 (HM Channel ID xxxxxx01) als TeamLead verwendet werden!

Insbesondere darf bei der Definition eines neuen virtuellen Devices nicht die HMID der VCCU oder eines IO verwendet werden. Man kann aber anstatt eines virtuellen Gerätes auch den ersten Kanal einer VCCU verwenden, falls der noch nicht anderweitig genutzt wird (nicht empfohlen).
define TeamDev CUL_HM <sechstellige selbstgewählte einmalige hmId> 
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team

Nach der Definition bitte unbedingt überprüfen, dass TeamDev das Attribut (attr) IODev bzw. IOgrp gesetzt hat! (das sollte normalerweise automatisch passieren)

Fehlt IODev (und bei Arbeit mit einer VCCU IOgrp) muss man dieses Attribut per Hand setzen, den richtigen Syntax/Inhalt findet man bei einem funktionierenden Homematic Gerät.

Am Besten die Konfiguration mit HMInfo configCheck prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.

Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:

set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor
 ...
save

Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.

Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der Konfiguration zu sichern.

Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.

Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.

Variablen

Internals

Keine Spezifischen.

Readings

Einzelne SDs

Für jeden SD sind folgende Readings relevant:

 teamCall from <name>:<count>
 state:[off|smoke-Alarm_<count>]
 smoke_detect:<von_name>
 battery:[ok|low]
 level:<0..200>
 sdRepeat:[on|off]
  • count ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können
  • level ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.
  • sdRepeat ist ein Flag ob der SD als Reapeater für Nachrichten anderer SDs arbeitet. Das kann nötig sein, wenn nicht jeder SD jeden anderen empfängt. Das Flag kann über die Taste am SD eingestellt werden (siehe Gebrauchsanleitung). Es dürfen maximal 3 SDs in einer Gruppe als Reapeater konfiguriert sein. Ansonsten kann es zu verzögerten Alarmmeldungen kommen.

TeamLead

Beim TeamLead laufen alle Alarme auf:

 teamCall: from <name>:<count>
 recentAlarm:<von_name>
 level:<0..200>
 eventNo:<count>
 state:[off|smoke-Alarm_<count>]
 smoke_detect:<von_name>
 SDteam:[add_<name>|remove_<name>]
  • von_name ist der Name des SD, der gemeldet hat.
  • smoke_detect ist der aktuelle Alarm, während recentAlarm die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.
  • SDteam kommt gelegentlich bei Konfigurationsereignissen zum Tragen.

Attribute

Besondere Attribute

  • msgRepeat sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-Kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms.
  • actCycle wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.
  • msgRepeat 1

Allgemein vorgeschlagen

IODev [HMLAN/HMUSB/CUL]
autoReadReg 5_readMissing
event-on-change-reading .*

Optional, nur als Anregung zu verstehen

devStateIcon off:general_ok .*:secur_alarm
group smokeDetect
icon secur_smoke_detector

Ebenfalls optional, jedoch nützlich für Homebridge-/Homekit-Anbindung:

genericDeviceType security

Alarme

Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.

Nutzt man HMInfo, wird ein Rauchalarm auch hier als "Error" gemeldet. In HMInfo wird dies für alle SD-Teams im System gemacht.

Probleme beim SD-2

Das Senden von TeamCall-/Alarmkommandos an die SD2 ist leider fragil. Bei jedem Befehl muss entweder der MessageCounter der Nachricht größer sein als der letzte oder (falls dies nicht der Fall ist) der Generationenzähler inkrementiert werden. Beide Werte werden in dem Reading aesCBCCounter des Teamleads abgelegt:

aesCBCCounter   GGGGMM

Hierbei ist GGGG der Generationenzähler in Hex und MM der Messagecounter in Hex. Sollte dieses Reading gelöscht werden, reagieren die SD2 nicht mehr, da sie denken, eine alte Nachricht empfangen zu haben. Leider kann man die aktuellen Werte auch nicht mehr aus den SD2 auslesen...

Falls die SD2 also nicht mehr reagieren, kann man mal probieren den Generationenzähler per Hand zu inkrementieren und den MessageCounter auf 0 zu setzen (aesCBCCounter hier vorher 0000XX):

setreading TeamLead aesCBCCounter 000100

Falls das Reading komplett gelöscht wurde, bitte langsam rantasten und den Generationenzähler immer nur um 1 erhöhen, denn was passiert, wenn der Generationencounter nach FFFF überläuft hat bisher noch niemand ausprobiert...

Nützliche Notifies

Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein.

  • Bei Alarm E-Mail schicken und Licht im Flur anschalten
  define sd.nf.report notify Rauchmelder_Team:.*smoke-Alarm.* {\
    <Mail versenden>;;
    fhem("set LichtTreppenhaus on");;
  }\
  • Bei Alarm alle SDs des Teams stumm schalten durch Stummschalten eines einzelnen
define sd.nf.quiet notify Rauchmelder_Team:.*level:.199 set Rauchmelder_Team alarmOff

Links

Quellen