Archiv der Kategorie: Hausautomatisierung

APRS, HAMnet, Hausautomatisierung, LoRa, Raspberry Pi, SDR

günstiger Raspberry Pi PoE HAT für 802.3af – Erfahrungen

3 Kommentare

In meinen Projekten betreibe ich viele Raspberries, die über PoE mit Strom versorgt werden. (Für eine Erklärung zu PoE siehe hier).

Ich nutze viele PoE Converter, um die nominal 48V von PoE bzw. PoE+ gemäß 802.3af / 802.3at auf 5V zu übersetzen und über Micro-USB dem Raspberry bereitzustellen. (Bei Raspi 4B ab jetzt natürlich häufiger mit USB-C).

Die neueren Raspberry-Modelle (3B+ und 4B) unterstützen ein offizielles Raspberry PoE HAT Modul. Dazu wurden 4 weitere PINs auf dem PCB des Raspberry Pi gesetzt und vom PoE HAT genutzt:

mitte/rechts: die 4 PINs für PoE

günstiges PoE HAT

Ich betrachte in diesem Blog nicht das offizielle PoE HAT, sondern eine günstige Alternative ohne Lüfter:

die günstige Alternative zum offiziellen PoE HAT

Im Gegensatz zum offiziellen PoE HAT gibt es hier zwar keine vorgesehene Position für einen Lüfter, allerdings sind die GPIO PINs verlängert bzw. werden durch das günstige PoE HAT durchgereicht. Ich kann also weitere HAT Aufsteckmodule nutzen.

Gekauft habe ich das Modul bei Aliexpress, es ist auch zB. über Amazon erhältlich:

Aufbau und Test

Ich habe es auf einen Raspberry 3B+ gesteckt und an ein Kabel, das von einem Ubiquiti EdgeSwitch 8 150W mit PoE+ versorgt wird.

Mein Ziel ist, einen LoRaWAN Gateway zu testen, der über PoE versorgt wird und LoRaWAN über ein IMST ic880a Board abwickelt. Um das ic880a Board am Raspberry GPIO zu betreiben ist ein Adapterboard nötig, das ich vom Verein OpenIoT erhalten habe.

Raspberry mit bereits aufgestecktem PoE HAT, OpenIoT Adapterboard und IMST ic880a (oben)

In Kombination sieht das „Sandwich“ dann so aus:

Die Module sind halbwegs stabil, ein gutes Gehäuse sollte dennoch her. Es sind leider keine Bohrungen für Distanzhalter vorgesehen.

Ich habe das Board mit einem Ubiquiti EdgeSwitch getestet, der EdgeSwitch unterstützt den PoE+-Standard und gibt mir auch die aktuelle Leistung je Port an:
im Leerlauf zieht ein Raspberry 3 B+ mit Raspbian Lite (Buster) nach einer frischen Installation etwa angezeigt 3,6 Watt.

Wenn ich das LoRaWAN Concentrator Board aufsetze und neu starte, wechselt die Anzeige zwischen 6,1 und 6,5 Watt:

PoE Verbrauch mit IMST ic880a LoRaWAN concentrator board in Betrieb

Auch auf einem Raspberry 4B hat sich das günstige PoE HAT problemlos betreiben lassen.

Temperatur

Bemerkenswert ist, dass das Gerät sehr heiß wird, wenn das IMST Board, das ja die Leistungsaufnahme ggü. dem Raspberry verdoppelt, angeschlossen wird. Die Angabe auf dem PoE HAT sind 2,5A – also 12 Watt. Wir nutzen hier zirka die Hälfte und es geht schon heiß her. Die Core Temperatur zeigt etwa 60 Grad bei Nutzung mit dem IMST Board. Dabei ist natürlich auch der Prozessor unter mehreren Aufsteckmodulen versteckt und hat wenig Luftzirkulation. Ohne LoRaWAN-HATs hat es etwa 53 Grad im Bereich der CPU.

Die Werte frage ich über vcgencmd ab:

