Kernfunktion ist die Verarbeitung eines ausgelösten Melders – in meiner BMA „Pin 1 wird logisch 1“ – oder ganz platt ich halte einen Draht mit +5V an den IN1 am MCP23017.

Dann werden die Blitzleuchten im Objekt sowie ein Signalhorn oder eine Durchsage aktiviert, das Schlüsseldepot (FSD) wird geöffnet und die Anlage schaltet die Übertragungseinheit (ÜE) zur Feuerwehr oder einem Sicherheitsdienst ein. Parallel dazu müssen die Feuermeldungen auch in den Meldungsspeicher des Feuerwehranzeigetableaus übertragen werden. Danach wartet die Anlage geduldig auf das Eingreifen der Feuerwehr.

Wenn es denn so einfach wäre

Nun gibt es aber in einer Brandmeldeanlage noch ein paar mehr Dinge zu beachten. Neben dem vorübergehenden deaktivieren von Meldegruppen oder einzelnen Meldern (Abschaltungen) gibt es Störungen und die Möglichkeit der Unterbrechung der Akustik, der Brandfallsteuerung und der Überleitung und das jeweils direkt an der BMZ oder am Feuerwehrbedienfeld mit teilweise unterschiedlichen Auswirkungen auf die Verarbeitung eines Ereignisses.

Darüber hinaus sind Funktionen wie Verzögerung der Überleitung für eine Erkundung durch den Betreiber und Spezialfälle wie „mindestens zwei benachbarte Melder müssen auslösen“ in echten Anlagen zu finden. Für die Bedienung der Feuerwehrseite sind diese aber nur bedingt relevant. Fakt ist, wenn die Anlage ausgelöst hat und der Feuerwehrmann vor FBF und FAT steht, muss er herausfinden, welche Melder ausgelöst haben und den betroffenen Bereich erkunden, um festzustellen, ob dort Feuer ist oder nur eine Fehlauslösung vorliegt. Dazu kann er am FBF die Akustik abschalten, die Überleitung unterbrechen und eben am FAT die Meldungen abrufen. Der Rest spielt sich auf der Betreiberseite an der BMZ ab und da sollte der Feuerwehrmann am besten gar nicht tätig werden.

Abschaltung von Meldern und Gruppe

Am einfachsten erschien mir erstmal mit Abschaltung von Meldern und Meldergruppen anzufangen. Über Node-RED erzeuge ich mittels virtuellen Schaltern eine MQTT-Meldung an den Broker, die nun im BMZ-Skript ausgewertet wird. Die abgeschalteten Linien, wie man in Feuerwehrkreisen auch oft noch sagt, und/oder Einzelmelder wandern in eine Variable und parallel wird eine Meldung in den Meldungsspeicher „Abschaltungen“ im FAT abgelegt.

In der Alarm-Funktion wird nun erstmal geprüft, ob der eingehende Melder in der Variablen für die Abschaltung zu finden ist. Falls ja erfolgt nur eine Ausgabe auf der Konsole, aber eben kein Alarm.

Abschaltung der Übertragung und Akustik

Spätestens, wenn die Feuerwehr kommt, wird über das Feuerwehrbedienfeld in die Ansteuerung der Akustik eingegriffen und der Signalweg unterbrochen. Nun muss man an dieser Stelle wissen, dass eine am FBF abgeschaltete Akustik auch nur dort wieder eingeschaltet werden kann. Gleiches gilt übrigens auch für die Übertragungseinheit.

Die notwendigen Steuerbefehle laufen ebenfalls durch den MQTT und werden in Zustandsvariablen lokal gespeichert und bei der Alarmverarbeitung und in der Main-Loop in jedem Prozesstakt geprüft.

„Wieso denn auch in der Main-Loop?“ … nun, wenn die Anlage sich im Zustand Alarm befindet und die Akustik oder die Übertragung wieder aktiviert werden, würde ohne die Prüfung in der Main-Loop beides nicht sofort erneut ausgelöst werden, solange kein neues Meldersignal die Alarmfunktion auslöst. Also müssen wir dafür Sorge tragen, dass im Alarmfall Akustik und/oder Überleitung sofort wieder aktiviert werden und deshalb schauen wir in der Main-Loop.

