Alle Beiträge von rainer

Bastelei, Brandmeldeanlage, Raspberry

4. Raspberry, Python und I2C

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

Allgemein, Bastelei, Brandmeldeanlage

3. C++, der ARDUINO und ich

Wie bereits in der Einleitung geschrieben, soll das ganze ein „Schulungsprojekt“ sein – an dieser Stelle kommen die ersten Gehversuche mit einem Arduino Nano, der Arduino IDE und der Programmiersprache C++. Bisher waren meine Kontakte mit der Arduino-Welt auf das Flashen eines fertigen Projektes für unser Amateurfunk-Relais beschränkt. Auch gegen C++ habe ich mich über die Jahre immer gewehrt, da ich bisher immer mit VisualBasic, php, Javascript und Python irgendwie zum Ziel gekommen bin.

Also erstmal grundsätzlich mit der Materie Arduino vertraut machen und ein paar Zeilen Code zum Abfragen eines Einganges und Setzen eines Ausganges in C++ schreiben. Dank dem Internet und viel Ähnlichkeit zu anderen Hochsprachen kein Hexenwerk und dann in der IDE den Sketch hochladen … Fehlermeldung – Board antwortet nicht.

Nach einer Runde Google offenbarte dmesg, dass der USB-zu-Seriell-Chipsatz CH341 meinem Pi 3B nicht schmeckte. Mit Hilfe einer Anleitung aus dem Netz (finde sie leider nicht wieder) konnte ich einen neuen Treiber für den CH341-Chip kompilieren. Dann gleich der nächster Fallstrick: die originalen Nanos haben irgendwann einen neuen Bootloader bekommen und somit ist die IDE auch primär darauf eingestellt. Die China-Nanos haben wohl überwiegend den alten, also in der IDE umstellen und damit gelang dann auch das Flashen einer blinkenden LED nach Tastendruck am Arduino.

Nun aber schnell zurück zum Projekt … der Arduino soll ja Eingänge lesen und Ausgänge ansteuern und muss noch irgendwie mit dem Raspberry, der ja den MQTT bereitstellt und später die BMZ sein soll kommunizieren. Da neben dem Arduino und dem Raspberry auch noch ein Display und weitere GPIO-Ports benötigt werden, habe ich mich für den I2C-Bus entschieden …

weitere Infos

Treiber CH341SER von juliagoda | GitHub

Allgemein, Bastelei, Brandmeldeanlage

2. Raspberry Pi, Mosquitto und Node-RED