stefan@lorawangw:~ $ vcgencmd measure_temp
temp=59.6'C

Fazit

Einen Langzeittest habe ich noch nicht gemacht, ich werde den Artikel hier dann aber mit den Erkenntnissen erweitern.

Das Modul funktioniert sehr gut, erspart mir in Zukunft hoffentlich einen weiteren externen Adapter, um PoE über MikroUSB oder USB-C dem Raspi zu geben.

Beobachten möchte ich die Temperatur, weil als Nebenwirkung des Boards der Raspi auffällig heiß wird.

Links zu den Modulen

Hier eine Übersicht der im Beitrag vorgestellten Artikel/Produkte:

Arduino, Funkfeuer, Hausautomatisierung, Raspberry Pi, Unifi

Übersicht über Power over Ethernet (PoE)

9 Kommentare

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.

PoE Injector & Splitter

zB. bei Amazon:


Allgemein, App, Code, fhem, Hausautomatisierung, Linux, Smartphone, WLAN

IoT und Hausautomatisierung mit Sonoff

2 Kommentare

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

Amateurfunk, Code, Hausautomatisierung, Linux, LoRa, Raspberry Pi, Unterwegs

LoRa Single Channel Gateway

19 Kommentare

Mit Freunden baue ich einen Multi-Channel-Gateway, der auf sämtlichen LoRa-Kanälen empfangen und senden kann – und das mit allen SF (Spreading Factors). So ein Gateway kostet knapp 400 Euro in Summe – das ist mir zum Spielen für zu Hause zu teuer.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Single Channel Gateway = günstig

Die günstige Variante, die streng genommen nicht LoRaWAN-kompatibel ist, weil sie nur eine Frequenz und einen Spreading Factor unterstützt, ist ein Single Channel Gateway. Dieses hört auf einen vordefinierten (aber konfigurierbaren) Kanal mit einem vordefinierten Spreading Factor (auch konfigurierbar) und sendet die Daten an The Things Network.

Als Basis nehme ich einen Raspberry Pi 2, der aktuell eh auf eine Aufgabe wartet. Das LoRa & GPS HAT von Dragino nutze ich für die LoRa-Übertragungen. Das HAT habe ich um € 29,- bei Tindie erstanden. In Summe bin ich bei Kosten von weniger als € 65,-.

Einsatzgebiet

Wie beschrieben ist ein Single Channel Gateway kein vollständig LoRaWAN-kompatibler Gateway. Er hört nur auf eine Frequenz (Kanal) und versteht nur einen SF. Nachdem meine Sensoren abwechselnd auf drei Frequenzen senden, stelle ich den Single Channel Gateway auf eine Frequenz ein – und ich stelle mich darauf ein, nur jedes dritte Paket zu empfangen. (Da bei LoRa ja ein Counter mitläuft, kann ich das leicht nachprüfen.)

Falls ich einmal einen Sensor permanent installieren möchte, würde ich ihn fix auf die eine Frequenz stellen, die der Gateway (oder mehrere?) auch nutzt. Damit wäre ein kleines LoRa-Netzwerk möglich, das aber nur auf einer Frequenz funktioniert.

Installation

Es ist ganz einfach:

  1. aktuelle Raspian-Version installieren und Raspberry vorbereiten (resize disk, SSH-Zugriff für Fernzugriff aktivieren, Passwort und IP-Einstellungen ändern)
  2. alles aktualisieren und wiring-pi installieren:
apt-get update && apt-get dist-upgrade
apt-get install wiringpi

3. in raspi-config das SPI Interface aktivieren & rebooten

4. die Single Channel Gateway Software von Github laden und installieren:

wget https://github.com/tftelkamp/single_chan_pkt_fwd/archive/master.zip
unzip master.zip

und ein paar Parameter in der main.cpp konfigurieren:

// SX1272 - Raspberry connections
int ssPin = 6;
int dio0  = 7;
int RST   = 0;

// Set spreading factor (SF7 - SF12)
sf_t sf = SF7;

