Projekt: Temperatur-Messsystem - Web-Modul


Menübild

Letzte Bearbeitung: 28.07.2018

Symbol Downloads
Schaltplan für Pegelwandler, einfache Variante
Schaltplan für Pegelwandler, Variante für den Anschluss der Matrixuhr
Stückliste mit Empfehlungen zur Bauteilbestellung
Software-Paket v4.00 für Raspberry Pi vom 26.07.2018web-modul-files-v400.tar.gz
Raspberry Pi Homepage - Downloads („Raspbian Stretch Lite“)https://www.raspberrypi.org/downloads/raspbian/
Homepage von Win32 Disk Imager (Images auf Speicherkarten schreiben oder von Speicherkarten lesen) https://sourceforge.net/projects/win32diskimager/
Homepage von PuTTY (SSH-Client)http://www.putty.org/
Homepage von Advanced IP Scanner (Netzwerk durchsuchen) https://www.advanced-ip-scanner.com/
Homepage von FileZilla Client (Dateien vom und zum Raspberry Pi übertragen) https://filezilla-project.org/
Symbol Inhaltsverzeichnis
BeschreibungAllgemeine Informationen über das Web-Modul
SchaltungBeschreibung der Schaltung des Web-Moduls
HardwareBilder und Hinweise zum Aufbau des Web-Moduls
SoftwareBeschreibung der Software des Web-Moduls
InbetriebnahmeInbetriebnahme des Web-Moduls
UpdateUpdate auf die aktuelle Version 4.00
KonfigurationKonfiguration des Web-Moduls
BedienungBedienung des Web-Moduls (Beschreibung der Web-Seiten)
SonstigesEinige weitere Informationen zum Web-Modul
SymbolBeschreibung

Das Web-Modul ermöglicht die Anzeige der aktuellen Sensordaten und Alarme des Temperaturmesssystems über einen Web-Browser. Außerdem werden die Sensordaten 10 Jahre lang in einer speziellen Datenbank aufbewahrt und lassen sich ebenfalls mittels Web-Browser grafisch darstellen. Alle im heimischen LAN oder WLAN angeschlossenen Geräte können auf das Web-Modul zugreifen und bei entsprechender Konfiguration des Routers ist sogar ein weltweiter Zugriff möglich. Dieses Projekt unterscheidet sich von den meisten anderen Projekten dieser Seite dadurch, dass hier weitgehend fertige Hardware zum Einsatz kommt und zwar in Form eines Raspberry Pi. Dieser hat praktisch alle erforderlichen Hardware-Komponenten an Bord und benötigt nur einen einfachen Pegelwandler zum Einlesen der Sensor- und Alarm-Daten vom Sensormodul. Weiterhin besteht die Möglichkeit, über einen erweiterten Pegelwandler eine Matrixuhr mit Daten zu versorgen. Als Betriebssystem kommt Linux (Raspbian Stretch) zum Einsatz, Perl-Programme lesen die Sensor- und Alarm-Daten, schreiben diese in Dateien und außerdem zyklisch in eine Datenbank. Der Web-Server lighttpd und einige HTML/PHP-Dateien bereiten die Daten schließlich so auf, dass sie von einem Web-Browser dargestellt werden können. Für die Datenbank und die grafische Anzeige wird RRDTool verwendet. Die aktuellen Sensorwerte werden nicht nur angezeigt, sondern auch bewertet. So kann für jeden Sensor ein unterer und ein oberer Grenzwert definiert werden und bei Unter- bzw. Überschreitung wird der Sensorwert rot angezeigt. Auch ein Sensorausfall wird registriert und entsprechend angezeigt. Die Anzeige der Alarme kann ebenfalls konfiguriert werden und je nach Zustand erscheint der Alarmstatus farbig. Weiterhin kann ein Alarm-Log mit bis zu 100 Ereignissen angezeigt werden. Weitere Seiten dienen zur Konfiguration des Web-Moduls und zur Anzeige der Auslastung des Web-Servers und des Linux-Systems.

Die komplette Seiten-Struktur des Web-Moduls wurde in HTML5 erstellt. Zum Anzeigen der Seiten genügt ein Standard-Browser und es wird komplett auf Skripte und sonstige Erweiterungen wie z.B. Java oder Flash verzichtet. Damit lässt sich das Web-Modul praktisch über jeden Browser aufrufen, auch von Mobilgeräten. Zum Aufbau und zur Inbetriebnahme sind keine speziellen Kenntnisse über Linux und Programmiersprachen notwendig - ich beschreibe alle nötigen Tätigkeiten Schritt für Schritt. Dennoch schadet es nicht, sich intensiver mit Linux und dem Raspberry Pi zu beschäftigen. Insbesondere bei der Fehlersuche sind einige Kenntnisse sehr hilfreich. Für mich war das gesamte Projekt übrigens auch ein Neuanfang, aber es hat viel Spaß gemacht und den Horizont etwas erweitert :-)

SymbolSchaltung

Das Web-Modul besteht hauptsächlich aus einer fertigen Raspberry-Pi-Platine, wobei hier alle aktuellen B-Modelle (mit Netzwerkanschluss) verwendet werden können. Zusätzlich wird ein Pegelwandler benötigt, um die über RS-232 vom Sensormodul gelieferten Daten auf den 3,3V-Pegel des Raspberry Pi umzusetzen. Für diesen Pegelwandler gibt es 2 Varianten: eine einfache, die nur für den Datenempfang vom Sensormodul genutzt werden kann und eine erweiterte, die zusätzlich einen RS-232-Sender enthält. An diesen lässt sich eine Matrixuhr anschließen und mit Daten versorgen. Optional kann noch eine Echtzeituhr (RTC) ergänzt werden, damit der Raspberry Pi nach einem Neustart ohne Internetverbindung auf eine gültige Zeit zugreifen kann. Für den Betrieb des Web-Moduls ist die Uhr grundsätzlich nicht erforderlich. Falls man allerdings weitere Anwendungen auf dem Web-Modul nutzen möchte, die auf eine genaue Zeit angewiesen sind (bei mir läuft z.B. noch „Fhem“ für die Haussteuerung), dann empfiehlt sich der Einbau der Uhr.

Es gibt noch eine weitere Möglichkeit für die Datenkommunikation mit dem Sensormodul. Mit einem fertigen USB-RS232-Wandler, welcher an einen freien USB-Port des Raspberry Pi angeschlossen wird, können ebenfalls die seriellen Daten des Sensormoduls gelesen werden. Dies erspart den Aufbau einer Pegelwandler-Platine und ist unter Umständen die einzige Alternative, wenn die RS-232-Schnittstelle des Raspberry Pi von einer anderen Anwendung benutzt wird. Die seriellen Daten vom Sensormodul werden dann dem 9-poligen D-Sub-Anschluss des Wandlers zugeführt. Die Anschlussbelegung ist identisch mit dem PC-Anschluss, der im Kapitel Datenkommunikation beschrieben wird. Hier können auch die Daten für eine Matrixuhr abgegriffen werden (Pin 3 und Pin 5). Bei Verwendung eines solchen Wandlers muss ein Programm angepasst werden, dies wird im Abschnitt Inbetriebnahme beschrieben.

Schaltung Ist keine Matrixuhr vorgesehen, dann kann man den nebenstehenden einfachen Pegelwandler aufbauen. Über die Buchse J2 gelangen die seriellen Daten des Sensormoduls mit den typischen RS-232-Pegeln von maximal ±12V über R1 an den Transistor T1. Dieser ist am Kollektor-Ausgang über R2 mit der 3,3V-Versorgungsspannung des Raspberry Pi verbunden, so dass hier neben der notwendigen Invertierung auch eine Pegelanpassung auf 3,3V stattfindet. Der Kollektor-Ausgang von T1 ist an Pin 10 des Raspberry-Pi-Anschlusses J1 geführt. Hier befindet sich der Anschluss UART0_RXD, über den der Raspberry Pi die seriellen Daten einliest. Die Diode D1 leitet negative Eingangsspannungen ab und schützt den Eingang. Für J2 habe ich eine Hohlstecker-Verbindung gewählt. Die eigentlich für Stromanschlüsse gedachten Stecker eignen sich am besten für diesen Zweck und lassen sich gut im Raspberry Pi-Gehäuse unterbringen. Es besteht auch keine Gefahr, falls hier versehentlich ein Netzteil angeschlossen wird - der Eingang ist gut geschützt und auch das Netzteil wird keinen Schaden nehmen.

Der mit einer gestrichelten Linie umrahmte Schaltungsteil enthält die Bauteile für die optionale Echtzeituhr. Diese besteht aus dem Uhren-IC DS1307, welches vom Raspberry Pi mit +5V gespeist wird. Zusätzlich ist noch die Lithium-Knopfzelle Bat1 vorhanden, die bei einer Stromunterbrechung die Uhr am Leben erhält. Die Uhr nutzt mit Q1 einen typischen Uhrenquarz mit einer Frequenz von 32,768 kHz. Über eine I²C-Verbindung mit den beiden Leitungen SCL und SDA erfolgt die Kommunikation mit dem Raspberry Pi.

Alle benötigten Bauteile sind in dieser Stückliste zu finden.

Schaltung Möchte man eine Matrixuhr direkt über ein Kabel vom Web-Modul ansteuern, dann ist es notwendig, den nebenstehenden erweiterten Pegelwandler aufzubauen. Bei dieser Variante wird anstatt der einfachen Transistorschaltung ein Schnittstellentreiber-IC MAX3232 verwendet, welches neben 2 Empfängern auch 2 Sender bereitstellt. Mithilfe der Kondensatoren C2-C5 erzeugt das IC die notwendigen Spannungen für die RS-232-Signale. IC2 wird mit 3,3V versorgt, somit haben die Pegel zum Raspberry Pi ebenfalls dieses Spannungsniveau. Über die Buchse J2 gelangen die seriellen Daten des Sensormoduls zunächst auf den Empfängereingang R1In von IC2, werden dort invertiert und dann über R1Out an Pin 10 des Raspberry-Pi-Anschlusses J1 geführt (UART0_RXD). Die für die Matrixuhr bestimmten Daten werden an Pin 8 von J1 (UART0_TXD) abgenommen und an T1In von IC2 geführt, wo ebenfalls eine Invertierung und Pegelanpassung erfolgt. Das Sendesignal mit einem Pegel von ungefähr ±6V gelangt dann von T1Out des IC2 an die Buchse J3. Auch bei dieser Variante wurden Hohlstecker-Verbindungen verwendet. Hier möchte ich aber nicht dafür garantieren, dass der versehentliche Anschluss eines Netzteil an J2 oder J3 ohne Folgen bleibt, also Vorsicht und am besten alle Anschlüsse gut beschriften.

Der mit einer gestrichelten Linie umrahmte Schaltungsteil enthält die Bauteile für die optionale Echtzeituhr. Dieser Teil ist identisch mit der Schaltung des einfachen Pegelwandlers und wurde dort bereits beschrieben.

Alle benötigten Bauteile sind in dieser Stückliste zu finden.

Für beide Schaltungsvarianten gilt: J1 war bei den älteren Raspberry-Pi-Modellen 26-polig und ist bei den aktuellen Varianten 40-polig. Da die zusätzlichen Anschlüsse nicht benötigt werden, kann man sowohl einen 26-poligen als auch einen 40-poligen Steckverbinder verwenden.

Hinweis: Soll eine Matrixuhr mit dem Web-Modul verbunden werden, dann ist mit der aktuellen Software von Web-Modul und Matrixuhr keine direkte Kabelverbindung mehr notwendig. Die Matrixuhr bekommt einen eigenen Raspberry Pi (die kleine und preiswerte Variante Raspberry Pi Zero WH) und die Datenkommunikation zwischen Web-Modul und Matrixuhr erfolgt dann über das Heimnetzwerk (WLAN). Somit ist in jedem Fall der einfache Pegelwandler ausreichend.

SymbolHardware

Symbol Einfacher Pegelwandler

Hinweis: Der auf den folgenden Bildern gezeigte einfache Pegelwandler wurde im Jahr 2013 aufgebaut. Zu dieser Zeit war nur das Raspberry-Pi-Modell 1 verfügbar und dieses hatte ein anderes Platinenlayout als die aktuellen Modelle. Die Pegelwandler-Platine passt deshalb nicht auf ein aktuelles Raspberry-Pi-Modell und muss anders gestaltet werden.

Web-Modul-Bild1 Hier wurde der einfache Pegelwandler ohne Echtzeituhr aufgebaut und die Schaltung findet auf einer kleinen Lochrasterplatine Platz. Auf der rechten Seite ist die Hohlstecker-Kupplung J2 für den Anschluss des Sensormoduls zu sehen. Diese wurde auf die Platine geklebt, da die Lötverbindung allein etwas wackelig erschien. Links sind die 4 Bauelemente R1, D1, T1 und R2 angeordnet und dahinter befindet sich die Buchsenleiste J1, die später auf den Raspberry Pi gesteckt wird. J1 ist normalerweise 26- bzw. 40-polig, da ich aber hier ein Reststück übrig hatte und nicht alle Anschlüsse benötigt werden, kommt dieses zum Einsatz.

Web-Modul-Bild2 Dieses Bild zeigt die Platine von unten. Die wenigen Verbindungen wurden mit blankem Kupferdraht bzw. mit Kupferlackdraht hergestellt.

Web-Modul-Bild3 Hier wurde die Pegelwandler-Platine auf den Raspberry Pi aufgesteckt. Damit ist die Hardware für die einfache Variante des Web-Moduls komplett.

Web-Modul-Bild4 Dieses Bild zeigt nochmals die komplette Hardware von der Seite. Wichtig ist hier, dass die Bauelemente auf der Pegelwandler-Platine (insbesondere die Kupplung J2) nicht mit dem Anschluss S2 auf dem Raspberry Pi kollidiert.

Web-Modul-Bild5 Hier wurde der Raspberry Pi zusammen mit der aufgesteckten Pegelwandler-Platine ins Gehäuse eingebaut. Für J2 müssen beide Gehäusehälften etwas bearbeitet werden.

Symbol Erweiterter Pegelwandler und Echtzeituhr

Web-Modul-Bild1 Für die erweiterte Schaltungsvariante wird ein etwas größeres Platinenstück benötigt. Hier ist nicht nur Platz für alle Bauteile des Pegelwandlers und der Echtzeituhr, sondern auch für Erweiterungen. Ganz oben befinden sich der Steckverbinder J1, darunter die beiden ICs für die Uhr und den RS-232-Treiber mit der notwendigen Außenbeschaltung. Links ist die Batterie nicht zu übersehen und rechts sind die beiden Hohlstecker-Kupplungen J2 und J3 (ganz oben und ganz unten). Dazwischen sind noch zwei kleinere Buchsen zu sehen, die jedoch nicht zum Web-Modul-Projekt gehören, ebenso wie die beiden Transistoren und 6 Widerstände links unten. Dies sind zwei LED-Treiber, die von „Fhem“ (der bereits erwähnten Haussteuerung) verwaltet werden.

Web-Modul-Bild2 Dieses Bild zeigt die Platine von unten. Auch hier wurde wieder mit viel Kupferlackdraht gearbeitet.

Web-Modul-Bild3 Auf diesem Bild wurde die erweiterte Pegelwandler-Platine auf den Raspberry Pi aufgesteckt. Ich verwende hier übrigens einen Raspberry Pi 2 Modell B.

Web-Modul-Bild4 Dieses Bild zeigt nochmals die komplette Hardware von der Seite. Auch hier muss man darauf achten, dass die Zusatzplatine nirgendwo Kontaktflächen des Raspberry Pi berührt. Bei meiner Platine liegen die beiden zusätzlichen Anschlussbuchsen auf dem Display-Steckverbinder auf und sorgen somit zufällig für die optimale Lage. Ich habe auch keine Schrauben verwendet - die Pegelwandler-Platine hat durch den 40-poligen Pfostenstecker genug Halt.

Web-Modul-Bild5 Hier wurde das fertige Web-Modul in ein schickes Gehäuse aus Plexiglas von ELV eingebaut. Für die Anschlüsse J2 und J3 müssen entsprechende Aussparungen ins Gehäuse gesägt werden. Wichtig ist die Beschriftung, damit die Datenleitungen nicht versehentlich vertauscht werden.

SymbolSoftware

Die Software des Web-Moduls ist sehr komplex, aber es gibt bereits viele fertige Anwendungen, die für dieses Projekt verwendet werden können. Dazu gehört das Betriebssystem Linux (Raspbian Stretch), der Web-Server lighttpd sowie RRDTool, welches Datenbanken verwaltet und deren grafische Auswertung ermöglicht. Außerdem wird noch mosquitto eingesetzt, das für die Verteilung der Daten im Netzwerk zuständig ist. Alle genannten Programme sind als Open-Source-Projekte kostenlos verfügbar und werden ständig weiterentwickelt. Weiterhin sind noch einige Programme und Dateien für spezielle Aufgaben erforderlich, die von mir erstellt wurden.

Symbol Einlesen und Auswerten der Daten vom Sensormodul

Für diese Aufgabe wurde ein Programm in Perl geschrieben. Das Programm sensor.pl besteht zunächst aus einer Reihe von Variablen-Deklarationen. Hier werden unter anderem 3 Verzeichnisse festgelegt, die für die Arbeit des Programms wichtig sind. Damit lässt sich das Programm auch auf andere Systeme anpassen, für den Einsatz auf dem Raspberry Pi sollte hier jedoch nichts verändert werden. Die Deklarationen haben folgende Funktion:

my $sendir = "/mnt/ram";In dem hier angegebenen Verzeichnis werden alle empfangenen Sensor- und Alarmdaten abgelegt. Dieses Verzeichnis befindet sich in einer RAM-Disk, um die Speicherkarte zu schonen. Die Alarmdaten haben die Namen al1 - al4, der Inhalt besteht aus dem Wert 0 oder 1 und einem Line Feed (ASCII 10). Sensordaten werden mit den Namen s1, s2, s3, ... s31 gespeichert und enthalten immer einen 5 Zeichen langen Wert und ein abschließendes Line Feed (ASCII 10).
my $cfgdir = "/srv/sensor";In diesem Verzeichnis wird das Alarmlog alog, die Sensorbelegung sen und die Sensor-Zuordnungsdatei map abgelegt. Später kommen hier noch verschiedene Dateien für den Web-Server hinzu: die Alarmkonfiguration al1 - al4, die Sensorkonfiguration s1 - s31 und die Passwortdatei pass. Auch die Datenbanken für die Sensordaten sensor.rrd und die Systemauslastung system.rrd werden hier gespeichert.
my $senif = "/dev/serial0";Dies ist der Gerätename der seriellen Schnittstelle des Raspberry Pi (UART0). Über diese Schnittstelle werden die seriellen Daten des Sensormoduls empfangen. Wird anstatt der Pegelwandler-Platine ein USB-RS232-Wandler angeschlossen, dann muss der Name /dev/ttyUSB0 verwendet werden.