Ohne so richtig zu wissen, wie ich das Herzstück meiner Brandmeldeanlage mal gestalte, geht es im Wesentlichen ja erstmal um diverse Eingänge (Melder, Taster, Schalter) und Ausgänge (LEDs, Display, Relaiskontakte, die sinnvoll miteinander verknüpft werden wollen.

Da ich im Bereich der Lichtsteuerung zu Hause schon mit MQTT arbeite, fand ich es naheliegend auch hier dieses Konzept zur Kommunikation mit Ein- und Ausgängen zu nutzen. Großer Vorteil aus meiner Sicht ist die Option jederzeit extern über den Broker Vorgänge zu triggern bzw. Zustände mitzuverfolgen – gerade während der Entwicklung hilfreich – egal, wie und womit ich später die eigentliche BMZ programmiere. Also erstmal einen Pi Zero mit minimalem Raspbian aufgesetzt und Mosquitto, NodeRED und Python3 installieren – auf die Details gehe ich an dieser Stelle nicht weiter ein.

Mit Node-RED wollte ich eigentlich erstmal nur die diversen Ein- und Ausgänge der Brandmeldeanlage für den MQTT simulieren, aber dann habe ich neben ein paar Flows und Dashboards für FBF, FAT und Melder noch ein paar Grundfunktionen der BMZ in einem Flow zusammengebaut, so dass eine Alarmauslösung, Rückstellung, die Akustik-Abschaltung und die Steuerung der Übertragungseinheit möglich sind. Nach einer Nachtschicht, funktionierte die rudimentäre BMA schon soweit, dass man ein paar grundlegende Dinge probieren kann – weit weg von einer normalen und realitätsnahen Bedienung, aber dennoch beeindrucken, was mit Node-RED so alles machbar ist.

Wie bereits in der Einleitung geschrieben, soll das ganze ja ein Schulungsprojekt sein – nicht nur für die Feuerwehrleute, die den Umgang mit einer BMA üben sollen, sondern auch für mich, denn bei diesem Projekt sehe ich mehr Ein- und Ausgänge als mein Pi Zero GPIO-Pins hat – es braucht also wohl etwas mehr Elektronik und wohl damit verbunden auch eine Auseinandersetzung mit Dingen wie seriellen Bus-Lösungen und Mikroprozessoren.

Links zum Weiterlesen

MQTT | Wikipedia

Node-RED | Webseite

MQTT-Broker Mosquitto | Webseite

Bastelei, Brandmeldeanlage, Raspberry

1. Bedienelemente

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

Allgemein

Raspberry Pi 4B – gesteuerter Lüfter

Wie ich in meinem Beitrag zum Pi4 als Desktop bereits ausgeführt habe, wir das aktive Kühlen beim Pi4 quasi zur Pflicht, wenn er nicht nur irgendwo in der Ecke steht und die allermeiste Zeit im „idle“ ist. Im Desktop-Betrieb mit LibreOffice oder Youtube per Webseite geht recht schnell die Temperatur hoch und der Lüfter muss laufen.

Ich hatte den 5V-Lüfter an einen 3,3V-Pin angeschlossen und die Masseleitung des Lüfters mit einer Drahtbrücke vom Steckbrett nach außen verlängert und dann bei Bedarf einfach die Brücke an die Masse am USB-Port gehängt. Das funktionierte prima, bis ich nun den Pi in einer Umräumaktion unter den Schreibtisch verlagert habe.

Hardware

Nun musste also was automatisches her und ich suchte aus der Bastelkiste einen Widerstand (4,7k) und einen Transistor (BC547). Für die Verbindung habe ich in Ermangelung einer Buchsenleiste 3 Steckbrücken geopfert.

Beim Anschluss habe ich wieder den 3.3V-Pin genommen (5V geht natürlich auch, ist aber deutlich lauter beim Lüften). Für die Ansteuerung habe ich GPIO2 (Pin3) genommen. Der liegt nach dem Boot auf HIGH und der Lüfter läuft ohne Steuerskript dauerhaft, was ich erstmal als „failsave“ betrachte.

Der GPIO2 geht nun über den 4,7k-Widerstand an die Basis vom Transistor. Die Masse wird auf den Emitter am Transistor geführt und geht von dort über den Kollektor weiter zum Lüfter. Die Verdrahtung ist mit Steckbrücken gebaut, so dass die Schaltung einfach zwischen den Lüfter und den GPIO gesteckt werden kann. Isoliert ist das ganze mit Schrumpfschlauch.

Software

Ich bin ein Freund von Python und daher kam für mich auch nix anderes in Frage. Das Skript wird einmalig gestartet und überwacht fortan die CPU-Temperatur. Ich habe mich dabei für einen Intervall von 5 Sekunden entschieden, weil ich glaube, dass das ausreichend sein sollte.

Beim Überschreiten der Schwelle von 70°C wird der Lüfter eingeschaltet und es wird „laut“ unter dem Schreibtisch. Beim Absinken der Temperatur unter 50°C wird der Lüfter wieder abgeschaltet und es herrscht wieder Ruhe.

cpu_cool.py
#!/usr/bin/python3

import RPi.GPIO as GPIO
from gpiozero import CPUTemperature
import time

GPIO.setmode(GPIO.BCM)
GPIO.setup(2, GPIO.OUT)

GPIO.output(2, GPIO.LOW)
cooler = 0

while True:
	ctemp = CPUTemperature().value * 100

	if ctemp > 70 and cooler == 0:
		GPIO.output(2, GPIO.HIGH)
		cooler = 1
	elif ctemp < 50 and cooler == 1:
		GPIO.output(2, GPIO.LOW)
		cooler = 0
	else:
		# wir lassen es so
		pass

	print('Temp:',round(ctemp,2),'Cooler:',cooler)
	time.sleep(5)

 

Grundlage

Tutorial im Raspi-Forum
https://forum-raspberrypi.de/forum/thread/774-lueftersteuerung-per-temperatur-einbauanleitung/

 

Raspberry

NotrufSim 2.0 – Änderungen und WebTool

Der letzte Beitrag ist ein paar Tage her und es gab viele kleine Änderungen und einen wesentlichen Schritt nach vorne.

Hardwaretausch

Auf der Hardwareseite habe ich einen kleinen WLAN-AccessPoint zugunsten einer FritzBox aus dem Bastelschrank getauscht. Die Idee dazu hatte ich bei der Überlegung ein DECT-Telefon als zusätzliches Regietelefon anzuknüpfen und bevor nun eine Bastelei mit ATA-Adapter auf eine DECT-Basis das ganze Gebilde wachsen lässt, war die FritzBox die bessere Lösung.

Die FritzBox ersetzt nun den WLAN-AccessPoint, ist DECT-Basis und macht nebenbei noch den DHCP-Server im Netz (hätte ich sonst als Dienst auf dem Raspi gemacht). Darüber hinaus kann man sich über LAN1 an ein bestehendes Netz als Client verbinden und bleibt trotzdem mit der Simulation im gekapselten Netz.

Was ich noch nicht probiert habe, aber durchaus noch eine Option wäre … ein Internet-Fallback über USB-UMTS-Stick an der FritzBox. Das ist sicher nichts um ein ganzes Netz mit Internet zu versorgen, aber es würde der FritzBox und dem zentralen Pi zum Beispiel einen Weg zum NTP-Zeitserver ebnen.

WebTool

Der nächste Schritt sollte das WebTool sein und so ist in den letzten Tagen die Anwendung NSeat entstanden.

Hier kann eine Sitzung für den jeweiligen Platz in der Leitstelle bzw. der Regie gestartet werden und man sieht auf dem Schirm ankommende und abgehende Anrufe und kann nach Gesprächsende auf die aufgezeichneten Anrufe zugreifen.

Dann war die Idee, darüber auch Anrufer zurückrufen zu können, nicht so wirklich Abstrakt – funktioniert in unserer Leitstelle direkt auf der Funk-Notruf-Abfrage ja auch ohne Leitsystem. Hierzu wurde im NSeat eine Wählhilfe integriert, die mittlerweile auch mit platzabhängigem Telefonbuch und Kurzwahltasten versehen ist.

Sind auf einem Platz zwei Leitungen aktiv, kann man diese über das WebTool auch miteinander verbinden. Diese Funktion ist komplett im Asterisk realisiert, so dass man hier unabhängig von den verwendeten Telefonen bleibt.

In der Regie kann NSeat als „MultiSeat“ gestartet werden. Dabei werden alle Plätze gleichzeitig darstellt. In der Wählhilfe kann dann über ein DropDown der abgehende Platz ausgewählt werden.

Wählplan

Eine wesentliche Änderung war die Auslagerung der „zufälligen Rufnummer“ in ein externes Skript. Ich fand es irgendwie schöner und leichter einzubinden als ein komplexes Extensiongebasel mit RAND und IF, um „schöne“ Rufnummern zu erzeugen.

Durch die Option der zusätzlichen Regie-Telefone als DECT, die man in einer Simulation dann durch einen festen Einspieler besetzen kann (für Telefon-CPR, oder sowas), ist die Idee entstanden dem jeweiligen Regie-Telefon eine feste Abgangsrufnummer zuzuordnen. Dies ist jetzt über einen Telefoncode vom Gerät aus steuerbar. Die aktuelle Rufnummer kann durch eine Ansage abgerufen werden.

In einer weiteren Funktion wird der Anrufername aus dem Telefonbuch des WebTools versucht aufzulösen, so dass auf den SIP-Telefonen auch der Name des Anrufers angezeigt wird, wenn man denn ohne das WebTool arbeitet.

Mit den Funktionen im WebTool (Wählhilfe und Verbinden) und der FritzBox als SIP-Client ergaben sich dann bei Testen ein paar kleine Probleme mit dem Wählplan. Die FritzBox routet zum Beispiel keine einstelligen Rufnummern nach extern und bricht die Anwahl intern ab. Der Wählplan wurde daraufhin nochmal etwas umgestellt und ein paar Dinge speziell für die FritzBox hinzugefügt.

Den komplette Wählplan, so wie er jetzt aktuell seinen Dienst verrichtet, habe ich mal hochgeladen extensions.conf.

Ein Video mit den neuen Funktionen gibt es dann auch die Tage noch mal.

Raspberry

NotrufSim 2.0 – Konfiguration der Telefone

Weiter geht’s mit dem Projekt NotrufSim 2.0 – Nachdem nun die Telefone und der PoE-Switch geliefert wurden, und der Asterisk-Server soweit läuft, ging es an die Einrichtung der Hardware. Die OpenStage 40 SIP kamen mit einer relativ aktuellen Firmware und waren bereits auf Werkseinstellungen. Die Grundeinrichtung geht wahlweise direkt am Telefon oder über den Browser.

Vorbereitungen

Als erstes habe ich dem Raspberry zusätzlich zur DHCP-Adresse eine feste IP verpasst, denn das System soll ja primär autark ohne fremdes Netzwerk und Internet auskommen. Alle weiteren Komponenten wie Switch, WLAN-AP und Telefone bekommen daher ebenfalls feste Adressen. Im Raspberry ist optional ein DHCP-Server vorkonfiguriert um später Tablet oder Laptop für die erweiterte Bedienung anzuknüpfen. DHCP soll dann über ein Webinterface aktivierbar sein.

Der Raspi hat in diesem Zuge auch noch einen NTP-Server (Zeitserver) bekommen, um andere Geräte im Netzwerk auf die gleiche Zeit zu bringen. Haken hierbei ist, dass der Raspi selbst keine aktuelle Zeit hat, weil er keine Realtime-Clock und die Uhr quasi am letzten Shutdown weiter läuft. Später gibt es dann im Webinterface eine Funktion zum Setzen der Systemzeit über den Browser.

Grundkonfiguration

Nach dem Verbinden mit dem PoE-Switch dauert es eine ganze Weile, bis das Telefon hochgefahren ist. Dann bietet es eine Auto-Konfiguration an, die man ablehnen muss. Über das Einstellungsmenü auf dem noch Englisch sprechenden Telefon kann man das Netzwerk auf IPv4 ohne DHCP einrichten und eine manuelle IP aus dem Netz des Raspi eingeben. Jetzt ist es unter eben dieser IP per Netzwerk erreichbar.

Wenn man, wie ich, keine Anleitungen ließt, dann bekommt man mit etwas rumprobieren irgendwann raus, was man in der Administration über den Webbrowser eintragen muss.

Als erstes wird die Netzwerk-Konfiguration vervollständig, also DNS und Default-Route auf den Raspi gebogen und die DNS-Domain noch auf local geändert, da wir ja keine echte Domäne haben.

Dann erfolgt die Einstellung der Identität – hier habe ich nen bisschen gebraucht, bis ich verstanden habe, was man eintragen muss, und wozu es dann dient. Der „Terminal name“ wird quasi der Hostname des Telefons. Die „Display Identity“ steht später im Telefondisplay und wurde mit der Platzbezeichnung und der internen Rufnummer gefüttert. Wichtig ist der kleine Haken bei „DisplayID“, sonst steht nämlich nur der Realm vom SIP-Account im Display.

Unter „Date and Time“ kann man noch die IP des Raspi als SNTP eintragen, damit sich das Telefon am Raspi eine Uhrzeit holen kann.

Danach wird unter „Security and Policies“ noch ein Password für die Weboberfläche des Users eingerichtet.  Danach besucht man genau diese und stellt unter „Locality“ auf Deutsch um.

[Screenshot einfügen]

Basis-SIP-Einstellungen für alle Telefone

Nun geht es an den Haupt-SIP-Account. Hier werden Server, Registrar und Gateway auf die IP des Raspi gesetzt. Der „Server Type“ muss auf „other“ gesetzt werden. Bei „Realm“ und „UserID“ kommt dann der „username“ für den entsprechenden Platz aus der sip.conf vom Asterisk rein und falls verwendet natürlich auch das Passwort. Nach dem Speichern meldet sich das Telefon direkt am Asterisk an und ist dann telefonierbereit.

erweitere Konfig für Leitplätze

Jetzt brauchen wir in den Leitstellen-Telefonen unsere verschiedenen Leitungen. Diese sollen auf den Softkeys seitlich am Display angezeigt werden. Das ganze findet man unter „System > Features > Programm Keys“ und dort kann man dann „Line“ auswählen und der Taste einen Namen geben und dann wieder Zugangsdaten aus der sip.conf für die entsprechende Platzleitung (z.B. notruf1, ktp1, etc) eingeben.

[Screenshot einfügen]

Jedes Mal, wenn man speichert, wird die neue Leitung sofort am Asterisk angemeldet und steht kurz danach zur Verfügung. Bei ankommenden Rufen leuchtet jetzt auch die entsprechende Taste und das ganze erfüllt schon mal meine Vorstellung.

Auf die Tasten kann man auch zahlreiche Funktionen und Kurzwahlen legen. Ich habe die untere Taste mit der Shift-Funktion belegt und auf der zweiten Ebene dann abgehende Anrufe auf die Tasten gelegt:

  • Leitung AMT & abgehend externer Anruf
  • Leitung 112 & abgehend an Polizei (110)
  • Leitung 19222 & abgehend an andere Leitstelle (19222)
  • Leitung 116117 & abgehend an Arzt (116117)

Unter „Fixed Keys“ habe ich noch die Taste für Rufumleitung auf „Consultation“ (Rückfrage) umgestellt, denn eine Rufumleitung wünschen wir uns zwar in der Leitstelle manchmal, aber die Rückfrage/Verbinden macht mehr Sinn.

erweiterte Konfiguration für Regie

In der Regie haben wir keine verschiedenen Leitungen, da brauchen wir nur ein paar Zielwahlen in die Leitstelle. Die Tasten unterste Taste ist wieder mit der Shift-Funktion belegt, die anderen in beiden Ebenen mit Zielwahlen in die Leitstelle:

  • zufällige Nummer an 112 & Festnetznummer an 112
  • anonym an AMT & Festnetznummer an AMT
  • anonym an 19222 & Festnetznummer an 19222
  • anonym an 116117 & Festnetznummer an 116117
  • Anruf als Polizei an AMT & Handynummer an 112

Auch hier wird die Taste für Rufumleitung auf „Consultation“ umgestellt, auch wenn die Regie eigentlich nicht verbinden muss – aber sie kann 😉

Hallo, ist da die Feuerwehr ?

Nachdem nun die Telefone konfiguriert sind, geht es an den Feldversuch. Die Anrufe in der Leitstelle funktionieren wie gewünscht und auch das Anrufen aus der Leitstelle funktioniert wie geplant. Der Versuch eines abgehenden Anrufes über die 112 wird wie gewünscht abgewiesen und mit der „Fehleransage“ belohnt.

Jetzt mal ein Notruf, der an die Polizei verbunden werden muss – Anruf annehmen > Rückfrage > Shift + Polizei und „Fehleransage“ – huch, was nun?

Das Telefon wählt beim Vermitteln automatisch über die Leitung raus, auf der der Anruf auch angekommen ist. Somit lande ich zurecht in der „Fehleransage“, wenn ich ein 112-Gespräch verbinden will. Ich habe bis jetzt noch nicht rausgefunden ob oder wie man das ändern kann, so dass nun die Konsequenz ist, dass ich den Wählplan im Asterisk so geändert habe, dass die Leitstelle doch mit allen Leitungen raustelefonieren kann, da sonst das Verbinden nicht klappt und das ist nun mal eine essentielle Leitstellen-Funktion.

rudimentäres WebTool mit Zugriff auf die Aufzeichnungen

Beim WebTool habe ich Quick’n’Dirty ein kleines PHP programmiert, was die Gesprächsdaten aus der Datenbank anzeigt. Dabei wird unterschieden zwischen „Anruf“, „Aktiv“ und „Beendet“ und mittels „Reload“ kann man dann manuell aktualisieren.

Bei den beendeten Gesprächen gibt es gleich einen Link zur Aufzeichnung, die mittels HMTL5-Audioplayer abgespielt wird.

Hier geht es dann als nächsten dran, um das ganze mit Javascript und CSS ansehnlich zu automatisieren.

Raspberry

NotrufSim 2.0 – Das Projekt

Bereits 2015 begann ich eine Artikelreihe mit dem Ziel einen „Wunderkasten“ als kleine Telefonanlage zur Simulation von Notrufen auf Basis Raspberry und Asterisk zu bauen und nachdem die Grundfunktion damals gegeben war, verschwand das Projekt wieder in der Versenkung und wurde nie fertig gestellt.

Nachdem wir im beruflichen Umfeld immer mehr mit Simulation arbeiten und diese aufgrund technischer Änderungen in unserem Schulungszentrum nicht mehr mit dort vorhandenen „Bordmitteln“ aufbauen können, braucht es nun doch wieder einen „Wunderkasten“.

Welche Funktionen sollte das System haben
  • bis zu 3 Leitstellenplätze
  • bis zu 2 Regieplätze
  • verschiedene Leitungen (Amt, 112, 19222, 116117)
  • aus der Regie müssen gezielt Anrufe an die verschiedenen Leitungen in der Leitstelle getätigt werden können und in der Leitstelle muss eine Unterscheidung der angerufenen Leitung  möglich sein
  • die Regie soll verschiedene abgehende Rufnummern simulieren können (Spoofing)
  • die Leitstelle muss beliebige Rufnummern anrufen können und in der Regie muss ersichtlich sein, welche Rufnummer die Leitstelle angerufen hat
  • Die Funktionen der TK-Anlage sollen in der Leitstelle möglichst ohne jegliche Einweisung nutzbar sein
  • Die Anrufe sollen wie in der echten Leitstelle aufgezeichnet werden. Sie sollen an den Plätzen auch als „Kurzzeitdoku“ zur Verfügung stehen
  • Die aufgenommenen Anrufe sollen am Ende der Simulation aus der Regie einfach gelöscht werden können
  • Für eine spätere Anbindung einer Mini-Leitstellen-Software sollen Daten der TK-Anlage über eine Datenbank/Schnittstelle nutzbar sein
Umsetzung

Wie bereits in der 2015er-Version ist der Kern ein Raspberry (Pi3b+ mit Raspbian Buster Lite) und ein Asterisk (16.2.1 mit de-Sounds). Auf die Installation von Raspbian und Asterisk werde ich nicht weiter eingehen.

Als Hardware-Telefone werden OpenStage 40 SIP zum Einsatz kommen, da diese bei Pollin gerade mal wieder für knapp 10 Euro zu haben sind. Dazu gibt’s einen gebrauchten PoE-Switch von HPenterprise aus der Bucht.

Anrufe aus der Regie

In der Regie wird für jedes Telefon nur ein SIP-Account im Asterisk eingerichtet. Für die Anrufsimulation gibt es einen umfangreichen Kontext, in dem die Ziel-Leitungen der Leitstelle gezielt ansprechbar sind und abgehenden Rufnummern per Nachwahl gesetzt werden können.

  • Bei Wahl einer beliebigen Nummer, wird diese Rufnummer als Anrufernummer auf der Amtsleitung der Leitstelle signalisiert. Wird lediglich eine 0 gewählt, erfolgt ein anonymer Anruf.
  • Ein Anruf auf der 112 wird mit einer zufälligen Nummer auf der Notrufleitung in der Leitstelle signalisiert. Wird an die 112 eine Rufnummer angehängt, wird diese als Anrufernummer gesetzt.
  • Die Sondernummern 19222 oder 116117 werden ohne weitere Nachwahl als anonymer Anruf auf der jeweiligen Leitung in der Leitstelle signalisiert. Mit angehängter Rufnummer wird wie bei 112 die Anrufernummer gesetzt.
  • mit einer 1 als Nachwahl hinter der 112 oder den Sondernummern wird eine zufällige Handynummer als Absender erzeugt. Eine 5 erzeugt eine Festnetznummer aus der Bereich 0555x.
Anrufe aus der Leitstelle

In der Leitstelle erhält jedes Telefon vier SIP-Accounts (Amt, 112, 19222, 116117) um eine Unterscheidung der angerufenen Leitung am Endgerät zu ermöglichen. Abgehende Anrufe sind nur über die Leitung „Amt“ möglich. Versucht man über die anderen Leitungen abgehend zu telefonieren kommt eine entsprechende Fehleransage.

Grundsätzlich sind alle Rufnummern von der Leitstelle aus an- bzw. rückrufbar. Eine Ausnahme bilden die anonymen Anrufe, die ebenfalls mit einer Fehleransage beendet werden.

Aufzeichnung der Anrufe

Alle Anrufe, die über die Anrufsimulation in die Leitstelle gehen oder von dort geführt werden, werden als WAV-Datei in einem Ordner abgespeichert. Sie stehen damit in einem späteren WebTool als Kurzzeitdokumentation an den Leitplätzen zur Verfügung.

Die Regie kann die Anrufe ebenfalls nochmals anhören und später im Debriefing der Simulation verwenden. Wenn der Simulationsdurchgang abgeschlossen ist, können die Aufzeichnungen per Telefoncode direkt gelöscht werden.

Anrufe, die gezielt an eine Nebenstelle in der Leitstelle oder der Regie geführt werden, sind von der Aufzeichnung ausgenommen.

Bereitstellen von Anrufdaten

Für alle Anrufe wird bei Beginn ein Datensatz in einer Datenbank angelegt. Hier werden bereits die Anrufernummer, das Anrufziel, der „Platz“ von dem er gestartet wurde sowie der Name der WAV-Datei gespeichert. Wenn eine Annahme des Anrufes erfolgt, wird der „Platz“ der Annahme gespeichert. Beim Beenden des Gespräches erfolgt ein weiterer Zeitstempel im Datensatz.

Damit sind dann später in einem WebTool alle anstehenden, alle aktiven sowie die beendeten Gespräche nachvollziehbar und alle notwendigen Daten für die Kurzzeit-Doku vorhanden.

In einem weiteren Schritt soll an diese Datenbank ein Mini-ELR als WebApp anknüpfen, um Einsätze zu verwalten und diese mit Anrufern zu verknüpfen – aber das ist noch Zukunftsmusik.

Was als nächstes kommt

Ich warte auf die Telefon-Hardware, denn bisher erfolgten nur kleine Tests per Softphone. Eine „Auslastung“ der Leitstelle konnte damit noch nicht getestet werden.

Das erste WebTool für das Anrufmanagement steht relativ weit oben auf der Liste. Auf der Leitstellenseite wird es primär als Anzeige dienen, die Kurzzeitdoku realisieren und vielleicht irgendwann Rückruffunktion bieten. Auf der Regieseite soll das Tool vorbereitete Rufnummer wählen können, so dass in Szenarien möglichst realistisch erneute Anrufe, Anrufe aus dem selben Ort, etc. per Klick erzeugt werden können.

… und dann schauen wir mal 😉

weiter zu: Teil 2 – Konfiguration der Telefone

Raspberry

Raspberry Pi 4 4GB als Desktop-Ersatz

Kurzer Ausflug in die Vorgeschichte … nachdem ich bereits mit dem 3b einen Dual-Screen-Desktop aufgesetzt hatte, diesen dann aber aufgrund der geringen Leistung nicht alltagstauglich fand, konnte ich einen Samsung Thinclient TX-WN für nicht mal 50 Euro aus der Bucht erobern. Dieser kommt mit allen gängigen Anschlüssen (2x DVI, USB3, Gigabit-LAN) daher und hat 2GB RAM und eine 16GB SSD mit Win7 embedded. Letzteres  fand ein schnelles Ende und wurde durch Lubuntu 18.04 LTS ersetzt. Das Setup lief besser als der Pi 3b, braucht allerdings mehr Platz auf dem Schreibtisch, setzt mehr Energie (12W laut Herstellerangabe, davon gefühlt 100% als Wärme) um und zeigte im Chromium bei Facebook und Youtube seine Schwächen.

Raspberry Pi 4b 4GByte

Mit Freude erwartete ich nun den Pi4, dessen neue Hardware etwas mehr Performance versprach:

  • 1,5 GHz -Quadcore
  • 4 GByte DDR4-RAM (gibt auch 1 oder 2 GByte-Versionen)
  • 2x USB 3.0, 2x USB 2.0
  • Gigabit Ethernet
  • 2x Micro-HDMI für Dualscreen-Betrieb in 4K
  • WLAN 2,5 & 5 GHz
  • Bluetooth 5.0

Ich habe eine Weile gewartet und wollte erstmal die Kinderkrankheiten abwarten, denn es gibt unter anderem einen Bug im Bereich der neuen USB-C Spannungsversorgung – da ich aber eh ein eigenes Netzteil verwenden will, stört es mich nicht und ich wollte einfach nicht länger warten.

Eine Funktion der 3er-Serien hat leider aufgrund neuer Bootloader-Strategie auf EEPROM noch keinen Einzug bei Pi4 gefunden: der Systemstart via USB oder Netzwerk (PXE). Schade, denn ich wollte den neuen Bewohner gerne komplett von einem USB-SSD-Speicher betreiben – so muss die SD leider weiterhin die boot-Partition liefern und dann an den SSD-Stick übergeben.

Einkaufsliste

Nun aber mal zu den Fakten, in diesem Fall die Einkaufsliste:

  • Raspberry Pi 4b 4 GByte
  • SanDisk Ultra 16GB SDHC
  • SanDisk Extreme PRO 128GB SSD-Stick
  • GeeekPi Gehäuse mit Kühlkörpersatz (4 Stück) und 40mm-Lüfter
  • Beris 5V / 3A Netzteil mit Schalter und USB-C
  • 2 x Micro-HDMI auf HDMI-Buchse

Gesamtkosten 150 Euro – vielleicht kein Schnäppchen, aber ein Quadcore PC mit 4 GB RAM und 128 GB SSD, der weniger Platz auf dem Schreibtisch braucht als mein Locher – verlockend !

Die erste(n) Installation(en)

Vorweg – ich bin kein Freund von Geräuschen am Schreibtisch, deswegen habe ich den 40mm-Lüfter beim Zusammenbau des Gehäuses erstmal nicht angeschlossen. Die passiven Kühlkörper(-chen) wurden brav montiert (verstehe auch nicht, wie man nen Pi ohne betreiben kann).

Als erstes habe ich ein Raspbian Lite auf die SD und den SSD-Stick kopiert. Dabei habe ich mich an der Anleitung von James Chambers orientiert und die SD als boot-Device und den Stick als root-Device verknüpft. Ein erster Start machte mich fast sprachlos, denn der Pi bootete in gerade mal 20 Sekunden bis zum Login.

Ich versuchte dann das Lite zum LXDE aufzuwerten und stellte aber fest, dass es irgendwie nicht so harmonierte, wie ich es mir vorgestellt habe. Scheinbar werden doch irgendwie nicht alle Pakete so installiert, als wenn ich Raspbian Full nehme. Es gelang mir zum Beispiel nicht Anydesk zum laufen zu bringen.

Zeit noch mal was anderes zu probieren: ich nahm ein Lubuntu-Arm64 und hoffte auf mein gewünschtes und gewohntes LXDE-Linux. Das startete im grafischen Desktop ebenfalls deutlich unter 30 Sekunden, aber es gelang mir auch in diesem Setup nicht Anydesk zu installieren, weil dies offensichtlich nicht mit Arm64 kompatibel ist.

das endgültige Setup mit Rasbian Full und LXDE

Na ist ja nicht schlimm, im dritten Anlauf kommt halt Raspbian Full auf Karte und Stick. Die notwendigen Schritte nun schon fast auswendig beherrschend ist das ganze in gut 5 Minuten bootbar und der Raspbian Desktop wird nach gerade mal 23 Sekunden angezeigt.

LXDE, Chromium und Anydesk installiert um einen ersten Vergleich zum Samsung-Thinclient herstellen zu können. Alles startet sehr schnell, die Webseiten scrollen flüssig (insbesondere Facebook, dass auf dem Samsung oft für Probleme sorgte) und auch Youtube läuft ruckelfrei. Nun folgte ein bisschen Feintuning, Aussehen anpassen, gewohnte Software installieren, Netzwerk-Links und Desktop-Starter installieren – immer wieder beeindruckt, wie schnell der Raspi Zugriffe im Dateisystem erledigt und neu startet – auch mit mehr Software im Gepäck.

Kühlen wird Pflicht

Nun kam die Stunde der Wahrheit: er soll endlich mal im Dual-Screen-Betrieb zeigen, was er kann und ich mache es kurz – er tut, was er soll. Im Betrieb ohne Lüfter mit ein bisschen Internetnutzung kommt die CPU auf 72 °C. Bei intensiver Nutzung mit mehreren Fenstern und vielen Zugriffen im Dateisystem erreichte er dann irgendwann die 80 °C-Grenze und zeigte das Symbol für Temperaturwarnung oben rechts im Bild an. Für mich war der Zeitpunkt gekommen ihn nun aktiv zu kühlen – mit Lüfter ging er dann auf rund 50 °C runter. Für mich stehen damit 2 Dinge fest: es braucht einen leisen 40mm-Lüfter und eine kleine GPIO-Steuerung, die den Lüfter ansteuert, wenn die Temperatur hoch geht.

Fazit

Nach einem Tag Raspberry 4b 4GB als Desktop-Ersatz kann ich sagen, dass ich den Kauf nicht bereut habe. Er läuft und erledigt die Alltagsaufgaben mit sehr guter Performance im Vergleich zum Samsung TX-WN und dem davor genutzten Pi 3b+. Insbesondere das echte Gigabit-LAN und der SSD-Stick bringen in vielen Dingen den nötigen Durchsatz und Dual-Screen ist nun ohne Bastelarbeiten (Gert-Board) und Kernel-Patch out-of-the-box möglich.

 https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/