// Set center frequency
uint32_t  freq = 868100000; // in Mhz! (868.1)

// Set location
float lat=48.0;
float lon=16.0;
int   alt=200;

/* Informal status fields */
static char platform[24] = "Single Channel Gateway"; /* platform definition */
static char email[40] = "meine@email.at"; /* used for contact email */
static char description[64] = "Dragino LoRa GPS HAT Raspberry 2"; /* used for free form description */

// define servers
#define SERVER1 "52.169.76.203" // The Things Network: router.eu.thethings.network #define PORT 1700 // The port on which to send data

Danach mit „make“ builden:

make

Und schon kann ich den Gateway starten:

./single_chan_pkt_fwd

Einrichten bei The Things Network

Nun erstelle ich den Gateway in der TTN Console:

  • Register Gateway
  • dann wähle ich „I’m using the legacy packet forwarder“. Somit kann ich die Gateway EUI eingeben, die mir beim Start meines Single Channel Gateways angezeigt wurde.
  • die Description kann frei gewählt werden
  • der Frequency Plan ist Europe in meinem Fall und der
  • Router EU. Das ist auch die IP-Adresse, die wir oben in der main.cpp definiert haben. (Details siehe hier: https://www.thethingsnetwork.org/wiki/Backend/Connect/Gateway)
  • mehr muss man nicht tun (natürlich ist es schön, die GPS-Position und Höhe einzugeben)

Das war’s! Bei „Data“ kann ich zusehen, wie die Daten ankommen, und binnen kurzer Zeit bestätigt sich die Vermutung, dass ich jeden dritten Counter sehen werde:

Stückliste zum Nachbauen

  1. Raspberry Pi (2 oder 3)
  2. Dragino LoRa GPS HAT, alternativ hier beim Hersteller mit längerer Lieferzeit zu erstehen: https://www.tindie.com/products/edwin/loragps-hat/
  3. ev. eine coole Antenne? (nicht unbedingt nötig, es ist eine beim LoRA GPS HAT dabei)
Amateurfunk, Dipol, Hausautomatisierung, LoRa

Empfehlung für eine LoRa Outdoor Antenne

8 Kommentare

Bei meinen Experimenten rund um das Thema LoRa haben wir natürlich mehrere Antennen probiert: die mitgelieferten Antennen sind total in Ordnung, auch die Magnetfußantennen für’s Auto haben sich bewährt, aber die größte Begeisterung habe ich für eine Außenantenne von WiMo entwickelt:

Die WiMo 18006.02 Groundplane für 800-1000 MHz um € 25,- hat es mir angetan.

Sämtliche Pakete kommen damit bis zum ca. 1km entfernten Gateway. Vorher waren es nur ca. 30%. Die Verbesserung ist damit ideal! Nach Herstellerangaben hat die Antenne 0 dBD (dBi?) Gewinn.

Ich habe sie über ein 1m Low Loss H-155 Kabel an eine Fensterdurchführung für GSM gehängt. Das 1m-Kabel hat SMA (für die Fensterdurchführung) und N-Stecker für die Antenne direkt drauf.

Am Foto ist sie mit einer Doppelkreuzschelle befestigt, so wie die Montage am Mast vorgesehen ist.

Stückliste zum Nachbestellen:

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Code, Hausautomatisierung, Linux, Raspberry Pi

Ubuntu Linux per SNMP in LibreNMS einbinden

Ein Kommentar

Neuerdings bin ich ein Fan von LibreNMS, einem Network Management System bzw. einer Open-Source-Lösung für System Management.

Installation von LibreNMS

Installiert habe ich LibreNMS nach dieser Anleitung von Oliver Marshall, das hat auf Anhieb super geklappt: http://olivermarshall.net/how-to-install-librenms-on-ubuntu/

Nach der Installation habe ich vor allem Router, Switches und sonstiges Netzwerkequipment eingebunden, das hat super funktioniert. SNMP ist dort meist recht einfach konfigurierbar, ältere Geräte haben nur SNMPv1 akzeptiert, bei neueren klappt’s dann auch mit SNMPv2c und SNMPv3.

Nun möchte ich Linux Server, meist Ubuntu und meist Virtuelle Maschinen, einbinden.

Aktiviere SNMP am Ubuntu Server

Die Server müssen natürlich vom LibreNMS erreichbar sein. SNMPd, also der Daemon (= Dienst), der SNMP-Verbindungen entgegennimmt und beantwortet ist standardmäßig nicht installiert.

Mittels

apt-get update
apt-get install snmpd

ist das schnell erledigt.

Nun antwortet der SNMP-Server jedoch nur auf lokale Anfragen (vom eigenen Host (localhost) bzw. der IP-Adresse 127.0.0.1). Außerdem muss man eine SNMP-Community wählen. Eine SNMP-Community entspricht im weiteren Sinne einem Passwort. Standardmäßig ist meist „public“ für lesenden Zugriff (Read-Only) und „private“ für Schreibzugriff (Read+Write) konfiguriert. Diese Werte müssen unbedingt geändert werden.

Konfiguration SNMPd

Um snmpd zu konfigurieren, öffne ich die Datei /etc/snmp/snmpd.conf:

und ändere folgende Zeilen:

agentAddress  udp:161
rocommunity MeineGeheimeCommunity default -V systemonly
rocommunity6 MeineGeheimeCommunity default -V systemonly

Mit den oben getätigten Einstellungen nimmt der SNMPd nun Verbindungen von allen IPv4-Adressen an, wenn diese über die Community „MeineGeheimeCommunity“ anfragen.

Damit auch die Location und der Kontakt korrekt über SNMP mitgeteilt werden, passe ich diese in der gleichen Konfigurationsdatei an:

sysLocation    mein_Standort
sysContact     meine@email.adresse

Einbindung in LibreNMS

Nun kann ich über das Menü „Devices“ und „Add Device“ den Linux Server einbinden:

Kurz darauf erscheint der Server in der Liste und LibreNMS sammelt Daten. Nach einigen Stunden hat man dann bereits aussagekräftige Grafiken.

Firewall

Nachdem wir hier den SNMPd so installiert haben, dass dieser allen IP-Adressen (auch aus dem Internet) antworten würde und der einzige Schutz die Community ist, empfehle ich eine lokale Firewall zu installieren, die den Port 161 für UDP schützt und nur vom LibreNMS-Server zulässt.

Eine Anleitung dazu findet ihr hier: http://awesomism.co.uk/allow-snmp-using-ufw-on-ubuntu-server-12-04/

Allgemein, Amateurfunk, Code, Funkfeuer, Hausautomatisierung, Linux, Raspberry Pi, WLAN

APC USV mit Raspberry überwacht

13 Kommentare

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>

 

Allgemein, Edimax2101W, fhem, Linux

HP MicroServer Gen8 Stromverbrauch

2 Kommentare

Zum Herumprobieren und für ein paar Anwendungen zu Hause (Interface zur Hausautomatisierung, ua.) habe ich einen neuen kleinen Server gesucht. Meine wesentlichen Anforderungen sind:

  • Unterstützung von Virtualisierung (VMWare ESXi, XenServer oder Hyper-V)
  • geringer Stromverbrauch
  • einfach zu managen
  • vernünftiger Preis

hpmicroservergen8Mit diesen Anforderungen wurde mir von einem Freund der HP MicroServer Gen8 empfohlen. Das Gerät kostet aktuel zirka 210,- Euro und ist ein „echter“ kleiner Server. ILO 4 (https://de.wikipedia.org/wiki/Integrated_Lights-Out) inklusive.

Wunderbare Sache! Ich habe den Server bestellt und noch um folgende Module erweitert:

  • ILO 4 Advanced Lizenz um € 18,12. (hier gekauft)
  • Kingston KVR1333D3E9S/8G Arbeitsspeicher 8GB (DDR3 ECC CL9 DIMM, 240-pin), um € 68,03 (hier gekauft)
  • MicroSD-Karte als Storage für die Virtualisierungsplattform (war vorhanden)

In Summe bin ich unter 300 Euro geblieben. Damit habe ich mein Ziel vorerst erreicht:

Der HP MicroServer wurde bei mir mit 2 GB RAM geliefert, durch das Upgrade habe ich nun 10 GB zur Verfügung. (Im Link oben verweise ich auf das neuere Modell, das bei etwa dem gleichen Preis mit 4 GB ausgeliefert wird.) In Zukunft kann ich das 2 GB Modul gegen ein weiteres 8 GB Modul tauschen und hätte dann 16 GB zur Verfügung. Das ist auch das Maximum, das der HP MicroServer Gen8 unterstützt.

Das Installieren des Betriebssystems (in meinem Fall habe ich zu Beginn Citrix XenServer probiert) funktioniert über ILO Advanced mit der Remote Console ohne Probleme und auch ohne Datenträger. Das ISO Image muss nur in der Remote Console gemountet werden und die Installation erfolgt superschnell über das Netzwerk.

In diesem Setup möchte ich nun den Stromverbrauch überprüfen. Das mache ich mit meinen bewährten Edimax2101W (hier gekauft).

Das Ergebnis:

  1. beim Starten: 45 Watt
    gen8watt01
  2. unter Last (beim Booten): 31 Watt
    gen8watt02
  3. und im Leerlauf: 27 Watt
    gen8watt03
  4. ausgeschaltet zieht die ILO-Funktion übrigens 5,5 Watt.
fhem, Hausautomatisierung, Linux, Unifi, WLAN

Unifi Controller in fhem einbinden

Schreibe einen Kommentar

Ich habe bereits über meine Unifi-Installation geschrieben, die sich weiterhin bewährt.

Mit großer Freude habe ich gelesen, dass seit 23. August 2015 auch ein Unifi-Modul für fhem verfügbar ist! (Das Changelog sagt: „added: 74_Unifi.pm for the Ubiquiti Networks (UBNT) – Unifi Controller“)

Das muss ich gleich probieren! Einen Unifi-Controller habe ich laufen, jetzt möchte ich diesen mit fhem verbinden und anhand der Clients im WLAN die Anwesenheitserkennung von fhem nutzen.

Mittlerweile habe ich den Unifi Controller in Version 4.6.6 bei mir laufen. Von Version 3 zu Version 4 hat sich einiges geändert, auch in der Unifi API. Es ist daher verständlich, dass man die Versionnummer angeben muss. Gleichzeitig ist es toll, dass das fhem-Modul sowohl Version 3 als auch Version 4 unterstützt.

Ich habe für den Unifi-Zugriff aus fhem einen eigenen User „fhem“ mit „Read Only“-Berechtigung im Unifi Controller angelegt.

Der Zugriff von fhem war mit einer Zeile erledigt:

define myunifi Unifi 192.168.1.9 443 fhem geheim 30 default 4

Der Syntax lautet gemäß Perl Modul:

define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID> [<version>]]]

