Archiv der Kategorie: Raspberry Pi

5″ Display für Raspberry Pi

Immer wieder muss ich meinen Monitor abstecken, um ihn an einen Raspberry anzuschließen. Das nervt.

Nachdem ich mehrere aufsteckbare LCD-Module probiert habe, bin ich mittlerweile an Treiberinstallationen und anzupassenden Kernels verzweifelt.

Jetzt habe ich eine einfache Lösung gefunden: natürlich ist HDMI die richtige Schnittstelle. Da braucht man einfach gar nichts zu konfigurieren, weil’s eh Standard ist.

Auf Aliexpress habe ich ein günstiges 5″ HDMI Display mit 800×480 Pixel Auflösung um € 22,- gefunden. Dieses Display hat auch eine Touch-Oberfläche, die ich aber nicht verwende. (Da befürchte ich wieder Treiberinstallationen und Kernelanpassungen…) Angeschlossen wird es über HDMI, es hat dazu einen Stecker/Adapter, der die beiden HDMI-Ports ganz einfach verbindet.

Das Display habe ich nach ein paar Wochen Lieferzeit erhalten und sofort auf einen Raspberry Pi 3 gesteckt. Funktionert hat es von Anfang an, allerdings nicht in voller Auflösung – es war rechts immer ein Teil unbenutzt. (Ich vermute, dass der Raspberry von 640×480 Pixel (VGA) ausgegangen ist und nicht die vollen 800px Breite genutzt hat. Durch drei Zeilen, die man in der /etc/boot.txt hinzufügt, lässt sich das beheben; ab dem nächsten Reboot wird der Bildschirm vollständig genutzt.

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

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

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

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

Als Eingabemethode verzichte ich ja auf die Touchscreen-Funktion. Dafür will ich eine Bluetooth-Tastatur oder vielleicht ein Android Handy als Bluetooth-Tastatur nutzen.

Links

LoRa APRS Gateway mit Raspberry Pi Zero W

In einem anderen Beitrag habe ich darüber berichtet, dass wir erfolgreich über LoRa-Modulation APRS-Pakete gesendet haben und wie ein APRS-Tracker mit Arduino zu bauen und programmieren ist.

Nun habe ich von Sascha (www.iot4pi.com) ein fertiges, von ihm konstruiertes Board, für einen LoRa APRS Gateway bekommen. Wie er diese Boards erstellt und zusammenbaut, hat er übrigens auf seiner Seite näher beschrieben:
www.iot4pi.com/de/bau-des-lora-gateway-shield

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

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

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

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

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

Wichtig ist auch, dass man zur Netzwerkanbindung das WLAN am Raspberry Zero W konfigurieren muss. Dazu tragt man in der Datei /etc/wpa_supplicant/wpa_supplicant.conf folgende Zeilen ein:

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

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

Da der Gateway nicht für den Außeneinsatz geeignet ist, habe ich mir eine kleine flache Fensterdurchführung zugelegt, mit der ich die Antennenleitung ans Fensterbrett bekomme und dort mit einer 70cm-Magnetfußantenne für 433 MHz verbinde.

Einkaufsliste LoRa APRS Gateway auf Raspberry Pi Zero W

Optional, für den Anschluss an einen Monitor:

günstiger 1ch LoRa Gateway: RFM95W direkt zu Raspberry verkabelt

Obwohl ich der Meinung bin, dass vollwerte LoRaWAN-kompatible Gateway wirklich Sinn ergeben, beschäftige ich auch mit den preiswerten Single Channel (1ch) Gateways. Für Entwicklungen zu Hause ist das ja eine günstige Option.

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!

Hier habe ich eine Anleitung gefunden, mit der tatsächlich um € 13,90 für das LoRa-Modul ein Raspberry Pi supereinfach zu so einem 1ch-Gateway wird: https://www.hackster.io/ChrisSamuelson/lora-raspberry-pi-single-channel-gateway-cheap-d57d36

Achtung, die Anleitung im Link oben empiehlt die Änderung zur amerikanischen Frequenz (902,3 MHz). In Europa bleiben wir bei 868,1 MHz! (Das ist eh der Standardwert) In meiner Anleitung ist auch die IP-Adresse der europäischen Server von TTN enthalten.Die Schritte sind recht einfach:

  • Man bestellt das LoRa RFM95W-868S2 Transceiver Modul.
  • man teilt 4 Jumper Wire Kabel in der Hälfte, sodass auf einer Seite eine Buchse (female) und auf der anderen Seite der blanke Draht ist.  7 davon lötet man an diese Position am Transceiver Modul: DI00, 3.3V, MISO, MOSI, SCK, RESET, NSS und GND (neben MISO)
  • Als Antenne verwenden wir hier zwei Drähte, die 83mm Länge haben und an die Positionen ANA und GND (neben ANA!) gelötet werden. Als Draht wird ein 18ga empfohlen, das ist in unseren Breiten ein 1mm Drahtstück.
  • Nun verbindet man diese mit den PINs am Raspberry GPIO:
    3.3V -> PIN1, GND -> PIN6, DI00 -> PIN7, RESET -> PIN11, NSS -> PIN22, MOSI -> PIN19, MISO -> PIN21 und SCK -> PIN23
  • jetzt kann auch schon die Software installiert werden. Es wird git, wiringpi und der Code für den Single Channel Gateway benötigt:
sudo apt install git wiringpi
git clone https://github.com/tftelkamp/single_chan_pkt_fwd
  • im raspi-config-Tool muss nun die SPI-Schnittstelle aktiviert werden (im Menü „Interfacing Options“ -> „SPI“:
sudo raspi-config
  • nach einem Reboot (wird von raspi-config vorgeschlagen) konfiguriert man die Einstellungen in der main.cpp des single_chan_pkt_fwd Codes:
// Set location
float lat=48.1906;
float lon=16.3867;
int alt=200;

/* Informal status fields */
static char platform[24] = "1ch Gateway";
static char email[40] = "meine@email.adresse";
static char description[64] = "RFM95W directly wired";

// define servers
#define SERVER1 "52.169.76.203"
  • Der Code kann nun mit make compiled werden:
make
  • Nun können wir den Gateway das erste Mal starten:
./single_chan_pkt_fwd
  • Die EUI, die hier gezeigt wird, müssen wir nun bei der Console von TheThingsNetwork als EUI eines neuen Gateways eintragen. Dieser wird sofort angezeigt und übermittelt auch auf Anhieb die Daten, die er empfangen hat.

Ich lege mir meist noch ein Startkommando zurecht, bei dem ich auch den Output in die Datei /var/log/ttn-single-chan-pkt-fwd.log schreibe. Dazu füge ich in der /etc/rc.local folgendes hinzu (am Ende, aber vor dem „exit 0“):

/home/stefan/single_chan_pkt_fwd/single_chan_pkt_fwd >> /var/log/ttn-single-chan-pkt-fwd.log 2>&1

Nach einem Reboot wird so die Software automatisch ausgeführt und ein Logfile angelegt.

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.

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!

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.

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)

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).

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!

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.

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!

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.

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 und auf Twitter (@TTN_Vienna) für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

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/

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>

 

Speedtest über Ubiquiti Edgerouter CLI

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.

Wenn ich vor Ort bin, nutze ich die Speedtest-App (hier der Link für iOS/iPhone/iPad) von Ookla Speedtest.net oder den RTR Netztest (auch für iOS/iPhone/iPad). Diese App gefällt mir in letzter Zeit sogar besser, weil auch viele andere Werte geprüft werden.

Für die Ubiquiti EdgeRouter oder Ubiquiti EdgePoints, die wir in letzter Zeit gerne einsetzen, gibt es da eine einfache Möglichkeit:

Installation: Speedtest für CLI

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:

Auf Github findet man das Python Script speedtest-cli: https://github.com/sivel/speedtest-cli

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:

curl -o /config/user-data/speedtest_cli.py https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest_cli.py

(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:

speedtest_cli1

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

speedtest_cli2–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

–secure nutzt https statt http für die Test

–version liefert die Versionsnummer zurück