Schlagwort-Archive: IoT

Wieso wird mein/e … gehackt?

Ich werde das sehr oft gefragt, daher ist es mir einen Beitrag wert:
„Wieso wurde mein/e … gehackt? Was hat der/die Hacker/in davon? Es ist ja nur ein kleines Gerät im Internet!“

Vor allem aufgrund eines Vorfalls mit Antennen von Uniquiti, die Mitte Mai massenhaft gehackt wurden und mich dazu bewegt haben, einen Blogbeitag zu verfassen, der mittlerweile zu den Meistgelesenen auf dieser Webseite gehört, wurde ich das gefragt.

Die Antwort ist eigentlich ganz einfach, aber schwierig kurz und prägnant zu erklären.

Viele dieser „kleinen“ Geräte, die da gehackt werden – egal ob Antenne, Router, Smartphones oder andere – besitzen ein mächtiges Betriebssystem, und das kann dem Zweck des Hackers nutzen. Es geht also nicht darum, das Gerät vom Netz zu trennen oder die Funktion einzuschränken: es geht darum, Zugrif auf das Gerät zu erlangen und dieses künftig für eigene Zwecke (mit) zu nutzen.

Oft wird die ursprüngliche Funktion des Geräts gar nicht beeinträchtigt – sonst würden die Besitzer ja merken, dass sie gehackt wurden und danach streben, die schadhafte Software zu entfernen. Ist doch praktischer, wenn’s keiner merkt…

Die Geräte werden oft so umprogrammiert (bzw. wird zusätzlich Software installiert), sodass sie auf Arbeitsaufträge („Kommandos“) aus dem Internet horchen und diese dann ausführen. Sie sind dann an sogenannte „Command and Control“-Systeme/-Server angebunden.

Das klingt jetzt noch nicht mächtig, aber wenn man berücksichtigt, dass hunderttausende solcher Geräte, über die Welt verteilt, an so einem System teilhaben, wird klarer, welches Potenzial dadurch entsteht.

Dieses Thema wird sich meiner Einschätzung nach im Zukunft noch zuspitzen: es werden immer mehr Geräte werden ans Internet angebunden und diese werden auch immer leistungsfähiger. Dadurch eignen sie sich immer mehr für solche Aktionen… Man nennt das auch die Ära des Internet of Things (IoT), auf die wir uns rasant zubewegen.

Was kann man dagegen tun? Ein wesentlicher Tipp ist bestimmt, möglichst aktuelle Updates einzuspielen, die häufig Sicherheitslücken beheben, mit denen Angreifer überhaupt die Möglichkeiten bekommen, Zugang zum Gerät zu erlangen und Schadsoftware aufzuspielen. Ansonsten rate ich weiterhin dazu, bewusster zu überlegen, ob wirklich alle Geräte ans Internet angebunden sein müssen bzw. Zugriff darauf haben müssen. Reicht es nicht, wenn zB. Elemente einer Hausautomatisierung mit der Zentrale kommunizieren können? Muss denn jedes Gerät uneingeschränkt mit dem Internet Daten austauschen können?

Mich hat ein aktuelles Ereignis (auch hier sehr gut beschrieben) zu diesem Beitrag inspiriert, außerdem wird dieses Thema nun auch von den Medien verstärkt aufgegriffen und verstanden. In diesem Fall haben hunderttausende Geräte die Kapazität ihrer Internetanbindung genutzt, um die Anbindungen und Bandbreiten großer Webportale lahmzulegen. Das nennt man eine Distributed Denial of Service-Attacke.

APRS: Telemetriedaten vom Raspberry Pi 2 mit pymultimonaprs übertragen

Im vorigen Artikel habe ich beschrieben, wie ich pymultimonaprs auf einem Raspberry Pi 2 konfiguriert habe.

Nun möchte ich in der Status-Zeile ein paar Telemetriedaten übermitteln, die vom Raspberry ausgelesen werden. Konkret sind das:

  • Core Temperatur
  • Core Spannung
  • Core Spannung der SDRAM_p
  • Clock Speeds von Core und ARM

Dazu habe ich ein Script erstellt, das alle 5 Minuten über cron gestartet wird und die vollständige Status-Zeile in der Datei /tmp/aprs-telemetrie.txt hinterlegt. pymultimonaprs versendet dann den Inhalt dieser Datei als Statusmeldung.

Dieses Script (abgelegt als /home/pi/aprs-telemetrie.sh) liest die Werte aus und erstellt die Datei:

#!/bin/bash
echo "Raspberry Pi 2 mit RTL Stick core_temp="`vcgencmd measure_temp | awk -F'=' '{print $2}'\
`" core_volt="`vcgencmd measure_volts core | awk -F'=' '{print $2}'`\
" sdram_p_volt="`vcgencmd measure_volts sdram_p | awk -F'=' '{print $2}'`\
" core_clock="`vcgencmd measure_clock core | awk -F'=' '{print $2}'`\
" arm_clock="`vcgencmd measure_clock arm | awk -F'=' '{print $2}'` > /tmp/aprs-telemetrie.txt

Die Datei sieht nun so aus:

pi@roofpi ~ $ cat /tmp/aprs-telemetrie.txt 
Raspberry Pi 2 mit RTL Stick core_temp=26.1'C core_volt=1.2000V sdram_p_volt=1.2250V core_clock=250000000 arm_clock=600000000

Den Cron-Job habe ich so erstellt:

*/5 * * * *   root    /home/pi/aprs-telemetrie.sh

