GPS am Dragino LoRA HAT

Mit dem Dragino LoRa GPS HAT auf meinem Raspberry Pi 2 betreibe ich einen Single Channel Gateway, wie in meinem anderen Beitrag beschrieben.

Nun möchte ich auch die GPS-Funktion ausprobieren! Vielleicht kann ich es zur Zeitsynchronisierung nutzen? Naja, vielleicht im Vergleich zu NTP für meine Anforderungen etwas viel Aufwand. Aber schauen wir mal…

Als Antenne verwende ich eine Magnetantenne (für zB. Autos) mit 3m Kabel.

Die serielle Schnittstelle ist am Raspberry mit der Console belegt und muss erst freigegeben werden, bevor wir GPS-Daten empfangen können:

In der Datei /boot/cmdline.txt entfernen wir den Eintrag für

console=/dev/ttyAMA0

Danach beenden und deaktivieren wir das Service für die serielle Ausgabe:

# systemctl stop serial-getty@ttyAMA0.service
# systemctl disable serial-getty@ttyAMA0.service

Nun installieren wir gpsd & Co:

# apt-get install gpsd gpsd-clients python-gps

Folgende Zeilen bleiben in meiner /etc/default/gpsd als Konfiguration:

START_DAEMON="true"
USBAUTO="true"
DEVICES=""
GPSD_OPTIONS="/dev/ttyAMA0"
GPSD_SOCKET="/var/run/gpsd.sock"

Nach einem Reboot kann ich cgps aufrufen:

An diesen Anleitungen habe ich mich orientiert:
für Raspberry Pi 2
für Raspberry Pi 3 funktioniert es ein bißerl anders.

LoRa Single Channel Gateway

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.

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)

Empfehlung für eine LoRa Outdoor Antenne

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:

LoRa Reichweite mit TTNmapper abschätzen

Nachdem wir jetzt auch einen Gateway fertig haben (ich werde in einem eigenen Beitrag berichten) und mehrere Sensoren funktionieren, wäre es doch mal interessant, die Reichweite der Signale kennenzulernen.

Grundsätzlich senden meine Sensoren bisher nur Messdaten, im Moment aber noch eher statische kurze Textmitteilungen. Was mir fehlt sind die GPS-Positionsdaten, damit ich feststellen kann, von welcher Position mit welcher Signalstärke Pakete empfangen wurden (RSSI).

Bevor ich mich damit beschäftige, mit dem LoRa/GPS Shield auch die GPS-Daten mitzusenden, möchte ich mit ttnmapper.org mal die GPS-Daten dazuschummeln. TTNmapper hat einen super Ansatz dafür gewählt: in der Annahme, dass ich mein Smartphone (Android) und meinen Sensor bei mir habe (mit mir herumtrage oder in meinem Fall beides mit dem selben Auto unterwegs ist), ergänzt TTNmapper mit einer eigenen App einfach die GPS-Position vom Smartphone. Clever!

Funktionsweise

Klarerweise muss ich auf meinem Android Smartphone die App aus dem Play Store installieren. Danach melde ich mich in der App mit meinen Login-Daten bei The Things Network an und wähle aus meinen Applikationen und Devices den Sensor aus, mit dem ich aktuell messen möchte. (Falls jemand seine Logindaten nicht bekanntgeben möchte, kann man auch direkt die Zugangsdaten für den MQTT-Zugang des Device eingeben, das ist natürlich viel umständlicher, aber man muss die Zugangsdaten nicht eingeben).

Ab sofort höre ich jedesmal, wenn ein Paket angekommen ist (die App erfährt das über MQTT wirklich sofort) einen Ton.

Also habe ich eine kleine Magnetfußantenne für 868 MHz neben meine APRS-Antenne auf’s Auto montiert und die App bei meiner heutigen Ausfahrt mitlaufen lassen. Die Stromversorgung über 12V Anschluss auf einen Verteiler mit USB-Hub war zum Glück für Amateurfunkzwecke schon vorhanden und musste ich nur mehr dazustecken.

Es hat super funktioniert! Beim Starten des Motors ist sofort das erste Klingeln am Smartphone hörbar gewesen.

Nach einer kurzen Ausfahrt hat sich folgendes Bild ergeben:

An die Farbgebung muss man sich noch gewöhnen, zum Glück ist eine Legende dabei. Die besten Signalstärken sind rot, die schlechtesten grün und türkis/blau.

Erfreulicher Weise hat mich auch der Gateway von Peter im 2. Bezirk ein paar Mal empfangen.

Zum Vergleich: links die heutige Route über APRS protokolliert und rechts die Punkte, an denen LoRa-Pakete angekommen sind:

LoRa TTN Gateway Pakete mit tcpdump mitprotokollieren