In der Commandref stehen auch die Details zur Nutzung des Moduls.

Die Standardwerte dafür sind:

  • interval = 30 Sekunden
  • siteID = default
  • version = 4

Ich habe dennoch alles explizit angegeben. Damit hoffe ich, dass in zukünftigen Versionen keine Problem auftauchen (zB. sobald es Version 5 gibt, etc.).

fhemunifi-siteidZuerst habe ich den angezeigten Namen vom Unifi-Controller meiner Site als siteID anzugeben. Damit habe ich  keine Werte bekommen. Nach kurzer Suche habe ich die Fehlermeldung im Log gefunden:

myunifi (Unifi_GetClients_Receive) - Failed! - state:'error' - msg:'api.err.NoSiteContext' - This error indicates that the <siteID> in your definition is wrong. Try to modify your definition with <sideID> = default.

Folgender Hinweis hilft: in der URL des Controller sieht man, mit welcher siteID man verbunden ist, auch wenn diese einen anderen Namen trägt, der im Controller angezeigt wird:

Es hat dann sofort funktioniert: im „Unsorted“-Bereich habe ich nun das Objekt myunifi und alle verbundenen Endgeräte:fhemunifi1Die Daten, die fhem vom Unifi Controller bezieht sind umfangreich und ermöglichen viele Anwendungen, auch außerhalb der Presence-Funktion. Hier die Details zu einem Client:unifi2