Nun habe ich folgende Einträge in der mymultimonaprs-Konfigurationsdatei /etc/pymultimonaprs.json geändert:

        "status": {
            "text": false,
            "file": "/tmp/aprs-telemetrie.txt"
        },

Nach einem Neustart von pymultimonaprs mittels

/etc/init.d/pymultimonaprs restart

hat das sofort geklappt:

Jan  2 13:17:40 roofpi pymultimonaprs: connecting... 95.155.111.242:14580
Jan  2 13:17:40 roofpi pymultimonaprs: connected
Jan  2 13:17:40 roofpi pymultimonaprs: # aprsc 2.0.14-g28c5a6a
Jan  2 13:17:40 roofpi pymultimonaprs: login OE1SCS-10 (PyMultimonAPRS 1.2.0)
Jan  2 13:17:40 roofpi pymultimonaprs: # logresp OE1SCS-10 verified, server T2KRAKOW
Jan  2 13:17:40 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:=4811.4 N/01623.2 E-RXonly APRS iGate
Jan  2 13:17:40 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:>Raspberry Pi 2 mit RTL Stick core_temp=25.6'C core_volt=1.2000V sdram_p_volt=1.2250V core_clock=250000000 arm_clock=600000000

 

APRS iGate über HAMnet mit pymultimonaprs

Seit kurzem habe ich bei mir im 3. Wiener Gemeindebezirk am Dach meines Wohnhauses (ca. 8. Stock) – unter anderem – folgendes Equipment installiert:

IMG_4834Der Raspberry und DVB-T-Stick sind in einem Outdoor-Gehäuse verbaut.