Das Programm sensor.pl liest zunächst die Sensor-Zuordnungsdatei map ein, sofern sie vorhanden ist, und prüft, ob der MQTT-Server mosquitto installiert ist. Falls dies zutrifft, dann wird die MQTT-Funktion aktiviert. Nach dem Einlesen der Konfigurationsdateien wird dann in eine Endlosschleife übergegangen. Dabei wird die serielle Schnittstelle zum Lesen geöffnet und auf eingehende Daten gewartet. Sobald ein Sensor- oder Alarmwert oder auch eine Sensorbelegung empfangen wird, erkennt das Programm an der Länge der Zeichenkette den Datentyp und bearbeitet diesen in einem separaten Programmabschnitt. Bei 3 Zeichen handelt es sich um eine Alarmmeldung, die gleich im ersten Abschnitt bearbeitet wird. Hier wird eine Plausibilitätsprüfung durchgeführt und die Alarmnummer sowie der Alarmwert ermittelt. Vor dem Speichern dieser Daten erfolgt ein Vergleich mit dem zuvor gespeicherten Alarmwert. Damit wird festgestellt, ob sich der Alarmstatus geändert hat und in einem solchen Fall wird eine neue Meldung ins Alarm-Log geschrieben. Ein neuer Log-Eintrag erscheint dabei immer an erster Stelle. Beim Empfang von 7 Zeichen handelt es sich um einen Sensorwert, dessen Auswertung im nächsten Programmabschnitt erfolgt. Hier wird zunächst entsprechend der Sensorkennung ermittelt, ob es sich um einen Temperatur-, Luftdruck- oder Luftfeuchtigkeitswert handelt und abhängig vom Sensortyp ein Plausibilitätstest durchgeführt. Anschließend wird die richtige Sensornummer aus der zuvor geladenen Zuordnungsdatei geholt und der Sensorwert gespeichert. Der letzte Programmteil behandelt den Empfang einer 8 Zeichen langen Sensorbelegung. Auch hier erfolgt ein Plausibilitätstest, anschließend wird die Anzahl der Sensoren ermittelt und das Ergebnis zusammen mit der Sensorbelegung gespeichert.
Bei jedem Schleifendurchlauf wird außerdem geprüft, ob die Änderungsdatei change vorhanden ist. Diese generiert der Web-Server, wenn eine Änderung an der Konfiguration durchgeführt wurde. Ist diese Datei vorhanden, dann wird sie zunächst wieder gelöscht und anschließend die geänderte Konfiguration eingelesen.

Das Alarm-Log ist übrigens folgendermaßen aufgebaut:

12.06.2018 15:19:32 11
12.06.2018 15:18:37 10
12.06.2018 14:19:32 31
12.06.2018 14:19:29 30

Jede Zeile enthält das Datum, die Uhrzeit, 2 Ziffern und ein Line Feed (ASCII 10) als Zeilenabschluss. Die erste Ziffer repräsentiert die Alarmnummer (1-4), die zweite Ziffer den Alarmwert (0 oder 1). Alarmnummer und -wert werden später auf der Web-Seite durch entsprechend konfigurierte Namen ersetzt.

Symbol Speichern der Sensorwerte in einer Datenbank

Alle Sensordaten werden zyklisch in einer Datenbank gespeichert. Diese ist so organisiert, dass alle 15 Minuten ein neuer Wert von allen Sensoren aufgenommen und bis zu 40 Tage lang aufgehoben wird. Gleichzeitig wird bei jedem Tageswechsel aus diesen Daten ein Mittelwert, ein Minimalwert und ein Maximalwert gebildet und diese Werte bleiben bis zu 10 Jahre gespeichert. Für die Verwaltung der Datenbank kommt hier das Programmpaket RRDTool zum Einsatz. Dieses verwaltet nicht nur die Daten, sondern kann diese auch grafisch darstellen. Damit die Sensordaten wie gewünscht in die Datenbank gelangen, wird ein zusätzliches Programm benötigt. Das Programm senupdate.pl wurde in Perl geschrieben und enthält zunächst einige Variablen-Deklarationen. Hier werden unter anderem die Arbeitsverzeichnisse und der Name der Datenbank festgelegt. Diese Daten kann man ändern, um das Programm an andere Umgebungen anzupassen, beim Raspberry Pi sind jedoch keine Änderungen notwendig. Dieses Programm läuft im Gegensatz zum bereits erwähnten sensor.pl nicht ständig und wird nur zu bestimmten Zeiten aufgerufen. Für den richtigen Zeitpunkt sorgt der Linux-Dienst cron, er startet das Programm alle 15 Minuten (Minute 0, 15, 30 und 45). Nach dem Start sammelt das Programm alle verfügbaren Sensorwerte ein und prüft, ob die Werte aktuell sind. Anschließend werden über einen RRDTool-Programmaufruf die Sensorwerte in die Datenbank übertragen und das Programm wieder beendet.

Ein weiteres Programm möchte ich auch noch erwähnen: Bevor Sensorwerte in die Datenbank geschrieben werden können, muss zunächst eine Datenbank erstellt werden. Dafür habe ich das Shell-Skript sencreate.sh erstellt, welches die Datenbank mit den oben beschriebenen Eigenschaften erstellt.

Symbol Präsentieren der Daten als Web-Seite

Für diese Funktion wird ein Web-Server auf dem Raspberry Pi installiert. Obwohl auch der bekannte Apache auf dem Raspberry Pi läuft, wird wegen der etwas knappen Ressourcen der schlankere lighttpd verwendet. Damit ist es möglich, die aktuellen Sensor- und Alarmwerte sowie grafische Kurvenverläufe auf einer Web-Seite darzustellen. Dazu wird grundsätzlich ein HTML-Gerüst verwendet und PHP-Kode darin eingebettet. Der Web-Server verarbeitet diesen PHP-Kode beim Aufruf der Seite und baut dessen Ergebnis in die HTML-Struktur ein.

Im Download-Paket ist eine vorgefertigte Web-Seite enthalten, die man an die eigene Sensor-Konfiguration anpassen kann. Die Seite besteht aus einem Menü-Kopf, über den man die folgenden 7 Unterseiten aufrufen kann:

 Sensoren 
(Hauptseite)
Auf dieser Seite erscheint eine Übersicht mit allen Sensorwerten und Alarmen in Form eines stilisierten Hauses. Die anzuzeigenden Daten können wahlweise als Text-Elemente in 2 Größen oder als Grafik-Element dargestellt und beliebig positioniert werden. Dies erfolgt über die Seite  Konfiguration 
 Tabellen Auf dieser Seite erscheint eine einfache Übersicht mit allen Sensorwerten und Alarmen in Form von Tabellen.
 Grafik Diese Seite ermöglicht die grafische Darstellung der Sensorwerte als Kurvenverlauf. Dabei lassen sich bis zu 4 Kurven gleichzeitig in einem Diagramm anzeigen. Unterhalb der Grafik befindet sich ein Menü, mit dem man die anzuzeigenden Daten und den Zeitraum festlegen kann. Über Navigations-Buttons kann man zum vorherigen oder nächsten Intervall springen oder auch zu den aktuellen Daten zurückkehren. Weiterhin lassen sich bis zu 20 Einstellungen als Preset speichern und wieder aufrufen.
 Alarme Auf dieser Seite erscheint eine Liste mit den letzten 100 Ereignissen der 4 Alarm-Eingänge des Sensormoduls.
 Konfiguration Diese Seite ermöglicht die Konfiguration der Seite Sensoren sowie die Grundeinstellung für die Sensoren und Alarme.
 Server Über diese Seite lässt sich die Auslastung des Web-Servers anzeigen. Erfasst wird die übertragene Datenmenge und die Anzahl der Anfragen pro Sekunde. Die Anzeige erfolgt in insgesamt 6 Diagrammen.
 System Auf dieser Seite wird über 3 Diagramme die Systemauslastung des Raspberry Pi angezeigt.

Symbol Verteilen der Daten an andere Geräte im Netzwerk

Alle vom Sensormodul empfangenen Daten können an andere Geräte im Netzwerk oder auch an andere Anwendungen auf dem Raspberry Pi weitergegeben werden. Für die Verteilung der Daten ist hier der MQTT-Server mosquitto zuständig. Das bereits beschriebene Perl-Programm sensor.pl dient nicht nur zum Speichern der Sensordaten und Alarminformationen, es baut außerdem eine Verbindung zum MQTT-Server auf und sendet ausgewählte Daten an diesen Server. Andere Programme oder Geräte können ebenfalls eine Verbindung zum MQTT-Server herstellen und die gewünschten Daten abonnieren. Immer wenn ein neues Paket mit Sensordaten oder Alarminformationen beim MQTT-Server eintrifft, dann wird dieses sofort an alle angemeldeten Abonnenten weitergeleitet. Das ermöglicht eine relativ einfache Verteilung der Daten an eine Matrixuhr oder auch an mehrere Matrixuhren. Da MQTT ein standardisiertes Protokoll ist, können die Daten sogar an Geräte geliefert werden, die gar nicht zum Temperatur-Messsystem gehören. Ich nutze diese Möglichkeit, um alle Sensorwerte und Alarmmeldungen zur Haussteuerung „Fhem“ zu übermitteln.

Alle Datenpakete werden beim Versand mit einem eindeutigen Namen versehen (MQTT Topic) und können über dieses Topic von anderen MQTT-Teilnehmern abonniert werden. Auf der Konfigurations-Seite des Web-Moduls kann jedem Sensor und jedem Alarm ein solches MQTT Topic zugeordnet werden. Abonnenten der Daten sind damit vollkommen unabhängig von den Sensor- und Alarm-Nummern des Temperatur-Messsystems. Die folgende Liste zeigt einige Beispiele für MQTT Topics:

Haus/EG/Wohnzimmer/Temperatur
Haus/EG/Wohnzimmer/Luftfeuchtigkeit
Haus/Aussen/Umgebung/Temperatur
Haus/EG/Briefkasten/Status
SymbolInbetriebnahme

Die Inbetriebnahme des Web-Moduls erfordert eine Menge Konfigurationsarbeit. Ich habe diese in mehrere Schritte unterteilt und es sollte erst dann mit dem nächsten Schritt begonnen werden, wenn der vorherige erfolgreich abgeschlossen wurde. Grundsätzlich sollte man sehr sorgfältig vorgehen, insbesondere dann, wenn Systemdateien bearbeitet werden müssen. Ein kleiner Fehler kann durchaus dazu führen, dass das System nicht mehr richtig funktioniert oder gar nicht mehr startet. Es empfiehlt sich, die teilweise recht langen Kommandozeilen in die Zwischenablage zu kopieren und dann im Terminalfenster einzufügen. Wichtig: Immer nur eine Zeile kopieren und erst nach dem Ausführen eines Kommandos die nächste Zeile holen. Nur beim Editieren von Dateien können mehrere Zeilen gleichzeitig übertragen werden. Falls trotz aller Vorsicht das System Probleme macht, dann sollte man nicht lange nach dem Fehler suchen und einfach noch mal von vorn beginnen.

Bei der Beschreibung gehe ich davon aus, dass ein Windows-PC zur Verfügung steht, mit dem die vorbereitenden Arbeiten durchgeführt werden. Diese Arbeiten können selbstverständlich auch mit Linux erledigt werden, diesen Weg habe ich aber nicht ausprobiert. Weiterhin werden alle Einstellungen für eine deutsche Sprachversion beschrieben. Soll ein Web-Modul in einer anderen Sprachversion installiert werden, dann sind abweichende Eingaben erforderlich. Die Beschreibung ist an vielen Stellen sehr knapp gehalten, da der Text sonst zu umfangreich geworden wäre. Bei einigen Schritten habe ich die verwendeten Quellen angegeben. Einige weitere Informationen über den Raspberry Pi, Linux, Perl, HTML und PHP habe ich auf der Seite Links, Software zusammengestellt.

Symbol Schritt 1 - Betriebssystem vorbereiten

Für die Inbetriebnahme eines neuen Web-Moduls ist zunächst ein Betriebssystem für den Raspberry Pi notwendig. Dieses kann man als Image-Datei downloaden und mit einer geeigneten Software auf eine SD-Karte schreiben. Die Karte wird dann in den Raspberry Pi gesteckt und dient sozusagen als Festplatte. Ich habe das Linux-System „Raspbian Stretch“ ausgewählt, welches von der Raspberry Pi Homepage geladen werden kann. Dieses steht in 2 Versionen zur Verfügung: „Raspbian Stretch with Desktop“ und „Raspbian Stretch Lite“. Der hauptsächliche Unterschied besteht darin, dass in der Lite-Version der grafische Desktop fehlt. Dadurch ist es etwas schlanker und kann sogar auf einer 4GB-Karte betrieben werden. Für die Funktion des Web-Moduls wird der grafische Desktop nicht benötigt, deshalb empfehle ich die Lite-Version. Die folgende Beschreibung bezieht sich auf „Raspbian Stretch Lite“ vom 27.06.2018 (2018-06-27-raspbian-stretch-lite.img).

Wir benötigen nun ein Programm, welches das Image auf unsere SD-Karte schreibt. Dazu wird allgemein der Win32 Disk Imager empfohlen und dieser hat sich auch bei mir bewährt. Dieses Programm ist allerdings nicht ganz ungefährlich und das liegt daran, dass es nicht nur auf SD-Karten schreiben kann, sondern auch auf beliebige andere Wechseldatenträger. Wenn man sich bei den Laufwerks-Buchstaben nicht ganz sicher ist, dann kann es passieren, dass man versehentlich eine angeschlossene USB-Festplatte oder einen USB-Stick überschreibt. Deshalb empfiehlt es sich, vor dem Programmstart alle nicht benötigten Wechseldatenträger zu entfernen.

Jetzt wird unser soeben geladenes Raspbian-Image entpackt und die SD-Karte in den Kartenleser des PCs gesteckt. Die SD-Karte sollte mindestens 4GB, besser 8GB groß sein. Bei der Wahl der Geschwindigkeitsklasse gibt es unterschiedliche Meinungen, ich empfehle eine Class-10-Karte wie in der Stückliste. Hier liegt auch ein Adapter bei, mit dem man die microSD-Karte in einen normalen Karten-Schlitz stecken kann. Jetzt wird der Win32 Disk Imager gestartet, bei Image File über das kleine Symbol das Raspbian-Image ausgewählt und im Feld Device sollte der Laufwerks-Buchstabe unserer SD-Karte stehen. Wenn man sich wirklich sicher ist, dann wird über den Button Write der Schreibvorgang gestartet, der einige Zeit dauern kann. Der Win32 Disk Imager ist übrigens auch später noch sehr nützlich, denn man kann damit auch SD-Karten auslesen und somit jederzeit ein komplettes Backup vom System anfertigen und bei Bedarf auch wieder auf die Karte zurückschreiben.

Ist der Win32 Disk Imager mit seiner Arbeit fertig, dann kann das Programm beendet werden. Die SD-Karte bleibt zunächst im Kartenleser gesteckt, da noch eine Datei auf die Karte geschrieben werden muss. Der Hintergrund ist folgender: Das Web-Modul soll „headless“ betrieben werden, also ohne Bildschirm und ohne Eingabegeräte. Auch die komplette Einrichtung wird ohne Zusatzgeräte durchgeführt. Alle Ein- und Ausgaben erfolgen über die Netzwerkverbindung unter Verwendung des SSH-Protokolls. Bei „Raspbian Stretch Lite“ ist die SSH-Funktion aus Sicherheitsgründen in der Voreinstellung ausgeschaltet und muss erst aktiviert werden. Dazu ist es erforderlich, eine Datei mit dem Namen ssh (in Kleinbuchstaben) auf der SD-Karte zu erstellen. Zunächst lassen wir uns mit einem Datei-Manager den Inhalt der SD-Karte anzeigen. Unter Windows ist ein kleiner Bereich der SD-Karte sichtbar und hier erstellen wir eine leere Datei mit dem Namen ssh. Bei Verwendung des Windows Explorers kann man hierfür mit der rechten Maustaste das Kontextmenü aufrufen und über die Auswahl Neu und Textdokument eine Datei anlegen. Wichtig: Die Datei muss ssh heißen und nicht ssh.txt. Leider zeigt Windows in der Voreinstellung bekannte Dateierweiterungen nicht an, deshalb sollte man in der Systemsteuerung und den Ordner-Optionen kontrollieren, dass die Einstellung Erweiterung bei bekannten Dateitypen ausblenden ausgeschaltet ist (kein Haken). Ob die Windows-Einstellung passt, kann man übrigens leicht feststellen: Auf der SD-Karte befindet sich unter anderem auch eine Datei mit dem Namen config.txt. Sollte diese im Datei-Manager nur als config angezeigt werden, dann muss die Einstellung geändert werden.