====================================== 
_id = 558XXXXXXXXXXXXXb85ae047 
_is_guest_by_uap = false 
_last_seen_by_uap = 1441082804 
_uptime_by_uap = 33149 
ap_mac = 24:a4:XX:XX:XX:c3 
assoc_time = 1441043174 
authorized = true 
bssid = 2e:a4:XX:XX:XX:c3 
bytes-r = 3 
ccq = 991 
channel = 7 
essid = MeineSSID 
first_seen = 1435052270 
hostname = android-bfeXXXXXXXXX9f0f 
idletime = 24 
ip = 192.168.XXX.103 
is_guest = false 
is_wired = false 
last_seen = 1441082804 
latest_assoc_time = 1441049655 
mac = 60:af:XX:XX:XX:e5 
name = Stefan Samsung XXXX
noise = -94 
note = 
noted = false 
oui = SamsungE 
powersave_enabled = true 
qos_policy_applied = true 
radio = ng 
radio_proto = ng 
roam_count = 2 
rssi = 40 
rx_bytes = 1339759 
rx_bytes-r = 3 
rx_packets = 6309 
rx_rate = 6000 
signal = -54 
site_id = 53ecXXXXXXXXXXXXXXX91e2a 
tx_bytes = 1905377 
tx_bytes-r = 0 
tx_packets = 5576 
tx_power = 30 
tx_rate = 72222 
uptime = 39630 
user_id = 55892XXXXXXXXXXXXX5ae047 
usergroup_id = 
======================================