Voralarm und Erkundung durch Betreiber

Da ich diese Funktion selbst auch nur aus Erzählungen kenne, ist es ein bisschen Stochern im Nebel. In meiner Umsetzung gibt es, wenn die Funktion in der BMZ aktiviert wird (geht nämlich auch ohne), zwei Timer: Voralarm und Erkundung.

Mit Einlauf der ersten Meldung, wird nun der Timer Voralarm gestartet, Blitzleuchte und Akustik aktiviert und der Betreiber kann im Zeitfenster des Timers an der BMZ die Taste Erkundung drücken. Drückt er sie nicht rechtzeitig, wird die Übertragung ausgelöst und die Feuerwehr gerufen.

Schafft er es rechtzeitig den Knopf „Erkundung“ zu drücken, wird der Timer Erkundung aktiviert und er gewinnt eine vordefinierte Zeit bevor die Anlage die Übertragung auslöst und damit die Feuerwehr ruft.

Nach meinem Verständnis ist eine Erkundung unsinnig, wenn mehrere Melder auslösen, denn dann ist schon sehr davon auszugehen, dass ein Brandfall vorliegt. Deshalb bricht meine BMZ den Voralarm und die Erkundung sofort ab, wenn weitere Melder eingehen und ruft die Feuerwehr.

Rückstellung der BMZ

Im richtigen Leben kann der Betreiber an der BMZ nach erfolgter Erkundung die Anlage wieder zurückstellen. Das macht aus Sicht der Betreiber durchaus Sinn, weil dann der Lärm aufhört und die so genannten Brandfallsteuerungen wieder abgeschaltet werden (Blockierung der Aufzüge, Schließen der Brandschutztüren, etc.) und die Arbeit weiter gehen kann. Aus Sicht der Feuerwehr gibt es gute Argumente gegen das Zurückstellen und Abbestellen der Feuerwehr.

Weil das Rückstellen durch Betreiber immer wieder für Probleme sorgte, weil für die Feuerwehr die Auslösung schwierig nachvollziehbar war, leuchtet in neueren Anlagen die Alarm-LED im FBF 15 Minuten nach der Rückstellung, so dass die Feuerwehr weiß, dass die Anlage definitiv ausgelöst hat und im FAT nach der Ursache suchen kann.

Auch an dieser Stelle greift die Rainer-BMA-Logik … wenn während der 15 Minuten die Anlage erneut auslöst, dann wird es wohl einen Grund geben, so dass in diesem Fall auch ohne Voralarm und Erkundung sofort die Überleitung aktiviert wird.

Einen Aspekt berücksichtig meine BMA derzeit noch gar nicht … nämlich die Auslösung und Überwachung des Schlüsseldepots. Es ist aus Gründen der Sicherheit in die Überwachung der BMA eingebunden und bei fehlenden Schlüsseln und offenen Klappen gibt es Probleme bei der Rückstellung der Anlage in den Ruhezustand. Aber auch das wird noch einen Weg in das Projekt finden 😉

Jetzt wird es langsam interessant, denn nun sollen Daten aus dem MQTT zum Ansteuern von LEDs und dem LCD-Display dienen und Taster am Arduino sollen entsprechend im MQTT signalisiert werden. Basierend auf meinen vorherigen Versuchen habe ich also in Python mit smbus und dem „Display-Treiber“ begonnen ein Schnittstellen-Modul zu schreiben. Für die Kommunikation mit dem MQTT-Broker kommt Bibliothek paho-mqtt zum Einsatz.

Anpassung der lcddisplay.py und i2c_lib.py

Da es mich schon zu Beginn störte, dass die Display-Beleuchtung immer eingeschaltet ist, habe ich mir mal den „LCD-Treiber“ (lcddriver.py) genauer angeschaut. Dort werden im Wesentlichen Byte-Konstanten definiert und es folgt eine Umsetzung der Daten in Byte-Folgen und die Adressierung für das Display.