Mit diesem Setup möchte ich einen APRS iGate realisieren, also eine Konfiguration, mit der APRS-Pakete auf der europäischen APRS-Frequenz 144.800 MHz empfangen und dann weitergeleitet werden. Die Weiterleitung soll primär über HAMnet erfolgen und nur im Fehlerfall oder bei nicht-Verfügbarkeit meiner HAMnet-Anbindung direkt ans einen APRS-IS-Tier2-Server (vgl. http://www.aprs2.net/)  ins Internet übertragen werden.

Voraussetzung

Als Voraussetzung sollte die RTL-SDR-Software und Treiber am Raspberry bereits installiert sein. Der Vorgang ist unter anderem hier beschrieben: http://thardes.de/raspberry-pi-als-sdr-server/

Weiters habe ich mittels GSM-Netz den Raspberry kalibriert und so die Ungenauigkeit meines Sticks festgestellt: 26 ppm. (vgl. ua. http://www.rtl-sdr.com/how-to-calibrate-rtl-sdr-using-kalibrate-rtl-on-linux/)

Installation

Die iGate-Software pymultimonaprs installiere und hole ich von GIT:

cd ~
sudo apt-get install python2.7 python-pkg-resources
git clone https://github.com/asdil12/pymultimonaprs.git
cd pymultimonaprs
sudo python2 setup.py install

Ich erstelle ein Startscript:

sudo cp pymultimonaprs.init /etc/init.d/pymultimonaprs
sudo chmod +x /etc/init.d/pymultimonaprs
sudo update-rc.d pymultimonaprs defaults

Um in das APRS-IS-Netzwerk Pakete zu übertragen, ist ein Passwort erforderlich, das sich aus dem Call ableitet und errechnet werden muss:

cd ~/pymultimonaprs
./keygen.py CALLSIGN
Key for CALLSIGN: 31983

Konfiguration

Nun passe ich die Konfigurationsdatei /etc/pymultimonaprs.json an. Fertig konfiguriert sieht sie so aus:

{
        "callsign": "OE1SCS-10",
        "passcode": "20123",
        "gateway": [
                "aprs.oe2xzr.ampr.at:14580", "44.143.40.90:14580",
                "aprs.oe1.ampr.at:14580", "44.143.10.90:14580",
                "aprs.oe6xrr.at.ampr.org:14580", "44.143.153.50:14580",
                "aprs.oe7xgr.ampr.at:14580", "44.143.168.68:14580",
                "44.225.41.232:14580",
                "44.225.42.181:14580",
                "euro.aprs2.net:14580"],
        "append_callsign": true,
        "source": "rtl",
        "rtl": {
                "freq": 144.800,
                "ppm": 26,
                "gain": 46,
                "offset_tuning": false,
                "device_index": 0
        },
        "alsa": {
                "device": "default"
        },
        "beacon": {
                "lat": 48.19060,
                "lng": 16.38670,
                "table": "/",
                "symbol": "-",
                "comment": "RXonly APRS iGate",
                "status": {
                        "text": "Raspberry Pi mit RTL Stick",
                        "file": false
                },
                "weather": false,
                "send_every": 1800,
                "ambiguity": 1
        }
}

Ich habe für meinen Call OE1SCS den Suffix -10, auch SSID genannt, gewählt, der lt. APRS SSID-Erklärung für „internet, Igates, echolink, winlink, AVRS, APRN, etc“ gedacht ist.

Im Eintrag „gateway“ habe ich eine Liste an APRS-IS Gateways eingetragen. Die Liste wird bei jedem Neustart von pymultimonaprs vom ersten Eintrag neu abgearbeitet. Ich habe also die Gateways, die ich bevorzuge, an den Anfang geschrieben. Die meisten iGates besitzen sprechende DNS-Namen. Ich will jedoch nicht von einem funktionierenden DNS-Dienst abhängig sein, daher trage ich die IP-Adressen ein. Damit dort nicht nur kryptische HAMnet-IP-Adressen (beginnen mit 44.) stehen habe, habe ich in der gleichen Zeile den DNS-Namen zusätzlich hinterlegt, zB.:
„aprs.oe2xzr.ampr.at:14580“, „44.143.40.90:14580“

Der Dienst versucht 120 Sekunden die APRS-iGates zu erreichen. Nach 120 Sekunden meldet er ein Timeout und probiert den nächsten iGate. Sollte das Netzwerk nicht verfügbar sein oder der iGate-Server am eingestellten Port nicht antworten, wartet pymultimonaprs das Timeout nicht ab, sondern probiert unmittelbar den nächsten iGate in der Liste.

Hier ein Beispiel aus meinem Logfile:

Jan  2 10:53:42 roofpi pymultimonaprs: connecting... 44.225.42.181:14580
Jan  2 10:53:42 roofpi pymultimonaprs: Error when connecting to 44.225.42.181:14580: '[Errno 101] Network is unreachable'
Jan  2 10:53:51 roofpi pymultimonaprs: connecting... 78.47.75.201:14580
Jan  2 10:53:51 roofpi pymultimonaprs: connected
Jan  2 10:53:51 roofpi pymultimonaprs: # aprsc 2.0.18-ge7666c5
Jan  2 10:53:51 roofpi pymultimonaprs: login OE1SCS-10 (PyMultimonAPRS 1.2.0)
Jan  2 10:53:51 roofpi pymultimonaprs: # logresp OE1SCS-10 verified, server T2EISBERG
Jan  2 10:53:51 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:=4811.4 N/01623.2 E-RXonly APRS iGate
Jan  2 10:53:51 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:>Raspberry Pi mit RTL Stick

Mittels „append_callsign“: true, gebe ich an, dass mein Call in den APRS-Pfad bei der Weiterleitung ans iGates dazugefügt werden soll.

im Abschnitt „rtl“ wähle ich die Frequenz 144.800 MHz als europäische APRS-QRG, gebe meine Ungenauigkeit des Sticks (26 ppm) an, die ich vorher gemessen habe und wähle einen Gain von 46. Offset-Tuning lasse ich unbenutzt und da ich nur einen DVB-T-Stick am Raspberry habe, lasse ich den device-index bei 0.

im Abschnitt „beacon“ konfiguriere ich die eigene, regelmäßige, Aussendung meiner „Station“:

Ich gebe die eigenen GPS-Koordinaten an, wähle als Darstellungssymbol ein Haus, gemäß dieser Tabelle:
http://www.aprs-dl.de/?APRS_Detailwissen:SSID%2BSymbole
Ganz unten bei diesem Link kann man die Symboltabelle als PDF runterladen!

Ich wähle einen statischen Text für „comment“ und „status„, außerdem übertrage ich im Moment keine Wetter-Informationen. Ich möchte, dass meine Aussendung alle 30 Minuten übertragen wird (30 Minuten * 60 Sekunden = 1800 Sekunden).

Um meine Positionen nicht 100%ig genau im APRS darzustellen, habe ich die „ambiguity“ auf „1“ gesetzt. Das verringert die Genauigkeit meiner GPS-Position um 1/10 Grad-Minute. Dadurch wird meine APRS-Position auf aprs.fi mit dem Hinweis „Position ambiguous: Precision reduced at transmitter by 1 digits, position resolution approximately 185.2 m.“ zB. so dargestellt:

aprs-ambiguous
meine Station wird bewusst mit einer Ungenauigkeit von ca. 185 Metern in dem violetten Feld angezeigt. Das Feld weist darauf hin, dass die Position nicht exakt ist.

Damit wäre alles konfiguriert und über das Kommando

/etc/init.d/pymultimonaprs start

habe ich den Dienst gestartet.

Die Funktion kann man über das Logfile /var/log/syslog rasch prüfen. Unmittelbar nach dem ersten Start war meine Station auf aprs.fi sichtbar: http://aprs.fi/info/a/OE1SCS-10

Erfahrungen, Tipps & Tricks

Zuverlässigkeit des USB-Sticks

Ich habe den Dienst einige Tage laufen gelassen. Nach zirka zwei Tagen habe ich folgende Fehlermeldung im Logfile gehabt. Auch über „dmesg“ war das Problem sichtbar:

Dec 30 21:23:34 roofpi kernel: [ 2139.021653] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.022123] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.022580] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.023041] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.023968] usb 1-1.3: USB disconnect, device number 4
Dec 30 21:23:34 roofpi kernel: [ 2139.260292] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
Dec 30 21:23:34 roofpi kernel: [ 2139.372309] usb 1-1.3: New USB device found, idVendor=0bda, idProduct=2832
Dec 30 21:23:34 roofpi kernel: [ 2139.372335] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 30 21:23:34 roofpi kernel: [ 2139.372353] usb 1-1.3: Product: RTL2832U
Dec 30 21:23:34 roofpi kernel: [ 2139.372369] usb 1-1.3: Manufacturer: Generic
Dec 30 21:23:34 roofpi kernel: [ 2139.372386] usb 1-1.3: SerialNumber: 77771111153705700

Es hat sich also der USB-Stick verabschiedet „usb 1-1.3: USB disconnect, device number 4“ und sofort wieder neu verbunden. Damit war natürlich ein Neustart des pymultimonaprs nötig, damit dieses wieder korrekt lauscht. Leider war es damit nicht getan und der Fehler ist wenige Minuten später wieder gekommen. Ich habe das ein paar Mal wiederholt und schon befürchtet, dass der Stick vielleicht kaputt ist. Ein Reboot hat die Situation aber entschärft und nun läuft der Stick wieder seit 2 Tagen stabil.

APRS-Meldungen der ISS