neue & weitere Funktionen

Das Modul für Unifi ist neu im fhem. Es wird laufend weiterentwickelt, so wurde letzte Nacht wieder um Funktionen erweitert, zB:

  • einen Client disconnecten,
  • einen Access Point restarten
  • die „Locate“-Funktion eines APs ein- & ausschalten (blinken)
  • Alarme am Controller archivieren

Am besten behält man das fhem Changelog im Auge. Dort werden Änderungen & Erweiterungen protokolliert.

Allgemein, Edimax2101W, fhem, Hausautomatisierung

Der Stromverbrauch meiner Kaffeemaschine

Schreibe einen Kommentar

edimax2101wJetzt kann ich dank fhem und des Edimax 2101W den Stromverbrauch meiner Haushaltsgeräte messen. Und begonnen habe ich, wie ihr wisst, mit der Nespresso Kaffemaschine:

edimax-fhem-kaffeemaschinenverbrauch

Die obere Grafik zeigt jeweils den Monatsverbrauch in kWh. Die untere Grafik zeigt den jeweils aktuellen Stromverbrauch in Watt. Die Granularität ist 30 Sekunden.

Hier eine detailliertere Ansicht (gezoomt):

edimax-nespresso-detailverbrauch

Was können wir aus diesen zwei Grafiken ableiten:

  • das Aufheizen der Maschine benötigt weniger als 1 Minute und „zieht“ 1100-1200 Watt
  • für das Halten der Temperatur benötigt die Maschine immer wieder bis zu 400 Watt
  • wenn ich mir einen Kaffee mache, zeigt der Edimax 2101W kurz 45 Watt an, ich vermute hier die Pumpe, etc

Daraus ergibt sich in kWh:

  • für’s Aufheizen verbraucht die Maschine etwa 0,003-0,005 kWh (= 3-5 Wh)
  • inkl. Aufheizen und einer Stunde Betrieb verbraucht die Maschine zirka 0,016 kWh (16 Wh)
  • für jede weitere Stunde verbraucht die Maschine 0,0091 kWh (= 9,1 Wh