Dieses Skript greift wiederum auf ein weiteres Skript im Paket zu (i2c_lib.py), dass eine Handvoll smbus-Funktionen in einer Klasse wrappt und die Device-Adresse des Displays festlegt. Erst hatte ich überlegt das Skript komplett rauszuwerfen, habe mich dann aber dazu entschlossen diesen Wrapper zu erweitern, um Fehler bei der I2C-Kommunikation abzufangen und Retrys und Timeouts zu realisieren. Mit ein paar weiteren Anpassungen für die Adressierung beliebiger Slaves ist es nun mein I2C-Busmaster geworden.

Im Display-Script habe ich auch noch ein paar Dinge umgebaut, so dass nun neben der Adressierung aufgrund der Änderung im I2C-Wrapper auch die Hintergrundbeleuchtung gesteuert werden kann.

Abfragen der Eingänge, setzen der Ausgänge und Anzeigen auf dem LCD

Nachdem die Verbindung zu den beiden I2C-Slaves (Display und Arduino) steht, wird eine LED angesteuert, wenn das Skript in der Main-Loop angekommen ist und auf dem Display erstmal die Uhrzeit angezeigt. Mit erstaunlich wenigen Befehlen werden zyklisch die Eingänge am Arduino abgefragt und in lokale Variablen geschrieben.

Den Broker kontaktieren

Mit dem Paket paho-mqtt gestaltet sich auch die Kommunikation mit dem MQTT-Broker recht einfach. Ich lasse mein Schnittstellen-Skript eine Nachricht an den Broker senden, wenn es Einsatzbereit ist und mache einen subscribe auf ein paar Topics, die derzeit von der Node-RED-Pseudo-BMZ mit Daten befüllt werden.

Im ersten Schritt lasse ich eine LED als Alarmsignal leuchten und schreibe die vom MQTT kommende Alarmmeldung aufs Display. Im Ruhezustand erzeugt die Node-RED-BMZ eine Ausgabe der aktuellen Uhrzeit.

Im zweiten Schritt sende ich Nachrichten an den Broker, wenn bestimmte Tasten am Arduino gedrückt werden. Die weitere Verarbeitung läuft dann allein im Node-RED.

Test mit MCP23017

Nachdem ich mich bei meiner Kommunikation zwischen Pi und Arduino an der Ansteuerung des MCP23017 orientiert habe, war es nun Zeit den Arduino eben durch den Portexpander zu ersetzen. Im Python musste ich noch den Befehl zur Initialisierung der Ein-Ausgänge hinzufügen, da ich diese im Arduino hardcoded hatten.

Nach Umstecken des I2C, der LEDs und Taster auf den MCP und Neustart des Skriptes funktionierte dieser sofort wie erwartet. Damit war die I2C-Schnittstelle für Display und ein paar erste LEDs und Taster funktional. Eine weitere Ausdehnung auf alle LEDs und Taster am FBF und FAT macht ohne entsprechende Hardware noch keinen Sinn, aber wo ein Portexpander funktioniert, funktionieren auch zwei 😉

Das Interface-Skript (nodebma_interface.py)

Das soeben gebaute Python-Interface zwischen MQTT und I2C kommt nun in eine screen-Session und wird als systemd-Service angelegt.

Da ich ein Freund von Textausgaben auf der Konsole bin, nutze ich gerne screen, um bei Bedarf einfach mal schauen zu können, was mein Skript gerade so macht. Natürlich könnte ich auch ein Logging in eine Datei machen – vielleicht baue ich das noch mal um.

und wie immer noch ein Link dazu

paho-mqtt für Python | Webseite

Mit Python habe ich bereits verschiedene Erfahrungen sammeln können, so dass ich nun „nur noch“ verstehen musste, wie I2C überhaupt funktioniert und wie man das in Python umsetzt. Als Bibliothek kommt smbus und für ein HD44780-LCD-Display noch eine kleine Treiber-Bibliothek aus einem Tutorial zum Einsatz.  

Levelshifter zwischen Pi und Arduino

Bevor wir nun gedankenlos den I2C-Bus des Raspberry und des Arduino verbinden und uns wundern, dass der Pi zwei GPIO-Ports weniger hat, müssen wir einen Pegelwandler für 3,3 und 5 Volt einsetzen, denn der Pi mag keine Spannungen über 3,3V am GPIO und der Arduino arbeitet regulär mit 5V. Der Pegelwandler wird einfach in die Busleitungen SCL und SDA eingefügt und mit Masse und Vin aus beiden Richtungen versorgt. Wenn das erledigt ist, kann man mit dem Kommandozeilentool i2cdetec schauen, ob die Slaves am Bus gefunden werden. Ist dies der Fall, geht es an die Programmierung.