Mit einem einfachen Hack, der unter anderem hier beschrieben wird, soll es möglich sein, neben der primären APRS-Frequenz 144.800 MHz auch die APRS-Frequenz der Raumstation ISS zu empfangen. Diese sendet auf 145.825 MHz. Natürlich können diese Meldungen nur gehört werden, wenn sich die ISS in Reichweite befindet. Es gibt zahlreiche Webseiten im Internet, mit denen der Zeitpunkt der nächsten Überflüge der ISS am eigenen Standorts berechnet werden kann.

Leider hat sich dieser Hack bei mir nicht bewährt: mein Stick schafft es kaum noch APRS-Meldungen zu decoden, wenn er auf beide Frequenzen hört. Die Qualität nimmt rapide ab. Woran es genau liegt, kann ich schwer sagen. Ich habe aber die Vermutung, dass es am Squelch liegt, der bei dieser Konfiguration genutzt werden muss: das Programm rtl_fm, das dem Empfang der Pakete übernimmt, funktioniert ohne Squelch, sofern man nur auf einer QRG hört. Wenn man mehrere QRGs angibt (144.8, 145.825, …) muss ein Squelch-Wert angegeben werden. Ich habe zwar 1 als kleinsten möglichen Wert konfiguriert, vermute aber, dass der Squelch bei APRS-Paketen zu spät reagiert und daher viele Pakete nicht vollständig gehört werden. Sobald ich nur auf 144.8 ohne Squelch höre, empfange ich wieder viel mehr Pakete und alles scheint zu funktionieren.

