Ich betreibe eine pfSense-Firewall, hinter der meine Services betrieben werden, die ich für meine Hobbies benötige. Die pfSense wickelt auch andere nützliche Dienste, wie SSL Offloading inkl. ACME-Client für automatischen Zertifikatstausch bei Let’s Encrypt ab oder Loadbalancing für zB. meinen RabbitMQ-Cluster.
Die pfSense läuft als Virtuelle Maschine (VM) auf einem Proxmox Host. Bisher war leider keine ordentliche Implementierung des qemu-guest-agent verfügbar, mit dem einige Management-Funktionen der virtuellen Umgebung auch für die PFsense nutzbar sind.
Seit Version 2.6.0 ist nun ein Paket verfügbar, das sich – zwar nicht über das Webinterface alleine – aber immerhin „ordentlich“ (in meiner Definition) installieren und betreiben lässt, sehr gut funktioniert und mit sinnvollem Aufwand zu installieren ist.
1) öffne die Console und gib folgendes Kommando für die Installation ein:
pkg install qemu-guest-agent
2) man benötigt das Paket „Shellcmd“, um beim Booten den automatischen Start des qemu-guest-agent einzurichten. Die Installation erfolgt über das Webinterface: 2a) unter System / Paketverwaltung das Paket „Shellcmd“ installieren. 2b) nun ist unter Dienste / Shellcmd möglich, dieses Kommando hinzuzufügen, das ab sofort bei jedem Reboot den Dienst startet:
service qemu-guest-agent start
3) in der Datei /etc/rc.local (in manchen Anleitungen steht /etc/rc.conf.local, für pfSense+ ist es /etc/rc.conf) muss man nun folgende Zeilen einfügen:
Damit ist die Installation abgeschlossen! Nach einem Reboot sollte der Dienst starten bzw. laufen und scheint bei mir in der Proxmox-Umgebung auch sofort auf.
4) als letzter Schritt wird empfohlen, in den Erweiterte Einstellungen / System Feinabstimmung („Tunables“) folgenden Eintrag hinzuzufügen:
Abstimmungsname: virtio_console_load
Wert: YES
Hinweis zu Fehlermeldung
Sollte (ist bei pfSense+ aufgetreten) in der Logdatei qemu-ag.log folgendes zu finden sein, dann ist der Qemu-Guest-Agent bei er VM noch nicht aktiv:
1680079085.256215: debug: disabling command: guest-fstrim 1680079085.256276: critical: error opening channel: No such file or directory 1680079085.256287: critical: error opening channel 1680079085.256293: critical: failed to create guest agent channel 1680079085.256300: critical: failed to initialize guest agent channel
Vielen Dank an Alexander Grümmer für die Ergänzungen, die er mir im März 2023 für pfSense+ geschickt hat, nachdem dort kleinere Anpassungen notwendig waren.
Für den Zugriff zu einem Projektarbeitsbereich haben wir beschlossen OpenVPN mit PFsense / OpnSense Firewalls zu nutzen.
Nach der Konfiguration der Firewall gibt es die Möglichkeit, das Profil für die Endbenutzer in einer .ovpn-Datei zu exportieren. Diese enthält bereits die wichtigsten Konfigurationsparameter wie den Servernamen der Firewall zu der man verbinden will, das Protokoll, genauere Details dazu und auch die Zertifikate sind enthalten. Toll, alles in einer Datei!
Unter Linux (Ubuntu 18.04 Desktop in meinem Fall) mit Gnome Desktop hat das auf den ersten Blick komplizierter gewirkt. Ist es aber nicht wirklich, wenn man weiß wie:
Zuerst installiert man die Network Manager-Erweiterung. Falls OpenVPN nicht schon installiert ist, wird diese automatisch mitinstalliert:
apt-get install network-manager-openvpn-gnome
Nun kann man das .ovpn-File, das wir für Windows bereits erzeugt haben, importieren:
nmcli connection import type openvpn file vpn-config.ovpn
Ab sofort scheint die Verbindung im Network Manager auf. Ich musste dann doch noch einzelne Parameter anpassen, bis es funktioniert hat, das war aber schnell erledigt:
Ich musste meinen Benutzernamen eingeben, das hat er nicht aus dem .ovpn-Konfigfile automatisch übernommen. Weiters habe ich ausgewählt, dass die Verbindung nur mir und nicht anderen Benutzern zur Verfügung steht. Fertig! Ich kann mich verbinden und auf die Daten über das VPN zugreifen.
Vor einigen Monaten bin ich von einem Freund auf die Produkte von Sonoff aufmerksam geworden. Die Geräte von Sonoff sind sehr preiswert und ermöglichen das Schalten von Verbrauchern, Auslesen von Sensorwerten und Messwerten.
Das Besondere dabei: die Geräte nutzen WLAN für die Kommunikation. Dafür wird der ESP8266 Chip verwendet, den viele schon aus der IoT („Internet of Things“)-Welt kennen. Es gibt neben der Sonoff-Software auch alternative Open Source-Projekte, mit denen die Geräte unabhängig von der „Sonoff-Cloud“ betrieben werden können. Beispielsweise verwende ich die TASMOTA-Software, um meine Sensoren und Aktoren von Sonoff mit FHEM zu nutzen. Der Austausch der Informationen funktioniert dabei mittels MQTT, wodurch man sehr flexibel ist – auch bei der Integration mit anderen Systemen.
Kurzer Überblick
Die Sonoff-Produkte senden ihre Daten entweder über ein eigenes Protokoll im 433-MHz-Bereich oder über WLAN. Ich konzentriere mich hier auf die WLAN-Nutzung, da sich damit für mich mehr Anwendungen realisieren lassen.
Schalter
Zum Schalten von 230 Volt-Endgeräten gibt es mehrere Möglichkeiten:
Es gibt noch etliche weitere Produkte von Sonoff. Stöbert doch einfach mal! Beim Kauf empfehle ich darauf zu achten, ob das Teil über WLAN oder 433 MHz zu betreiben ist, damit alle Produkte zueinander kompatibel sind.
Software / Firmware
Falls ihr die Geräte werden nach dem Kauf mit der Original-Software betreiben möchtet, gibt es eine entsprechende Smartphone-App für die Konfiguration. Die Daten landen in der Sonoff-Cloud und können dort mit Diensten wie zB. Alexa oder IFTTT verknüpft werden. Natürlich ist man hier von der Cloud abhängig.
Als Alternative kann ich die Software TASMOTA empfehlen. Man muss zwar einmalig jedes Gerät mit TASMOTA flashen (ein TTL-Konverter mit 3,3V wird benötigt), ist dann jedoch unabhängiger. Man kann Schaltbefehle über ein Webinterface steuern oder das Gerät per MQTT an eine Haussteuerung oä. anbinden. Für diese Variante hat man zwar ein bißerl mehr Aufwand, ist aber unabhängiger.
Ich beziehe mich bewusst nicht nur auf Handys bzw. Smartphones, weil ich glaube, dass dieses induktive Laden viele andere Anwendungsmöglichkeiten bietet. Ich möchte ja auch den Akku eines tragbaren LoRaWAN-Sensors künftig induktiv laden, aber das ist ein anderes Thema…
Dass es die Möglichkeit gibt, Smartphones induktiv aufzuladen, ist mir schon länger bewusst. Ich habe aber auch gesehen, dass es mehrere Standards gibt, die nur eingeschränkt (wenn überhaupt) kompatibel erscheinen. Im letzten Urlaub habe ich einiges zu dem Thema gelesen und bin nun auf den Zug aufgesprungen und sehr begeistert.
Hauptgrund war, dass es nun einen von allen Herstellern anerkannten und kompatiblen Standard gibt und meine Bedenken hinsichtlich Gesundheitsproblemen durch permanente Strahlung zerstreut wurden.
Funktionsweise
Induktives Laden läuft: 53%. Ca. 1 h 22 min bis voll geladen
Wie funktioniert das induktive Laden? Im Prinzip werden eine Ladeschale (oder Halterung) benötigt, die mit einer Stromversorgung (meist USB) verbunden ist und ein Endgerät (Smartphone), das induktives Laden unterstützt. Sobald man das Smartphone auf die Ladeschale legt, beginnt das Handy zu laden.
Dabei bedient man sich einer Technologie, die von Transformatoren her längst bekannt und im Einsatz ist: eine Spule in der Ladeschale induziert ein Magnetfeld und dieses wird von einer Spule im Smartphone wieder in elektrischen Strom umgewandelt.
Spezifikation
Das Wort „Qi“ bedeutet auf chinesisch „Lebensenergie“ und ist vielleicht von Qi Gong her bekannt. Hier beschreibt der Name die proprietäre Technologie des Wireless Power Consortiums. Nachdem sich der konkurrierende Standard „Powermat“ der „Power Matters Alliance“ zurückgezogen hat, ist nun Qi der de-facto Industriestandard.
Die Übertragung findet im Bereich der Langwelle von 110 bis 205 kHz mit nominal 19 Volt statt. Es gibt mehrere Leistungsklassen von 5-15 Watt (Low Power) bis 120 Watt (Medium Power). Ich glaube, dass dadurch in naher Zukunft auch Anwendungen für andere Geräte mit höherem Energiebedarf ermöglicht werden. Die Übertragung funktioniert meist bei einem Abstand im Bereich einzelner Millimeter. Die Effizienz der Übertragung liegt je nach Gerät bei 60-90%, ist also immer verlustbehafteter im Vergleich zum Laden über Kabel.
Besonders gut hat mir gefallen, dass der Standard auch eine Datenübertragung zwischen den Geräten definiert. Diese ist mit 2 kbit/s spezifiziert und ermöglicht den Informationsaustausch zwischen den Qi-Komponenten. Damit ist nun auch klar, dass der Sendeteil (zB. die Ladeschale) nicht permanent ein starkes elektromagnetisches Feld erzeugt, sondern erst mit höherer Leistung beginnt, sobald ein kompatibles Endgerät erkannt wurde, die Datenverbindung hergestellt ist und die Geräte vereinbart haben, welche Ladung (zB. Leistung) durchgeführt wird.
Kann mein Smartphone Qi und was mache ich, wenn nicht?
Die einfachste Möglichkeit herauszufinden ob das eigene Smartphone Qi unterstützt ist wie üblich: ausprobieren, oder im Handbuch nachlesen. 😉
Samsung Smartphones sind beispielsweise seit dem Samsung S6 Qi-fähig und Apple-Geräte seit dem iPhone 7.
Es ist aber auch möglich, das eigene Smartphone nachzurüsten. Dazu gibt es recht günstig dünne induktive Ladeempfänger, die man zB. in der Schutzhülle des Handys verstecken kann. Diese Empfänger werden zB. per USB Micro (oder Typ C) an das Smartphone angeschlossen. Das Handy merkt eigentlich nicht, dass es induktiv geladen wird, sondern erkennt natürlich nur, dass es an einem „Ladekabel“ hängt. Der USB-Port ist damit natürlich auch belegt – das sollte man beachten. Die Empfänger sind so dünn und oft so passgenau, dass sie zwar einerseits kaum sichtbar/spürbar sind, andererseits aber kaum Spielraum haben und man immer die Hülle herunternehmen muss, falls man den USB-Port anders nutzen möchte.
Ladeempfänger ist zu lang und verdeckt den Fingerprint Sensor teilweise
Außerdem empfehle ich sehr, nachzusehen ob der Ladeempfänger von der Form für das eigene Smartphone passt. Bei meinem ersten Kauf für mein Nexus 5X habe ich einen zu großen Empfänger gekauft, der verdeckt fast die Hälfte des Fingerprint-Scanners. Den verwende ich nicht, also stört es mich nicht, aber hätte ich besser aufgepasst, hätte ich was Passendes um’s gleiche Geld bekommen.
Ergebnisse im Test
Mittlerweile habe ich ein paar Ladeschalen und ein paar Qi-fähige Endgeräte getestet, sowie eine handvoll Handys nachgerüstet.
Es funktioniert alles einwandfrei. Man muss sich daran gewöhnen, dass die Ladezeiten länger werden, weil die meisten kostengünstigen Qi-Geräte 800mAh oder vielleicht 1000mAh schaffen. Damit brauchen moderne Handyakkus schon rein rechnerisch 4-5 Stunden für eine volle Ladung. Aufgrund des Verlusts in der Übertragung wird das nochmal erheblich mehr. Über Nacht ist das aber normalerweise kein Problem.
Ich erwähne die längere Ladezeit nur deswegen so explizit, weil ich das Gefühl habe, dass bei kabelgebundenen Lademöglichkeiten gerade die Erwartungen sehr hoch gesteckt werden, nämlich „mehrere zig“-Prozent in einzelnen Minuten laden zu können. Dort kommen auch Ströme von 4,6 Ampere zum Einsatz, die über den USB-Port in den Akku „gedrückt“ werden. (Vgl. Qualcomm Quick Charge 3 oder 4+).
Eine berichtenswerte Erfahrung habe ich aber auch gemacht: ich habe mir eine Ladeschale ins Büro gelegt. Tagsüber bin ich öfters in Besprechungen und dann meist nur 20 Minuten kurz am Platz die neuen Emails durchschauen. Früher habe ich dabei nie oder selten das Handy angesteckt und aufgeladen. Heute lege ich es regelmäßig bei diesen kurzen Aufenthalten auf die Ladeschale. Und das führt dazu, dass ich tagsüber immer wieder nachlade und so an manchen Tagen eigentlich kaum noch unter 90% auf der Akkuanzeige komme…
Eine weitere Erkenntnis ist, dass man manche Smartphones relativ genau platzieren muss, damit das Laden funktioniert. Die Spulen müssen möglichst übereinander liegen. Ein Samsung S6 zum Beispiel funktioniert auf einem meiner getesteten Ladeschalen (es handelt sich um dieses Modell) nur, wenn ich es eher rechts platziere. Mittig funktioniert es nicht und links auch nicht. Andere Smartphones funktionieren mittig und rechts, aber links auch nicht. Daran habe ich mich aber recht schnell gewöhnt und lege die jeweiligen Geräte mittlerweile ohne viel Nachdenken richtig auf.
Folgende Geräte sind auf den Fotos in diesem Blog gezeigt:
(der Micro USB Empfänger ist nicht mehr lieferbar)
Fazit
Ich liebe es! Einziger Wermutstropfen ist der Energieverlust bei der Übertragung. Das ist sehr schade und Verschwendung. Von der Zuverlässigkeit, Kompatibilität und Geschwindigkeit (für mich ausreichend) alles super!
Immer wieder muss ich meinen Monitor abstecken, um ihn an einen Raspberry anzuschließen. Das nervt.
Nachdem ich mehrere aufsteckbare LCD-Module probiert habe, bin ich mittlerweile an Treiberinstallationen und anzupassenden Kernels verzweifelt.
Jetzt habe ich eine einfache Lösung gefunden: natürlich ist HDMI die richtige Schnittstelle. Da braucht man einfach gar nichts zu konfigurieren, weil’s eh Standard ist.
Auf Aliexpress habe ich ein günstiges 5″ HDMI Display mit 800×480 Pixel Auflösung um € 22,- gefunden. Dieses Display hat auch eine Touch-Oberfläche, die ich aber nicht verwende. (Da befürchte ich wieder Treiberinstallationen und Kernelanpassungen…) Angeschlossen wird es über HDMI, es hat dazu einen Stecker/Adapter, der die beiden HDMI-Ports ganz einfach verbindet.
Das Display habe ich nach ein paar Wochen Lieferzeit erhalten und sofort auf einen Raspberry Pi 3 gesteckt. Funktionert hat es von Anfang an, allerdings nicht in voller Auflösung – es war rechts immer ein Teil unbenutzt. (Ich vermute, dass der Raspberry von 640×480 Pixel (VGA) ausgegangen ist und nicht die vollen 800px Breite genutzt hat. Durch drei Zeilen, die man in der /etc/boot.txt hinzufügt, lässt sich das beheben; ab dem nächsten Reboot wird der Bildschirm vollständig genutzt.
Als Eingabemethode verzichte ich ja auf die Touchscreen-Funktion. Dafür will ich eine Bluetooth-Tastatur oder vielleicht ein Android Handy als Bluetooth-Tastatur nutzen.
In einem anderen Beitrag habe ich darüber berichtet, dass wir erfolgreich über LoRa-Modulation APRS-Pakete gesendet haben und wie ein APRS-Tracker mit Arduino zu bauen und programmieren ist.
Nun habe ich von Sascha (www.iot4pi.com) ein fertiges, von ihm konstruiertes Board, für einen LoRa APRS Gateway bekommen. Wie er diese Boards erstellt und zusammenbaut, hat er übrigens auf seiner Seite näher beschrieben: www.iot4pi.com/de/bau-des-lora-gateway-shield
Wichtig ist auch, dass man zur Netzwerkanbindung das WLAN am Raspberry Zero W konfigurieren muss. Dazu tragt man in der Datei /etc/wpa_supplicant/wpa_supplicant.conf folgende Zeilen ein:
Da der Gateway nicht für den Außeneinsatz geeignet ist, habe ich mir eine kleine flache Fensterdurchführung zugelegt, mit der ich die Antennenleitung ans Fensterbrett bekomme und dort mit einer 70cm-Magnetfußantenne für 433 MHz verbinde.
Einkaufsliste LoRa APRS Gateway auf Raspberry Pi Zero W
Ich muss wieder öfter SD-Karten backupen und kopieren, daher notiere ich mir hier ein für alle Mal die Kommandos unter Linux dazu. Vielleicht hilft’s noch wem.
Mittlerweile nutze ich für mehrere Projekte WordPress. Ich bin recht zufrieden, die Blogs laufen teilweise schon fast 3 Jahre und ich habe kaum Probleme.
Leider laufe ich immer wieder in Probleme beim Update über das Webinterface. Eine Alternative scheint zu sein, Updates per Kommandozeile auszuführen. Dazu gibt es das Werkzeug „wp-cli“, das ich hier kurz vorstellen möchte.
Nun kann ich es systemweit als „wp“ aufrufen. Für Aktionen sollte es als User laufen, mit dem auch WordPress betrieben wird. Dazu starte ich es über sudo und mit Hinweis auf den Installationspfad der WordPress-Dateien:
Updates spiele ich nun mit Hilfe von wp-cli ein. Damit lassen sich auch mehrere Updates über mehrere Installationen automatisieren. Mit dem Suffix „–all“ muss man nicht einzeln die Plugins anführen, sondern kann alle Plugins in einem Durchgang aktualisieren.
Plugins kann man mit diesem Kommando auf einmal updaten:
Ich habe mit den mitgelieferten Antennen bei Access Points mit verschiedenen Herstellern sehr unterschiedliche (und oft schlechte) Erfahrungen gemacht.
RP-SMA Buchse
Da zum Glück die meisten Hersteller RP-SMA-Anschlüsse verbauen, habe ich mir folgende Antennen in größerer Stückzahl zugelegt und tausche sie nun regelmäßig gegen die ursprünglich mitgelieferten. Auch im Outdoor-Bereich habe ich damit seit zwei Wintern keine Probleme gehabt, obwohl die Antennen nur für indoor designed sind:
2,4 GHz und 5 GHz 8 dbi RP SMA Antenne
Die Modellbezeichnung ist bei Amazon Huacom HCM82. Eigentlich habe ich die Antenne ursprünglich auf Aliexpress gefunden und getestet. Sie ist quasi baugleich mit dem Modell, das auf Amazon angeboten wird, mittlerweile ist sie auf Aliexpress sogar teurer.
Die Antenne ist für 2,4 GHz und 5 GHz WLAN geeignet und verfügt über ein Gelenk, über das sie 45° oder 90° „geknickt“ werden kann.
Der Antennengewinn ist mit 8 dbi angegeben. Damit ist auch guter Empfang von weiter entfernten Stationen möglich.
Blick ins Innere: Antennendraht beim Gelenk
Übrigens: in Österreich (ich glaube überall in der EU) ist die maximal zulässige Leistung als e.i.r.p. definiert. EIRP bedeutet, dass die Leistung des Geräts zum Antennengewinn addiert werden muss und dann einen gewissen Wert nicht überschreiten darf. Wenn man jetzt eine stärkere Antenne montiert, sollte man darüber nachdenken, die Leistungsstufe des Geräts zu reduzieren um im gesetzlichen Rahmen zu bleiben.
Auch ein Projekt, das ich schon lange umsetzen wollte: ich möchte eine USV installieren, um bei einem Stromausfall die Netzwerkverbindungen (Internet!) über Funkfeuer aufrecht zu halten. Es sollen
das Funkfeuer-Equipment am Dach,
mein Switch,
der Router
und ein Access Point
abgesichert werden.
Die Anforderungen an die Leistung sind also recht gering (jedenfalls weit unter 100W), daher dachte ich mir, dass eine günstigere USV ausreichen müsste.
Gleichzeitig habe ich nicht die Anforderung, dass ein Server oder NAS bei einem Stromausfall heruntergefahren werden muss. Es handelt sich rein um Netzwerkgeräte, die einfach abgeschaltet werden können sobald die Akkus leer sind und auch wieder zuverlässig starten sobald sie wieder Strom erhalten.
last but not least: sie kann über ein USB-Kabel überwacht werden und ist kompatibel zu gängigen Standards.
Inbetriebnahme
Die USV war rasch in Betrieb genommen. Es muss nur ein Kabel an die Batterie im Batteriefach angeschlossen werden und dann steckt man die USV an die Steckdose. Fertig!
Über zwei LEDs (grün und rot) signalisiert die USV den Zustand und mögliche Defekte.
Überwachung
Es wäre nicht meine Art, die USV einfach vor sich hinlaufen zu lassen und darauf zu hoffen, dass alles in Ordnung ist. Es müssen also eine Überwachung der Funktion sowie ein paar Statistiken her.
Die Daten kann man von der USV über USB abrufen. Server habe ich keinen in der Nähe, also habe ich mich entschieden einen Raspberry Pi der ersten Generation (der schon einige Monate ohne Auftrag herumkugelt) für diese Funktion einzusetzen.
apcupsd auf Raspberry Pi
Als Basissystem habe ich Debian Jessie in der Minimalinstallation (ohne grafischer Oberfläche) gewählt. Mittels
apt-get install apcupsd
ist der Daemon schnell installiert.
Zwei Konfigurationsdateien müssen dann noch angepasst werden:
Die hauptsächliche Konfiguration wird in der Datei /etc/apcupsd/apcupsd.conf vorgenommen. Ich habe nur folgende Zeilen angepasst:
UPSCABLE usb
UPSTYPE usb
DEVICE
Die Zeile „DEVICE“ bleibt bewusst ohne weitere Angabe. Das ist beim USBTYPE „usb“ so vorgesehen. Damit wird die USV automatisch erkannt.
In der Datei /etc/default/apcupsd muss ISCONFIGURED auf „yes“ gesetzt werden, damit der Dienst (beim Booten) startet.
ISCONFIGURED=yes
Nach dem Aufruf von“service apcupsd start“ startet der Daemon.
Mittels „apcaccess status“ kann auch sofort der Status der USV abgerufen werden:
pi@upsberry:~ $ apcaccess status
APC : 001,035,0906
DATE : 2016-12-30 14:58:11 +0100
HOSTNAME : upsberry
VERSION : 3.14.12 (29 March 2014) debian
UPSNAME : upsberry
CABLE : USB Cable
DRIVER : USB UPS Driver
UPSMODE : Stand Alone
STARTTIME: 2016-12-30 10:53:17 +0100
MODEL : Back-UPS ES 700G
STATUS : ONLINE
LINEV : 228.0 Volts
LOADPCT : 0.0 Percent
BCHARGE : 100.0 Percent
TIMELEFT : 38.4 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME : 0 Seconds
SENSE : Medium
LOTRANS : 180.0 Volts
HITRANS : 266.0 Volts
ALARMDEL : 30 Seconds
BATTV : 13.5 Volts
LASTXFER : Unacceptable line voltage changes
NUMXFERS : 1
XONBATT : 2016-12-30 10:56:54 +0100
TONBATT : 0 Seconds
CUMONBATT: 53 Seconds
XOFFBATT : 2016-12-30 10:57:47 +0100
STATFLAG : 0x05000008
SERIALNO : 5B16xxx
BATTDATE : 2016-08-05
NOMINV : 230 Volts
NOMBATTV : 12.0 Volts
FIRMWARE : 871.O4 .I USB FW:O4
END APC : 2016-12-30 14:58:53 +0100
Alarmierung per Email
Beispiel einer Email-Benachrichtigung nach Ausfall der Netzspannung
Wie beschrieben benötige ich keine weiteren Maßnahmen bei einem Stromausfall. Es muss also kein Server oder NAS runtergefahren werden. Ich möchte aber schon ein Email erhalten, das mir eine Statusänderung mitteilt.
In meinem Fall habe ich einen lokalen Mailserver installiert, der die Emails direkt zustellt (ohne Smarthost bzw. nicht über einen anderen SMTP-Server).
apt-get install sendmail
Um den Emailversand zu aktivieren, gehören zwei Zeilen in der /etc/apcupsd/apccontrol angepasst:
Nach dem Neustart des apcupsd habe ich die USV von der Stromversorgung getrennt und kurz darauf ein Email mit der Warnmeldung „UPS Power Failure!!!“ erhalten.
Webinterface
upsstats.cgi
Für die Anzeige von Statistiken am Webinterface gibt es vier CGIs:
multimon.cgi: hier wird übersichtlich der Status angezeigt. Das ist vor allem sinnvoll, wenn mehrere USVs von einem Daemon überwacht werden sollen:
apcupsd multimon.cgi – alles OK
apcupsd multimon.cgi – Ausfall der Stromversorgung
upsstats.cgi: detaillierte Statistik zu einer USV (siehe Screenshot oben)
upsfstats.cgi: textbasierter Output, wie beim CLI Tool „apcaccess status“ (siehe oben)
upsimage.cgi: hat bei mir nicht funktioniert
Installiert ist das Ganze recht einfach:
apt-get install apcupsd-cgi apache2
a2enmod cgi
Hiermit wird ein Apache Webserver installiert (falls nicht schon vorhanden) und die CGIs im Verzeichnis /usr/lib/cgi-bin/ hinterlegt. Über das a2enmod-Kommando wird CGI am Webserver aktiviert.
Ab sofort kann man mit dem Webbrowser die Statistiken zur USV abrufen. Da der Webserver nur vom internen LAN (nicht im Internet) erreichbar ist und auch auf dem Server keine weiteren Dienste laufen, habe ich mir die index.html im /var/www/html-Verzeichnis mit folgenden Einträgen überschrieben, um die CGIs gemütlich aufrufen zu können:
Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.