I2C im Python ansprechen

Als erstes ein paar Experimente mit dem Display. Auf dem HD44780 ist, dank des kleinen Treibers, schnell ein erster Text angezeigt. Der Code für die Ansteuerung ist fast selbsterklärend und man hat mit dem darunterliegenden I2C-Bus eigentlich noch keinen richtigen Kontakt. Wenn man es genau betrachtet ist der Treiber auch eher ein Wrapper, der die Strings für das Display in die passenden Bytes und Adressierungen umsetzt und die Kommunikation mit dem I2C-Bus über smbus organisiert.

Pi spricht mit dem Arduino

Aufgabe 1: Vom Pi einen Befehl senden, der auf dem Arduino eine LED ein oder aus schaltet.

Das gelingt Mithilfe einiger Anleitungen aus dem Netz und der Wire-Bibliothek auf dem Arduino recht schnell. Den Arduino als I2C-Slave initialisieren, ihm eine Adresse geben und dann auf die ankommenden Bytes reagieren … 0x00 LED aus, 0x01 LED an … aber Moment … das muss doch auch eleganter gehen, indem ich nicht nur ein Byte als Adresse sondern je Adresse auch noch weitere Bytes als Parameter übertrage und auswerte.

Nach etwas Knoten im Kopf und umdenken (bisher habe ich in Projekten immer über Sockets, APIs und MQTT mit Strings kommuniziert) habe ich dann herausgefunden wie die smbus-Funktionen und die C++Befehle dafür aussehen und die Daten aufbereitet und ausgewertet werden müssen. Nach ein paar frustranen Versuchen ist der Knoten geplatzt und es funktioniert.

Aufgabe 2: Vom Pi einen Eingang am Arduino abfragen.

In meinem Leichtsinn dachte ich, dass ich einfach auf einen Befehl antworten kann, aber bei I2C wird die Übertragung ausschließlich vom Master gesteuert.

Wenn man nochmal genau nachließt und dann auch verstanden hat, dass der Master entweder nur Daten sendet oder einen Request mit eigenen Daten an den Slave sendet und dieser dann direkt antwortet, kommt man auf den richtigen Weg. Also im Arduino den Code umgebaut und siehe da, ich kann nun auch den aktuellen Schaltzustand meiner LED und eines Einganges abfragen.

Aufgabe 3: eine sinnvolle Adressierung auf dem Arduino für IN/OUT

Ich mache es kurz … ich habe einfach die wesentlichen Adressen für die io-Ports aus dem Datenblatt des MCP23017 übernommen. Für das Verständnis des Datenblattes und der Abläufe auf dem I2C-Bus hat mir ein unten verlinktes Tutorial zum MCP sehr geholfen.

Zu meiner Schande musste ich mich nach jahrelanger Erfahrung mit selbst beigebrachten Hobby-Programmierkenntnissen nun endlich mal mit binärer Logik beschäftigen … also wie setze ich 8 Bits zu einem Byte zusammen und wie prüfe ich effektiv und einfach auf der anderen Seite welche Bits 1 bzw. 0 sind. Grundsätzlich war der Zusammenhang klar, aber wie es in Python und C++ praktisch funktioniert war dann eine Abendstudie und ein bisschen Try und Error.

Dabei hat mich die Funktion pow() im C++ fast zur Verzweifelung getrieben, bis ich verstanden habe, dass sie als float-Funktion eben ein „krummes“ Ergebnis liefert, was dann beim Vergleich mit einem Integer zu falschen Ergebnissen führt. Nach weiter Forschung habe ich dann mit bit() die für diesen Zweck richtig Funktion gefunden.

Nun konnte ich also meinen Arduino als dummen I2C-Portexpander missbrauchen und ihn für Ein- und Ausgänge an meiner Brandmeldeanlage nutzen.

„Warum haste nicht gleich nen MCP23017 genommen?“ … das ist schnell erklärt: ich wollte ja verstehen, wie I2C funktioniert und wie solche Bausteine kommunizieren. Das geht natürlich leichter, wenn man auf beiden Seiten des Busses mitlesen kann. Mission erfüllt 😉