Ein anderer Benutzer hat ähnliches erlebt: „I was unable to scan both 144.39 and 145.825 and decode the packets reliably.“ (http://www.algissalys.com/amateur-radio/raspberry-pi-sdr-dongle-aprs-igate)

Wetter- & Telemetriedaten übertragen

(Edit: ich habe in einem separaten Artikel hier mittlerweile die Übertragung von Telemetriedaten beschrieben…)

pymultimonaprs kann auch Wetterdaten mitsenden. Ich habe leider keine Wetterstation, möchte aber Telemetriedaten meines Raspberry Pi 2 übermitteln. Dazu kann man ein JSON-File erstellen, das diesem Format entspricht (Quelle: https://github.com/asdil12/pymultimonaprs/blob/master/README.md):

You can set weather to a json-file. eg: "weather": "/path/to/weather.json",

If you don’t want do send weather date, just leave it on false.
This will be read in like the status-file and can look like that:

{
    "timestamp": 1366148418,
    "wind": {
        "speed": 10,
        "direction": 240,
        "gust": 200
    },
    "temperature": 18.5,
    "rain": {
        "rainlast1h": 10,
        "rainlast24h": 20,
        "rainmidnight": 15
    },
    "humidity": 20,
    "pressure": 1013.25
}
  • timestamp is seconds since epoch – must be included
  • wind
    • speed is in km/h
    • direction is in deg
    • gust is in km/h
  • temperature is in °C
  • rain
    • rainlast1h is in mm
    • rainlast24h is in mm
    • rainmidnight is in mm
  • humidity is in %
  • pressure is in hPa

The timestamp must be included – everything else is optional.

Meine Idee wäre, die Temperatur & Spannung des Raspberry Core zu übermitteln, die mittels des Kommandos „vcgencmd“ ermittelt werden können. Details siehe hier: http://elinux.org/RPI_vcgencmd_usage

Ich müsste also ein JSON-File erstellen, in das ich

  • den aktuellen UNIX-Timestamp angebe,
  • bei temperature die Ausgabe von „vcgencmd measure_temp“
pi@roofpi ~ $ vcgencmd measure_temp
temp=27.2'C

Damit übertrage ich zwar nicht die Daten des Wetters, sondern die Temperatur der CPU, aber ich kann das zum Testen mal so machen.

Es würde sich auch anbieten, andere Telemetriedaten mitzusenden, wie zB. die Spannungen der Elemente des Raspberry:

pi@roofpi ~ $ vcgencmd measure_volts core
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_c
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_i
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_p
volt=1.2250V

Für die Spannungen ist kein Feld in den Wetterdaten vorgesehen. Man könnte diese Daten also über die „status„-Aussendung übermitteln. Dazu ändert man im Konfig file (/etc/pymultimonaprs.json) im Bereich „status“ folgendes:

"status": {
 "text": false,
 "file": "/tmp/aprs-status.txt"
 },

In die Datei /tmp/aprs-status.txt schreibt man nun eine Zeile, die man als Status aussenden will, beispielsweise:

Raspberry Pi mit RTL Stick core_temp=27.2'C core_volt=1.2000V sdram_c_volt=1.2000V sdram_i_volt=1.2000V sdram_p_volt=1.2250V

Ideen für weitere Werte, die man aussenden könnte:

  • uptime
  • clock-speeds von core, arm und anderen Modulen im Raspberry
  • uvm…

Ich habe mittlerweile die Übertragung der Telemetriedaten in einem eigenen Artikel beschrieben.

APRS Smartbeaconing bewährt sich bei mir nicht

AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs
AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs

SmartBeaconing ist eine gute Idee: statt per APRS seine Position alle x Sekunden auszusenden und damit das APRS-Netz unnötig zu belasten, wird die Position nur gesendet, sobald es das System „smart“ findet: bei Richtungsänderungen, wesentlichen Geschwindigkeitsänderungen, etc.

Das entlastet das Netz hinsichtlich der Anzahl an Meldungen, die direkt oder über Digipeating übertragen werden und erhöht die Wahrscheinlichkeit für andere Benutzer, dass Airtime für deren Aussendung frei ist.

AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)

Ich habe überall SmartBeaconing verwendet. Schließlich bin ich großteils im Stadtgebiet von Wien und in der näheren Umgebung unterwegs und dort ist die Dichte an APRS-Empfängern & -Digipeatern sehr hoch.

AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015
AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015

Leider hat sich SmartBeaconing für mich nicht bewährt: obwohl ich mit 5 Watt über eine externe Magnetfußantenne (Nagoya UT-106UV) vom Autodach aus sende, werden nur 30-40% meiner Meldungen aufgenommen. Und das reicht nicht, um die Strecke annähernd korrekt abzubilden. Vor allem, wenn eine Richtungsänderung nur alle 1-2 Minuten passiert, hinterlasse ich nur alle 5 Minuten einen Punkt auf der Map bei dieser schlechten Erfolgsquote der Übertragung.

Ich habe daher SmartBeaconing deaktiviert und sende im Moment stur alle 30 Sekunden. Damit bekomme ich ausreichend Übertragungen zusammen, um die Route gut abzubilden. Gleichzeitig ist mir bewusst, dass dadurch das Netz stärker belastet wird. Da ich aber nicht viel mit dem Auto unterwegs bin, denke ich, dass es zumutbar ist

APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconing
APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconin

 

SainSonic AP510

Vor einigen Monaten habe ich mir ein SainSonic AP510 um knapp € 100,- über eBay aus DL gekauft. Ich bin total begeistert! Vielleicht ausnahmsweise mal weniger, weil es etwas Bestimmtes so gut kann. Sondern diesmal weil es so viel kann.

Das Ding wird als „APRS Tracker VHF GPS Bluetooth Thermometer TF Card APRSdroid“ angepriesen. Man sieht schon: da steckt viel drinnen.

Ursprünglich dachte ich, ich kaufe einen APRS Tracker. Ich war froh, dass ein leistungsfähiger Akku (angeblich 3.300mAh LiPo) drinnen ist, der auch wirklich 2 Tage hält, und dass ich kein separates Funkgerät brauche (mit komplizierten und herstellerspezifischen Adapterkabeln), sondern ein Transceiver mit 1 Watt (manche behaupten 1,5 Watt) für VHF (2 Meter-Band) mit drinnen ist.

Auspacken & Inbetriebnahme

Ich möchte da ja nicht zu sehr auf andere Blogger verweisen. Aber lest mal, was die alles erlebt haben! Ich kann das großteils auch bestätigen, aber die zentrale Aussage bleibt: auspacken und gleich mal ein Firmware Upgrade machen. Damit erspart ihr euch diese Erfahrungen und mit der Firmware aus Oktober 2014 funktioniert das Gerät bei mir sehr gut.

Meine Erfahrungen habe ich mit der Software vom 8.10.2014 (20141008) gemacht. Generell kann ich den Thread des Herstellers empfehlen. Die Seite ist zwar 95% chinesisch, aber die Downloads sind zu erkennen und selbsterklärend: http://www.y027.com/dvbbs8/dispbbs.asp?boardid=5&Id=829

Falls das Update-Programm nach dem Start alles chinesisch darstellt, habe ich einen einfachen Trick gefunden: im Verzeichnis des Programms gibt es eine Datei „avrubd.ini“. Öffnet diese mit einem Texteditor und sucht im obersten Block „[last]“ nach „language“ und ändert diese auf „English“:

language=English

Ein paar Dateien werden für den Start der Programme benötigt, zB. mscomm32.ocx oder msstdfmt.dll. Diese Dateien findet ihr im Internet oder auf der Seite eines anderen Bloggers.

In der Version von Oktober 2014 hat sich das Konfigurationsprogramm einwandfrei bedienen lassen.

20150612 - Konfig StefanDie Einstellungen sind weitgehend selbsterklärend. Folgende Punkte möchte ich kurz beschreiben:

  • MIC-E aktiviert die Komrimierung der APRS-Daten. Ich habe damit in OE, S5, HA und 9A keine Probleme gehabt. Die Übertragungsdauer wird durch diese Funktion reduziert.
  • Smart beaconing: das ist ein lobenswertes Feature, mit dem nicht ununterbrochen periodisch Nachrichten gesendet werden, sondern Meldungen erst dann geschickt werden, wenn sich meine Fahrtrichtung ändert.
  • Busy-control: damit hört der AP510 kurz in den Kanal, ob dieser frei ist, bevor die eigene APRS-Aussendung beginnt.

Erfahrungen

AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)

In den nächsten Tagen habe ich das Gerät überall mitgenommen. Zum Testen natürlich.

SainSonic AP510 im Zug mit Antenne Diamond RH951S
SainSonic AP510 im Zug mit Antenne Diamond RH951S

Meine Positionsmeldungen wurden großteils gut übertragen, ich habe allerdings in Gebäuden (auch direkt hinter (vmtl. bedampften) Fenstern) oft keinen GPS Fix bekommen.

 

 

 

Let’s encrypt: Zertifikat automatisch erneuern

Im vorigen Beitrag habe ich für diesen Blog ein Zertifikat von Let’s encrypt! erstellt. Dieses ist 3 Monate gültig. Es ist vorgesehen, dass das Erneuern des Zertifikats automatisch passiert.

Konkret werde ich einen Cronjob erstellen, der monatlich ein neues Zertifikat mit Hilfe des „letsencrypt-auto“ Python-Script bezieht.

Konfiguration

