Archiv der Kategorie: Allgemein

qemu-guest-agent für pfSense (ab Version 2.6.0) und pfSense+

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.

Mehr Infos zum qemu-guest-agent gibt es ua. hier:

Meine Anleitung stützt sich – neben meinen Erkenntnissen – auf diese Artikel:

Schritt für Schritt durch die Installation

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:

qemu_guest_agent_enable="YES"
qemu_guest_agent_flags="-d -v -l /var/log/qemu-ga.log"

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.

OpenVPN Profil in Ubuntu Desktop Network Manager importieren

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!

Diese Datei hat sich für Windows erzeugen lassen, wobei ich den Community-Client (“Installer, Windows 7 and later”) empfehle: https://openvpn.net/index.php/download/community-downloads.html

Für Android muss man ein eigenes Konfig-File exportieren, dieses hat sich problemlos mit diesem Client nutzen lassen: https://play.google.com/store/apps/details?id=de.blinkt.openvpn

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.

IoT und Hausautomatisierung mit Sonoff

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:

Schalter mit Messfunktion

Diese Produkte ermöglichen das Schalten abhängig von Temperatur und Luftfeuchtewerten bzw. melden den Energieverbrauch.

Für die Nutzung der Temperatur- & Luftfeuchtemessung gibt es drei Sensoren, die an den TH10 oder TH16 angeschlossen werden:

  • DS18B20: Außensensor aus rostfreiem Stahl
  • AM2301: Innensensor mit Temperatur- & Luftfreuchtesensor
  • Si7021: Innensensor mit hochpräzisem Temperatur- & Luftfreuchtesensor

Touch

Mit diesen kapazitativen Schaltern kann man Kommandos an die Haussteuerung senden oder Schalter bedienen.

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.

Details zu TASMOTA und dem Flashen dieser Firmware gibt es hier:
https://github.com/arendst/Sonoff-Tasmota/wiki

Induktives Laden mit Qi

Samsung S7 hat induktiv voll geladen

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:

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!

Meldung eines Samsung S7

5″ Display für Raspberry Pi

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.

Diese Zeilen hänge ich der /etc/boot.txt an:

hdmi_group=2
hdmi_mode=87
hdmi_cvt 800 480 60 6 0 0 0

Den Tipp habe ich übrigens von hier. Da findet man auch die Anleitung für die Aktivierung der Touchscreen-Funktion.

Wer keine 3-5 Wochen auf den Screen warten möchte, bekommt ihn hier auch auf Amazon.de.

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.

Links

LoRa APRS Gateway mit Raspberry Pi Zero W

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

Die Software, das Image für die SD-Karte (ich habe ein 8 GB-Karte zur Hand), findet ihr hier zum Download:
www.iot4pi.com/de/raspberry-pi-projekte-software/lora-aprs-gateway

Nachdem man die SD-Karte in den Raspberry gesteckt und das Gehäuse mit dem Raspberry darin geschlossen ist, bootet man den Raspberry zum ersten Mal.

Ich habe in der /etc/network/interfaces sofort eine statische IP-Adresse eingetragen.

Die Konfiguration des Gateways fwird in der Datei /home/pi/iot4pi/APRS.conf vorgenommen. Im Wesentlichen muss man nur folgende Zeilen anpassen:

APRS_IS_CALL:OE1SCS-10
APRS_IS_PASSCODE:12345
LATITUDE:4811.48N
LONGITUDE:01623.23E

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:

country=AT
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
    ssid="meinwlan"
    psk="meinpasswort"
}

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

Optional, für den Anschluss an einen Monitor:

SD-Karte mit Linux kopieren

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.

Erstellen eines Backups

sudo dd bs=4M if=/dev/sdb | gzip > ./sd-card-img.gz

Zurückspielen eines Backups

sudo gzip -dc sd-card-ah2-rpi2-1ch-dragino.img.gz | sudo dd bs=4M of=/dev/sdb

Kopieren einer Karte

sudo dd bs=4M if=/dev/sdb of=/dev/sdc

WordPress Updates über Kommandozeile

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.

Installation von wp-cli

Das Werkzeug wird von dieser Adresse gedownloadet und getestet: https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
$ php wp-cli.phar --info

Wenn alles OK ist, installiere ich es als /bin/wp und setze das Execute-Bit:

$ chmod +x wp-cli.phar
$ sudo mv wp-cli.phar /bin/wp

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:

root@wp:~# sudo -u wp -i wp --path=/var/www/html --info
PHP binary: /usr/bin/php5
PHP version: 5.5.9-1ubuntu4.22
php.ini used: /etc/php5/cli/php.ini
WP-CLI root dir: phar://wp-cli.phar
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /home/wp
WP-CLI packages dir: 
WP-CLI global config: 
WP-CLI project config: 
WP-CLI version: 1.4.1

Updates

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:

sudo -u wp -i wp --path=/var/www/html plugin update --all

Themes werden auf diesem Weg alle aktualisiert:

sudo -u wp -i wp --path=/var/www/html theme update --all

Und die Core Version von WordPress wird mit diesem Kommando auf den neuesten Stand gehoben:

sudo -u wp -i wp --path=/var/www/html core update

 

Empfehlung: externe RP-SMA-Antennen

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.

APC USV mit Raspberry überwacht

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.

Ich habe also die APC Backup-UPS ES 700 mit 700 VA um weniger als € 90,- gekauft.

Die wesentlichen Entscheidungspunkte waren:

  • namhafter Hersteller,
  • ausreichend Kapazität (700 VA),
  • Schuko-Steckdosen in ausreichender Anzahl,
  • ausgesprochen preiswert und
  • 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:

export SYSADMIN=stefan@schultheis.at
export APCUPSD_MAIL="/usr/sbin/sendmail"

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:

<title>APC USV Vorzimmer</title>
<body>
<a href="/cgi-bin/apcupsd/multimon.cgi">
apcupsd MultiMon
</a><br>
<a href="/cgi-bin/apcupsd/upsstats.cgi">
apcupsd Stats
</a><br>
<a href="/cgi-bin/apcupsd/upsfstats.cgi">
apcupsd fStats
</a><br>
<a href="/cgi-bin/apcupsd/upsimage.cgi">
(apcupsd Image)
</a>
</body>