HM-SEC-SD Rauchmelder: Unterschied zwischen den Versionen

Aus FHEMWiki
Keine Bearbeitungszusammenfassung
Zeile 3: Zeile 3:


== Hinweise zum Betrieb mit FHEM ==
== Hinweise zum Betrieb mit FHEM ==
Der HM-SEC-SD Rauchmelder beherrscht die AES authentifizierte Kommunikation. Allerdings ist die Steuerung bei aktivierter [[AES Encryption]] nur zusammen mit dem [[HMLAN Konfigurator]] möglich. Der normale Betrieb, also das Melden von Rauchalarm, ist aber natürlich auch über [[CUL]] möglich.
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit <u>[[HMLAN Konfigurator]]</u> oder mit <u>[[CUL]]</u> möglich.
Das Pairing sollte wie in <u>[[HomeMatic Devices pairen]]</u> beschrieben durchgeführt werden.


Ein Druck auf die Prüftaste führt zu keiner Funkmeldung.  
===Teams===
Ein Test des Alarms kann über den Befehl
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.
Um einen SD in ein Team aufzunehmen nutzt man das Kommando peerChan
<code>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set</code>.
Siehe auch TeamLead.<br>
Die korrekte Gruppierung sollte nach der Konfiguration durch einen teamCall geprüft werden. <br>
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.


<code>set EurerTeamleader alarmOn</code>
  <code>set EurerTeamleader alarmOn
  set EurerTeamleader alarmOff
  set EurerTeamleader teamCall</code>


am Teamlead erreicht werden und mit
'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen.


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


wieder deaktiviert werden. Per
==virtueller TeamLead==
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>set EurerTeamleader teamCall</code>
<code>define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn_1 Rauchmelder_Team</code>


kann die Funkvernetzung der Rauchmelder getestet werden. Alle Rauchmelder sollten 10 mal leise piepen.
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:


An den einzelnen Rauchmeldern kann als Befehl nur "statusRequest" ausgeführt werden.
<code>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set
...
save</code>.


Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Es gibt bei den Rauchmeldern 2 Varianten betreffend des Pairings und des Peerings:
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>
=== Variante 1: einer der Rauchmelder fungiert als Teamleader ===
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mir alarmOn.
Vorteil: Der Alarm eines Rauchmelders wird auch dann an andere Rauchmelder weiter gegeben, wenn FHEM nicht aktiv ist.  
==Attribute==
 
besondere Attribute
Nachteil: Es kann nicht jeder einzelne Rauchmelder von FHEM aus manuell an- und abgeschaltet werden, dies übernimmt der ''Teamleader''.
* '''msgRepeat''' sollte auf 01 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 Tag ebei der Zentrale, was der ActionDetector prüft.
Hier sind zunächst die Rauchmelder laut der Homematic-Anleitung untereinander anzulernen (miteinander vernetzt = Peering). Ein Rauchmelder in der Gruppe (der erste, bei dem die Anlerntaste gedrückt wurde) fungiert dabei als ''Teamleader'' und wird in dem Attribut peerIDs gelistet.  
* '''msgRepeat''' 1
 
Allgemein vorgeschlagen
Beispiel für die Konfiguration einer Dreiergruppe, bei welcher TH.SD0 der ''Teamleader'' ist:
  '''IODev''' [HMLAN/HMUSB/CUL]
*ssssss, tttttt, uuuuuu -&gt; 6-stellige hexadezimale Seriennummern. (Siehe Logfile: CUL_HM Unknown device CUL_HM_SD_ssssss, please define it)
  '''autoReadReg''' 5_readMissing
*xxxxxxx, yyyyyyy, zzzzzzz -&gt; 10-stellige Seriennummern (vom Aufkleber auf dem Gerät)
  '''event-on-change-reading''' .*
 
Optional, nur als Anregung zu verstehen
define TH.SD0 CUL_HM ssssss
  '''devStateIcon off''' general_ok *:secur_alarm
attr TH.SD0 .devInfo 000100
  '''group''' smokeDetect
attr TH.SD0 .stc CD
  '''icon''' secur_smoke_detector
attr TH.SD0 actCycle 028:00
==Alarme==
attr TH.SD0 actStatus unknown
Meldet ein SD einen Alarm wird dieser in dem SD und im TeamLead angezeigt.<br>
attr TH.SD0 autoReadReg 4_reqStatus
Nutzt man HMIinfo wird ein Rauchalarm auch hier als "Error" gemeldet. In HMInfo wird dies für alle SD-teams im System gemacht.
attr TH.SD0 expert 2_full
attr TH.SD0 firmware 1.0
attr TH.SD0 model HM-SEC-SD
attr TH.SD0 msgRepeat 1
attr TH.SD0 peerIDs 00000000,ssssss,
attr TH.SD0 room Alarm
attr TH.SD0 serialNr xxxxxxxxxx
attr TH.SD0 subType smokeDetector
attr TH.SD0 webCmd test:alarmOn:alarmOff
 
define TH.SD1 CUL_HM tttttt
attr TH.SD1 .devInfo 000100
attr TH.SD1 .stc CD
attr TH.SD1 actCycle 028:00
attr TH.SD1 actStatus unknown
attr TH.SD1 autoReadReg 4_reqStatus
attr TH.SD1 expert 2_full
attr TH.SD1 firmware 1.0
attr TH.SD1 model HM-SEC-SD
attr TH.SD1 msgRepeat 1
attr TH.SD1 peerIDs 00000000,ssssss,
attr TH.SD1 room Alarm
  attr TH.SD1 serialNr yyyyyyyyyy