Um mir eine Menge Kommandozeilenoptionen zu ersparen, erstelle ich eine Konfigurationsdatei /etc/letsencrypt/cli.ini, die meine Standardwerte enthält:

rsa-key-size = 4096
text
redirect
renew-by-default
agree-tos 
email = meine.email@adresse.at

Hier sind die Parameter kurz erklärt:

rsa-key-size
entweder 2048 (Standard) oder sicherer mit 4096 Bit. Ich möchte meine Zertifikate mit 4096 Bit RSA erstellen.

text
nur im Text-Modus starten (ohne Menüführung). Schließlich soll der Client automatisch im Hintergrund funktionieren.

redirect
ich wurde immer gefragt:

Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Um diese Frage vorab zu beantworten, fügt man entweder die CLI-Option „–redirect“ an, oder eben in der cli.ini den Ausdruck „redirect“. Damit wird die Option 2 gewählt: make all requests redirect to secure HTTPS access.

renew-by-default
Erneuert das Zertifikat standardmäßig.

agree-tos
Damit stimmt man den Regeln von let’s encrypt! zu. Schließlich wollen wir den Vorgang ja per Cronjob automatisieren und nicht die Regeln manuell bestätigen müssen.

email
Die Email-Adresse, mit der ich bei let’s encrypt! registiert bin.

Testlauf

Zuerst muss ich das Kommando testen:

./letsencrypt-auto -c /etc/letsencrypt/cli.ini -d stefan.schultheis.at

Es funktioniert:

letsencrypt-headless

Cronjob

Um den Job am 20. des Monats um 6:10 auszuführen, habe ich als User root in der Datei /etc/crontab folgenden Eintrag erstellt:

$ sudo vi /etc/crontab

10 6   20 * *   root    /home/stefan/letsencrypt/letsencrypt-auto -c /etc/letsencrypt/cli.ini -d stefan.schultheis.at

Der Cron-Daemon muss die Änderung noch neu laden:

$ sudo service cron reload

Damit bekomme ich jedes Monat am 20. Tag das Zertifikat erneuert. Da derzeit das Zertifikat für 90 Tage gültig ist, bin ich damit auf der sicheren Seite und habe immer ein Zertifikat, das maximal 31 Tage alt ist.

Let’s encrypt: Apache Webserver mit SSL-Zertifikat von letsencrypt für WordPress unter Ubuntu Linux

Kurze Einführung

SSL-Zertifikate für Webserver nach dem Standard X.509 haben – kurz gesagt – zwei Aufgaben:

  1. sie verschlüsseln die Verbindung zwischen Webserver und Client bzw. Browser am Client (Internet Explorer, Firefox, Chrome, Safari, …). Das ist erkennbar am https:// zu Beginn einer Webseitenadresse.
  2. sie bestätigen, dass der aufgerufene Webdienst zu der Organisation gehört, die man aufgerufen hat. Das ist zB. beim Online Banking wichtig. Da will man ja wirklich nur bei der eigenen Bank einloggen und die Kennworte eingeben und nicht auf einer Fishing-Seite, die vorgibt, die Seite der Bank zu sein und in Wirklichkeit die Zugangsdaten an Betrüger übergibt.

Bisher habe ich meine SSL-Zertifikate für Webserver über CACert erhalten. Damit diese ohne Warnung bzw. Fehlermeldung von den Clients/Browsern akzeptiert werden, muss man jedoch erst manuell dem Root-Zertifikat von CACert vertrauen. Nur wenige Distributationen, zB. Debian, vertrauen CACert standardmäßig.

Der neue Internet-Dienst Let’s Encrypt bietet kostenlose SSL-Zertifikate an, die von gängigen Browsern akzeptiert werden. Seit 3. Dezember 2015 ist dieser Dienst in einer Public Beta Phase und kann nun von jedermann genutzt werden.

Hinter Let’s Encrypt stehen namhafte Firmen und Organisationen wie Mozilla, Akamai, Cisco, EFF, Facebook, ISC uvm.

Besonders spannend finde ich, dass Let’s Encrypt einen Client bereitstellt, mit dem die Zertifikate erzeugt/beantragt werden und der sie auch gleich im Webserver installiert. Die gängigen Methoden über Certificate Signing Requests (CSR) werden nicht angeboten.

Das Ziel

Um den neuen Dienst auszuprobieren, möchte ich meinen WordPress-Blog, der aktuell unter http:// und https:// (mit CACert-SSL-Zertifikat) erreichbar ist, nur mehr über https:// anbieten und mit einem Let’s Encrypt-Zertifikat versehen.

Die Standard-URL meines Blogs ist derzeit http://, also unverschlüsselt. Das möchte ich auch ändern und somit in Zukunft den Inhalt nur mehr verschlüsselt ausliefern.

Let’s go!

Mein Blog läuft unter Ubuntu 14.04 LTS. Hier muss ich zuerst „git“ installieren, damit der letsencrypt-Client geladen werden kann:

apt-get update ; apt-get install git

Auf https://letsencrypt.org/howitworks/ werden die Schritte gut beschrieben, ich lade also zuerst den Client runter:

git clone https://github.com/letsencrypt/letsencrypt

Danach kann ich ins Verzeichnis „letsencrypt“ wechseln und dort das Programm „letsencrypt“ mit dem Parameter „auto“ ausführen. Mein Webserver (apache) ist ein häufig verwendeter Webserver und sollte vom Programm erkannt werden:

cd letsencrypt/
./letsencrypt-auto

Es erscheint ein praktisches ncurses-geführtes Menü, das nach der Webseite bzw. dem Domainnamen fragt, für den ein Zertifkat erstellt werden soll. Der Dienst hat also meine Konfiguration korrekt erkannt:

letsenc01

Nach der Bestätigung, werde ich nach meiner Email-Adresse gefragt:

letsenc02

Hier erhalte ich leider eine Fehlermeldung: „There seem to be a problem with that address.“. Ich habe das leider nicht lösen können. Lt. Recherche im Internet wird überprüft, ob zu der Email-Adresse entsprechende MX bzw. A-Records bei DNS eingerichtet sind. In meinem Fall gibt es gültige MX-Records. Trotzdem akzepiert letsencrypt die Adresse nicht. Es gibt zwei Möglichkeiten fortzusetzen;

  • entweder man startet den letsencrypt-Client mit dem Parameter –register-unsafely-without-email oder
  • ich verwende eine andere Email-Adresse.

letsenc03-problem-email

Da in Foren davon abgeraten wird, keine Email-Adresse anzuführen, habe ich einfach eine GMX-Adresse von mir genutzt. Damit war das Problem „gelöst“.

Im nächsten Schritt hat mich der letsencrypt-Client gefragt, ob ich in der Webserver-Konfiguration auch http-Verbindungen zulassen möchte, oder nur https. Die Varianten heißen „Easy“ und „Secure“. Ich habe ja als Ziel im Auge, alle Verbindungen mit dem Zertifikat zu versehen, also habe ich „Secure“ gewählt:

letsenc04

Und schon kommt die Meldung, dass letsencrypt fertig ist:

letenc05

Ich habe sofort die Webseite in meinem Browser neu geladen und sofort  das letsencrypt-Zertifikat gesehen. Die Seite wurde ohne Fehler angezeigt.

Der letzte Schliff in WordPress

Weil mein Blog bisher über http:// angeboten wurde, habe ich im WordPress Backend die Hauptadresse und Webseiten-Adresse angepasst und von https://stefan.schultheis.at auf https://stefan.schultheis.at geändert:

wpeinsthttps

Um sicher zu gehen, dass keine Inhalte mehr über http geladen werden, habe ich ein WordPress Plugin installiert: Easy HTTPS (SSL) Redirection. Dieses Plugin sendet bei http-Aufrufen ein Redirect (http 301, Moved Permanently) zu https. Damit stelle ich sicher, dass künftig alle Aufrufe über https beantwortet werden.

Die Konfiguration des Plugins war wirklich einfach. Ich habe die „Automatic redirection to the HTTPS“ aktiviert und für „The whole domain“ gewählt. Weiters erzwinge ich https mittels „Force resources to use HTTPS URL“:

wppluginhttps-redirection

Es gibt eine Warnung, die am Screenshot oben rot sichtbar ist, was zu tun wäre, wenn es zu Problemen kommt. Diese Warnung habe ich ignoriert, ich hatte auch keine Probleme nach der Aktivierung.

Prüfung des Zertifikats

Ab sofort ist mein Blog also unter https:// erreichbar. Wenn man mit http:// aufruft, wird man sofort mittels 301-Redirect auf die verschlüsselte Version verwiesen.

Das Zertifikat wird in Firefox (Version 42.0) problemlos angezeigt:

letsenc-blogzert01

Das Zertifikat ist als 2048 Bit RSA mit SHA-256 und Gültigkeit von 3 Monaten sichtbar:

letsenc-blogzert02

Die Zertifkatskette zeigt „DST Root CA X3“ als Stammzertifizierungsstelle, danach die „Let’s Encrypt Authority X1“:

letsenc-blogzert03

Nach der Installation des Zertifikats empfiehlt übrigens auch Let’s Encrypt, dass man die Konfiguration mittels eines Gratisdiensts von Qualys SSL Labs prüft: https://www.ssllabs.com/ssltest/

In meinem Fall habe ich Grade A bekommen, also die Bestnote. Das spricht für die saubere Implementierung durch den Let’s Encrypt Client und für eine saubere Konfiguration der Sicherheitseinstellungen des Webservers:

qualys

Der Qualys-Test überprüft eine große Anzahl an Werten und Konfigurations-Einstellungen. Unter anderem beispielsweise die angebotenen Verschlüsselungsstärken, die Konfiguration von Perfect Forward Secrecy, die Kompatibiltät zu Endgeräten und Browsern uvm.

Falls bei euch hier Einschränkungen angezeigt werden, helfen vielleicht die Empfehlungen von bettercrypto.org. Dort findet ihr ein „Paper“, in dem für zahlreiche gängige Webvserver Konfigurationen empfohlen werden, um die Sicherheit zu verbessern und unsichere Methoden zu beseitigen. Ich gehe mittlerweile bei der Installation von neuen Webserver immer nach deren Anleitung vor, auch beim gegenständlichen Blog.

Mein Fazit

Die Installation war super-einfach und hat super funktioniert, bis auf meine Email-Adresse, die vom Client nicht akzeptiert wurde (wie oben beschrieben). Da diese Email-Adresse aber sowieso nicht im Zertifikat zu sehen ist, sehe ich da kein großes Problem – Hauptsache, es ist eine gültige Email-Adresse verknüpft. Der übrige Teil der Installation und das Zertifikat selbst waren einwandfrei.

Für mich stellt sich noch eine Frage: vertraue ich dem Zertifikat für sensible Kommunikation?
Hier bin ich noch vorsichtig. Vielleicht bin ich zu Paranoid und es ist hier gar nicht angebracht, aber die bisher gängige Methode mittels CSR war mir schon sympathisch. Der private Schlüsselteil ist dabei nämlich immer bei mir geblieben. Ich vermute, dass auch bei Let’s Encrypt der private Teil des Schlüssels meinen Server nicht verlässt. Auch aufgrund der Tatsache, dass der Quellcode des Programms offen ist (Open Source) und jeder im Internet überprüfen kann, was bei der Installation genau passiert.