Über die Schnittstellen bei TTN (The Things Network) kann man eine Menge Daten auslesen – natürlich die Inhalte (Payload) der Applikationen und einige technische Werte.

Konkret interessiert mich zB. der RSSI (Eingangssignalstärke) der vom LoRa Gateway empfangenen Pakete. Im Webinterface kann man in der TTN Console im Bereich Gateway mitschauen und erhält hübsche JSON-Objekte, in denen alles enthalten ist. Ich habe aber keine Schnittstelle gefunden, mit der ich es auslesen kann – weder live noch nachträglich (als gespeicherte Werte).

Nachdem ich mir das Protokoll schon angeschaut habe, war mir klar, dass es die Daten unverschlüsselt überträgt. Es nutzt übrigens UDP für die Kommunikation zu den TTN Network Servern auf Port 1700.

Also habe ich meiner /etc/rc.local (vor dem „exit 0“!) folgenden Eintrag hinzugefügt:

/usr/sbin/tcpdump -Aq port 1700 >> /var/log/ttn-tcpdump-gateway.asc &

Damit wird nach jedem Reboot in die Datei /var/log/ttn-tcpdump-gateway.asc per tcpdump in ASCII die Inhalte aller Verbindungen zu Port 1700 gespeichert:

Mich interessieren eigentlich nur Übertragungen und Statusmeldungen. In beiden kommt „rx“ vor:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx

Die Meldungen beginnen immer mit 41 Zeichen (Byte) Header, die kann man wegschneiden:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx | cut -c 41-

Wenn nach „rxpk“, der Meldung für ein empfangenes Paket suche, erhalte ich nur Meldungen, die der Gateway über LoRa empfangen hat:

cat /var/log/ttn-tcpdump-gateway.asc | grep rxpk | cut -c 41-

Hier hat man nun je Zeile ein JSON-Objekt mit sämtlichen Details zur Kommunikation:

{"rxpk":[{"tmst":4242060820,"time":"2017-04-15T14:55:05.977557Z","chan":1,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":-10.5,"rssi":-115,"size":24,"data":"QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"}]}

wird zB. mit http://jsonviewer.stack.hu/ zu

{
  "rxpk": [
    {
      "tmst": 4242060820,
      "time": "2017-04-15T14:55:05.977557Z",
      "chan": 1,
      "rfch": 1,
      "freq": 868.300000,
      "stat": 1,
      "modu": "LORA",
      "datr": "SF9BW125",
      "codr": "4/5",
      "lsnr": -10.5,
      "rssi": -115,
      "size": 24,
      "data": "QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"
    }
  ]
}

LoRa Sensor mittels Arduino und LoRa Shield

Über einen Freund bin ich vor ein paar Wochen auf das Thema LoRa bzw. LoRaWAN aufmerksam geworden.

Vor allem seit ich The Things Network (https://www.thethingsnetwork.org) kenne und somit über die Community eine Möglichkeit besteht, die Technologie sinnvoll zu nutzen, bin ich interessiert mich damit mehr zu beschäftigen.

Ein LoRa Sensor ist ein Endgerät, das über das LoRa-Protokoll in ein Netzwerk Informationen funkt. Empfangen werden die Pakete üblicherweise von einem Gateway. Bis zur Auswertung der Pakete sind noch Network Server und Application Server nötig, die in meinem Fall über TTN (The Things Network) bereitgestellt werden.

Da ich auch mit Freunden einen Gateway bauen möchte, brauchen wir natürlich einen LoRa Sensor, um unseren Gateway zu testen. Als günstige Variante habe ich Arduino + LoRa Shield für Arduino gefunden.

Zutaten

Falls jemand entspannt an das Projekt herangeht und mit 5-6 Wochen Lieferzeit aus Shenzhen (China) kein Problem hat, gibt es das LoRa Shield auch kostengünstiger (€ 18,70 am 1.4.2017) über Tindie zu kaufen. Hier beachtet bitte, dass Shipping (+ € 6,12 nach Österreich) und ggf. Zoll dazukommen.

Bitte beachtet bei Bestellungen immer, dass ihr die 868 MHz-Variante auswählt! Nur diese darf in der EU betrieben werden bzw. wird hier funktionieren!

Von der Vorgehensweise halte ich mich an diese Anleitungen:

  1. ein tolles Youtube-Video, das genau den hier beschriebenen Aufbau erklärt: LoRa Node with Arduino and Dragino Shield connected to TTN LoRaWAN von Andreas Spiess
  2. Software (Arduino Sketch) „Hello World“ von https://github.com/SensorsIot/LoRa
  3. LMIC library von IBM, angepasst für Arduino: wird vom Arduino Sketch benötigt

Vielen Dank an die Kollegen von TTN Zürich, die diese Anleitungen und Programme zur Verfügung stellen!

Zusammenbau

Das LoRa Shield muss nun nur mehr auf den Arduino gesteckt werden. Die Antenne wird an den SMA-Anschluss geschraubt.

Konfiguration

Nun lädt man den Arduino Sketch („Hello World“, siehe Link oben) ins Arduino IDE und muss ein paar Werte anpassen. Dazu erstellt man eine „Application“ in der Console von TTN und legt ein Gerät („Device“) an. Eine Over-The-Air-Activation (OTAA) ist nicht möglich, daher muss man manuell ABP wählen und die Werte vom Webinterface abschreiben. Diese werden von TTN automatisch generiert.

  1. NWKSKEY: der Network Session Key muss im korrekten Format in die geschwungenden Klammern { } eingefügt werden.
  2. APPSKEY: ebenso der Application Session Key und zum Schluss die
  3. DEVADDR, also die Geräteadresse im korrekten Format.

TTN bietet im Webinterface übrigens die Werte bereits im richtigen Format an. Im Zweifelsfall muss man auf „< >“ klicken, dann werden die Werte in anderen Formaten dargestellt und können mit copy & paste übernommen werden. Das gewünschte Format ist „msb“.

Ansonsten musste ich keine weiteren Änderungen am Code durchführen.

Trotzdem habe ich den zu übertragenden Text von „HI“ auf „stefan test“ geändert: dazu habe ich die Payload in der Variable „message[]“ in Zeile 57 angepasst:

  // Payload to send (uplink)
  static uint8_t message[] = "stefan test";

Nun habe ich den Sketch kompiliert und auf den Arduino übertragen. Unmittelbar darauf hat er begonnen, alle 20 Sekunden kurz zu blinken, wodurch ich mich bestätigt gefühlt habe, dass es funktioniert und nun alle 20 Sekunden die Meldung „stefan test“ mittels LoRa übertragen wird.

Überprüfen am Gateway

Einen Gateway hatten wir parat und er hat sofort die Pakete empfangen. Über die „Traffic“ Funktion in der TTN Console kann man die ankommenden Pakete gleich sehen.

Man sieht hier mehrere Pakete, die im Abstand von ca. 25 Sekunden ankommen. Die Frequenz wechselt bei jedem Paket, weil mehrere Kanäle genutzt werden: 868,1 – 868,5 – 868,3 usw.

Folgendes JSON Objekt mit allen Details erhält man aus der TTN Console beim Gateway Traffic:

{
  "gw_id": "eui-b827ebfffe6f377d",
  "payload": "QI4cASaAaAABhVJosx+GBwUwHBqp4DGG",
  "f_cnt": 104,
  "lora": {
    "spreading_factor": 9,
    "bandwidth": 125,
    "air_time": 205824000
  },
  "coding_rate": "4/5",
  "timestamp": "2017-03-29T05:57:06.352Z",
  "rssi": -25,
  "snr": 11.2,
  "dev_addr": "26011C8E",
  "frequency": 868100000
}

Es enthält sämtliche Details zur Übertragung. Ein paar Werte möchte ich kurz hervorheben:

  • gw_id: zeigt die ID des Gateways, der das Paket empfangen hat
  • payload: sind die übertragenen Daten in verschlüsselter Form
  • f_cnt: ist der Counter und gibt die Anzahl der Pakete wider
  • lora.spreading_factor: zeigt hier den Spreading Factor 9, der im Sketch eingestellt ist
  • rssi: zeigt die Signalstärke des empfangenen Pakets am Gateway an (hier: -25 dbm)
  • snr: das Signal/Rausch-Verhältnis
  • dev_addr: die Geräteadresse, die von TTN vergeben wurde und ich als DEVADDR im Sketch hinterlegt habe.
  • frequency gibt die Frequenz in Hertz an

Wir sehen, dass das Paket einwandfrei übertragen wurde und sogar sehr gut (-25 dbm) empfangen wurde. Bei diesem Test war der Abstand vom Sensor zum Gateway aber auch im Bereich von 5 Metern.

Optimierungen

Als Spreading Factor ist 9 eingestellt. Um die Reichweite zu erhöhen, kann man auch zB. SF12 einstellen. Das geht im Arduino Sketch auf Zeile 90:

  // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
  LMIC_setDrTxpow(DR_SF9, 14);

Falls man die Pakete weniger oft übertragen möchte (alle 20 Sekunden ist zum Testen super, aber dauerhaft verbraucht es zu viel Airtime), kann das in Zeile 39 anpassen:

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 20;

Ubuntu Linux per SNMP in LibreNMS einbinden

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/

Unifi AP AC Mesh Erfahrungsbericht

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

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:
    • 24V Passive PoE (alter Ubiquiti/Mikrotik/etc. Standard)
    • 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.

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>

 

Hobby, Technik, Erfahrungsberichte, …