Jetzt müssen irgendwie die Taster und LEDs am Arduino mit dem MQTT verbunden werden …

Hier die erwähnten Quellen aus dem Text

Tutorial: HD44780 per I2C ansteuern | Webseite | Python-Bibiothek

Tutorial: Raspberry Pi GPIOs mittels I2C Port Expander erweitern | Webseite

Bevor ich nun eine eigene Brandmeldeanlage baue, muss ich mir erstmal einen Überblick verschaffen, welche Komponenten für die Feuerwehr interessant sind. Neben dem Herzstück – die Brandmeldezentrale – und den Meldern gibt es ein paar genormte Bedienelemente für die Feuerwehr.

Erster Anlaufpunkt ist für die Feuerwehr das Feuerwehr-Schlüsseldepot (FSD) und ggf. das Freischaltelement (FSE). Gestaltung und Funktion sind in der DIN beschrieben. Gerade die Besonderheiten bei der Handhabung des FSD im Bezug auf die Entnahme und Rücklage von Schlüsseln ist ein übenswerter Prozess. An ein originales FSD zu kommen, ist aber aufgrund des hohen Preises eher schwierig, aber auch nicht unmöglich.

Aus elektrischer Sicht besteht ein FSD aus einem elektrischen Türöffner und Rückmeldekontakten über die die geöffnete Tür und das Fehlen eines Schlüssels erkannt wird.

Das Freischaltelement ist aus elektrischer Sicht lediglich ein Kontakt der überwacht wird. Wird er ausgelöst, so wird die Anlage in den Alarmzustand versetzt, als wenn ein Melder im Objekt auslöst. In der Folge wird das FSD geöffnet und die Feuerwehr bekommt Zugang zum Objekt. Mechanisch betrachtet waren es in älteren Brandmeldeanlagen Schlüsselschalter, in neueren Anlage sind es Rohrzylinder, die gezogen und wieder eingesteckt werden.

Ist man nun mit einem Schlüssel im Objekt geht es zum Feuerwehr-Bedienfeld (FBF). Hier kann bei Eintreffen durch Abschalten der Akustik für etwas Ruhe gesorgt werden und im Verlauf des Einsatzes kann die Übertragung zur Leitstelle unterbrochen werden und natürlich die Anlage wieder in den „Ruhezustand“ gebracht werden. Dem Feuerwehrmann bieten sich neben LED-Anzeigen ein paar Taster, die teilweise einrasten. Alles ist dank der DIN einheitlich angeordnet, beschriftet und funktioniert unabhängig vom Hersteller der BMZ bzw. der Bedienfeldes immer nach gleichem Prinzip.

Daneben ist das Feuerwehr-Anzeigetableau (FAT) die entscheidende Informationsquelle im Falle einer Auslösung. Hier wird die Meldegruppe und der auslösende Melder in einem LCD-Display angezeigt. In neueren Anlagen steht oftmals noch ein Klartext zum Melder zur Verfügung. Das Vorhandensein mehrerer Meldungen wird durch LEDs signalisiert und über Taster können diese abgerufen werden. Auch wird am FAT über Abschaltungen von Meldern und Störungen der Anlage informiert. An diesem, ebenfalls genormten Bedienelement kann der Feuerwehrmann nix falsch machen, da im FAT nur Meldungen aus der Anlage gespeichert und angezeigt werden können – es gibt keinen „Rückkanal“ in die Anlage. Selbst wenn durch einen unglücklichen Fall die BMZ durch den Brand ausfällt, stehen die Meldungen im FAT noch zur Verfügung, solange Betriebsspannung anliegt.

Nun kenne ich die wichtigsten LEDs und Knöpfe auf der Feuerwehrseite … jetzt brauche ich eine Idee für die eigene BMZ.

Informationsquellen

Feuerwehr-Bedienfeld | Wikipedia

Feuerwehr-Anzeigetableau | Wikipedia

Feuerwehr-Schlüsseldepot | Wikipedia

Freischaltelement | Wikipedia

Brandmeldeanlage im Einsatzleiter-Wiki