Seit geraumer Zeit gibt es nun schon in ganz Deutschland die Pflicht, Rauchmelder in der Wohnung zu haben. Ich habe hierzu eine sehr gespaltene Meinung, aber natürlich haben auch wir Rauchmelder. Unser Modell funkt auf 433MHz und kann folglich mit FHEM angesteuert werden.

Es liest sich immer so toll: Rauchmelder retten Leben. So steht es auf den eigens zu diesem Thema betrieben Websites wie zum Beispiel www.rauchmelderpflicht.net, www.rauchmelderpflicht.eu oder www.feuerfritze.de. Diese Webseiten und die Tatsache, dass die Regeln in jedem Bundesland unterschiedlich sind, sind absolut typisch Deutsch. Umso lustiger ist es, dass gerade www.rauchmelderpflicht.de die Website eines Fotografen ist.

Pro und Kontra

Ich bin bei jeder Argumentation dabei, dass diese Dinger Menschen aus dem Tiefschlaf reißen, die sonst vermutlich jämmerlich erstickt oder verbrannt wären. Meine eigene Erfahrung des letzten Jahres zeigt mir aber, das primär unsere Kinder und wir aus dem Tiefschlaf gerissen wurden – und das ohne jedwelchen Grund. Zum Glück. Trotzdem: Die Kinder haben mittlerweile Panik vor dem roten Blinken der Rauchmelder. Der vermeintliche Lebensretter wird so eher zum Horrorszenario der Einschlafenszeit. Zudem führen die Fehlalarme dazu, dass Nachbarn das schrille Pfeifen nicht mehr ernst nehmen und nicht zu Hilfe eilen.

Komisch ist doch auch, dass zum Beispiel in Sachsen nur neu erbaute Häuser „gesichert“ werden müssen. Brennen ältere Häuser seltener? Brandmelder in Küchen sind in keinem Bundesland Pflicht. Dabei brechen dort am ehesten Brände aus [1]. Nun gibt es Häuser, in denen  Flächen gewerblich und privat genutzt werden. Hier [2] wird es ganz abstrus: Ein Restaurant im Erdgeschoss ist nicht verpflichtet, Rauchmelder einzubauen. Die Wohnung in den Obergeschossen müssen schon welche haben. Der Vermieter muss auch in einem Treppenhaus aus Holz [3] keine Rauchmelder einbauen. Nur in den Wohnungen.

Es fällt mir schwer, hier noch den Willen zum Schutz zu erkennen. Entweder ist hier – typisch verwaltungstechnisches Bearbeiten – in der Ausführung grundlegend etwas schief gegangen, oder es wurde nur ein Placebo geschaffen. Was noch viel schlimmer ist: Vielleicht ist dieses Placebo sogar am Ende der entscheidende Grund, aus dem eine Versicherung nicht mehr zahlen will. Mich nervt so etwas. Und da hilft auch nicht das immer wieder gebrachte Argument: Die Dinger kosten ja kaum was. Das ist Blödsinn. Nicht zuletzt kosten sie Nerven. Und auch etwas was wenig kostet ist zu teuer, wenn es am Ende nichts bringt.

Das Beste draus machen: Vernetzte Rauchmelder KD101

Aber: Ich bin kein Feuerwehrmann und kein Politiker, also füge ich mich in mein Schicksal ;-). Unsere Vermieterin war nicht die Schnellste im Umsetzen der neuen Gesetzeslage Anfang des Jahres 2016, so dass ich mir unsere Rauchmelder selbst aussuchen konnte. Ich entschied mich für das Modell KD101, dass man vernetzen kann. Es gibt diesen Rauchmelder von vielen Anbietern, sei es nun Profitec, Mumbi oder Jucon [4], von dem ich es kaufte. Wenn man eine größere Wohnung oder einen etwas verwinkelteren Altbau bewohnt, dann profitiert man hier wenigstens von einer gemeinsamen Alarmauslösung. Und: Man kann diese Rauchmelder an FHEM anbinden. Das ermöglicht es, einen Alarm auch aus der Ferne zu bemerken, die regelmäßigen Tests zu vereinfachen und ein Logbuch von Fehlalarmen zu führen. Letzteres ist derzeit leider der Hauptzweck meiner Installation.

Der Rauchmelder selbst wird mit einer 9V-Blockbatterie angetrieben.

Im Falle eines Fehlalarms ist die 9V-Blockbatterie zu entfernen!

