In meinem Blog habe ich häufig Raspberry-basierte Lösungen und Anwendungen beschrieben. In letzter Zeit (in den letzten 1-2 Jahren) entstehen in der Community aber immer mehr Lösungen auf Basis von ESP8266 bzw. dem quasi-Nachfolger ESP32, also basierend auf einem „Mikroprozessor“ und nicht einem vollständigen Linux-System, wie es beim Raspberry der Fall ist. Das finde ich sehr toll, weil damit die Pflege des vollständigen Linux-Systems hinfällig wird und ich leider auch schon viele SD-Karten tauschen musste, die mit der Zeit kaputt geworden sind. Immerhin sind die Rapsberrys oft im Außenbereich den Temperaturschwankungen und Änderungen der Luftfeuchtigkeit des Wetters und der Jahreszeiten ausgesetzt.
ESP32 basierter APRS LoRa iGate von OE5BPA
Als Client, Node, Tracker, Endgerät – wie auch immer man es nennen möchte – ist der ESP8266 schon länger im Einsatz. Neu ist, dass nun mit dem ESP32 Prozessor ein leistungsstarker Kern verfügbar ist, der auch Anwendungen ermöglicht, die früher einen Raspberry oder ähnliche Geräte erfordert hätten. Immerhin hat der im Jahr 2016 vorgsetellte ESP32 beeindruckende Leistungsdaten (für einen stromsparenden Mikroprozessor): 160 bis 240 MHz auf einer Dual-Core-Plattform mit 520 KB SRAM. Eingebaut sind WLAN (802.11 b/g/n) mit Bluetooth und zahlreiche Schnittstellen, auszugsweise zB.: GPIOs, 12bit ADC und 8bit DAC, SPI, I²S, I²C, UART, Unterstützung für SD/eMMC, Ethernet, CAN 2.0 uvm. Das Datenblatt gibt dazu mehr Auskunft.
Nachdem in diesem Leistungsbereich jetzt neue Anwendungen ermöglich werden, freut es mich besonders, dass Initiativen wie LoRa APRS davon profitieren und handfeste Lösungen auch für den Gateway-Einsatz (als iGate) verfügbar sind, aktiv entwickelt und laufend verbessert werden.
Bei vielen Anwendungen nutze ich Power over Ethernet (= PoE). Ist doch praktisch: ein Netzwerkabel wird für die Anwendung oft sowieso benötigt, dann kann man es auch gleich nutzen, um das Endgerät mit Strom zu versorgen. Außerdem ist oft keine Steckdose, wo man sie benötigen würde. Ich habe grundsätzlich nur gute Erfahrungen damit gemacht, teilweise entstehen durch die Nutzung von PoE auch neue Möglichkeiten. Es gibt jedoch verschiedene Standards und Varianten – und die müssen zusammenpassen. Hier also eine kleine Übersicht, die meinen Wissensstand und meine Erfahrungen widerspiegeln.
Im Wesentlichen sehe ich zwei große Varianten an PoE:
Passives PoE und
PoE nach 802.3af oder 802.3at (auch aktives PoE genannt, bzw. PoE+ bei 802.3at)
Beachtet, dass diese Varianten nicht miteinander kompatibel sind.
Passives PoE
Bei passivem PoE werden mehrere Adern des 8-poligen-Gigabit-Ethernet-Kabels für die Übertragung von Strom genutzt. Meist werden die Adern 4+5 für + und 7+8 für – genutzt. Hier wird einfach Strom von einem Netzteil (auch Injector genannt) durchgeschickt. Grundsätzlich sollte man hier vorsichtig sein, dass man (a) die richtige PoE-Variante einsetzt, (b) die korrekte Spannung überträgt und (c) das Endgerät das unterstützt. Sonst könnte es passieren, dass eine Netzwerkkarte defekt wird, wenn ihr einfach über diese PINs der Strom geschickt wird.
Es gibt viele gängige Varianten, die sich meist durch die Spannung unterscheiden. Bei Ubiquiti und Mikrotik findet man meist 24V passive PoE, in anderen Anwendungen (zB. Videokameras) kommt oft 12V zum Einsatz. Vereinzelt sieht man 5V, hier habe ich die Erfahrung gemacht, dass bei größeren Kabellängen (bereits so ab 10m) der Spannungsabfall relevant wird, von 5V würde ich also abraten bei passive PoE.
In den meisten Anwendungen sieht man, dass ca. 2,1 bis max. 2,5 Ampere übertragen werden. Je nach Spannung kann man also leicht ausrechnen, wieviel Leistung mit dieser Variante zur Verfügung gestellt werden kann. Bei 24V mit 2,1A sind das bereits gut 50 Watt, bei 12V die Hälfte.
Passives PoE heißt also so, weil es einfach Strom durchschickt, ohne weiterer Überprüfung oder Logik.
PoE & PoE+ nach 802.3af und 802.3at
Man sieht an der Überschrift: diese Variante ist genauer standardisiert. Die IEEE hat im Standard 802.3af und 802.3at genau spezifiziert, wie PoE durch das Netzwerkkabel geschickt wird und viele Hersteller nutzen diesen Standard. Das erhöht natürlich die Kompatibilität und so wird es möglich, einen PoE-fähigen-Switch mit beliebigen Endgeräten zu verbinden.
PoE und PoE+ orientieren sich an 48V (Nominalspannung), tatsächlich sieht der Standard 36V bis 57V vor. Das ist schon vernünftig aufgrund der Robustheit bei längeren Ethernet-Verbindungen.
Meines Wissens nach unterscheiden sich PoE (IEEE 802.3af) und PoE+ (IEEE 802.3at) vor allem aufgrund der maximal vorgesehenen Leistung. Diese wird beim Anschluss des Kabels „detektiert“, dafür gibt es einen ausgeklügelten Mechanismus, der den Widerstand des Engerätes misst und darüber erfährt, welchen Standard und welche Leistungsklasse das Endgerät unterstützt. Tolle Sache, va. ist hier auch abgesichert, dass ein Endgerät ohne PoE-Funktion keinen Schaden nimmt und nicht einfach Spannung durchgeschickt wird, wie bei der passiven Variante.
Grundsätzlich würde ich, wenn möglich, dieser Variante von PoE den Vorzug geben.
Falls euch Details zu den Modi, Spannungen, der Detektion und den Leistungsklassen interessiert, möchte ich auf die Wikipedia-Seite verweisen, da diese sehr ausführlich darüber aufklärt: https://de.wikipedia.org/wiki/Power_over_Ethernet
Anmerken möchte ich noch, dass es auch bei IEEE 802.3af/at eine passive Variante gibt, dort werden die PINs 1+2 für + und 3+6 für – genutzt. Vor allem günstigere Injectoren und Splitter setzen darauf. Bisher habe ich keine Probleme damit gehabt. Splitter nach dem 802.3af/at-Standard haben in allen Kombinationen mit Injectoren & Switches funktioniert.
PoE bei Switches
Es gibt von verschiedenen Herstellern zahlreiche Switches, die PoE unterstützen. Die meisten setzen auch hier auf den 802.3af/at-Standard.
Ich finde es sehr praktisch, dass man von Switches aus direkt die Endgeräte mit Strom versorgen kann. Meistens sind diese Endgeräte WLAN Access Points oder IP Kameras. Ich nutze es aber auch gerne für Raspberry Pi oder Arduinos (und andere IoT-Geräte oder Sensoren).
Ein wesentlicher Vorteil hierbei ist, dass man am Switch (meist per Webinterface) den Port PoE-mäßig resetten kann. Wenn also eine IP Cam nicht mehr reagiert, kann ich bequem einen Restart auslösen. Das ist vor allem praktisch bei weit entfernten Standorten und erhöht die Betriebssicherheit immens. Manche Switches können auch Endgeräte per PING überwachen, und wenn diese ein paar Minuten nicht mehr erreichbar sind, resetten sie PoE am Port automatisch.
Bei einer Sache muss man jedoch achtgeben: PoE Switches haben meist ein „Power Budget“, also eine maximale Leistung (in Watt), die sie auf einzelnen Ports oder insgesamt(!) bedienen können. Es kann also sein, dass auf einem 24-Port-PoE-Switch, der zB. 70 Watt Power Budget unterstützt, nicht auf jedem Port eine Kamera mit PoE versorgt werden kann. Das sollte man sich vorher überlegen und danach den richtigen Switch mit der richtigen Leistung wählen.
PoE Adapter für DIY-Projekte
Ich werde oft gefragt, welche PoE-Injectoren (= führt die Spannung in das Netzwerkkabel und enthält manchmal direkt das Netzteil) ich verwende und wie ich die Endgeräte anschließe, zB. Raspberry PI.
Ich führe hier also ein paar Geräte an, die kostengünstig sind und mit denen ich gute Erfahrungen gemacht habe. Die Teile sind Großteils bei Amazon erhältlich oder – wenn man mehr Zeit für die Lieferung hat – auch bei Aliexpress.
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.
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
An den vielen anderen Beiträgen zum Thema Ubiquiti Unifi könnt ihr erkennen, dass ich diesem System bereits an mehreren Standorten vertraue. Bisher hat sich die Wahl für Unifi für mich bewährt: das System ist einfach zu bedienen, stabil im Betrieb und bietet alle Features, die ich benötige. Vor kurzem (Dezember 2016) sind neue Produkte von Ubiquiti erschienen, die auch im Freien die aktuellen WLAN-Standards kostengünstig bieten.
Das bisherige Dilemma im Outdoor-Bereich
UAP AC Mesh passt dank mitgeliefertem Adapter problemlos in die vorhandene Wandhalterung
Für den Innenbereich habe ich bereits in anderen Beiträgen entsprechende Produkt vorgestellt. Allerdings gab es bisher keine sinnvoll erschwinglichen Outdoor Access Points, die auch 5 GHz mit 802.11ac abdecken. Das war bislang ein großes Manko. Entweder man nimmt den
oder man leistet sich den Unifi AP AC um mehr als € 300,-. Diese bietet zwar 802.11ac, unterstützt allerdings kein DFS, wodurch die Auswahl an Kanälen in Europa auf 4 reduziert ist.
Unifi Mesh
Zum Glück gibt es nun zwei neue Produkte, die diese Lücke schließen:
Beide sind für den Außeneinsatz gerüstet, unterstützen 2,4 GHz und 5 GHz inklusive 802.11ac und DFS. Und das zum erschwinglichen Preis (Stand Jänner 2017: knapp über € 120,- für den Unifi UAP AC Mesh und etwa € 200, für den Unifi UAP AC Mesh Pro).
UAP AC Mesh
Der Unifi UAP AC Mesh hat das Potenzial, mein neues Standardgerät zu werden. Es ist auch für den Innenbereich fesch, bietet alle gängig benötigten Technologien und unterstützt die PoE Varianten „24V Passive PoE“ und „802.3af Alternative A“, wodurch es im Privatbereich günstig eingesetzt, aber auch an bestehende Switches im Firmenbereich angeschlossen werden kann:
ein Gerät für indoor & outdoor
lässt sich mit vielen bestehenden PoE-Switches nutzen, da es zwei Standards für die PoE-Versorgung unterstützt:
802.3af (Alternative A; vmtl. auch an 802.3at nutzbar)
unterstützt beide WLAN Frequenzen: 2,4 GHz und 5 GHz
erfüllt mit 802.11ac und 2×2 MIMO die modernsten WLAN-Standards mit Geschwindigkeiten bis 867 MBit/s. Und ist kompatibel zu 802.11a/b/g/n/ac.
bindet sich in bestehende Unifi-Management-Umgebungen ein und bietet somit zentrale Konfiguration & Monitoring. Optional kann der AP selbstständig mit unabhängiger lokaler Konfiguration betrieben werden.
abnehmbare Antennen. Der APs enthält Montagevorrichtungen, um mit externen Antennen zB. für bestehende Sektor- oder Panelantennen betrieben zu werden.
VLANs und 802.1q. Für mich immer wichtig, mehrere Netze über VLANs zuführen zu können und als separate SSIDs auszusenden (4 SSIDs sind gleichzeitig je Frequenz je AP möglich, die beiden Frequenzen können für unterschiedliche SSID-Konfigurationen genutzt werden)
Außerdem kann der UAP AC Mesh an vorhandene Wandhalterungen oder Antenna mounts (zB. AirMax Antennen oder Unifi Sektor-Antennen) montiert werden (zB. für die Rocket-Serie).
UAP AC Mesh Pro
Was mir zum Unifi UAP AC Mesh Pro als erstes auffällt: er ist erheblich größer! 34,32×18,12 cm ergeben eine ziemlich eindrucksvolle Fläche, für eine Außenmontage auf einem Mast werde ich hier die Windlast speziell berücksichtigen.
Obwohl das Gerät wie eine Panelantenne aussieht, handelt es ich um einen Rundstrahler. Drei Antennen mit 8 dbi Gewinn sind verbaut, wodurch 3×3 MIMO möglich ist und nominal 5 GHz 802.11ac 1.300 MBit/s (1,3 GBit/s!), sowie für 2,4 GHz 450 Mbit/s möglich werden. Natürlich werden die Bandbreiten nur erreicht, wenn auch das Endgerät das Senden und Empfangen über 3 Antennen ermöglicht.
Hinsichtlich PoE wird beim Pro nur 802.3af unterstützt.
Erwähnenswert ist noch, dass der Pro über zwei Gigabit-Ethernet-Ports verfügt, wodurch es möglich ist, weitere Access Points „hinter“ dem Unifi UAP Mesh Pro zu betreiben (Daisy Chain).
Mesh?
Ich finde den Namen „Mesh“ etwas verfänglich: bei Mesh Network denke ich immer an Netztopologien ähnlich zu Funkfeuer. Also zu weit verteilten Netzen, wo WLAN-Systeme oder -Knoten mit mehreren anderen Systemen oder Knoten verbunden sind.
Für die hier beschriebenen Produkte finde ich das nicht ganz passend: Unifi Systeme können zwar über „Wireless Uplink“ einen Access Point über einen anderen AP anbinden. Allerdings kann ein AP, der nur ohne Kabel verbunden ist, das Signal nicht an noch einen weiteren AP weiterreichen. (Update Februar 2017: siehe Kommentar von Harry unten, es ist bei den Mesh-Produkten möglich, auch mehrere Access Points untereinander über Wireless Uplink zu verbinden: https://help.ubnt.com/hc/en-us/articles/115002262328-UniFi-Feature-Guide-Wireless-Uplink).
Unpacking
Ich habe mich bemüht, recht zeitig nach Erscheinen der Produkte zwei Unifi UAP AC Mesh zu bestellen, da ich schon dringend ein paar Außenbereiche mit WLAN versorgen müsste, das aber bisher nur halbherzig gemacht habe, da ja die bisher verfügbaren Produkte nicht zufriedenstellend waren.
Ubiquiti hat scheinbar das Design des Zubehörs angepasst. Neu ist nämlich, dass das Netzteil und das Kabel weiß – wie der AP selbst – sind. Das Netzteil entspricht den Spezifikationen der bisherigen Produkte für 24V Gigabit passive PoE (0,5 A), ich finde abgesehen von Farbe (und der abgerundeten Form) keine technischen Unterschiede. Jedenfalls möchte ich darauf hinweisen, dass – obwohl ältere Netzteile funktionieren – darauf geachtet werden soll, dass Gigabit unterstützt wird. Schließlich ermöglicht der Access Point ja Bandbreiten, bei denen man nicht möchte, dass dann das Netzteil zum Flaschenhals wird.
Ansonst wirkt der Access Point robust, die beiden Antennen sind abschraubbar (RP-SMA-Anschlüsse). Es können also jederzeit externe Antennen angeschlossen werden. UAP AC Mesh können gemeinsam mit AirMax-Antennen oder -Sektor-Antennen genutzt werden, die bisher zB. für die Rocket-Produkte oder Outdoor+/Outdoor5 gedacht waren.
Eine Signal-LED auf der Seite des Access Points zeigt – wie auch bei anderen Unifi-Produkten üblich – den Status des Access Points:
Das Einbinden in den Unifi Controller funktioniert problemlos. Das Gerät wird sofort erkannt, ein Software-Upgrade wird angeboten und man kann es problemlos adoptieren. ich habe das richtige Profil zugewiesen und kurz darauf haben sich schon die ersten Clients verbunden. Fertig.
Das ging wirklich so schnell, dass ich dann noch versucht habe, den Unifi UAP AC Mesh über einen Wireless Uplink einzubinden. Auch hier hat alles klaglos funktioniert.
Die Signalstärken sind einwandfrei: auch mit zwei Wänden und einem Abstand von 25 Metern zum Access Point bekomme ich -65 dB angezeigt.
Fazit
Ich werde wohl vermehrt auf den Unifi UAP AC Mesh setzen, nachdem er universell in Gebäuden wie im Freien eingesetzt werden kann. Der Unifi UAP AC Mesh Pro bietet in Umgebungen mit vielen Clients aufgrund der zusätzlichen Antenne Vorteile, ich habe jedoch kaum Umgebungen, bei denen ich > 30 Geräte je AP versorgen muss.
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:
Ich erstelle beispielsweise jeden Tag in der Früh einen Report über die Geschwindigkeiten auf meinen Funkfeuer-Standorten. Den Report erhalte ich per Email und kann daran die Performance der weit entfernten Standorte erkennen.
Seit kurzem ist speedtest-cli allerdings durch speedtest.py abgelöst worden. Das Tool speedtest.py wurde vom gleichen Developer entwickelt. Es erscheint beim Aufruf von speedtest-cli folgende Meldung:
The file speedtest_cli.py has been deprecated in favor of speedtest.py
In einem früheren Beitrag habe ich bereits beschrieben, warum ich baulich für eine ordentliche WLAN-Versorgung in meiner Wohnung ein ordentliches WLAN-System möchte.
Ich habe mich ja damals für ein Unifi System von Ubiquiti entschieden und das nie bereut. Auch die Migration zur „neuen Generation“ (Wave 2?) von Unifi AC Geräten (AC = sie unterstützen den aktuellen WLAN-Standard 802.11ac) hat problemlos funktioniert.
Nachtrag Jänner 2017: mittlerweile sind auch 802.11ac-fähgie Geräte im leistbaren Segment für Außeninstallationen erschienen, die ich in einem separaten Artikel vorstelle. Diese Geräte eigenen sich auch gut für den Innenbereich.
Hier möchte ich einen die Vor- & Nachteile der einzelnen Produkte diskutieren und meine Erfahrung im Einsatz beitragen.
Der AC Lite unterstützt beide Frequenzbänder (2,4 GHz und 5 GHz), natürlich den neuen 802.11ac-Standard (ist aber auch kompatibel zu älteren WLAN-Standards 802.11a/b/g/n/ac), liefert mit 2×2 MIMO im 5 GHz-Band bis zu 867 MBit/s zu den Clients und ist dank 24 V passive PoE mit meinem bestehenden System kompatibel. Im 2,4 GHz Band schafft er 300 MBit/s (802.11n).
Das Gerät ist preisgünstig und kann einerseits als eigenständiges Gerät betrieben werden (Konfiguration über Android App) oder wird in das Unifi-System integriert: damit wird der AP von einem Unifi Controller (zB. Ubiquiti Cloud Key, läuft aber auch zB. auf einem Raspberry oder über eine App im Synology NAS) zentral konfiguriert und gemonitored. Das Anlegen oder Ändern einer SSID in einer Umgebung mit vielen Access Points ist somit sehr bequem zu bewerkstelligen. Je AP und Frequenz werden übrigens 4 SSIDs unterstützt.
Dieser Access Point hat für mich das beste Preis-/Leistungsverhältnis. Er erfüllt alle meine Anforderungen. Ich habe damit auch bereits mehr als 30 WLAN-Geräte gleichzeitig erfolgreich bedient und bisher keine Kapazitätsgrenzen kennengelernt.
Auch beim Roaming mit anderen Unifi AC APs gibt es keine Probleme. Ich verwende dazu kein ZH (Zero Handoff, dabei unterstützen die Access Points den Roaming-Vorgang) und es geht trotzdem wunderbar. Ohne ZH kann jeder AP eine anderen Funkkanal nutzen und stört bzw. überlappt nicht mit den anderen APs.
Unifi UAP AC Pro
Der AC Pro Access Point ist dem LITE sehr ähnlich, unterstützt jedoch 3×3 MIMO, wodurch er 1.300 MBit/s (1,3 GBit/s!) zu den Endgeräten verspricht und wird durch PoE (802.3af oder 802.3at) versorgt. Eine Versorgung durch 24 V PoE ist nicht möglich.
Hinsichtlich Management unterstützt der AP Pro alle oben genannten Methoden.
Unifi UAP AC LR
Die Long Range-Version beinhaltet eine Antenne mit höherem Gewinn. Das ist ermöglicht in vielen Ländern eine höhere Reichweite beim Senden. Da in Österreich (und wie ich glaube in der ganzen EU) die Sendeleistung nach EIRP beschränkt ist, darf der AC LR bei korrekter Ländereinstellung bei uns nicht mit voller Leistung senden.
Die „bessere“ Antenne wirkt aber auch empfangsseitig. Und das ist aus meiner Sicht die große Stärke dieses Modells. In schwierigen Umgebungen (zB. Gebäuden mit dicken Mauern) habe ich damit erheblich bessere Ergebnisse erzielt (Bandbreite und Stabilität). Ich bin teilweise ganz erstaunt gewesen, wie zuverlässig der AP LR über große Entfernungen in Gebäuden noch problemlos funktioniert hat.
Meine Erfahrungen mit diesen Geräten sind jeweils top. Sie funktionieren zuverlässig, haben höchste Kompatibilität (es hat nie Probleme gegeben, dass sich jemand nicht verbinden konnte) und das Management über den Unifi Controller, den ich unter Ubuntu Linux laufen habe, funktioniert super!
Näheres zu meiner Konfiguration mit dem Unifi Controller habe ich in einem älteren Beitrag beschrieben. Die Produkte dort sind mittlerweile veraltert, aber die Funktionen des Controllers sind weiterhin gültig.
Ich betreibe mit den Access Points einen Funkfeuer-Hotspot und sehe eigentlich jeden Tag einzelne User, die den Dienst nutzen. Für den Hotspot wird auch eine Landing Page vorgeschaltet und dann ein Redirect auf www.funkfeuer.at erzwungen. Alles funktioniert seit Monaten einwandfrei. (Das System schon über einem Jahr, aber die UAP ACs habe ich erst ein halbes Jahr damit im Einsatz).
Ich betreibe mehrere Standorte, die im Wiener Funkfeuer-Netz verteilt sind. Mich interessiert die Performance (vor allem die Bandbreite vom bzw. zum Internet), die ja abhängig von Tages- oder Jahreszeit schwanken kann.
Update Dezember 2016: das Tool speedtest-cli ist durch speedtest.py, das vom gleichen Entwickler geschrieben wurde und die gleichen Möglichkeiten bietet, abgelöst worden. Die Installation ist daher abweichend. Ich habe die neue Vorgehensweise in einem neuen Beitrag erklärt. Die hier beschriebenen Optionen und Möglichkeit haben jedoch weiterhin Gültigkeit.
Bisherwar ich recht erfolgreich mit Bandbreite iPerf. Dazu benötige ich aber zwei Geräte, zwischen denen dann die Bandbreite gemessen wird – das ist die richtige Methode, wenn man zB. eine Funk-Verbindung zwischen zwei Geräten messen möchte. Aber wenn ich die Internet-Performance messen möchte, muss ich zwei Geräte bedienen. Die Ergebnisse sind dafür belastbar, sind nachvollziehbar/plausibel und spiegeln die erlebte Performance wider.
Heute haben mir Freunde ein Messergebnis geschickt, das eindeutig über die CLI gemessen wurde. Dabei ist mir die Idee gekommen, auch meine EdgeRouter (und EdgePoints, also die Outdoor-Variante) damit auszurüsten und in Zukunft selbst gemütlich über die CLI testen zu können. Also hab‘ ich mir das gleich angesehen:
Man benötigt nur das .py-Script, das recht einfach am EdgeRouter heruntergeladen werden kann. Damit es auch nach einem Update des Routers verfügbar bleibt, speichere ich es in /config/user-data:
(Weil wget im Standard-Image nicht installiert ist, verwende ich curl -o. Weil unzip nicht verfügbar ist, lade ich das .py-Script vom letzten master-Branch raw von github).
Danach markiere ich das Script als ausführbar:
chmod u+x /config/user-data/speedtest_cli.py
Und schon kann’s losgehen, ich starte einen Speedtest mittels:
/config/user-data/speedtest_cli.py
Das Ergebnis überzeugt mich:
Optionen
Es gibt noch ein paar erwähnenswerte Optionen zu dem Tool. Vor allem –simple könnte zB. für Scripts interessant sein:
–simple zeigt nur den Output an: Ping/RTT, Download- & Uploadraten.
/config/user-data/speedtest_cli.py --simple
ergibt:
Ping: 26.968 ms
Download: 38.36 Mbit/s
Upload: 27.19 Mbit/s
–share liefert eine URL zurück, bei der das Ergebnis grafisch dargestellt wird:
–server SERVER-ID nutzt den Zielserver mit der entsprechenden ID. Diese kann man in der Liste aller verfügbaren Server finden, welche mittels –list abgerufen wird
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.
