HM-SEC-SD Rauchmelder: Unterschied zwischen den Versionen
Zeile 60: | Zeile 60: | ||
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| | state:[off|smoke-Alarm_<count>] | ||
smoke_detect:<von_name> | smoke_detect:<von_name> | ||
battery:[ok|low] | battery:[ok|low] | ||
Zeile 72: | Zeile 72: | ||
level:<0..200> | level:<0..200> | ||
eventNo:<count> | eventNo:<count> | ||
state:[off| | state:[off|smoke-Alarm_<count>] | ||
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=== |
Version vom 31. März 2014, 18:13 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.
Variablen
Internals
keine Spezifischen
Readings
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>
- count ist ein Zähler, den das Gerät liefert um neue Alarme unterschieden zu können
- level ist ein Wert zwischen 0 und 200. 200 ist alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.
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
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