Die nun fertige SD-Karte wird über die „Auswerfen“-Funktion auf der Windows-Taskleiste vom System abgemeldet und in den noch ausgeschalteten Raspberry Pi gesteckt. Jetzt werden noch ein Netzteil (siehe Stückliste) und ein LAN-Kabel benötigt, letzteres muss mit dem Router oder einem Switch des Heimnetzwerks verbunden werden. Der Raspberry Pi kann auch mit WLAN arbeiten, dafür wird entweder ein Raspberry Pi 3 oder zusätzlich ein USB-WLAN-Stick benötigt (und möglicherweise ein stärkeres Netzteil), außerdem muss noch eine Datei mit den WLAN-Informationen erstellt werden. Darauf möchte ich hier aber nicht eingehen, zumal eine solide Kabelverbindung immer die bessere Wahl ist. Eine Beschreibung für die Inbetriebnahme über WLAN ist übrigens beim Projekt Matrixuhr (Abschnitt Inbetriebnahme, Schritt 3) zu finden.
Die Verbindung zum Sensormodul ist jetzt noch nicht notwendig, die Pegelwandler-Platine sollte jedoch schon aufgesteckt werden. Ist die LAN-Verbindung hergestellt, dann kann die Stromversorgung des Raspberry Pi eingeschaltet werden. Je nach Modell erkennt man den Bootvorgang am Flackern einer LED, außerdem sollte die LAN-Verbindung aktiv werden. Beim ersten Start des Raspberry Pi wird übrigens das Raspbian-System an die Größe der SD-Karte angepasst und anschließend ein Reboot durchgeführt. Man sollte also dem Raspberry Pi beim ersten Start mindestens eine Minute Zeit geben, bevor man versucht, eine Verbindung herzustellen.

Symbol Schritt 2 - Verbindung mit dem Raspberry Pi herstellen

Das Raspbian-System ist so konfiguriert, dass der Raspberry Pi über DHCP vom Router des Heimnetzwerks eine IP-Adresse zugewiesen bekommt. Diese Adresse muss jetzt ermittelt werden und dafür kann man sich entweder in den Router einloggen oder das Freeware-Programm Advanced IP Scanner verwenden, welches alle Geräte im Heimnetz anzeigt. Jetzt wird noch ein SSH-Client auf dem PC benötigt, damit wir eine Verbindung zum Raspberry Pi aufbauen können. Ich habe mich hier für das Freeware-Programm PuTTY entschieden. Die Bedienung ist auch nicht kompliziert: In das Feld Host Name kommt die IP-Adresse des Raspberry Pi, als Beispiel verwende ich hier 192.168.1.12 und im Feld Port steht schon die richtige Nummer 22. Mit einem Klick auf Open wird die Verbindung aufgebaut. Zunächst erscheint jedoch eine Sicherheitswarnung. PuTTY speichert von jedem Server eine Art Fingerabdruck und prüft diesen bei jedem Verbindungsaufbau. So kann man vor dem Login erkennen, ob man mit dem richtigen Server verbunden ist. Von unserem Raspberry Pi liegt dieser Fingerabdruck noch nicht vor und wir haben jetzt die Möglichkeit, mit einem Klick auf Ja den Fingerabdruck zu speichern. Jetzt erscheint die folgende Eingabezeile:

login as: _

Hier geben wir den Benutzernamen pi ein. Anschließend erscheint eine Passwortabfrage, die in unserem Beispiel so aussehen würde:

pi@192.168.1.12's password: _

Hier geben wir das voreingestellte Passwort raspberry ein. Wenn alles geklappt hat, dann erscheinen einige Informationen und zum Schluss der folgende Eingabe-Prompt:

pi@raspberrypi:~ $ _

Sollte PuTTY keine Verbindung zum Raspberry Pi herstellen können, dann kann man zunächst an der Windows-Kommandozeile (cmd.exe) einen Ping versuchen:

ping 192.168.1.12

Damit lässt sich prüfen, ob eine Netzwerkverbindung zur angegebenen IP-Adresse vorhanden ist. Wenn die IP-Adresse richtig ist und der Ping funktioniert, die SSH-Verbindung jedoch nicht, dann wurde offensichtlich der SSH-Server auf dem Raspberry Pi nicht aktiviert. In diesem Fall sollte man den Raspberry Pi wieder ausschalten und nochmals mit dem Schritt 1 beginnen. Wichtig ist, dass eine Datei mit dem exakten Namen ssh erstellt wird. Und nicht vergessen, dass Windows in der Grundeinstellung eine mögliche Datei-Erweiterung (also weitere Zeichen im Namen nach dem Punkt) nicht anzeigt.

Wenn alles geklappt hat, dann kann man noch etwas an der Optik von PuTTY arbeiten. Dazu klickt man auf das kleine Symbol links oben auf der Titelzeile und wählt die Option Change Settings... aus. Hier habe ich in der Kategorie Window die vorgegebene Fenstergröße von 80x24 auf 120x32 vergrößert, damit mehr Informationen im Terminalfenster zu sehen sind. Auch der Zeichensatz ist nicht optimal, diesen kann man in der Kategorie Window - Appearance und Change... ändern, z.B. auf Consolas, 12-point. Alle Einstellungen lassen sich natürlich auch speichern, dies erfolgt in der Kategorie Session. Hier gibt man einen passenden Namen in das Feld Saved Sessions ein und klickt auf Save. Mit Apply wird das Einstellungsfenster wieder geschlossen und zum Terminalfenster zurückgekehrt. Wird PuTTY später erneut gestartet, dann lässt sich die soeben gespeicherte Session durch einen Doppelklick auf den Namen wieder aufrufen.

Symbol Schritt 3 - Betriebssystem konfigurieren

Nachdem PuTTY nun optimal eingerichtet ist, werden wir mit dessen Hilfe das Raspbian-Betriebssystem konfigurieren. Dafür werden Kommandos verwendet, die direkt am Eingabe-Prompt eingegeben werden müssen. Diese Kommandos können durchaus recht lang sein und hier bietet es sich an, diese hier im Browser zu markieren und in die Zwischenablage zu kopieren. Im Terminalfenster von PuTTY kann man dann den Inhalt der Zwischenablage mit der rechten Maustaste an der aktuellen Cursor-Position einfügen. Alle Eingaben am Prompt werden außerdem von Raspbian in einer Historie gespeichert. Mit den Pfeiltasten nach oben und unten kann man durch diese Historie blättern und so ein bestimmtes Kommando nochmals an den Eingabe-Prompt holen. Weiterhin beherrscht Linux eine sehr gute Autovervollständigung, die man mit der Tabulator-Taste auslösen kann. Kommandos, Verzeichnisnamen und teilweise auch Parameter werden dann ergänzt, soweit dies möglich ist. Zeigt sich beim Druck auf die Tab-Taste keine Reaktion, dann gibt es entweder nichts zu vervollständigen oder es stehen mehrere Möglichkeiten zur Auswahl. Letztere werden bei nochmaligem Druck auf die Tab-Taste angezeigt.

Wir geben nun das erste Kommando ein oder kopieren es über die Zwischenablage ins Terminalfenster:

sudo raspi-config

Damit wird das Programm raspi-config gestartet, welches eine menügeführte Einstellung vieler Systemfunktionen ermöglicht. Einige Einstellungen erfordern erweiterte Rechte, diese werden mit dem vorangestellten sudo gewährt. Ist das Programm gestartet, dann werden hauptsächlich die Pfeiltasten, die Tabulator-Taste und Enter verwendet. Los geht's:

Damit sind alle für das Web-Modul notwendigen Systemeinstellungen erledigt. Wir wechseln nun mit Tab auf Finish und drücken Enter. Danach erscheint ein Fenster, in dem ein Reboot angeboten wird, dieses bestätigen wir mit Yes und Enter. Der Raspberry Pi startet nun neu und trennt dabei die SSH-Verbindung. PuTTY zeigt diesen Zustand mit einer Fehlermeldung an. Wir geben dem Raspberry Pi mindestens 45 Sekunden Zeit und bauen die Verbindung wieder auf. Dazu quittieren wir die Fehlermeldung von PuTTY und klicken anschließend auf das kleine Symbol links oben auf der Titelzeile. In dem nun erscheinenden Menü wählen wir Restart Session aus. Es folgt nun wieder die Abfrage von Benutzername und Passwort, wobei ab jetzt das neue Passwort verwendet werden muss. Sollte an dieser Stelle die Verbindung nicht wieder hergestellt werden können, dann hat offensichtlich der Router dem Raspberry Pi eine neue IP-Adresse zugeteilt. In diesem Fall muss man PuTTY beenden und die neue IP-Adresse ermitteln (über den Router oder mit dem Advanced IP Scanner). PuTTY wird nun neu gestartet und eine Verbindung zur aktuellen IP-Adresse des Raspberry Pi aufgebaut.

Symbol Schritt 4 - Netzwerk konfigurieren

Grundsätzlich ist das Netzwerk des Raspberry Pi bereits konfiguriert, anderenfalls wäre keine SSH-Verbindung möglich. Aber es ist so konfiguriert, dass der Raspberry Pi beim Systemstart vom Router des Heimnetzwerks über DHCP eine IP-Adresse zugewiesen bekommt (dynamische IP-Adresse). Das hat leider den Nachteil, dass die IP-Adresse nicht vorhersehbar ist und sich auch jederzeit ändern kann. Zwar erkennen viele Router-Modelle den Raspberry Pi nach einem Neustart wieder und vergeben die gleiche IP-Adresse, trotzdem bietet eine statische Adresse einige Vorteile. So ist das zukünftige Web-Modul immer unter der gleichen IP-Adresse erreichbar und diese Adresse können wir in gewissen Grenzen selbst festlegen.

Zur Vergabe einer statischen Adresse sind 3 Parameter notwendig: die IP-Adresse, die Subnetz-Maske und das Gateway. Mit dem folgenden Kommando kann man sich einige Parameter des Netzwerks anschauen:

netstat -rn

Unsere Beispiel-Konfiguration würde dann folgendes Bild ergeben:
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Das sind typische Werte in einem Heimnetz und hier kann man bereits zwei Parameter entnehmen: Die Subnetz-Maske ist 255.255.255.0 und das Gateway (Adresse des Routers) 192.168.1.1. Nun muss noch die IP-Adresse festgelegt werden, wobei die ersten 3 Teile mehr oder weniger vom Router vorgegeben sind (192.168.1). Den 4. Teil der Adresse können wir aber selbst bestimmen und hier ist es wichtig, dass dieser nicht bereits von einem anderen Gerät im Netz verwendet wird und auch nicht im DHCP-Bereich des Routers liegt. Diese Informationen kann man normalerweise aus dem Router auslesen. Meist sind die Adressen ab 201 frei und so verwende ich bei der folgenden Konfiguration beispielhaft die IP-Adresse 192.168.1.222.

Um eine statische IP-Adresse festzulegen, ist das Bearbeiten einer Konfigurationsdatei des Linux-Systems erforderlich. Hier bietet sich der vorinstallierte Texteditor nano an. Dieser ist nicht schwer zu bedienen, allerdings sind die Funktionen für den Windows-Benutzer etwas ungewohnt. Aber so viele Funktionen muss man sich gar nicht merken, wichtig ist Strg-O zum Speichern einer Datei und Strg-X zum Beenden des Editors. Mit dem folgenden Kommando wird der Texteditor mit erweiterten Rechten gestartet und die zu bearbeitende Konfigurationsdatei geöffnet:

sudo nano /etc/dhcpcd.conf

Wir bewegen nun mit den Pfeiltasten den Cursor an das Ende der Datei und fügen die folgenden Zeilen ein (ich benutze hier die Daten von unserem Beispiel):
interface eth0
  static ip_address=192.168.1.222/24
  static routers=192.168.1.1
  static domain_name_servers=192.168.1.1

In der zweiten Zeile wird die gewünschte IP-Adresse des Raspberry Pi angegeben. Der Wert hinter dem Schrägstrich entspricht unserer Subnetz-Maske in einer anderen Schreibweise. Schreibt man die Subnetz-Maske 255.255.255.0 binär, dann sieht das so aus: 11111111.11111111.11111111.00000000. In der alternativen Schreibweise wird einfach die Anzahl der Einsen angegeben, in diesem Fall 24. Die Adressen in Zeile 3 und 4 sind identisch und entsprechen der IP-Adresse des Routers. Mit der bereits erwähnten Tastenkombination Strg-O wird die Datei gespeichert, der Dateiname nochmals mit Enter bestätigt und der Editor mit Strg-X wieder verlassen. Die einfachste Möglichkeit zur Aktivierung der neuen Netzwerk-Konfiguration ist ein Neustart. Dazu verwenden wir das folgende Kommando:

sudo reboot

Dabei verliert PuTTY wieder die Verbindung. Da sich nun die IP-Adresse des Raspberry Pi geändert hat, bestätigen wir die Fehlermeldung und beenden PuTTY. Nun starten wir PuTTY neu, klicken in der Liste der Saved Sessions auf unsere gespeicherte Einstellung und anschließend auf den Button Load. Im Feld Host Name tragen wir nun die neue IP-Adresse ein (in unserem Beispiel wäre das die 192.168.1.222) und klicken anschließend auf den Button Save. Damit haben wir die gespeicherte Einstellung auf den aktuellen Stand gebracht und können diese nun mit einem Doppelklick auf unseren Eintrag in den Saved Sessions starten. Wenn alles geklappt hat, dann erscheint login as: und wir können uns erneut einloggen.

Symbol Schritt 5 - Betriebssystem updaten

Jetzt ist ein guter Zeitpunkt, das Betriebssystem Raspbian auf den neuesten Stand zu bringen, dafür geben wir das folgende Kommando ein:

sudo apt-get update

Raspbian stellt nun Verbindungen zu mehreren Servern her und holt aktuelle Paketlisten. Kurz gesagt, es werden Informationen zu den aktuellen Softwareständen geholt.

Mit dem nächsten Kommando werden alle installierten Pakete aufgelistet, die nicht auf dem neuesten Stand sind. Werden hier nur wenige Pakete gefunden, dann beginnt das Update sofort. Anderenfalls erscheint erst eine Sicherheitsabfrage, die mit J oder Enter bestätigt werden muss:

sudo apt-get upgrade

Insbesondere das zweite Kommando kann einige Zeit in Anspruch nehmen. Diese beiden Kommandos sollte man in gewissen Zeitabständen wiederholen, damit das System immer auf dem aktuellen Stand bleibt.

Symbol Schritt 6 - Echtzeituhr einrichten (optional)

Wichtiger Hinweis: Dieser Schritt darf nur mit installierter Echtzeituhr IC1 (DS1307) ausgeführt werden! Wird keine Echtzeituhr verwendet, dann geht es mit Schritt 7 weiter.

Damit der Raspberry Pi mit der Uhr kommuniziert, muss die I²C-Schnittstelle aktiviert werden - dies haben wir bereits im Schritt 3 getan. Weiterhin muss ein so genanntes Device Tree Overlay für das Echtzeituhr-IC geladen werden. Dazu ist es wieder erforderlich, eine Systemdatei zu editieren:

sudo nano /boot/config.txt

Hier ergänzen wir am Ende der Datei die folgende Zeile:

dtoverlay=i2c-rtc,ds1307
Mit den bekannten Tastenkombinationen Strg-O und Strg-X speichern und verlassen wir die Datei wieder. Nun muss noch eine weitere Datei editiert werden:

sudo nano /lib/udev/hwclock-set

Die folgenden 3 Zeilen müssen deaktiviert werden:
if [ -e /run/systemd/system ] ; then
    exit 0
fi
Dazu setzen wir ein Rautesymbol (Doppelkreuz) als Kommentarzeichen vor jede Zeile und dann sollte das Ergebnis so aussehen:
# if [ -e /run/systemd/system ] ; then
#     exit 0
# fi

Auch hier wird wiederum mit Strg-O und Strg-X gespeichert. Jetzt ist ein Reboot erforderlich:

sudo reboot

Die SSH-Verbindung wird dabei wieder unterbrochen und wir müssen uns nach einer kurzen Wartezeit neu einloggen. Anschließend wird folgendes Kommando eingegeben:

dmesg

In der nun erscheinenden Liste sollte die folgende Zeile zu finden sein:

[    3.829050] rtc-ds1307 1-0068: registered as rtc0

Auf älteren Systemen kann die Ausgabe zweizeilig sein und so aussehen:

[    4.413838] rtc-ds1307 1-0068: rtc core: registered ds1307 as rtc0
[    4.413877] rtc-ds1307 1-0068: 56 bytes nvram

Die Zahl in den eckigen Klammern gibt den Zeitpunkt der Nachricht an und kann abweichen. Wichtig für uns ist nur die Information dahinter und diese besagt, dass unsere RTC (Real Time Clock) mit dem DS1307 auf I²C-Bus 1 und Adresse 0068 gefunden wurde.

Grundsätzlich verwaltet das Raspbian-System die Echtzeituhr selbst. Es holt sich während des Systemstarts die Zeit aus dieser Uhr, wird aber später bei bestehender Online-Verbindung trotzdem die genaue Zeit von einem Server holen und diese außerdem in bestimmten Zeitabständen zur Echtzeituhr übertragen. Zur Kontrolle versuchen wir die Echtzeituhr auszulesen:

sudo hwclock -r

Im Idealfall wird jetzt die richtige Zeit angezeigt. Es ist aber auch möglich, dass eine völlig falsche oder unsinnige Zeit angezeigt wird. In diesem Fall wurde die Uhr noch nicht vom System gestellt. Man kann jetzt einfach abwarten und den gleichen Befehl später nochmals versuchen. Ungeduldige können mit den folgenden Kommandos die Echtzeituhr manuell stellen. Dazu prüfen wir zunächst, ob die aktuelle Systemzeit stimmt:

date

Hier sollte die richtige Zeit erscheinen, da sich der Raspberry Pi gleich nach dem Systemstart die Uhrzeit über ntp von einem Zeit-Server holt. Stimmt die Zeit, dann kann mit dem folgenden Kommando die Echtzeituhr gestellt werden:

sudo hwclock -w

Zur Kontrolle kann man nun nochmals das Lesekommando benutzen:

sudo hwclock -r

Die entscheidenden Hinweise für die Konfiguration der Echtzeituhr fand ich übrigens hier: https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=125003.

Symbol Schritt 7 - RAM-Disk einrichten

Der Raspberry Pi arbeitet mit einer SD-Karte als Festplatte und diese Speicherkarten haben die Eigenschaft, dass sie nur eine begrenzte Anzahl an Schreibvorgängen vertragen. Die Software des Web-Moduls empfängt (abhängig von der Einstellung des Sensormoduls) mindestens einen Datensatz pro Sekunde und speichert diesen als Datei ab. Das bedeutet, dass jede Sekunde ein Schreibzugriff stattfindet, der langfristig die Speicherkarte beschädigen kann. Um dies zu verhindern, wird jetzt ein spezielles Laufwerk eingerichtet, welches die Daten im RAM speichert. Dazu erstellen wir zunächst ein Verzeichnis, in dem wir später die Daten unserer RAM-Disk verwalten wollen:

sudo mkdir /mnt/ram

Jetzt muss wieder eine Systemdatei editiert werden:

sudo nano /etc/fstab

Hier muss jetzt folgende Zeile an die bereits vorhandene Tabelle angefügt werden:

tmpfs           /mnt/ram        tmpfs   defaults,size=256k 0      0

Die RAM-Disk scheint mit 256kB reichlich bemessen, zumal effektiv weniger als 1kB benötigt wird. Hier muss man jedoch mehr einplanen, da auch kleine Dateien immer einen Block von mindestens 4kB belegen.
Auf meinem System sieht die komplette Datei dann so aus:

proc            /proc           proc    defaults          0       0
PARTUUID=14b840a3-01  /boot           vfat    defaults          0       2
PARTUUID=14b840a3-02  /               ext4    defaults,noatime  0       1
tmpfs           /mnt/ram        tmpfs   defaults,size=256k 0      0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

Die bereits vorhandenen Zeilen dürfen nicht verändert werden. Insbesondere die Nummer hinter PARTUUID= ist auf jedem System anders und das ist richtig so. Nach dem Speichern der Datei (Strg-O) und dem Beenden des Editors (Strg-X) kann man entweder das System neu starten oder mit dem folgenden Kommando die Änderungen sofort wirksam machen:

sudo mount -a

Damit werden alle Tabelleneinträge sofort eingerichtet und man kann mit dem folgenden einfachen Kommando sehen, dass auch unsere RAM-Disk eingerichtet wurde (an letzter Stelle):

df -h

Was noch erwähnt werden muss: eine RAM-Disk verliert beim Ausschalten oder Rebooten des Systems alle Daten. Das ist aber hier nicht schlimm, da die Sensordaten nach dem Systemstart sofort neu eingelesen werden.

Symbol Schritt 8 - Datei-Archiv web-modul-files-v400.tar.gz auf den Raspberry Pi laden und entpacken

Das Archiv web-modul-files-v400.tar.gz enthält alle Dateien für das Web-Modul in komprimierter Form. Ich habe hier absichtlich das Linux-Programm tar verwendet, da neben der Verzeichnisstruktur auch die Zugriffsrechte archiviert werden. Das Archiv kann mit folgendem Kommando direkt in den Raspberry Pi geladen werden:

wget https://s-huehn.de/elektronik/tempmess/webm/web-modul-files-v400.tar.gz

Jetzt packen wir das Archiv auf dem Raspberry Pi aus:

tar -xf web-modul-files-v400.tar.gz

Nach Ausführung dieses Kommandos finden wir im Home-Verzeichnis /home/pi einige neue Verzeichnisse, deren Inhalt wir mit dem folgenden Kommando anzeigen können:

ls web-modul-files/*

Die aufgelisteten 4 Unterverzeichnisse haben folgenden Inhalt:

web-modul-files/confenthält einige Konfigurationsdateien für das Web-Modul
web-modul-files/infoenthält die Versions-Historie
web-modul-files/progenthält Perl-Programme und Shell-Skripte für verschiedene Aufgaben
web-modul-files/wwwenthält alle Dateien für die Web-Seite

Diese Struktur wird übrigens während der gesamten Inbetriebnahme nicht verändert - von allen benötigten Dateien werden grundsätzlich Kopien in den entsprechenden Systemverzeichnissen erstellt und alle persönlichen Anpassungen an den Kopien durchgeführt. So kann man bei Bedarf jederzeit auf diese Originaldateien zurückgreifen. Auch hat dieses Vorgehen den Vorteil, dass nach dem Auspacken einer neuen Archiv-Version keine Systemdateien überschrieben werden und nur dieses Archiv erneuert wird.

Symbol Schritt 9 - Systemdienst zum Einlesen der Sensordaten einrichten

Wie schon erwähnt, gelangen die Sensordaten über eine serielle Schnittstelle in den Raspberry Pi und die müssen natürlich jetzt von einem Programm dort abgeholt und entsprechend verarbeitet werden. Ich habe dafür die Interpreter-Sprache Perl verwendet. Das hat sowohl Vor- als auch Nachteile. Der Vorteil ist, dass Perl ein fester Bestandteil des Raspbian-Systems ist und man sofort damit arbeiten kann. Außerdem ist das Programm im Klartext lesbar, kann bei Bedarf relativ einfach geändert und sofort gestartet werden. Der Nachteil ist die etwas schlechtere Performance gegenüber einem C-Programm, aber das stört in der Praxis nicht - der Raspberry Pi hat hier genügend Reserven.

Das Programm benötigt für die ordnungsgemäße Funktion zwei Verzeichnisse. Das erste ist /mnt/ram, welches wir bereits als RAM-Disk eingerichtet haben und hier werden die empfangenen Sensordaten abgelegt. Das zweite Verzeichnis /srv/sensor wird auf der SD-Karte angelegt und soll das Alarm-Log und die Sensorbelegung dauerhaft speichern. Weiterhin finden hier später die Konfigurationsdateien für die Sensoren und Alarme Platz und auch die Datenbank mit den Sensordaten. Mit den folgenden Kommandos legen wir das Verzeichnis an und übergeben dieses dem Benutzer www-data sowie der Benutzergruppe www-data. Damit bekommt der Web-Server, der in Schritt 12 eingerichtet wird, den vollen Zugriff auf diese Konfigurationsdateien. Mit dem letzten Kommando wird der Benutzer pi der Benutzergruppe www-data zugeordnet und das ermöglicht uns später den problemlosen Zugriff auf die Konfigurationsdateien in diesem Verzeichnis.

sudo mkdir /srv/sensor
sudo chown www-data:www-data /srv/sensor
sudo chmod 775 /srv/sensor
sudo usermod -a -G www-data pi

An dieser Stelle müssen wir uns aus- und wieder einloggen, damit die geänderten Rechte wirksam werden:

exit

Dabei wird auch PuTTY beendet und wir müssen es neu starten. Anschließend loggen wir uns wieder ein und kopieren eine Konfigurationsdatei in das soeben angelegte Verzeichnis:

cp web-modul-files/conf/map /srv/sensor

Als nächstes kopieren wir das Perl-Programm mit dem Namen sensor.pl an eine Position im System, die für ausführbare Dateien vorgesehen ist:

sudo cp web-modul-files/prog/sensor.pl /usr/local/bin

Wichtig für die Funktion des Perl-Programms sind noch 2 Zusatzmodule, welche nacheinander mit den folgenden Kommandos installiert werden:

sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants

Nach der Eingabe des ersten Kommandos erscheint noch eine Frage, die mit Enter bestätigt werden muss. Beide Installationen nehmen etwas Zeit in Anspruch - Zeit für einen Kaffee :-)

Jetzt sind alle Voraussetzungen für einen ersten Testlauf erfüllt. Dazu muss unbedingt das Sensormodul angeschlossen sein, damit wir Daten empfangen können. Mit folgendem Kommando wird nun das Programm gestartet:

sudo sensor.pl

Es erfolgt hier keine Ausgabe auf dem Bildschirm, aber es werden jetzt Daten in die RAM-Disk geschrieben. Um das zu prüfen, lassen wir das Programm ungefähr eine Minute laufen und brechen es dann mit Strg-C ab. Anschließend erscheint der Eingabe-Prompt wieder. Nun schauen wir uns den Inhalt der RAM-Disk an:

ls /mnt/ram

Hier sollten jetzt einige Dateien wie al1, al2, al3, al4, s1, s2 usw. aufgelistet werden. Diese Dateien enthalten den empfangenen Alarmstatus und die Sensorwerte, auf die dann später der Web-Server zugreifen wird.

Wichtig: Es geht jetzt normalerweise unter dem eingerückten Text weiter. Nur wenn ein USB-RS232-Wandler anstatt einer Pegelwandler-Platine für den Datenempfang vom Sensormodul verwendet wird, dann ist die im folgenden eingerückten Abschnitt beschriebene Änderung erforderlich:

Das Programm sensor.pl muss ein wenig modifiziert werden:

sudo nano /usr/local/bin/sensor.pl

Hier finden wir auf der ersten Seite die folgende Zeile:

my $senif = "/dev/serial0"; # Serielle Schnittstelle des Raspberry Pi

Diese ändern wir wie folgt ab:

my $senif = "/dev/ttyUSB0"; # USB-Schnittstelle wird verwendet

Mit Strg-O wird die Datei gespeichert und der Editor mit Strg-X wieder verlassen. Nun wird ein neuer Testlauf gestartet:

sudo sensor.pl

Auch hier erfolgt keine Ausgabe auf dem Bildschirm, aber es werden jetzt Daten in die RAM-Disk geschrieben. Um das zu prüfen, lassen wir das Programm ungefähr eine Minute laufen und brechen es dann mit Strg-C ab. Anschließend erscheint der Eingabe-Prompt wieder. Nun schauen wir uns den Inhalt der RAM-Disk an:

ls /mnt/ram

Jetzt sollten einige Dateien wie al1, al2, al3, al4, s1, s2 usw. aufgelistet werden.

Die empfangenen Sensordaten und Alarminformationen können auch angezeigt werden. So zeigt das folgende Kommando den Messwert von Sensor 1 an und das zweite Kommando den Inhalt aller Dateien:

cat /mnt/ram/s1
cat /mnt/ram/*

Jetzt müssen wir dafür sorgen, dass das Programm zum Datenempfang automatisch beim Systemstart im Hintergrund ausgeführt wird. Dazu habe ich eine Konfigurationsdatei vorbereitet, welche ins System eingebunden wird und dann für den Autostart sorgt. Zunächst muss diese Datei an die richtige Stelle kopiert werden:

sudo cp web-modul-files/conf/sensor.service /etc/systemd/system

Anschließend erfolgt die Einbindung ins System:

sudo systemctl enable sensor

Damit ist der automatische Start eingerichtet und beim nächsten Systemstart brauchen wir uns nicht mehr darum zu kümmern. Im Moment ist der Sensordienst noch nicht aktiv und mit dem folgenden Kommando wird dieser manuell gestartet:

sudo systemctl start sensor

Jetzt läuft das Perl-Programm im Hintergrund und schreibt Sensordaten in die RAM-Disk. Davon sollten wir uns überzeugen und mit folgendem Kommando den Inhalt der RAM-Disk etwas ausführlicher anzeigen. Dabei ist vor allem die Erstellungszeit der Dateien von Interesse:

ls -l /mnt/ram

Der Sensordienst lässt sich bei Bedarf auch wieder stoppen oder auch neu starten. Das ist notwendig, wenn das Perl-Programm oder die Sensor-Zuordnung (wird später noch beschrieben) verändert wurde. Die beiden folgenden Kommandos ermöglichen den Stopp bzw. den Neustart des Sensordienstes (nur zur Information, müssen nicht ausgeführt werden):

sudo systemctl stop sensor
sudo systemctl restart sensor

Über ein weiteres Kommando kann man den aktuellen Zustand des Sensordienst abfragen:

systemctl status sensor

Symbol Schritt 10 - Aufzeichnung der Sensorwerte einrichten

In diesem Schritt wird zunächst das Programmpaket RRDTool installiert. Dieses kann spezielle Datenbanken verwalten sowie deren Inhalte grafisch anzeigen. Wir nutzen RRDTool bei diesem Projekt hauptsächlich zur Speicherung aller Sensordaten sowie zur Anzeige dieser Daten in Form von Diagrammen.

sudo apt-get install rrdtool

Weiterhin wird noch ein Zusatzmodul für Perl benötigt, damit die Sensordaten mittels Perl-Programm in die Datenbank übertragen werden können:

sudo apt-get install librrds-perl

Jetzt sind alle Voraussetzungen erfüllt und wir können die Datenbank für die Sensorwerte erstellen. Da hier eine sehr lange Kommandozeile mit vielen Parametern eingegeben werden muss, habe ich dafür ein Shell-Skript vorbereitet:

web-modul-files/prog/sencreate.sh

Anschließend finden wir im Verzeichnis /srv/sensor die neue Datei sensor.rrd mit einer Größe von 3,7MB:

ls -l /srv/sensor

Diese Datenbank ist so eingerichtet, dass alle 31 Sensoren eines voll ausgebauten Temperatur-Messsystems verwaltet werden können. Die Speicherung der Daten erfolgt dabei in 2 Bereichen. Bereich 1 arbeitet mit hoher Auflösung und nimmt alle 15 Minuten die aktuellen Werte aller Sensoren auf. Der Speicherplatz reicht dabei für 40 Tage. Kommen weitere Daten hinzu, dann werden automatisch alte Daten überschrieben. Man kann somit immer 40 Tage in die Vergangenheit schauen. Außerdem wird täglich ein weiterer Datensatz im etwas ungenaueren Bereich 2 gespeichert. Dieser enthält den Mittelwert, den Minimalwert sowie den Maximalwert des Tages von allen Sensoren. Diese Daten werden länger aufgehoben und zwar für 3700 Tage (etwas über 10 Jahre). Nach Ablauf dieser Zeit werden auch hier alte Daten durch neue überschrieben.

Die Struktur der Datenbank wird in dem soeben ausgeführten Skript festgelegt, lässt sich aber durch Änderungen am Skript nach eigenen Wünschen ändern. Zur besseren Übersicht stehen alle Parameter in einer separaten Zeile, für die Speicherdauer sind die letzten 4 Zeilen zuständig. Die Struktur der Datenbank sollte man sich vorher gut überlegen, denn spätere Änderungen sind kaum ohne Datenverlust möglich.

Jetzt müssen wir dafür sorgen, dass unsere Sensordaten alle 15 Minuten eingesammelt und in der richtigen Form an die Datenbank übergeben werden. Dafür habe ich ein Perl-Programm erstellt, welches alle Sensorwerte aus den Dateien im Verzeichnis /mnt/ram liest, die Aktualität prüft und dann über ein RRDTool-Kommando in die Datenbank schreibt. Dieses Programm wird nun an eine geeignete Stelle im System kopiert:

sudo cp web-modul-files/prog/senupdate.pl /usr/local/bin

Zum Test kann man dieses Programm einfach mal starten, dabei darf keine Fehlermeldung erscheinen:

senupdate.pl

Damit die Sensorwerte pünktlich alle 15 Minuten in die Datenbank geschrieben werden, benutzen wir den Linux-Dienst cron. Über das folgende Kommando können wir eine Tabelle aufrufen und hier alle Vorgänge eintragen, die zu einer bestimmten Zeit ausgeführt werden sollen:

crontab -e

Beim ersten Aufruf dieses Kommandos muss einmalig ein Editor für die Eingabe festgelegt werden, hier kann man die Vorgabe [2] (2. /bin/nano) mit Enter übernehmen. Für den zyklischen Aufruf unseres Programms ergänzen wir am Ende der Datei die folgende Zeile:

0,15,30,45 * * * * perl /usr/local/bin/senupdate.pl

Anschließend speichern wir die Tabelle mit der bekannten Tastenkombination Strg-O und beenden mit Strg-X den Editor. Ab jetzt wird automatisch zur Minute 0, 15, 30 und 45 unser Programm gestartet und die Datenbank mit neuen Werten versorgt. Zum Testen können wir jetzt über ein RRDTool-Kommando die Zeit des letzten Datenbank-Updates abfragen:

rrdtool last /srv/sensor/sensor.rrd

Als Ergebnis erhalten wir eine große Zahl, die den so genannten Unix-Zeitstempel repräsentiert. Das ist die Anzahl der Sekunden, die seit dem 01.01.1970 vergangen sind. Um zu überprüfen, ob das automatische Speichern funktioniert, können wir im nächsten 15-Minuten-Intervall das letzte Kommando nochmals aufrufen. Jetzt sollte sich die Zahl geändert haben. Zum finalen Test rufen wir jetzt noch die Datenbank-Struktur auf:

rrdtool info /srv/sensor/sensor.rrd|more

Nun werden viele Zeilen ausgegeben, die mehrere Bildschirme füllen. Hier sollte man darauf achten, dass die Datenfelder Werte enthalten, z.B.:

ds[s1].last_ds = "23.5"

Hat alles geklappt, dann brauchen wir uns jetzt nicht mehr um die Datenbank zu kümmern. Auch weitere Aktionen, wie z.B. das Ermitteln der Tageswerte (Minimal-, Maximal und Mittelwerte), erledigt RRDTool automatisch.

Symbol Schritt 11 - Aufzeichnung der Systemauslastung einrichten

Dieser Schritt ist nicht unbedingt für die Funktion des Web-Moduls notwendig. Allerdings ist die Systemauslastung eines Servers eine durchaus interessante Information. Aus diesem Grund habe ich die nachfolgende Funktion eingebaut. Für die Erfassung der Systemauslastung und deren spätere grafische Anzeige wird eine ähnliche Datei wie im Schritt 10 erstellt, allerdings mit anderen Parametern. Außerdem wird sich ein Systemdienst um die Übertragung der aktuellen Systemauslastung in die Datenbank kümmern. Zunächst erstellen wir die Datenbank über ein Shell-Skript:

web-modul-files/prog/syscreate.sh

Anschließend finden wir im Verzeichnis /srv/sensor die neue Datei system.rrd mit einer Größe von knapp 36kB:

ls -l /srv/sensor

Diese Datenbank erfasst einmal pro Minute die Systemauslastung und speichert die Daten in 3 Bereichen. Der erste Bereich arbeitet mit der höchsten Auflösung von einer Minute und bietet Platz für 8 Stunden. Ein weiterer Bereich arbeitet etwas ungenauer und nimmt nur alle 10 Minuten einen Messwert auf. Hier reicht der Platz für 3 Tage. Und es gibt noch einen dritten Bereich, der alle nur 2 Stunden speichert und für 40 Tage ausreicht. Mit dieser Datenbank werden später Diagramme für einen Zeitraum von 5 Stunden, 2 Tagen und 30 Tagen erzeugt. Auch diese Datenbank funktioniert so, dass ältere Werte überschrieben werden, sobald ein Bereich gefüllt ist und neue Werte gespeichert werden müssen.

Die Struktur der Datenbank wird in dem soeben ausgeführten Skript festgelegt, lässt sich aber durch Änderungen am Skript an eigene Wünsche anpassen. Auch hier gilt: Die Struktur der Datenbank sollte man sich vorher gut überlegen, denn spätere Änderungen sind kaum ohne Datenverlust möglich.

Jetzt müssen wir dafür sorgen, dass jede Minute die Systemauslastung ermittelt und in der richtigen Form an die Datenbank übergeben wird. Auch hierfür gibt es wieder ein Perl-Programm, welches als Systemdienst gestartet wird. Dieses Programm wird nun an eine geeignete Stelle im System kopiert:

sudo cp web-modul-files/prog/sysupd.pl /usr/local/bin

Zum Test kann man dieses Programm einfach mal starten, dabei darf keine Fehlermeldung erscheinen:

sysupd.pl

Strg-C beendet das Programm wieder. Jetzt müssen wir dafür sorgen, dass das Programm automatisch beim Systemstart im Hintergrund ausgeführt wird. Dazu habe ich wiederum eine Konfigurationsdatei vorbereitet, welche ins System eingebunden wird und dann für den Autostart sorgt. Zunächst muss diese Datei an die richtige Stelle kopiert werden:

sudo cp web-modul-files/conf/sysupd.service /etc/systemd/system

Anschließend erfolgt die Einbindung ins System:

sudo systemctl enable sysupd

Damit ist der automatische Start eingerichtet und beim nächsten Systemstart brauchen wir uns nicht mehr darum zu kümmern. Auch dieses Skript bietet Möglichkeiten, den Systemdienst manuell zu starten oder zu stoppen und es ist auch eine Status-Abfrage möglich. An dieser Stelle ist ein Start sinnvoll:

sudo systemctl start sysupd

Symbol Schritt 12 - Web-Server installieren

Jetzt wollen wir unsere aktuellen und auch die gespeicherten Sensordaten in Form einer Web-Seite anzeigen. Dazu benötigen wir einen Web-Server, der auf http-Anfragen reagiert und die entsprechenden Daten an den Web-Browser ausliefert. Der Web-Server ist kein fester Bestandteil des Raspbian-Lite-Systems und muss zunächst installiert werden. Dies erfolgt über die folgenden beiden Kommandos, das erste installiert die Basis-Software, das zweite weitere Zusatzmodule:

sudo apt-get install lighttpd
sudo apt-get install php7.0-common php7.0-cgi php7.0 php-rrd

Nun sind einige Änderungen in der Rechteverwaltung erforderlich.

sudo chown www-data:www-data /var/www
sudo chown www-data:www-data /var/www/html
sudo chmod 775 /var/www
sudo chmod 775 /var/www/html

Die ersten beiden Kommandos übergeben die Verzeichnisse /var/www und /var/www/html, welche für die Dateien der Web-Seite vorgesehen sind, an den Benutzer www-data und die Gruppe www-data. Anschließend wird das Schreibrecht auf diese Verzeichnisse für alle Mitglieder der Gruppe www-data erteilt. Zu dieser Gruppe gehört auch der Benutzer pi, den wir im Schritt 9 hinzugefügt haben. Der Web-Server ist bereits aktiv, allerdings müssen noch Zusatzmodule eingeschaltet werden und dafür dienen die 3 folgenden Kommandos. Das erste Kommando aktiviert zunächst das FastCGI-Modul, welches wir für PHP benötigen. Das darauf folgende Kommando startet das RRDTool-Modul für die Erfassung der Server-Auslastung und legt außerdem die dafür nötige Datenbank lighttpd.rrd im Verzeichnis /var/www an. Mit dem letzten Kommando starten wir den Web-Server neu, damit die Änderungen an der Konfiguration wirksam werden:

sudo lighty-enable-mod fastcgi-php
sudo lighty-enable-mod rrdtool
sudo systemctl force-reload lighttpd

Damit ist der Web-Server funktionsbereit und das können wir gleich mal testen. Dazu wird auf dem PC ein neues Fenster oder ein Tab im Web-Browser geöffnet und dort die IP-Adresse des Raspberry Pi als Ziel eingegeben, z.B. http://192.168.1.222 und es sollte jetzt die „Placeholder page“ von lighttpd erscheinen.

Für die Anzeige unserer Sensordaten müssen wir noch eine eigene Web-Seite erstellen. Ich habe da schon mal einige Dateien vorbereitet, die noch an die richtige Stelle kopiert werden müssen:

cp web-modul-files/www/* /var/www/html
sudo chown www-data:www-data /var/www/html/sensor.dat

Das zweite Kommando sorgt dafür, dass eine Konfigurationsdatei später vom Web-Server bearbeitet werden kann. Nun kommt der große Moment: Wir rufen jetzt vom PC nochmals unseren Web-Server auf oder klicken einfach auf die Funktion Neuladen des Browsers und dann sollte ein Bild wie dieses erscheinen:

Web-Server

Die an einigen Stellen angezeigten Fehler können wir zunächst ignorieren, denn die Konfiguration für die Sensoren und Alarme fehlt noch. Diese werden wir im nächsten Abschnitt Konfiguration durchführen. Die angezeigten Werte sind aber aktuell und werden alle 60 Sekunden auf den neuesten Stand gebracht. Die beiden Diagramme zeigen möglicherweise noch keine Daten an, diese werden erst nach einigen 15-Minuten-Intervallen sichtbar.

Als letzte Tätigkeit dieses Installationsschrittes löschen wir noch die Beispiel-Web-Seite von lighttpd:

sudo rm /var/www/html/index.lighttpd.html

Auch für diesen Schritt gibt es eine Quelle: http://www.raspberrypi-spy.co.uk/2013/06/how-to-setup-a-web-server-on-your-raspberry-pi/

Symbol Schritt 13 - Passwortschutz für den Web-Server einrichten

Dieser Schritt ist optional, aber sehr zu empfehlen. Wenn der Web-Server später für das Internet freigegeben werden soll, dann ist ein Passwortschutz unbedingt erforderlich. Hierfür sollte man auf keinen Fall die Daten des SSH-Zugangs verwenden (pi und das dazugehörige Passwort), sondern eine separate Name- und Passwort-Kombination wählen. Als Beispiel für die folgende Beschreibung verwende ich hier den Namen meinname und das Passwort test99. Zunächst wird im Verzeichnis /srv/sensor (wo auch die Konfigurationsdaten liegen) eine Datei mit den Zugangsdaten angelegt, die wir pass nennen:

nano /srv/sensor/pass

Hier schreiben wir den Namen und das Passwort (durch einen Doppelpunkt getrennt) in eine Zeile. Das würde mit unseren Beispieldaten so aussehen:

meinname:test99

Mit den (hoffentlich noch bekannten) Tastenkombinationen Strg-O, Enter und Strg-X wird die Datei angelegt und der Editor wieder verlassen. Die folgenden beiden Kommandos übergeben die Datei-Rechte an den Web-Server und erteilen der Gruppe www-data das Schreibrecht:

sudo chown www-data:www-data /srv/sensor/pass
sudo chmod 664 /srv/sensor/pass

Der Web-Server benötigt eine zusätzliche Konfigurationsdatei mit den Einstellungen für den Passwortschutz. In der Web-Server-Konfiguration liegt bereits eine Musterdatei bei, diese werden wir aber nicht verwenden und deshalb umbenennen und durch eine vorkonfigurierte Datei ersetzen:

sudo mv /etc/lighttpd/conf-available/05-auth.conf /etc/lighttpd/conf-available/05-auth.conf.org
sudo cp web-modul-files/conf/05-auth.conf /etc/lighttpd/conf-available

Trotz Vorkonfiguration ist es notwendig, eine Zeile zu bearbeiten. Dazu wird die soeben kopierte Datei geöffnet:

sudo nano /etc/lighttpd/conf-available/05-auth.conf

In die Zeile  "require" => "user=username"  muss noch der richtige Benutzername eingetragen werden. Bezogen auf unsere Beispiel-Zugangsdaten muss die Zeile anschließend so aussehen:  "require" => "user=meinname". Jetzt kann die Datei wieder gespeichert werden. Zum Abschluss muss das Authentication-Modul noch eingeschaltet werden und nach einem Neustart des Web-Servers ist dann auch der Passwortschutz aktiv:

sudo lighty-enable-mod auth
sudo systemctl force-reload lighttpd

Wenn alles geklappt hat, dann werden jetzt beim Aufruf unserer Web-Seite der Benutzername und das Passwort abgefragt. Falls später der Wunsch besteht, Benutzername und Passwort zu ändern, dann muss zunächst die Datei pass geändert werden. Bei Änderung des Usernamens muss zusätzlich (wie soeben beschrieben) die Datei 05-auth.conf angepasst und der Web-Server neu gestartet werden.

Symbol Schritt 14 - SSL-Verschlüsselung einrichten (https)

Auch dieser Schritt ist optional und nicht notwendig, wenn der Web-Server nur im lokalen Netz zu erreichen ist. Anderenfalls sollte man nicht auf eine Verschlüsselung verzichten, denn die im Schritt 13 festgelegten Zugangsdaten werden sonst im Klartext übertragen und alle anderen Daten ebenfalls. Allerdings muss ich darauf hinweisen, dass die hier gezeigte Lösung nicht optimal ist. Normalerweise ist die SSL-Verschlüsselung mit einem Zertifikat verknüpft, welches von einer autorisierten Stelle generiert und registriert wird. Somit kann ein Browser beim Aufruf einer verschlüsselten Seite nachprüfen, ob die Verbindung vertrauenswürdig ist. Für unseren Web-Server erstellen wir das Zertifikat selbst und das hat zur Folge, dass die meisten Web-Browser die Gültigkeit des Zertifikats anzweifeln, da es nirgendwo registriert ist. Die Verschlüsselung wird aber trotzdem aktiviert, was man über die Verbindungseigenschaften des Browsers leicht nachprüfen kann. Auch lässt sich hier das Zertifikat anzeigen und da wir dessen Inhalt kennen, können wir gegebenenfalls selbst die Echtheit prüfen. Zuerst wollen wir ein Zertifikat erstellen:

openssl req -new -x509 -keyout server.pem -out server.pem -days 3650 -nodes

Anschließend werden einige Daten abgefragt, wobei hier durchaus Phantasiedaten eingegeben werden können. Man sollte allerdings auf Umlaute und Sonderzeichen verzichten. Als Ergebnis erhalten wir eine Datei mit dem Namen server.pem. Diese muss ins Verzeichnis des Web-Servers kopiert werden:

sudo cp server.pem /etc/lighttpd/

Jetzt ist es noch erforderlich, das SSL-Modul des Web-Servers zu aktivieren und den Web-Server neu zu starten:

sudo lighty-enable-mod ssl
sudo systemctl force-reload lighttpd

Nun versuchen wir unsere Seite über https aufzurufen: https://192.168.1.222. Jeder ordentliche Browser wird jetzt eine Warnung ausgeben, so sagt z.B. Firefox: Diese Verbindung ist nicht sicher. Je nach Browser muss man die Warnung bestätigen und gegebenenfalls eine Ausnahmeregel erstellen. Danach wird die Seite angezeigt und auch die Verschlüsselung wird aktiviert. Man kann zur Kontrolle die Seiteninformationen aufrufen (meist über die rechte Maustaste zu erreichen) und dort den Status der Verbindung anzeigen lassen. Auch das Zertifikat lässt sich hier einsehen. Unser Zertifikat ist übrigens 10 Jahre gültig.

Symbol Schritt 15 - Zugriff aus dem Internet einrichten

Ein wichtiger Hinweis vorweg: Man sollte sich diesen Schritt gut überlegen, denn man öffnet hier eine Tür, die auch ungebetene Gäste anlockt. Praktisch jeder Internet-Nutzer hat die Möglichkeit, eine Verbindung zu unserem Web-Modul aufzubauen.

Für diesen Schritt ist eine Konfiguration am Router notwendig und er setzt auch die Schritte 13 (Passwort) und 14 (Verschlüsselung) voraus. Grundsätzlich ist der typische Router im Heimnetzwerk so eingestellt, dass Anfragen aus dem Internet abgeblockt werden. Wir wollen nun erreichen, dass ganz bestimmte Anfragen aus dem Internet zu unserem Web-Modul weitergeleitet werden. Das Schlüsselwort für die Suche nach dem richtigen Konfigurationsmenü im Router ist hier: Portweiterleitung, Portumleitung oder Port Forwarding. Hier sind folgende Informationen wichtig:

Protokoll: TCP
Eingehender Port (öffentlich, extern): 443 (oder andere Nummer, siehe Text weiter unten)
Ausgehender Port (privat, intern): 443
IP-Adresse: Adresse des Web-Moduls, z.B. 192.168.1.222

Nach dem Speichern der Daten ist es möglich, unser Web-Modul aus dem Internet anzusprechen. Allerdings brauchen wir dafür die öffentliche IP-Adresse, die uns der Internet-Provider zugewiesen hat und genau hier gibt es ein Problem: Die IP-Adresse wird beim Aufbau einer DSL-, Kabel oder Mobilfunkverbindung meist dynamisch vergeben und ist nicht vorhersehbar. Manche Provider trennen regelmäßig die Verbindung und auch hier bekommt man eine neue IP-Adresse zugewiesen. Zum Glück gibt es das so genannte dynamische DNS, welches dieses Problem löst. Damit das funktioniert, müssen 2 Bedingungen erfüllt sein: Man muss sich zunächst bei einem solchen Dienst anmelden (hier ist eine kleine Auswahl: http://www.pcwelt.de/ratgeber/DynDNS-Alternativen-kostenlos-5680355.html) und der Router muss für diesen Dienst konfiguriert werden. Hat man diese Hürden genommen, dann wird künftig jede Änderung der IP-Adresse automatisch vom Router an den DNS-Dienstleister gemeldet. Dieser wiederum stellt uns einen festen Namen zur Verfügung und sorgt dafür, dass alle Anfragen an diesen Namen zur gerade aktuellen IP-Adresse unseres Routers weitergeleitet werden.

Und hier noch ein Tipp: Ich habe die Erfahrung gemacht, dass gelegentlich Zugriffe auf das Web-Modul stattfinden. Dies kann man weitgehend unterbinden, indem man für den externen Zugang einen vom Standard abweichenden Port verwendet. Es empfiehlt sich also, für den eingehenden Port nicht die 443 (Standard für https), sondern eine Zahl zwischen 1000 und 65535 zu wählen. Unser Zugang funktioniert trotzdem, wir müssen nur beim Aufruf aus dem Internet die gewählte Portnummer angeben, z.B.: https://mein-server.dyn-service.com:3456. Das alles gilt nur für den Aufruf des Web-Moduls über das Internet, im Heimnetz ändert sich dadurch nichts.

Übrigens, man kann noch einen Schritt weiter gehen und auch den SSH-Zugang für das Internet freigeben. Die Einstellungen für die Portweiterleitung sind ähnlich wie beim Web-Server, nur dass hier der ausgehende Port 22 verwendet wird. Auch hier sollte man für den eingehenden Port nicht die 22 wählen. Damit ist dann auch ein weltweites Remote-Login mit PuTTY möglich. Hier sollte man aber gründlich überlegen, ob man das wirklich braucht, denn sollte es jemandem gelingen, sich in das Web-Modul einzuloggen, dann hat dieser die volle Kontrolle über den Raspberry Pi und möglicherweise auch über andere Geräte im Heimnetzwerk.

Noch eine Information: Die hier beschriebenen Einstellungen für das Netzwerk entsprechen dem Standard IPv4. Eigentlich wollte ich auf das aktuelle IPv6 eingehen, aber das Thema ist doch recht komplex.

Symbol Schritt 16 - MQTT-Server einrichten (optional)

Dieser Schritt ist optional und nur dann erforderlich, wenn mindestens eine Matrixuhr mit Sensordaten und Alarminformationen versorgt werden soll. Ein MQTT-Server bietet außerdem die Möglichkeit, Sensordaten und Alarminformationen an andere Systeme im Netzwerk (z.B. Haussteuerungen) zu übermitteln. Das Prinzip eines MQTT-Servers ist relativ einfach erklärt: Der Server (auch Broker genannt) ist über TCP/IP von allen Geräten im Netzwerk erreichbar und dient als Nachrichtenverteiler. Geräte mit MQTT-Fähigkeit können eine Verbindung zum Server herstellen und ihre Daten übermitteln. Andere Geräte, die Daten benötigen, können sich ebenfalls mit dem Server verbinden und die gewünschten Daten abonnieren. Immer dann, wenn ein neues Datenpaket auf dem Server eintrifft, wird dieses an die entsprechenden Abonnenten weitergegeben.

Als MQTT-Server hat sich die Software mosquitto bewährt. Diese wird über das folgende Kommando installiert:

sudo apt-get install mosquitto

In der Voreinstellung speichert mosquitto alle empfangenen Daten in einer Datenbank und stellt diese nach einem Neustart des Systems auch wieder her. Das ist hier nicht sinnvoll, denn durch den kontinuierlichen Datenempfang würde die SD-Karte ständig durch Schreibzugriffe gestresst. Es ist also völlig ausreichend, wenn mosquitto die Daten im RAM verwaltet. Zur Änderung dieser Einstellung öffnen wir mit folgendem Kommando die Konfigurationsdatei von mosquitto:

sudo nano /etc/mosquitto/mosquitto.conf

Hier wird die folgende Zeile gesucht und komplett gelöscht:

persistence true

Nach dem Speichern (Strg-O) und Beenden (Strg-X) muss mosquitto neu gestartet werden, damit die Änderung wirksam wird:

sudo systemctl restart mosquitto

Damit ist die Installation des MQTT-Servers abgeschlossen. Üblicherweise sichert man jeden Server mit einem Passwort ab und auch eine Transportverschlüsselung ist immer sinnvoll. Hier wird jedoch darauf verzichtet, da die verarbeiteten Daten das lokale Netzwerk nicht verlassen und hier nur vertrauenswürdige Geräte aktiv sind. Außerdem besteht so die Möglichkeit, dass auch Geräte mit weniger leistungsstarker Hardware mit MQTT arbeiten können.

Trotzdem gibt es noch eins zu tun: Der Sensordienst muss einmal neu gestartet werden. Der Grund ist folgender: Der Sensordienst prüft beim Start, ob mosquitto installiert ist und schaltet abhängig davon die MQTT-Funktion aus- oder ein. Mit dem Neustart wird also die MQTT-Funktion aktiviert.

sudo systemctl restart sensor

Damit ist die Inbetriebnahme des Web-Moduls abgeschlossen.

Symbol Sonstiges - Backup, Restore, nützlicher Helfer

In regelmäßigen Abständen sollte man das gesamte System sichern. Damit erspart man sich im Notfall die soeben beschriebene Neuinbetriebnahme und die noch folgende Konfiguration. Außerdem lassen sich die in der Datenbank gesammelten Sensorwerte bis zum Zeitpunkt der letzten Datensicherung wieder herstellen. Für die Sicherung bietet sich ein Zeitpunkt kurz nach einem Datenbank-Update an, also kurz nach der Minute 0, 15, 30 oder 45. Die 15 Minuten bis zum nächsten Datenbank-Update reichen meist für die Sicherungsprozedur aus und so entstehen keine Lücken in der Aufzeichnung.

Zunächst müssen wir das System herunterfahren und abschalten, damit die SD-Karte entnommen werden kann:

sudo poweroff

Diese Prozedur ist übrigens immer sinnvoll, wenn der Raspberry Pi ausgeschaltet werden soll. Auch wenn das Linux-System recht robust ist und ein Ausschalten ohne Herunterfahren meist ohne Schaden übersteht - Herunterfahren ist in jedem Fall die bessere Alternative. Nach dem Poweroff-Kommando vergehen noch einige Sekunden, anschließend blinkt eine der LEDs auf dem Raspberry Pi 10 mal und gibt damit das Zeichen zum Ausschalten. Wenn man den Raspberry Pi während des Herunterfahrens nicht beobachten kann, dann wartet man einfach nach dem Kommando noch 30 Sekunden und schaltet dann aus.

Für die Datensicherung kommt wieder der Win32 Disk Imager zum Einsatz. Die SD-Karte kommt in den Kartenleser des PCs und der Win32 Disk Imager wird gestartet. Im Feld Image File wird über das kleine Symbol ein Name und ein Speicherort für das Backup-Image ausgewählt bzw. eingegeben. Im Feld Device wählen wir den Laufwerks-Buchstaben der SD-Karte. Nun wird auf den Button Read geklickt und der Lese-Vorgang beginnt, der je nach Speichergröße der Karte einige Zeit dauern kann. Nach Bestätigung der Erfolgsmeldung kann das Programm wieder beendet und die SD-Karte über die „Auswerfen“-Funktion auf der Windows-Taskleiste vom System abgemeldet werden. Nun kann die Karte wieder in den (noch ausgeschalteten) Raspberry Pi gesteckt und dieser an den Strom angeschlossen werden. Nach ungefähr 45 Sekunden ist dann unser Web-Modul wieder online.

Falls die Notwendigkeit besteht, das System wieder herzustellen, kann man sich das Herunterfahren sparen und den Raspberry Pi direkt ausschalten. Die SD-Karte kommt in den Kartenleser des PCs, wobei eventuelle Reparaturversuche von Windows unbedingt ignoriert werden sollten. Anschließend wird der Win32 Disk Imager gestartet. Bei Image File wird nun über das kleine Symbol das letzte Backup-Image ausgewählt und im Feld Device sollte der richtige Laufwerks-Buchstabe stehen. Zur Sicherheit sollte man andere Wechseldatenträger entfernen, damit nicht versehentlich ein falsches Laufwerk beschrieben wird. Wenn man sich wirklich sicher ist, dann wird über den Button Write der Schreibvorgang gestartet, der einige Zeit dauern kann. Nach der Fertig-Meldung des Win32 Disk Imagers kann das Programm wieder beendet werden. Die SD-Karte wird über die „Auswerfen“-Funktion auf der Windows-Taskleiste vom System abgemeldet und kommt nun in den ausgeschalteten Raspberry Pi. Schaltet man den Strom wieder ein, dann sollte das System genau so starten und laufen wie zum Zeitpunkt der Backup-Erstellung.

Zwei kleine Tipps:

  1. Es wird empfohlen, das Backup mit dem Schritt 5 der Inbetriebnahme zu kombinieren: Zuerst führt man das Backup durch und wenn das Web-Modul wieder läuft, startet man nacheinander die beiden Update-Kommandos. Das hat den Vorteil, dass bei einem fehlerhaften Update-Vorgang das System wieder auf den vorherigen stabilen Stand gebracht werden kann.
  2. Man sollte für das Web-Modul 2 identische SD-Karten kaufen. Falls eine Karte im laufenden Betrieb ausfallen sollte, dann kann man problemlos das Backup auf die Reserve-Karte schreiben. Kauft man später eine neue Karte, dann kann es durchaus passieren, dass diese trotz gleicher Speicherkapazität weniger verfügbaren Platz hat. Die Folge ist, dass das Backup nicht auf die Karte geschrieben werden kann. Es gibt zwar Möglichkeiten, die Größe anzupassen, aber das ist nicht ganz so einfach. Zur Not kann man in einem solchen Fall ohne Probleme eine größere Speicherkarte nehmen (z.B. 16GB anstatt 8GB).

An dieser Stelle möchte ich noch auf einen nützlichen Helfer hinweisen. Die ältere Generation erinnert sich bestimmt noch an den legendären Norton Commander. Ein ähnliches Programm gibt es auch für Linux unter dem Namen Midnight Commander. Damit kann man bequem durch die Verzeichnisse navigieren sowie Dateien kopieren, verschieben, löschen, anzeigen, editieren oder vergleichen und vieles mehr. Der Midnight Commander kann folgendermaßen installiert werden:

sudo apt-get install mc

Nach der Installation kann man das Programm sofort benutzen:

mc

Man kann den Midnight Commander auch mit erweiterten Rechten starten:

sudo mc

Aber Vorsicht! Hier hat man sozusagen die Allmacht und kann viel kaputt machen.

SymbolUpdate

Über die folgende Anleitung lässt sich das Web-Modul von der vorherigen Software v3.10 auf die aktuelle v4.00 updaten. Bei älteren Versionen vor v3.10 empfehle ich eine komplette Neuinstallation des gesamten Systems, denn vermutlich ist hier auch das Betriebssystem veraltet. Grundsätzlich sollte man bei einer Neuinstallation eine neue SD-Karte verwenden. So kann man bei einem Fehlschlag einfach die alte Karte wieder in den Raspberry Pi einsetzen und alles läuft weiter wie bisher. Außerdem empfiehlt es sich, alle wichtigen Dateien auf einem PC zu sichern. Für diesen Zweck kann z.B. das Programm FileZilla Client verwendet werden. Dieses ermöglicht die Übertragung von Dateien vom Raspberry Pi auf den PC und natürlich auch umgekehrt. Folgende Verzeichnisse sind wichtig und sollten auf den PC gerettet werden:

/srv/sensorenthält alle Konfigurationsdateien für Alarme und Sensoren sowie die Sensor-Datenbank
/var/www/htmlenthält alle HTML-Dateien des Web-Servers und deren Einstellungen

Wenn man nicht weiß, welche Software-Version installiert ist, kann man das folgende Kommando verwenden. Es listet die Versions-Historie des zuletzt verwendeten Software-Pakets auf:

less web-modul-files/info/history.txt

In der ersten Zeile findet man die aktuelle Versionsnummer und mit q wird der Lister wieder beendet. Diese Abfrage sollte man allerdings machen, bevor man eine neue Version lädt und entpackt. Ist der richtige Softwarestand v3.10 vorhanden, dann wird nun die aktuelle Version 4.00 geladen und entpackt:

wget https://s-huehn.de/elektronik/tempmess/webm/web-modul-files-v400.tar.gz
tar -xf web-modul-files-v400.tar.gz

Wichtig für die Funktion der Software v4.00 sind noch 2 Zusatzmodule, welche nacheinander mit den folgenden Kommandos installiert werden:

sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants

Nach der Eingabe des ersten Kommandos erscheint noch eine Frage, die mit Enter bestätigt werden muss. Beide Installationen nehmen etwas Zeit in Anspruch.

Im nächsten Schritt stoppen wir 2 Systemdienste und deaktivieren diese auch, da sie nach einem veralteten Verfahren eingerichtet wurden:

sudo service sensor stop
sudo service sysupd stop
sudo update-rc.d sensor remove
sudo update-rc.d sysupd remove
sudo rm /etc/init.d/sensor
sudo rm /etc/init.d/sysupd

Nun kopieren wir die aktuellen Dateien an die richtige Stelle und startet die Systemdienste wieder:

sudo cp web-modul-files/prog/sensor.pl /usr/local/bin/
sudo cp web-modul-files/prog/sysupd.pl /usr/local/bin/
sudo cp web-modul-files/prog/senupdate.pl /usr/local/bin/
sudo cp web-modul-files/conf/sensor.service /etc/systemd/system
sudo cp web-modul-files/conf/sysupd.service /etc/systemd/system
sudo systemctl enable sensor
sudo systemctl enable sysupd
sudo systemctl start sensor
sudo systemctl start sysupd

Jetzt ist es noch erforderlich, die HTML-Dateien des Web-Servers zu erneuern:

cp web-modul-files/www/*.php /var/www/html
cp web-modul-files/www/style.css /var/www/html

Der nachfolgende Teil ist optional und nur dann notwendig, wenn Sensordaten und Alarminformationen an eine Matrixuhr oder an andere Geräte im Netzwerk übermittelt werden sollen. Für diese Funktion wird der MQTT-Server mosquitto installiert:

sudo apt-get install mosquitto

Hier ist anschließend noch die Änderung einer Einstellung notwendig. Dazu öffnen wir mit folgendem Kommando die Konfigurationsdatei von mosquitto:

sudo nano /etc/mosquitto/mosquitto.conf

Hier wird die folgende Zeile gesucht und komplett gelöscht:

persistence true

Nach dem Speichern (Strg-O) und Beenden (Strg-X) muss mosquitto neu gestartet werden, damit die Änderung wirksam wird. Außerdem muss der Sensordienst neu gestartet werden, damit dieser die Installation von mosquitto erkennt und Daten an diesen senden kann.

sudo systemctl restart mosquitto
sudo systemctl restart sensor

Damit ist das Update abgeschlossen. Um die neuen Funktionen zu aktivieren, ist jetzt noch die im folgenden Abschnitt beschriebene Konfiguration durchzuführen.

SymbolKonfiguration

Wenn die Inbetriebnahme geschafft ist und alles wie beschrieben funktioniert, kann das Web-Modul an das eigene Sensornetzwerk angepasst werden. Dies erfolgt (bis auf eine selten benötigte Ausnahme) komplett über die Web-Seite. Dazu klicken wir im Menü der Web-Seite auf  Konfiguration . Nun sollte sich eine Seite mit vielen Eingabefeldern öffnen, die in folgende umrahmte Bereiche unterteilt sind:

Wir arbeiten nun die 4 Bereiche von unten nach oben ab. Das mag zunächst unlogisch erscheinen, aber ich habe die Anordnung nach der Häufigkeit der Benutzung gewählt. In der Praxis wird man nur selten am Servernamen und an der Grund-Konfiguration etwas ändern, während die Anzeige-Konfiguration, also die Übersicht auf der Seite  Sensoren  vermutlich häufiger modifiziert wird.

Symbol Bereich Servername

Konfig Servername

Hier kann man dem Server einen Namen geben, der dann auf der linken Seite des Menüs und auch in der Titelzeile des Browsers angezeigt wird. Dieser Name darf auch Umlaute und Sonderzeichen enthalten und maximal 50 Zeichen lang sein. Mit einem Klick auf Button wird der Name in einer Datei abgelegt, die Seite neu aufgebaut und rechts neben dem Button der Hinweis  gespeichert  ausgegeben. Technisch bedingt erscheint der neue Name erst beim nächsten Aufruf der Seite.

Symbol Bereich Alarm-Grundkonfiguration

Konfig Alarme 1

In diesem Bereich lassen sich die 4 Alarme des Sensormoduls entsprechend der Funktion konfigurieren. Im Feld Alarmname kann man dem Alarm einen Namen geben, der maximal 50 Zeichen lang sein kann und auch Umlaute und Sonderzeichen enthalten darf. Das Feld Ruhezustand legt fest, wie der Alarmeingang zu bewerten ist. Standardmäßig werden an die Alarmeingänge Schaltkontakte gegen Masse angeschlossen. Ist dieser Kontakt im Ruhezustand offen und wird dieser zur Alarmauslösung geschlossen, dann ist hier die Einstellung Kontakt offen zu wählen. Die alternative Einstellung Kontakt geschlossen gilt für den Fall, dass der Kontakt allgemein geschlossen ist und zur Alarmauslösung geöffnet wird. In die nächsten beiden Felder kann im Klartext der Status des Alarms im Normalzustand sowie der Status im Alarmzustand eingetragen werden. Auch diese Felder dürfen Umlaute und Sonderzeichen enthalten und maximal 50 Zeichen lang sein.

Das letzte Feld MQTT Topic muss nur dann ausgefüllt werden, wenn der MQTT-Server mosquitto installiert ist (Inbetriebnahme, Schritt 16) und Alarmmeldungen an Matrixuhren oder andere Geräte übermittelt werden sollen. In diesem Fall kann für jeden genutzten Alarm ein eindeutiger Topic-Name eingegeben werden. Ich habe bei meinem Web-Modul eine allgemein empfohlene Schreibweise verwendet, die aus 4 Teilen besteht, welche mit Schrägstrichen abgetrennt sind. Der Name darf hier bis 100 Zeichen lang sein, sollte aber möglichst keine Umlaute und Sonderzeichen enthalten. Zum Sichern der Einstellungen wird auf Button geklickt und beim folgenden Neuaufbau der Seite erscheint die Bestätigung  gespeichert  neben dem Button.

Das oben stehende Beispielbild zeigt die Alarmkonfiguration meines Web-Moduls. Die Alarme 1, 3 und 4 sind hier mit Kontakten beschaltet, die im Ruhezustand geschlossen sind. Der Alarm 2 wird zurzeit nicht genutzt. Alle Meldungen der 3 genutzten Alarme werden an den MQTT-Server gesendet.

Symbol Bereich Sensor-Grundkonfiguration

Konfig Sensoren 1

In diesem Bereich kann man jedem Sensor einen Namen geben. Wie bei den Alarmnamen sind auch hier maximal 50 Zeichen sowie Umlaute und Sonderzeichen zulässig. Weiterhin lässt sich für jeden Sensor ein unterer Grenzwert (Min) sowie ein oberer Grenzwert (Max) festlegen. Liegt der Sensorwert innerhalb der beiden Grenzwerte, dann wird er im Menü  Sensoren  und  Tabellen  grün angezeigt, anderenfalls rot. So lässt sich später auf einen Blick erkennen, wenn irgendwo ein Wert von der Norm abweicht. Die Angabe der Grenzwerte ist optional, man kann bei Bedarf auch nur einen Grenzwert angeben oder gar keinen. Die Grenzwerte dürfen auch eine Nachkommastelle enthalten, wobei man hier das Komma als Punkt schreiben muss. Für einen Grenzwert von beispielsweise 22,5°C muss dann 22.5 geschrieben werden. Das Feld Sperre ist speziell für die Seite  Grafik  gedacht. Ein gesperrter Sensor wird nicht bei der Grafikeinstellung angeboten und macht die Auswahl übersichtlicher.

Auch hier muss das Feld MQTT Topic nur dann ausgefüllt werden, wenn der MQTT-Server mosquitto installiert ist und Sensorwerte an Matrixuhren oder andere Geräte übermittelt werden sollen. In diesem Fall kann für jeden Sensor ein eindeutiger Topic-Name eingetragen werden. Ebenso wie bei den Alarmen habe ich auch hier eine empfohlene Schreibweise verwendet. Der Name darf 100 Zeichen lang sein und sollte möglichst keine Umlaute und Sonderzeichen enthalten. Mit einen Klick auf Button (hier im Bild nicht sichtbar) wird die Einstellung gespeichert und es erscheint neben dem Button die Bestätigung  gespeichert .

Im oben stehenden Bild ist die Konfiguration der ersten 4 Sensoren meines Web-Moduls zu sehen. Hier nutze ich auch die Felder Min und Max, wobei im Fall der Garage nur die Überschreitung einer Temperatur von 40°C zu einer roten Darstellung des Wertes führt. Da diese 4 Sensoren auch im Menü  Grafik  verwendet werden sollen, ist die Sperre hier ausgeschaltet. Außerdem werden alle Sensordaten zum MQTT-Server übermittelt.

Symbol Bereich Anzeige-Konfiguration

Konfig Anzeige 1

Mit dieser Tabelle kann die Seite  Sensoren  relativ frei gestaltet werden. In jeder Zeile lässt sich ein Sensor-, Alarm- oder Grafik-Element beliebig auf der Seite platzieren. Die hier angezeigte Beispiel-Liste zeigt das grundsätzliche Prinzip. Bevor man jedoch mit der Platzierung beginnt, sollte ein geeignetes Hintergrundbild erstellt werden. Ich habe ein einfaches Linienmodell mit transparentem Hintergrund vom Querschnitt meines Hauses angefertigt, welches als house1.png unterhalb der Tabelle eingetragen ist. Es wird noch ein zweites Bild mitgeliefert, welches zusätzlich eine symbolische Lüftungsanlage enthält (house2.png). Diese Bilder werden in den seltensten Fällen passen, so dass hier jeder kreativ werden kann. Es geht aber auch ohne Bild, in diesem Fall muss das Eingabefeld Name der Hintergrundgrafik leer bleiben.

Hat man ein geeignetes Bild erstellt, dann kopiert man die Datei z.B. mit FileZilla auf den Raspberry Pi in das Verzeichnis /var/www/html. Den Namen des Bildes trägt man dann in das Eingabefeld Name der Hintergrundgrafik ein, klickt auf Button (hier im Bild nicht sichtbar) und der Hinweis  gespeichert  erscheint. Wenn man alles richtig gemacht hat, dann sollte beim Wechsel auf die Seite  Sensoren  das neue Bild zu sehen sein. Jetzt ist der richtige Zeitpunkt, um die Tabelle zum Platzieren der Elemente zu bearbeiten. Dafür kann es hilfreich sein, 2 Browser-Fenster neben- oder untereinander auf den Desktop zu legen - ein Fenster zeigt die Seite  Sensoren , das andere die  Konfiguration . So kann man nach dem Speichern der geänderten Konfiguration im Nachbar-Fenster auf Neuladen klicken und das Ergebnis sofort sehen.

Zum Bearbeiten eines Elements wählt man zunächst einen geeigneten Feldtyp aus. Zur Auswahl stehen Textfeld klein (Text-Elemente in normaler Schriftgröße), Textfeld groß (Text-Elemente in großer Schrift) und Grafik (ein Bild mit einem grafischen Werteverlauf). Bei einem bereits vorhandenen Element erscheint hier zusätzlich die Auswahl Löschen. Wählt man diese, dann wird die gesamte Zeile beim Speichervorgang entfernt. Man muss sich an dieser Stelle übrigens keine Sorgen machen, dass irgendwann nicht mehr genügend Zeilen zur Verfügung stehen - nach jedem Speichervorgang wird ganz unten eine Zeile angefügt, in der man ein neues Element eingeben kann. Es gibt hier auch keine Begrenzung der Zeilenanzahl.

Im nächsten Eingabefeld Horizontal sind 2 Eingaben erforderlich: Mit der Auswahl der Ausrichtung links oder rechts wird festgelegt, ob das anzuzeigende Element am linken oder am rechten Bildrand ausgerichtet werden soll. Über das Eingabefeld Abstand wird der Abstand des Elements vom gewählten Bildrand in Pixel festgelegt. Bei Links-Ausrichtung gilt dabei der Abstand vom linken Bildrand zum linken Rand des Elements, bei Rechts-Ausrichtung der Abstand vom rechten Bildrand zum rechten Rand des Elements. Die nächsten beiden Eingabefelder unter Vertikal funktionieren nach dem gleichen Prinzip. Hier gilt bei der Ausrichtung nach oben der Abstand vom oberen Bildrand zum oberen Rand des Elements und bei der Ausrichtung nach unten der Abstand vom unteren Bildrand zum unteren Rand des Elements.

Die restlichen Eingabefelder bestimmten die Elemente, die an der festgelegten Position erscheinen sollen. Man hat hier die Möglichkeit, bis zu 3 Elemente zu definieren, die dann untereinander zentriert angezeigt werden. In meiner Beispiel-Konfiguration bedeutet die Zeile 1: An Position Links 915 und Oben 327 soll der Name von Alarm 1 und gleich darunter der Wert von Alarm 1 erscheinen. Mit Sensordaten funktioniert das gleichermaßen, so bedeutet die Zeile 5: An Position Links 145 und Oben 368 soll der Name von Sensor 2 und darunter dessen Wert erscheinen. Hier wäre eine sinnvolle Möglichkeit, ein drittes Element zu definieren, z.B. einen Luftfeuchtigkeitssensor, der sich im gleichen Raum befindet. Die Zeile 5 könnte dann z.B. so aussehen:

Konfig Anzeige 2

Bei der Auswahl einer Grafik sind andere Eingaben erforderlich. Zunächst müssen auch hier die horizontalen und vertikalen Positionsdaten angegeben werden. Beim Element 1 muss zwingend ein Grafiksensor mit der gewünschten Sensornummern als Parameter ausgewählt werden. Über das Element 2 erfolgt die Auswahl Grafikfarbe, die als Parameter einen Farbwert in hexadezimaler Schreibweise im Format RRGGBB erfordert. Meine Beispiel-Konfiguration definiert in den letzten beiden Zeilen der Tabelle zwei Grafiken. Die obere der beiden Zeilen legt fest, dass an der Position Links 0 und Oben 25 eine Grafik vom Sensor 1 mit der Farbe rot angezeigt werden soll:

Konfig Anzeige 3

Generell muss man bei den Eingaben einfach ein wenig experimentieren, insbesondere bei den Positionsangaben. Die Position Links 0 / Oben 0 entspricht immer der linken oberen Ecke direkt unter dem Menü. Nutzt man die Ausrichtung nach Rechts oder Unten, dann beziehen sich die Abstände immer auf den rechten und unteren Rand der Hintergrundgrafik. Wenn ohne Hintergrundgrafik gearbeitet wird, dann wird eine Bildgröße von 800 x 600 Pixel angenommen. Die Eingabefelder akzeptieren zum Teil auch unplausible Eingaben - hier wäre der Aufwand einfach zu groß geworden, um alle Varianten zu prüfen.

Symbol Weitere Informationen

An dieser Stelle ist die Konfiguration des Web-Moduls abgeschlossen. Es gibt allerdings noch eine Funktion, die sich nicht über die Web-Seite konfigurieren lässt und das ist die Sensor-Zuordnung. Diese Funktion ist bei einer Neueinrichtung des Web-Moduls nicht erforderlich und auch bei späteren Sensorerweiterungen sollten seit der Software v2.10 des Sensormoduls keine Verschiebungen von Sensornummern mehr auftreten. Trotzdem ist die Funktion noch vorhanden und wird über die Zuordnungsdatei map realisiert.

Die folgende Tabelle zeigt die normale Zuordnung der Sensoren des Sensormoduls zu den Sensoren im Web-Modul:

Sensorkennung
im Sensormodul
Zuordnungsdatei
(map)
Konfigurationsdatei
im Web-Modul
SensortypBemerkung
Tem1Pfeil
1-24
s1Temperatur
Tem2s2Temperatur
Tem3s3Temperatur
Tem4s4Temperatur
Tem5s5Temperatur
Tem6s6Temperatur
Tem7s7Temperatur
Tem8s8Temperatur
TemAs9Temperatur
TemBs10Temperatur
TemCs11Temperatur
TemDs12Temperatur
TemEs13Temperatur
TemFs14Temperatur
TemGs15Temperatur
TemHs16Temperatur
TemIs17Temperatur
TemJs18Temperatur
TemKs19Temperatur
TemLs20Temperatur
TemMs21Temperatur
TemNs22Temperatur
TemOs23Temperatur
TemPs24Temperatur
TemQPfeil
25-27
s25Temperatur verknüpft mit s29 (HX)
TemRs26Temperaturverknüpft mit s30 (HY)
TemSs27Temperaturverknüpft mit s31 (HZ)
Luftdrucks28Luftdruck
HXPfeil
25-27
s29Luftfeuchtigkeit verknüpft mit s25 (TemQ)
HYs30Luftfeuchtigkeitverknüpft mit s26 (TemR)
HZs31Luftfeuchtigkeitverknüpft mit s27 (TemS)

Die Zuordnungsdatei map enthält eine Liste und die sieht so aus (in der Mitte etwas gekürzt):

1
2
3
4
...
24
25
26
27

Die Zuordnungsdatei funktioniert folgendermaßen: Das Perl-Programm sensor.pl, welches für das Einlesen der seriellen Daten vom Sensormodul zuständig ist, schaut bei jedem empfangenen Sensorwert in diese Zuordnungsdatei und entnimmt die hier eingetragene Nummer für die weitere Speicherung der Daten. Ein Beispiel: Vom Sensormodul wird ein Wert vom Sensor 4 empfangen. Das Programm schaut nun in die Zeile 4 der Zuordnungsdatei und entnimmt die dort vorgefundene Nummer. Hier steht ebenfalls eine 4 und so wird der empfangene Sensorwert in der Datei s4 gespeichert. Hier scheint der Aufwand mit der Zuordnungsdatei wenig Sinn zu machen, aber konstruieren wir mal eine Sensorerweiterung, wie sie mit früheren Software-Versionen des Sensormoduls durchaus vorgekommen ist:

Dazu nehmen wir an, es gibt bereits 5 Sensoren im System und es kommt ein weiterer hinzu. Wenn wir diesen Sensor an den letzten Bus des Sensormoduls anschließen und großes Glück haben, dann erscheinen die Werte des neuen Sensors unter der neuen Nummer 6. In diesem Fall gibt es keinen Handlungsbedarf. Die Praxis wird aber eher so aussehen, dass sich der neue Sensor z.B. unter der Nummer 3 meldet. Der bisherige Sensor 3 sendet seine Daten nun unter der Nummer 4, der bisherige Sensor 4 sendet seine Daten unter der Nummer 5 und der bisherige Sensor 5 sendet seine Daten unter der Nummer 6. Damit jetzt alle Daten wieder an den richtigen Positionen auf der Web-Seite erscheinen und auch die Datenbank korrekt fortgeschrieben wird, müssen wir die Zuordnungsdatei anpassen. Dazu loggen wir uns über SSH mit PuTTY ein und verwenden folgendes Kommando:

nano /srv/sensor/map

Als kleine Hilfe zum Auffinden der richtigen Zeilennummern im Text können wir beim nano-Editor die Anzeige der Cursor-Position aktivieren, indem wir nacheinander Esc und c drücken. Der Anfang der Zuordnungsdatei wird dann für unser Beispiel so geändert:
1
2
6
3
4
5
7
...
Kommt jetzt beispielsweise ein Datensatz vom Sensor 5 (unser früherer Sensor 4), dann wird das Perl-Programm sensor.pl jetzt in die Zeile 5 der Zuordnungsdatei schauen, findet dort die Nummer 4 und speichert die Daten folglich in der Datei s4 wie früher ab. Somit ist die Ordnung wieder hergestellt.

Es gibt noch etwas bei der Sensor-Zuordnung zu beachten. Es existieren systembedingt 2 Sensorgruppen: Die Temperatursensoren 1-24 und die Kombisensoren für Luftfeuchtigkeit und Temperatur 25-27. Bei einer Erweiterung der Temperatursensoren kann es zu Verschiebungen im Bereich 1-24 kommen, die andere Sensorgruppe 25-27 bleibt in diesem Fall unverändert. Beim Hinzufügen von Kombisensoren kann sich die Zuordnung im Bereich 25-27 ändern und die Gruppe 1-24 bleibt unverändert. Kurz gesagt: Änderungen betreffen entweder die Zeilen 1-24 oder 25-27.

Ich habe ein kleines Programm geschrieben (ebenfalls in Perl), mit dem man nach einer Änderung der Zuordnungsdatei diese überprüfen kann. Das Programm liest die Datei map ein und prüft, ob die Anzahl der Zeilen korrekt ist, ob die beiden Bereiche (1-24 und 25-27) getrennt sind und ob alle Nummern jeweils einmal verwendet wurden. Alle gefundenen Fehler werden direkt angezeigt und die sollte man auch korrigieren, da sonst Fehlfunktionen auftreten können. Das Programm wird wie folgt aufgerufen:

web-modul-files/prog/mapcheck.pl

Wichtig: Die Änderungen in der Zuordnungsdatei werden nicht sofort wirksam. Das Programm sensor.pl ist so geschrieben, dass beim Start die Zuordnungsdatei einmal eingelesen wird und im weiteren Verlauf die Werte im Speicher benutzt werden. Das steigert zum einen die Performance des Programms und bietet zum anderen die Möglichkeit, Änderungen an der Zuordnungsdatei vor der Aktivierung zu prüfen. Um eine geänderte Zuordnung zu aktivieren ist es also erforderlich, den Sensordienst neu zu starten:

sudo systemctl restart sensor

Auch wichtig: Wie schon erwähnt, war die Zuordnungsdatei map früher erforderlich, um Verschiebungen bei den Sensoren auszugleichen, die bei Erweiterungen aufgetreten sind. Mit der aktuellen Software des Sensormoduls passiert dies nicht mehr und es gibt praktisch keinen Grund mehr, die Zuordnungsdatei zu verändern.

Neben der Zuordnungsdatei kann noch eine weitere Datei editiert werden, um die Menü-Anordnung zu ändern:

nano /var/www/html/menu.dat

Jede Zeile stellt eine Menü-Option dar und durch Ändern der Zeilen-Reihenfolge kann man die Reihenfolge des Menüs anpassen. Auch lassen sich die Namen der Menüs ändern, so kann man z.B. das Menü  Sensoren  in  Übersicht  ändern, in dem man den Text vor dem Komma entsprechend anpasst. Es können auch Menü-Optionen ausgeblendet werden, indem man ein Raute-Zeichen (#) an den Zeilenanfang setzt. Das kann man z.B. nutzen, um das Menü  Tabellen  auszublenden, wenn man dies nicht benötigt. Es ist auch möglich, das Menü zu erweitern. Durch Hinzufügen der folgenden Zeile lässt sich beispielsweise eine Google-Suche einbauen:

Google,https://www.google.de

Zum Abschluss dieses Abschnitts noch eine Übersicht über die Dateien, die vom Web-Modul verwendet werden und deren Funktion:

/srv/sensor/al1 - al4Konfiguration der Alarme 1 - 4
/srv/sensor/s1 - s31Konfiguration der Sensoren 1 - 31
/srv/sensor/alogAlarm-Log mit den letzten 100 Ereignissen
/srv/sensor/mapSensor-Zuordnungsdatei
/srv/sensor/passPasswortliste für den Zugang zum Web-Server
/srv/sensor/senempfangene Sensorbelegung
/srv/sensor/sensor.rrdDatenbank für die Sensorwerte
/srv/sensor/system.rrdDatenbank für die Systemauslastungswerte
/srv/sensor/changeHinweis der Web-Seite für den Sensordienst zum erneuten Einlesen der Konfigurationsdaten
 
/mnt/ram/al1 - al4aktueller Status der Alarme 1 - 4
/mnt/ram/s1 - s31aktueller Wert der Sensoren 1 - 31
 
/var/www/html/index.phpHauptseite  Sensoren  (Sensor- und Alarm-Übersicht)
/var/www/html/tables.phpSeite  Tabellen  (Sensor- und Alarm-Daten in Tabellenform)
/var/www/html/graph.phpSeite  Grafik  (grafische Kurvenverläufe von bis zu 4 Sensoren)
/var/www/html/alarms.phpSeite  Alarme  (Alarm-Log mit den letzten 100 Ereignissen)
/var/www/html/config.phpSeite  Konfiguration  (Konfiguration der Sensoren und Alarme sowie der Elemente der Seite  Sensoren )
/var/www/html/server.phpSeite  Server  (Auslastung des Web-Servers in 6 Diagrammen)
/var/www/html/system.phpSeite  System  (Auslastung des Systems in 3 Diagrammen)
/var/www/html/menu.phpMenü der Seite (wird von den Web-Seiten aufgerufen)
/var/www/html/menu.datMenüstruktur (wird von menu.php verwendet)
/var/www/html/title.phpSeiten-Titel (wird von den Web-Seiten aufgerufen)
/var/www/html/sensor.datgespeicherte Sensor-, Alarm- und Grafik-Einstellungen für die Seite  Sensoren 
/var/www/html/server.datgespeicherter Servername
/var/www/html/style.cssSchriftgrößen, Farben, Parameter für Rahmen und Tabellen usw.
/var/www/html/house1.pngstilisiertes Haus als Hintergrundbild, Variante 1
/var/www/html/house2.pngstilisiertes Haus als Hintergrundbild, Variante 2
/var/www/html/favicon.icoMini-Bild für Browser
/var/www/html/icon.pnggrößeres Bild für Mobilgeräte (Start-Icon)
/var/www/html/graph.pnggeneriertes Diagramm auf der Seite  Grafik 
/var/www/html/last.datletzte Einstellung der Seite  Grafik 

Es werden bei der Benutzung der Seiten einige weitere Dateien erstellt, z.B. die Grafik-Elemente der Seite  Sensoren  und die 20 Grafik-Presets. Grundsätzlich können alle Elemente der Web-Seite im Verzeichnis /var/www/html beliebig bearbeitet oder durch eigene Dateien ersetzt werden.

SymbolBedienung

Die folgenden Bilder zeigen einige Seiten von meinem Web-Modul. Auf den meisten Seiten gibt es nicht viel zu bedienen und das gilt auch für die Seite  Sensoren  im nächsten Bild. Es gibt nur eine Besonderheit: diese Seite wird alle 60 Sekunden automatisch aktualisiert.

SFHs Web-Server 1

Auf der nächsten Seite  Tabellen  lässt sich ebenfalls nur der aktuelle Status betrachten. Auch diese Seite wird alle 60 Sekunden aktualisiert.

SFHs Web-Server 2

Auf der Seite  Grafik  lassen sich die Kurvenverläufe von bis zu 4 Sensoren in einem Diagramm darstellen und auch in weiten Grenzen anpassen.

SFHs Web-Server 3

Im unteren Teil des Diagramms wird automatisch eine Legende erzeugt, die neben den Sensornamen auch den Minimal- und Maximalwert des Sensors im gewählten Zeitraum anzeigt. Die Beschriftung der X-Achse ist leider in Englisch und lässt sich nicht so einfach ändern. Da aber die deutschen Wochentage und Monate ähnlich sind, sollte es keine Verständigungsprobleme geben.

Für die Auswahl der anzuzeigenden Sensoren, den gewünschten Zeitraum, den Wertetyp (Mittel, Minimum, Maximum) und einige weitere Einstellungen ist ein HTML-Formular vorgesehen, welches direkt unter der Grafik eingeblendet wird. Dieses Formular ist dynamisch und passt sich an die Einstellung an, die bereits auf der Seite  Konfiguration  vorgenommen wurde. Hier ist das zur Grafik passende Formular von meinem Web-Modul:

SFHs Web-Server 4

Das Formular gliedert sich in 3 Bereiche, die durch einen Rahmen voneinander getrennt sind:

Preset ladenIn diesem Bereich lässt sich eine vorher gespeicherte Einstellung wieder laden. Es besteht die Möglichkeit, bis zu 20 solcher Voreinstellungen zu definieren. Da diese Funktion vermutlich am meisten benutzt wird, habe ich sie im oberen Teil angeordnet. Zum Aufruf eines Presets wird zunächst im linken Auswahlfeld das gewünschte Preset ausgewählt und dann auf Button geklickt. Anschließend baut sich die Web-Seite mit den gewählten Daten neu auf.
Kurvenverläufe
definieren
In diesem Bereich können die angezeigten Kurvenverläufe in weiten Grenzen konfiguriert werden. Dazu wählt man zunächst den Zeitraum aus, den man betrachten möchte. Im Angebot sind insgesamt 10 Zeiträume im Bereich von einem Tag bis zu einem Jahr. In den 8 darunter angeordneten Auswahlfeldern sucht man sich die Sensoren und Wertetypen aus, die angezeigt werden sollen. Es werden alle Sensoren zur Auswahl angeboten, die auf der Seite  Konfiguration  nicht mit einer Sperre versehen sind. Bei den Wertetypen stehen der Mittelwert, der Minimalwert und der Maximalwert zur Verfügung. Zur Anzeige der aktuellen 15-Minuten-Werte wählt man hier den Mittelwert aus.

Im umrahmten Bereich rechts daneben sind noch 2 spezielle Einstellungen möglich. Der Hintergrund der Option Alternative Y-Skala ist folgender: Die Software RRDTool, die für die Erstellung der Grafik verantwortlich ist, passt sich normalerweise an den Wertebereich an und beschriftet dann auch entsprechend die Y-Skala. Leider klappt das nicht immer perfekt und so kann man eine von 3 alternativen Beschriftungen wählen. Bei der Einstellung aus arbeitet die Automatik von RRDTool. Die Einstellung 1 stellt ein festes Raster von einer Einheit ein (je nach Sensortyp 1°C, 1% oder 1hPa), die Einstellung 2 benutzt 2 Einheiten und die Einstellung 3 benutzt 4 Einheiten. Hier darf man gern ein wenig experimentieren. Die Option Linienstärke (Pixel) ist selbsterklärend.

Wichtig: Erst wenn man auf den Button Button klickt, werden die Eingaben in diesem Bereich übernommen und die Seite mit den gewählten Daten neu aufgebaut. Dabei werden auch die Datumsangaben neben der Zeitraum-Auswahl aktualisiert. Diese sollen helfen, den angezeigten Bereich der Grafik besser einzuordnen. Alternativ kann man auch einen der 3 Buttons rechts neben Button benutzen: Auch hier werden die gewählten Einstellungen übernommen, zusätzlich wird beim Button Button um ein Zeitraum-Intervall in die Vergangenheit gesprungen. Über den Button Button erfolgt ein Sprung um ein Zeitraum-Intervall in Richtung Gegenwart und der Button Button führt immer zu den aktuellen Daten.
Preset speichern
oder löschen
Der letzte Bereich bietet eine Funktion zum Speichern eines neuen Presets sowie zum Löschen eines Presets. Zum Speichern eines Presets trägt man in das Feld, welches mit dem Text Presetname eingeben, Presetplatz wählen vorausgefüllt ist, den gewünschten Namen des Presets ein und wählt anschließend rechts daneben einen der 20 Speicherplätze aus. Bei der Auswahl eines mit leer bezeichneten Platzes wird ein komplett neues Preset angelegt, bei Auswahl eines bereits belegten Platzes wird dieser ohne Rückfrage überschrieben - das Speichern wird aber erst dann ausgeführt, wenn man auf den Button Button klickt.
Das Löschen ist etwas einfacher. Hier braucht man nur im rechten Auswahlfeld das gewünschte Preset auszuwählen und anschließend auf den Button Button zu klicken. Das Löschen erfolgt ohne Rückfrage und der Speicherplatz wird anschließend als leer angezeigt.

Noch einige Hinweise zur  Grafik -Seite: Beim Speichern eines Presets spielt es keine Rolle, ob aktuelle Daten oder Daten in der Vergangenheit angezeigt werden - es wird nur der gewählte Zeitraum gespeichert, jedoch nicht der gerade angezeigte Zeitbereich. Wird ein Preset geladen, dann werden immer aktuelle Daten angezeigt. Alle Einstellungen auf dieser Seite bleiben erhalten und wenn man später erneut auf die Grafik-Seite wechselt, dann erscheint die Seite wieder mit gleichen Einstellungen. In diesem Fall bleibt auch der zuletzt angezeigte Zeitbereich erhalten, allerdings mit einer Besonderheit: Es wird der relative Abstand zur aktuellen Zeit gespeichert und später wieder hergestellt. Lag z.B. der angezeigte Bereich eine Woche in der Vergangenheit, dann werden beim nächsten Aufruf der Seite wieder Daten von einer Woche zuvor angezeigt, allerdings bezogen auf die aktuelle Zeit. Das liegt daran, dass ich RRDTool mit relativen Zeitangaben aufrufe, was einfacher zu handhaben ist. RRDTool hat noch andere Eigenheiten, die man kennen sollte. So arbeitet es intern mit UTC und das hat zur Folge, dass die Tageswerte in unserer Zeitzone um 1:00 Uhr und während der Sommerzeit sogar erst um 2:00 Uhr ermittelt werden. Außerdem sehen die Zeitangaben etwas seltsam aus, wenn ein Zeitbereich während der Sommerzeitumstellung angezeigt wird. Das alles ist kein Problem, man sollte es nur wissen und sich nicht wundern :-)

Folgendes muss auch noch erwähnt werden: Diese Seite  Grafik  ist im Prinzip nur für einen Benutzer vorgesehen. Dieser wird bei einem späteren Aufruf die Seite wieder genau so vorfinden, wie er sie beim letzten Besuch verlassen hat, da die Einstellungen gespeichert werden. Es können durchaus auch mehrere Benutzer auf diese Seite zugreifen, dann kann es allerdings passieren, dass man beim nächsten Besuch eine völlig andere Einstellungen vorfindet - nämlich die, die der vorherige Besucher hinterlassen hat. Bei einem gleichzeitigen Zugriff mehrerer Benutzer ist es unter Umständen gar nicht vorhersehbar, was angezeigt wird. Aber das dürfte in der Praxis eher selten vorkommen. Grundsätzlich wäre es möglich, mehrere Benutzer zu verwalten oder Cookies zu verwenden, aber der Aufwand war mir zu groß. Ebenfalls aufwändig wäre es, die Eingabe im Formular so einzurichten, dass nur ein Sensortyp angezeigt wird (Temperatur, Luftfeuchtigkeit oder Luftdruck). Es ist hier möglich, die verschiedenen Sensortypen gemischt darzustellen, das Ergebnis wird aber nicht überzeugen.

Und hier noch einige Informationen zur Datenstruktur: Wenn die Datenbank nach meiner Voreinstellung angelegt wurde, dann werden alle Sensorwerte im Abstand von 15 Minuten gespeichert und insgesamt 40 Tage lang aufbewahrt. Danach werden die ältesten Daten überschrieben, vom aktuellen Zeitpunkt aus gesehen kann man dennoch immer 40 Tage in die Vergangenheit schauen. Bei jedem Tageswechsel wird außerdem ein Mittelwert, ein Minimalwert und ein Maximalwert in einem weiteren Speicherbereich abgelegt, der Platz für 3700 Tage bietet, also über 10 Jahre. Auch hier werden dann irgendwann ältere Daten überschrieben, aber es bleiben vom aktuellen Zeitpunkt aus gesehen immer 3700 Tage greifbar. Werden bei der grafischen Anzeige Minimal- oder Maximalwerte ausgewählt, dann wird immer auf diesen zweiten Speicherbereich zugegriffen. Anders funktioniert das bei den Mittelwerten: Solange der angezeigte Bereich weniger als 40 Tage in der Vergangenheit liegt, werden die Daten aus dem höher aufgelösten 40-Tage-Speicher entnommen. Sollen Daten angezeigt werden, die weiter in der Vergangenheit liegen, dann greift RRDTool automatisch auf den zweiten Bereich zu und zeigt immer die ungenaueren Tageswerte an, auch wenn ein Teil des Anzeigebereiches im 40-Tage-Zeitraum liegt.

Die nächste Seite  Alarme  erfordert keine Bedienung und zeigt eine Tabelle mit den letzten 100 Alarm-Ereignissen an, wobei das neueste Ereignis ganz oben steht. Diese Seite wird alle 60 Sekunden aktualisiert.

SFHs Web-Server 5

Die nun folgende Seite  Konfiguration  überspringe ich hier, da diese bereits beschrieben wurde. Die nächste Seite  Server  zeigt die Auslastung des Web-Servers an:

SFHs Web-Server 6

Diese Seite zeigt insgesamt 6 Diagramme, welche die Auslastung unseres Web-Servers in 3 Zeitintervallen darstellen: die oberen beiden Bilder zeigen die Auslastung in den vergangenen 4 Stunden, die mittleren beiden Bilder die Auslastung in den vergangenen 24 Stunden und die unteren Bilder die Auslastung in den vergangenen 30 Tagen. Auf der linken Seite ist die übertragene Datenmenge zu sehen, zusätzlich noch der Minimal-, Mittel- und Maximalwert im dargestellten Zeitraum, getrennt nach Up- und Download (In und Out). Allerdings muss ich zugeben, dass mir die Bedeutung dieser Werte nicht ganz klar ist. Die rechte Seite zählt die Serveranfragen. Diese Server-Auslastung habe ich von der lighttpd-Homepage übernommen, in PHP übertragen und ein wenig eingedeutscht: http://redmine.lighttpd.net/projects/1/wiki/Docs_ModRRDTool. Während im Original die Grafiken zu bestimmten Zeiten über den cron-Dienst erstellt werden, lasse ich die Grafiken erst beim Aufruf der Seite generieren. Das dauert zwar 1-2 Sekunden, aber die Bilder sind dann aktuell.

Die letzte Seite  System  zeigt die Auslastung des Raspbian-Systems an:

SFHs Web-Server 7

Die Anzeige der Systemauslastung erfolgt über 3 Diagramme in verschiedenen Zeitintervallen. Das obere Diagramm zeigt die Auslastung der vergangenen 5 Stunden mit einer Auflösung von einer Minute an. Die beiden anderen Diagramme stellen die mittlere und die maximale Auslastung der vergangenen 2 Tage und 30 Tage dar, die Auflösung beträgt hier 10 Minuten bzw. 2 Stunden. Im Gegensatz zum oberen Diagramm erscheinen hier 2 Werte. Eine schwarze Linie zeigt die durchschnittliche Auslastung an und die Balken in Orange die maximale Auslastung.

Die angezeigten Werte entsprechen dem „Load average“ des Linux-Systems und geben die Anzahl an wartenden Prozessen an. Eine Auslastung unter 1 bedeutet, dass das System alle anfallenden Aufgaben sofort erledigen kann. Werte über 1 bedeuten, dass Prozesse in einer Warteschlange stehen und somit das System überlastet ist. Die Werte muss man außerdem im Zusammenhang mit der Anzahl der Prozessoren betrachten. Bei einem alten Raspberry Pi mit nur einem Prozessor liegt der maximale Auslastungswert bei 1, die neueren Raspberry Pi-Modelle 2 und 3 haben 4 Prozessorkerne und hier liegt der maximale Wert bei 4. Bei meinem System (Raspberry Pi-Modell 2) ist also alles im grünen Bereich.

SymbolSonstiges

Dieses Projekt war eigentlich schon lange geplant, allerdings hatte ich die Realisierung immer wieder aufgeschoben. Das Thema ist nämlich recht komplex und ein einzelner Bastler ist schlicht nicht in der Lage, die komplette Hard- und Software für ein solches Projekt selbst zu erstellen. Also suchte ich nach geeigneten Lösungen, die man für diesen Zweck verwenden kann. Da gibt es z.B. Web-Server auf der Basis eines AVR-Mikrocontrollers. Das wäre eigentlich ein Projekt nach meinem Geschmack gewesen, die Praxis hat aber gezeigt, dass das nicht so zuverlässig funktioniert. Auch kann man hier nicht mal eben schnell die Konfiguration ändern - diese muss man erst in den Quelltext einbauen, neu kompilieren und den kompletten Flash-Speicher des Controllers neu beschreiben. Dann gibt es noch fertige Produkte wie z.B. den XPort von Lantronics, aber das ist schon recht speziell und es war nicht klar, ob sich dieses Modul überhaupt für mein Projekt eignet.

Im Herbst 2013 kaufte ich einen Raspberry Pi, obwohl ich anfangs auch hier keinen Plan hatte, wie ich mein Projekt damit realisieren könnte. Schließlich hatte ich keine Erfahrungen mit Linux, Shell, Perl, Python oder PHP. Zum Glück gibt es gerade für Linux und die dort verwendeten Sprachen viele Informationen im großen Netz und so wurde schnell klar, dass der Raspberry Pi die perfekte Plattform für das Web-Modul bietet. So fing ich gegen Mitte November 2013 an, ein Programm zu schreiben, um die Daten vom Sensormodul erst einmal in den Raspberry Pi zu bekommen. Anfangs versuchte ich das mit Python, entschied mich dann aber für Perl. Es gab natürlich immer mal Hindernisse und Probleme, aber alles konnte irgendwie gelöst werden. Nachdem das Einlesen der Sensordaten zuverlässig funktionierte, beschäftigte ich mich mit dem Web-Server und die nächste Lernphase mit PHP begann. Aber schließlich funktionierte irgendwann das gesamte Projekt wie gewünscht.

Ich habe dann lange überlegt, ob ich dieses Projekt überhaupt veröffentlichen sollte, denn das passt eigentlich gar nicht zu den anderen Bastelprojekten. Andererseits ist der Aufbau des Web-Moduls schon eine Art Bastelei - durch die vielen Konfigurationsarbeiten allerdings auf höherem Niveau :-)  Da ich neben dem Sensor-Programm und den Web-Server-Dateien auch noch eine ausführliche Anleitung mitgeben wollte, habe ich mein bereits laufendes Web-Modul noch einmal „platt“ gemacht und die Installation komplett von vorn begonnen. Dabei wurde jeder Schritt genau dokumentiert, damit auch ja nichts vergessen wird. Während der Installation fanden sich sogar noch einige Dinge, die ich beim ersten Versuch nicht so optimal gelöst hatte.

Im Februar 2014 wurde mit der nächsten Stufe begonnen: RRDTool. Dafür kaufte ich zunächst einen weiteren Raspberry Pi und kopierte anschließend alle Daten vom laufenden Web-Modul auf das neue Testsystem. Es dauerte dann einige Zeit, bis das Konzept von RRDTool verstanden wurde und erste Erfolge zu sehen waren. Wichtig war zunächst, den Mechanismus zum Speichern der Werte in der Datenbank fertig zu stellen, damit ausreichend Daten zum Testen der Grafik-Ausgabe zur Verfügung stehen. Ich hatte sogar darüber nachgedacht, die gesammelten Daten von AnzKom in die Datenbank zu übertragen, dies aber wegen des hohen Aufwandes wieder verworfen. Da die Entwicklung der Grafik-Seite länger dauerte als geplant, waren schließlich doch genügend Testdaten vorhanden.

Im Sommer 2014 installierte ich zusätzlich die Hausautomatisierungssoftware „Fhem“ (www.fhem.de) und in diesem Zusammenhang wurde das Web-Modul mit einer Echtzeituhr ausgestattet. Diese Erweiterung habe ich nicht veröffentlicht, da die Uhr nicht unbedingt notwendig ist und auch weil das Einbinden einer solchen Uhr in das damalige Raspbian Wheezy sehr umständlich war. Im Sommer 2015 war nochmals eine Erweiterung notwendig, denn die neue Matrixuhr sollte eine Verbindung zum Web-Modul bekommen. Dazu musste zum einen die Hardware geändert werden und zum anderen auch die Seitenstruktur des Web-Servers. Ich habe die Gelegenheit genutzt und zunächst die Seiten des Web-Servers so erweitert, dass alle Einstellungen über HTML-Formulare erfolgen können und keine Dateien mehr editiert werden müssen. Außerdem setzte ich ein Testsystem mit dem neuen Raspbian Jessie auf und passte die gesamte Inbetriebnahme auf dieses System an.

Leider ist beim 2016 auf dem Markt gekommenen Raspberry Pi Modell 3 die bisher für die Kommunikation verwendete serielle Schnittstelle /dev/ttyAMA0 jetzt mit dem integrierten Bluetooth-Modul verbunden. Das hat zur Folge, dass eine Anpassung meiner Software notwendig wurde. Bei dieser Gelegenheit habe ich im Oktober 2016 die Beschreibung der Inbetriebnahme überarbeitet und für die aktuellen Versionen von „Raspbian Jessie with Pixel“ und „Raspbian Jessie Lite“ angepasst.

Im August 2017 wurde die neue Raspbian-Version Stretch veröffentlicht. Das bedeutete für mich, dass ich die Beschreibung des Web-Moduls wieder überarbeiten muss. Ich habe die Gelegenheit genutzt und mein Web-Modul komplett neu aufgesetzt. Dabei bin ich diesmal etwas anders vorgegangen und habe eine Möglichkeit gefunden, den Raspberry Pi ohne weitere Zusatzgeräte wie Bildschirm, Tastatur und Maus in Betrieb zu nehmen. Dies habe ich natürlich wieder Schritt für Schritt dokumentiert und veröffentlicht. Auch ist mein Web-Modul inzwischen auf einen Raspberry Pi 2 umgezogen und dafür musste ein neuer Pegelwandler aufgebaut werden. Dieser passt nun auf alle aktuellen Raspberry Pi-Modelle und bei der Gelegenheit habe ich einige Fotos erneuert.

Im Frühjahr 2018 habe ich eine zweite Matrixuhr gebaut und hier musste ein grundsätzliches Problem gelöst werden: Die Verbindung zwischen dem Web-Modul und der Matrixuhr (bzw. den Matrixuhren) muss anders erfolgen und am besten drahtlos. Die Lösung war ein Nachrichtenverteiler in Form des MQTT-Servers mosquitto. Hiermit kann man die Sensordaten und Alarminformationen nicht nur an mehrere Matrixuhren verteilen, sondern auch an andere Geräte oder Anwendungen, die gar nicht zum Temperatur-Messsystem gehören. Somit ergab sich in meinem Fall auch noch eine elegante Möglichkeit, alle Daten an die Haussteuerung „Fhem“ zu übermitteln. Jede Matrixuhr muss allerdings mit einem eigenen Raspberry Pi ausgerüstet werden, der jedoch in einer preisgünstigen Version erhältlich ist und durch die WLAN-Funktion keine Kabelverbindung zum Web-Modul benötigt.

Eins möchte ich noch erwähnen: Alle hier verwendeten Programme können kostenlos genutzt werden. Vielen Dank an die Entwickler, die hier sicher unzählige Stunden geopfert haben und trotzdem alles kostenlos zur Verfügung stellen.