Drei zusätzliche AA-Batterien sind für den Funkverkehr zwischen den Rauchmeldern zuständig. Man kann einen oder mehrere Master-Melder definieren, die dann im Falle einer Auslösung eine gesamte Gruppe piepen lassen. Die Vernetzung entpuppte sich jedoch als eine echte Herausforderung: Die Gebrauchsanweisung brachte Tasten, LEDs und Farben so durcheinander, dass ich auf überhaupt keinen grünen Zweig kam – Eine Meisterleistung bei gerade mal zwei Tasten und zwei LEDs am Gerät! Jeder Fehler wird vom Gerät dann auch noch dankenswerter Weise mit einer Vorführung des Alarms gewürdigt. Und der ist nicht leise (Anmerkung: Keiner unserer Nachbarn interessierte sich für das schallende Piepen in unserer Wohnung! Siehe oben …).

Für einen Funktionstest ist der Test-Taster gedrückt zu halten. Daraufhin leuchten die Test-LED rot und die Learn-LED grün auf. Kurz danach verspürt man mittleren Druck auf den Ohren und die Kinder kommen panisch zu angerannt ;-).

Zum Anlernen einer Melder-Grupper stieß ich final zum Glück auf eine erleuchtende Rezension bei Amazon [5]. Diese beschreibt, was der Anleitung nicht zu entnehmen ist:

1. Learn-Taster am Master-Melder so oft drücken, bis die Learn-LED grün leuchtet.
2. Learn-Taster an allen Slave-Meldern so oft drücken, bis die Learn-LED rot leuchtet.
3. Während (!) die Learn-LEDs leuchten den Test-Taster am Master-Melder gedrückt halten. Dies sendet das Anlern-Signal an alle Slaves. Deren Test-LEDs beginnen zu blinken und der Alarm wird ausgelöst.
4. Während (!) die Learn-LEDs leuchten den Test-Taster an den Slave-Meldern gedrückt halten. Dies sendet das Anlern-Signal an den Master. Alle Test-LEDs sollten wieder blinken und der Alarm wir wieder ausgelöst.

Im Anschluss daran empfehle ich eine Pause, weil der Druck des Alarms doch ziemlich zwischen die Ohren geht ;-).

Was man sonst noch wissen sollte

Der Rauchmelder muss richtig im Raum positioniert werden. Hierzu bieten viele Websites, unter anderem die oben genannten, viel Lesestoff. Vor allem bei Dachschrägen muss man aufpassen, dass man den Melder nicht ganz oben im Giebel anbringt. Es dauert zu lange, bis dort wirklich Rauch nachgewiesen werden kann.

Die Test-LED eines Rauchmelders blinkt einmal alle 40 Sekunden kurz auf. Wer dagegen empfindlich ist, sollte auch dies beim Positionieren des Melders vor allem im Schlafzimmer beachten.

Viele Rauchmelder senden ein kurzes – zur Freude aller nur schwer lokalisierbares – Piepen, wenn die Batterie zur Neige geht. Ich habe das Gefühl, dass meine Melder in diesem Fall eher so Fehlalarme senden.

Es ist (natürlich) wichtig, die Rauchmelder regelmäßig zu testen. Die Gesetze verlangen, dass der Mieter dies durchführt. Hierzu nutze ich mein FHEM-System. Dabei sollte man wissen, dass eine zusammengeschaltete Rauchmeldergruppe als nur ein Melder in FHEM erscheint.

Integration in FHEM

Die Rauchmelder kommunizieren untereinander auf der Frequenz 433,92 MHz. Ich hatte gehofft, ein paar weitere Stati wie zum Beispiel den Füllstand der Batterien auf dieser Frequenz abfragen zu können … am Ende ist es aber doch nur der Empfang eines Signals bei ausgelöstem Alarm und das Senden eines solchen, um einen Alarm auszulösen. Aber letztendlich genügt das schon.

Um die Sprache der Melder zu sprechen, nutze ich einen bei eBay ergatterten RFXtrx433E-Transceiver [6]. Da unsere Wohnung jedoch recht weitläufig ist, musste ich die Antenne gegen eine stärkere austauschen [7]. Die finale Montage war hochgradig einfach.

Im Verzeichnis /dev/serial/by-id taucht ein usb-RFXCOM_RFXtrx433-Device auf, welches über die folgende Zeile in FHEM eingebunden wird [8]:

define RFXTRXUSB TRX /dev/serial/by-id/usb-RFXCOM_RFXtrx433_A13X79E-if00-port0@38400

Wenn autocreate aktiv ist, tauchen dann schon beim ersten Start wie von Geisterhand die Rauchmelder als TRX_SECURITY-Devices auf. Ein Rauchmeldertest verursacht von nun an neben dem unsäglichen Geräusch auch einen Logeintrag „alert“ im Reading smoke eines Devices.

Tests und Logging via FHEM

Dieses einfach Reading machte mich natürlich nicht glücklich. Ich habe mir etwas gebaut, dass so aussieht wie im Screenshot oben zu sehen ist. Dafür habe ich zunächst die Definition der Rauchmelder selbst um einen Eintrag erweitert, der diese nicht weiter Logs schreiben lässt:

define melder_1 TRX_SECURITY KD101 <ID> smoke
attr melder_1 IODev RFXTRXUSB
attr melder_1 DbLogExclude .*

Dem habe ich ein Dummy-Device mit den Readings alerts (die Alarme) und last_test (Zeit des letzten Tests) zur Seite gestellt, in welchem dann letztendlich Voodoo stattfinden soll:

define log_melder_1 DUMMY
attr log_melder_1 event-on-update-reading alerts, last_test
attr log_melder_1 alias <lesbarer Name>

Leben in die Bude kommt dann, indem eine Statusänderung der Rauchmelder eine Funktion triggert (notify). Diese Funktion reagiert auf alles was mit melder (melder.*) beginnt und benennt den Auslöser in der Variable $NAME. Wenn also der melder_1 einen Alarm produziert, dann soll die aktuelle Uhrzeit in das alerts-Reading von log_melder_1 geschrieben werden. Da ich nun später auch Tests triggern möchte, lese ich noch das Reading last_test aus dem log_melder_1 aus und prüfe, ob dieses erst wenige (10) Sekunden zurück liegt. Nur wenn dem nicht so ist handelt es sich um einen echten Alarm:

define do_melder_alert notify melder.* {\
my $last_test=ReadingsVal(„log_$NAME“,“last_test“,0);;\
my $differenz=time()-$last_test;;\
if ( $differenz > 10 ) {\
fhem(„setreading log_$NAME alerts „.localtime(time));;\
} else {\
fhem(„setreading log_$NAME test_status Wecker.Wochentags“);;\
}\
}

Der Wecker.Wochentags ist in FHEM als das grüne Glockenicon definiert, welches oben im Screenshot zu sehen ist. Dasselbe Icon in gelb heißt Wecker.Wochenende und in rot Wecker.Immer. Die folgende Funktion testet jeden Tag um 12:00 Uhr, wie viele Tage der letzte Test her ist. Sind es weniger als 14 Tage ist die Glocke grün, sind es weniger als 28 gelb und ist es länger so ist die Glocke rot:

define do_melder_warning at *12:00:00 {\
my $time_now=time();;\
my $differenz=$time_now-ReadingsVal(„log_melder_1″,“last_test“,0);;\
if ( $differenz < 14*24*3600 ) {\
fhem(„setreading log_melder_1 test_status Wecker.Wochentags“) \
} elsif ( $differenz < 28*24*3600 ) {\
fhem(„setreading log_melder_1 test_status Wecker.Wochenende“) \
} else {\
fhem(„setreading log_melder_1 test_status Wecker.Immer“) \
}\
}

Die letzte Funktion im Bunde löst dann einen Test aus. Da die Funktion eventuell von einem log_melder.*-Device aus aufgerufen wird, muss das aufrufende Event einmal bearbeitet werden:

define do_melder_test notify do_melder_test {\
my $device=$EVENT;;\
$device =~ s/log_(.*)$/\1/;;\
fhem(„setreading log_$device last_test „.time());;\
fhem(„set $device alert“);;\
}

Was jetzt noch fehlt ist die folgende, hochgradig übersichtliche (;-)) readingsGroup. Hier werden die alerts-, last_test– und test_status-Readings aller log_melder.*-Devices tabellarisch dargestellt. Sollte es noch keine Zeiteinträge für ein Device geben, wird „nie“ angezeigt. Wenn noch kein Test durchgeführt wurde zeigt die Tabelle eine rote Glocke:

define rg readingsGroup <%secur_smoke_detector>,<Letzte Auslösung>,<Letzter Test>,<Test auslösen> log_melder.*:!alerts,!last_test,!test_status
attr rg alias Auslösung der Rauchmelder
attr rg mapping %ALIAS
attr rg valueFormat { \
‚alerts‘ => ‚{ ($READING eq $VALUE)?“nie“:“$VALUE“ }‘,\
‚last_test‘ => ‚{ ($READING eq $VALUE)?“nie“:$VALUE) }‘,\
‚test_status‘ => ($READING eq $VALUE)?“Wecker.Immer“:“$VALUE“ }
attr rg valueIcon { „test_status“ => „$VALUE“ }
attr rg commands { „test_status“ => „trigger do_melder_test %DEVICE“ }
attr rg valueStyle style=“text-align:center“

Wenn jemand bessere, andere oder weiterführende Ideen hat: Nur her damit! 😉

Weiterführende Informationen

[1] http://www.rauchmeldertest.net/rauchmelder-in-der-kuche/
[2] Kommentar: Rauchmelder in Gewerberäumen
[3] Kommentar: Treppenhaus aus Holz
[4] https://www.amazon.de/dp/B0049A70OG
[5] Rezension bei Amazon
[6] eBay: RFXtrx433E Transceiver
[7] eBay: 433MHz 6dBi-Antenne
[8] https://wiki.fhem.de/wiki/RFXtrx