attr TH.SD1 subType smokeDetector
  attr TH.SD1 webCmd test
 
  define TH.SD2 CUL_HM uuuuuu
attr TH.SD2 .devInfo 000100
attr TH.SD2 .stc CD
attr TH.SD2 actCycle 028:00
attr TH.SD2 actStatus unknown
attr TH.SD2 autoReadReg 4_reqStatus
  attr TH.SD2 expert 2_full
attr TH.SD2 firmware 1.0
attr TH.SD2 model HM-SEC-SD
attr TH.SD2 msgRepeat 1
attr TH.SD2 peerIDs 00000000,ssssss,
attr TH.SD2 room Alarm
attr TH.SD2 serialNr zzzzzzzzzz
attr TH.SD2 subType smokeDetector
attr TH.SD2 webCmd test
 
 
=== Variante 2: ein virtueller Aktor fungiert als Teamleader ===
Vorteil: Es kann jeder einzelne Rauchmelder von FHEM aus manuell an- und abgeschaltet werden.
 
Nachteil: Der Alarm eines Rauchmelders '''nicht''' an andere Rauchmelder weiter gegeben, wenn FHEM nicht aktiv ist.
 
Die Rauchmelder sind hierbei im Werkszustand und werden nicht laut der HM-Anleitung aneinander angelernt (miteinander vernetzt = Peering). Es erfolg zuerst das Pairing der Rauchmelder mit FHEM durch z.B.
 
<code>set HMLAN1 hmPairForSec 60</code>
 
und drücken der Anlerntaste am Rauchmelder. Dann definiert man einen virtuellen Aktor mit
 
<code>define TeamDev CUL_HM 111111</code>
 
Bitte beachten: die HMID muss für die gesamte Installation einmalig sein, keine Attribute wie model oder subtype für den virtuellen Aktor manuell erfassen. Anschließend muss man noch einen Homematic-Kanal für das Peering definieren. Durch
 
<code>set TeamDev virtual 1</code>
 
wird 1 Kanal angelegt, wenn autocreate aktiviert ist. Sonst kann man diesen auch manuell mit:
 
<code>define Rauchmelder_Team CUL_HM 11111101</code>
 
definieren. (Gleiche HMID wie der Aktor, da ja der Kanal zum Aktor gehört und zusätzlich 2 Ziffern für den Kanal).
Wurde der Kanal per autocreate angelegt, sollte dieser umbenannt werden:
 
<code>rename TeamDev_Btn_1 Rauchmelder_Team</code>
 
Anschließend jeden Rauchmelder mit dem virtuellen Teamleader (=Kanal des virtuellen Aktors) peeren mit:
 
<code>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set</code>.
 
Hierbei ist "Rauchmelder_Team" der Name des virtuellen Teamleaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.  
Dadurch sollte in jedem Rauchmelder der Name des virtuellen Teamleaders in der peerList stehen und beim virtuellen Teamleader jeder Rauchmelder.


== Software ==
== Software ==

Version vom 31. März 2014, 07:58 Uhr

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.

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.

Teams

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. Um einen SD in ein Team aufzunehmen nutzt man das Kommando peerChan

set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set.

Siehe auch TeamLead.
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 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.
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.
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 TeamId gesendet werden stehen sie nur bei der Komponente des Teamleads zu Verfügung.
Dazu gehören teamCall, alarmOn und alarmOff.
Sie stehen nur für die Entity des TeamLeads zu Verfügung.

 set EurerTeamleader alarmOn
 set EurerTeamleader alarmOff
 set EurerTeamleader teamCall

teamCall testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen.

Einzelne SDs kann man mit "statusRequest" abfragen.

virtueller TeamLead

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.
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.
Erzeugen eines virtuellen TeamLeads könnte so aussehen:

define TeamDev CUL_HM 111111 
set TeamDev virtual 1
rename TeamDev_Btn_1 Rauchmelder_Team

Bitte beachten: die HMID muss für die gesamte Installation einmalig sein.
Anschließend muss man noch einen Homematic-Kanal für das Peering definieren.
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:

set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set
...
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 im Config file zu sichern.
Bei jedem Rauchmelder sollte den 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 mir alarmOn.

Attribute

besondere Attribute

  • msgRepeat sollte auf 01 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 Tag ebei 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

Alarme

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.

Software

Mit dem folgenden Codefragment wird eine Warnungsmeldung an ein FHEM-Display (1-Wire OWXLCD) abgesetzt, sobald ein Rauchalarm anspricht. Ferner wird der Wert des SD.D dummy auf "alarm" gesetzt. Durch Drücken der Taste TH.3x (die in der Beispielinstallation normalerweise das Treppenhauslicht schaltet) wird bei aktiviertem Alarm der Alarm abgeschaltet.

define SD.N notify TH.SD0:smoke-Alarm {\
   OWXLCD_SetLine($defs{'WZ.LCD'},0,"Rauchalarm !!");;\
   fhem("set SD.D alarm")}
attr SD.N room Alarm
define SD.D dummy
attr SD.D room Alarm
define SD.O notify TH.3x:.* {\
   if( $value{'SD.D'} eq "alarm"){\
   fhem("set TH.SD0 alarmOff");;\
   fhem("set SD.D no alarm");;\
   OWXLCD_SetLine($defs{'WZ.LCD'},0,"")}}
attr SD.O room Alarm

Links

Anleitung [1] PDF