Trotzdem: ich werde Let’s Encrypt auf meinen Webseiten verwenden, die für die Öffentlichkeit gedacht sind. Auf Webseiten, die private und schützenswerte Inhalte liefern (zB. OwnCloud oder VPNs) werde ich wohl derweil noch bei selbstsignierten Zertifikaten bleiben oder CACert nutzen, wo man über CSR die Zertifikate beantragt.

Unifi Controller in fhem einbinden

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.

Der Stromverbrauch meiner Kaffeemaschine

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

Strom messen mit FHEM und Edimax 2101W

Ich wollte immer schon wissen, wieviel Energie die Geräte im Haushalt verbrauchen. Waschmaschine, Kaffeemaschine beim Aufheizen, Computer, SAT Receiver, meine Funkfeuer-Installation am Dach, etc… Anwendungsbereiche hätte ich viele.

Ein Energiemessgerät mit Anzeige oder Logger auf SD-Karte hat meine Ansprüche nicht ganz zufriedengestellt. Natürlich möchte ich die Daten automatisch und zeitnah auslesen und darstellen.

Toll, dass das nun möglich ist und dass es sich in FHEM, meiner zentralen Software für die Hausautomatisierung, einbinden lässt.

Einrichtung

edimax2101wHeute Früh hat die Post meinen Edimax 2101W, gekauft um knapp weniger als € 50,-, zugestellt. Es handelt sich dabei um einen Zwischenstecker für Steckdosen, der per WLAN verbunden ist und über eine Android-App geschaltet (ein/aus), konfiguriert (Zeitschaltfunktionen, WLAN-Zugangsdaten) und ausgelesen (Energieverbrauch) werden kann.

Das Gerät sendet nach dem Anstecken an einer Steckdose eine SSID als Master (Access Point) aus. Ich verbinde mich mit meinem Android Tablet zu dieser offenen SSID, starte die EdiMax-App und konfiguriere die SSID und das Kennwort für mein WLAN, damit der Edimax 2101W sich nach einem Reboot in mein Hausnetz integriert. Meinem DHCP-Server am Router habe ich eine feste IP-Adresse für die MAC-Adresse des Edimax Gerätes eingestellt, damit sich diese nicht ändert und ich per Hausautomatisierung das Gerät abfragen kann.

Einbindung FHEM

In FHEM gibt es seit ein paar Wochen ein fertiges Modul für die Einbindung des Edimax 2101W. Es ist nicht mehr zu tun, als das Gerät mit einem einzeiligen Kommando einzubinden:

define SmartPlugCpower EDIPLUG 192.168.1.23

FHEM nimmt nun für die Authentifizierung die  Standardwerte admin/1234 an und liest sofort alle Daten aus:

fhem-edi-examplelines

Für die Verbesserung der Darstellung (va. am Floorplan) habe ich noch folgende Zeilen konfiguriert:

define SmartPlugCpower EDIPLUG 192.168.1.23
attr SmartPlugCpower eventMap on:an off:aus
attr SmartPlugCpower interval 60
attr SmartPlugCpower model SP2101W
attr SmartPlugCpower password 1234
attr SmartPlugCpower room Wohnzimmer
attr SmartPlugCpower user admin

Natürlich möchte ich die Werte in einer Datei loggen und auch als SVG zeichnen. Danke an’s FHEM Forum für die wichtigen Hinweise zu diesem Thema:

define FileLog_SmartPlugCpower FileLog ./log/SmartPlugCpower_01-%Y-%m.log SmartPlugCpower

define SVG_SmartPlugCpower SVG FileLog_SmartPlugCpower:SVG_FileLog_SmartPlugCpower:CURRENT
attr SVG_SmartPlugCpower room Wohnzimmer

define SVG_FileLog_SmartPlugCpower_Monat SVG FileLog_SmartPlugCpower:SVG_FileLog_SmartPlugCpower_Monat:CURRENT
attr SVG_FileLog_SmartPlugCpower_Monat room Wohnzimmer

fhem-edi-gplot

Die Liste der Anpassungen:

  • Y-Axis label left entfernt
  • Y-Axis label right auf „Watt“ geändert
  • im Diagramm die Sources der ersten Zeile auf „Verbrauch Watt“ geändert
  • statt der standardmäßigen Regex auf SmartPlugCpower.power_now geändert, weil das der Wert ist, den ich sehen will.

Durch Klicken auf „Write .gplot file“ wird die Einstellung aktiviert und eine Grafik erstellt.

Für die Monatsgrafik habe ich die gleichen Zeilen angepasst, die Einheit ist allerdings „kWh“:

fhem-edi-gplot-kwh

Ich mach‘ mir mal einen Kaffee

Ich hab‘ also einmal die Nespresso Kaffeemaschine angeschlossen und mir zwei Espressi gemacht:

fhem-ediplug-kaffeemaschine

Nach dem Einschalten beim Aufzeihen der Maschine werden kurz immerhin 1.200 Watt benötigt:

2015-07-16_06:49:43 SmartPlugCpower ON / 1201.70 W / 5.3106 A

Auch zwischendurch heizt die Maschine immer wieder kurz nach und hat in 1,5 Stunden (aufzeihen, zwei Espressi + 1,5h Leerlauf, danach abgeschaltet) immerhin 0,031 kWh verbraucht.