Das ist ein Update des ursprünglichen Artikels da sich ein paar wichtige Dinge geändert haben und ich auch einen DNS-Loop eingebaut hatte…

Installation

Mit einer Zeile ist er auf dem Raspberry Pi installiert: der Werbeblocker Pi-hole

curl -L https://install.pi-hole.net | bash

Während der Installation wird die Konfiguration von Pi-hole durch eine grafische Oberfläche erleichtert. Die meisten Voreinstellungen kann man ohne Änderung abnicken.

Nach erfolgreicher Installation ist die Weboberfläche des Pi-hole unter der Adresse http://<servername>:<port>/admin zu erreichen.

Wichtige Einstellungen

Unter anderem ist als DNS-Server der von Google voreingestellt. Diese Einstellung kann nach Abschluss der Installation nachträglich in der Pi-hole-Oberfläche angepasst werden. Dazu dort einloggen und unter Settings -> DNS einen anderen voreingestellten DNS auswählen oder auf der rechten Seite einen frei wählbaren DNS-Server eintragen. Natürlich kann die Einstellung auch auf dem Google-DNS belassen werden.

Neben der Weboberfläche können die Einstellungen auch über die Konsole in der Konfigurationsdatei mit

sudo vim /etc/dnsmasq.d/01-pihole.conf

angepasst werden.

Pi-hole als DNS im eigenen Netzwerk nutzen

Damit nun der Pi-hole auch netzwerkweit als DNS genutzt wird, muss z.B. in der FritzBox unter „Internet-> Zugangsdaten“ im Reiter „DNS-Server“ noch die IP des Pi-hole-Rechners als lokaler DNS-Server eintragen werden. Hier im Bild für IPv4 und IPv6 dargestellt. Die IPv6-Adresse des Pi-hole findet ihr u.a. auf der Weboberfläche unter Settings im Reiter „System„.

Lokale Namensauflösung

Die meisten werden Pi-hole nicht als DHCP-Server nutzen, sondern DHCP dem DSL-Router überlassen. Damit der Pi-hole auch die Namensauflösung im lokalen Netzwerk kennt, muss der lokale Router unter Settings->DNS im Breich „Conditional Forwarding“ eingetragen werden. Im Bild ist die entsprechende Konfiguration für eine FritzBox zu sehen. Nun sollte auch die Namensauflösung im lokalen Netzwerk wieder funktionieren.

Geschafft!

Soviel zur Installation und Konfiguration von Pi-hole! Es kann ein paar Minuten dauern bis die Hostnamen im lokalen Netz wieder aufgelöst werden. Ab nun laufen die DNS-Anfragen aller im Heimnetz eingebundenen Geräte (LAN oder WLAN) über den Pi-hole und alles ist werbefrei!

Portkonflikt

Die Weboberfläche von Pi-hole erreicht man standardmäßig über den HTTP-Port 80. Da bei mir auf dem Raspberry aber parallel noch ein Apache werkelt, konnt der lighttpd nicht auf Port 80 gestartet werden. Eine entsprechende Fehlermeldung kam am Ende der Installation. Daher musste ich den Port des lighttpd noch ändern. Dazu die Konfiguration des lighttpd mit

sudo vim /etc/lighttpd/lighttpd.conf

editieren (nach „80“ suchen und den Wert hinter server.port auf den gewünschten Port stellen). Anschliessend den lighttpd-Service mit folgendem Befehl neu starten:

sudo service lighttpd restart

Leider muss diese Änderung aktuell nach jedem Update gemacht werden da die Konfiguration standardmäßig wieder den Port 80 nutzt.

Daten per JSON abfragen

Verschiedene der in der Adminoberfläche angezeigten Information können auch sehr einfach über eine JSON-Schnittstelle abgefragt werden. Die Adresse ist http://<servername>:<port>/admin/api.php. Hier ein kurzes Beispiel um diese Abfrage in PHP zu realsieren und ein Screenshot der Implementierung in meiner Hausübersicht (links unten).

$json = file_get_contents('http://<servername>:<port>/admin/api.php');
$data = json_decode($json);
print "Domains blockiert: ".$data->{'domains_being_blocked'};
print "DNS-Abfragen: ".$data->{'dns_queries_today'};
print "Blockierte Werbung: ".$data->{'ads_blocked_today'};
print "Prozentuale Werbung: ".$data->{'ads_percentage_today'};

Konsole anstatt Weboberfläche

Neben der Weboberfläche kann man auch auf der Konsole mittels pihole [option] verschiedene Funktionen aufrufen.

So kann zum Beispiel die Liste der Werbe-Domains aktualisiert werden:

pihole -g

Update des Pi-hole:

pihole -up

Zeigt alle möglichen Optionen:

pihole -h

So, und nun viel Spaß mit einem größtenteil werbefreien Internet!

Gruß

Chris

Meine Implementierung ist schon etwas älter und auch mit der Zeit gewachsen. Da es sich bei dieser Webseite um ein recht überschaubares Projekt handelt und ich mit dem Ergebnis zufrieden bin, habe ich mir nie die Mühe gemacht die Seite generischer zu gestalten. Daher muss bei nötigen Anpassungen der Code direkt geändert werden und es gibt auch keine Trennung von HTML und PHP, keine durchgehende allumfassende Fehlerbehandlung, evtl. „unschönes“ HTML usw.

Der Code soll als Anregung und Grundlage für eine eigene Seite dienen…nicht mehr, nicht weniger. Wem´s ausreicht kann es natürlich auch 1:1 übernehmen. Positiv an meiner Lösung finde ich immer noch die Flexibilität in den Auswertungen die direkt auf der Datenbank mittels SQL ausgeführt werden können.

Die Startseite

Die Startseite wird mittels „Meta-Refresh“ alle 180 Sekunden neu geladen und dient der Übersicht der wichtigsten Sensordaten. Mit Klick auf die (verlinkten) Boxen gelangt man jeweils zu einer detaillierteren Übersicht der Sensordaten. In der Übersicht werden keine komplizierten Datenbankauswertungen gemacht. Hier werden die Snapshot-Tabellen mit den aktuellen Werten ausgelesen und einige SQL-Aggregat-Funktionen genutzt. Das ging auch auf einem alten Raspi einigermaßen schnell. Das hängt natürlich von den Tabellengrößen in den Datenbanken ab. Da bei mir einige Tabellen mit den Jahren relativ groß geworden sind (~500k Zeilen), bin ich irgendwann auf einen Odroid umgestiegen.

Übersicht der Außentemperaturen

Die Übersicht der Außentemperatur wird aus den Daten des Außenfühlers der Viessmann-Heizung generiert. Die Übersichten für anderen Sensoren sehen analog dieser Ansicht aus.

Die Übersicht der Heizungsdaten

Die Übersicht der Heizungsdaten stellt verschiedene Daten dar die mittels openv aus der Heizung ausgelesen werden. Aktuell lese ich mit openv nur aus und setze keine Werte (z.B. Sommer-/Winterumschaltung).

Voraussetzung und Grundlagen

Details zum Auslesen der verschiedenen Sensordaten findet ihr in vorangegangenen Artikeln hier im Blog:

• Viessmann Heizung mittels openv auslesen
• M-Bus Wasserzähler auslesen
• Gaszähler mit Reed auslesen
• Stromzähler mit optischem Lesekopf auslesen

Die Webseite liest die Datenbanken des Wasserzähler, des Gaszählers, der Heizung und des Stromzählers aus. Folgend nochmal eine Übersicht der Tabellenstrukturen welche auch in den Artikel oben zu finden sind. In MySQL (bzw. MariaDB) habe ich zwei Datenbanken angelegt (vito, haus) mit verschiedenen Tabellen.

Die Tabellen der Datenbank „vito“:

 CREATE TABLE `brenner` (
 `timestamp` datetime NOT NULL,
 `brennerstarts` float NOT NULL,
 `brennerstunden` float NOT NULL,
 `brennerstatus` int(11) NOT NULL,
 KEY `timestamp` (`timestamp`)
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1

CREATE TABLE `snapshot` (
 `timestamp` datetime NOT NULL,
 `brennerstatus` float NOT NULL,
 `brennerstarts` float NOT NULL,
 `brennerstunden` float NOT NULL,
 `solarstunden` float NOT NULL,
 `solarleistung` float NOT NULL,
 `aussentemperatur` float NOT NULL,
 `warmwasser` float NOT NULL,
 `speicher_unten` float NOT NULL,
 `kollektor` float NOT NULL,
 `kesseltemperatur` float NOT NULL,
 `vorlauftemperaturM2` float NOT NULL,
 `vorlaufsolltemperaturM2` float NOT NULL,
 `raumsolltemperaturM1` float NOT NULL,
 `raumsolltemperaturM2` float NOT NULL,
 `raumsolltemperaturredM1` float NOT NULL,
 `raumsolltemperaturredM2` float NOT NULL,
 `warmwassersoll` float NOT NULL,
 `kesseltemperatursoll` float NOT NULL,
 `pumpestatusM1` float NOT NULL,
 `pumpestatusSP` float NOT NULL,
 `pumpestatussolar` float NOT NULL,
 `statusstoerung` varchar(100) CHARACTER SET latin1 COLLATE latin1_german1_ci NOT NULL,
 `systemzeit` varchar(100) CHARACTER SET latin1 COLLATE latin1_german1_ci NOT NULL,
 `error0` varchar(500) CHARACTER SET latin1 COLLATE latin1_german1_ci NOT NULL,
 `BetriebArt` varchar(20) NOT NULL,
 `BetriebArtM2` varchar(20) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1

CREATE TABLE `solar` (
 `timestamp` datetime NOT NULL,
 `solarstunden` float NOT NULL,
 `solarleistung` float NOT NULL,
 `solarpumpe` int(11) NOT NULL,
 KEY `timestamp` (`timestamp`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

CREATE TABLE `temperaturen` (
 `timestamp` datetime NOT NULL,
 `aussentemperatur` float NOT NULL,
 `warmwasser` float NOT NULL,
 `speicher_unten` float NOT NULL,
 `kollektor` float NOT NULL,
 `vorlaufsolltemperaturM2` float NOT NULL,
 KEY `timestamp` (`timestamp`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Die Tabellen der Datenbank „haus“:

CREATE TABLE `gaszaehler` (
 `timestamp` datetime NOT NULL,
 `zaehlerstand` float NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1

CREATE TABLE `stromzaehler` (
 `timestamp` datetime NOT NULL,
 `public_key` varchar(100) NOT NULL,
 `zaehlerstand` float DEFAULT NULL,
 `active_power` float NOT NULL,
 KEY `strom_index` (`timestamp`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

CREATE TABLE `strom_snapshot` (
 `zeitstempel` date NOT NULL,
 `zaehlerstand` float NOT NULL,
 `wirkleistung` float NOT NULL,
 `aktuelles_jahr` float NOT NULL,
 `aktueller_monat` float NOT NULL,
 `aktueller_tag` float NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1

CREATE TABLE `wasserzaehler` (
 `timestamp` datetime NOT NULL,
 `zaehlerid` int(11) NOT NULL,
 `zaehlerstand` float NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1

CREATE TABLE `wasser_snapshot` (
 `timestamp` date NOT NULL,
 `zaehlerstand` float NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1

„Installation“

Einen funktionierenden Webserver (z.B. Apache) mit PHP und eine MySQL oder MariaDB vorausgesetzt, muss das unten verlinkte tar.gz in ein beliebiges Verzeichnis im www-Verzeichnis des Webservers entpackt werden.

Das funktioniert mit 

tar -xvzf webseite_sensordaten.tar.gz

Konfiguration

In der Datei config.inc müssen ein paar wenige Einstellungen vorgenommen werden. Folgende Einstellungen werden für die Verbindung zur Datenbank benötigt:

$mysqlhost="<hostname>";
$mysqluser="<username>";
$mysqlpwd="<passwort>";
$mysqldbvito="<name_der_db_mit_den_vito_tabellen>";
$mysqldbhaus="<name_der_db_mit_den_haus_tabellen>";

Die folgenden Werte dienen der Auswertung des Gaszählers. Da dieser per Reed-Kontakt ausgelesen keinen Gesamtstand ausgibt und nur die einzelnen Impulse zählt, kann hier ein Startwert definiert. Auch die Werte zur Umrechnung von m³ in KW werden hier eingetragen. Diese Informationen gibt es beim Gaslieferanten.

Zudem kann noch definiert werden wie viel Tage in der Übersicht angezeigt werden sollen. Entsprechender Werte gibt es auch für den Wasserzähler und den Stromzähler.

$gas_startwert="2311650";
$brennwert_gas=10.097;
$zustandszahl_gas=0.9309;
$anz_tage_gas=7;

$anz_tage_wasser=7;

$anz_tage_strom=7;

Wichtiger und letzter Schritt: Das Verzeichnis „tmp“ muss schreibbar für den Webserver sein. Dort werden die generierten Graphen als PNG gespeichert. Das war es schon!

Fehlt nur noch das Paket mit den PHP-Seiten: webseite_sensordaten.tar.gz

Viel Spaß mit

Chris

Der Sensor kann zwei Partikelgrößen parallel messen:
– PM₁₀, inhalierbarer Feinstaub mit 10µm Durchmesser
– PM_2,5, lungengängiger (alveolengängiger) Feinstaub mit im Mittel 2,5 µm Durchmesser

Mehr zu diesem Thema gibt’s im Wikipedia-Artikel.

Also, Sensor bestellt und drei Wochen später ohne Zollprobleme frei Haus geliefert bekommen.

Der Sensor kommt mit USB-Adapter für den einfachen Anschluss am Odroid (oder auch am Raspberry Pi wie im Artikel beschrieben). Im Make-Artikel wird ein Shellscript vorgestellt, mit dem die Sensordaten gelesen und verarbeitet werden. Ich habe am Ende des Scriptes nur noch eine Zeile zum Speichern der Daten in meine MySQL-Datenbank eingefügt. D.h. nach 10 Minuten Bastelei lief schon alles…das war fast zu einfach. Das Script wurde dann alle 10 Minuten per Cron aufgerufen um die gemessenen Daten in meine MySQL-Tabelle zu schreiben. Der Lüfter des Sensors läuft bei dieser Lösung durchgehend (dazu unten mehr).

Jetzt konnte ich die Feinstaubbelastung im Heizungsraum bestimmen. Irgendwie musste der Sensor nun noch nach draußen. Da ich kein Loch in den Fensterrahmen bohren wollte, stellte sich das als Problem heraus.

Auf der Suche nach einer kabellosen Lösung und mit einem NodeMcu in der Schublade, bin ich nach kurzer Internet-Recherche auf die Webseite http://luftdaten.info aus Stuttgart gestoßen. Dort wird eine sehr einfache Selbstbaulösung zur Feinstaubmessung auf Basis des NodeMcu vorgestellt. Es werden verschiedenen Sensoren zur Feinstaubmessung und Temperatur- und Luftfeuchtemessung unterstützt. Unter anderem ist dort auch der im Make-Artikel verwendete SDS011-Feinstaubsensor integriert. Die Firmware gibt es als Bin auf der Webseite zum Download und die Quellen bei Github. Die Lösung mit den HT-Rohren als Gehäuse fand ich auch sehr gelungen und günstig. Das Aufspielen der Firmware, die Verkabelung und Verstauung der wenigen Teile im HT-Rohr sind in wenigen Minuten erledigt.

Nach Anschluss des NodeMcu an ein herkömmliches USB-Netzteil ist der NodeMcu als Access Point (AP) unter der Standardadresse http://192.168.4.1/ eines ESP8266 erreichbar. Dort können dann unter anderem die Zugangsdaten für das eigene Wifi-Netzwerk eingerichtet werden. Zudem können die angeschlossenen Sensoren ausgewählt werden sowie die Übertragung der ermittelten Daten an verschiedene Datenbanken z.B. zur Aufnahme in die Karte de/aktiviert werden. Hier gibt es auch die Möglichkeit eine API zur eigenen Verarbeitung der Daten anzusprechen. Das funktionierte bei mir leider nicht, so das ich im ersten Anlauf die vom NodeMCU generierte Webseite parsen musste um die Daten in meine MySQL-Tabelle zu speichern. Schon ein paar Tage später konnte man aber mittels der neuen Firmware (die OTA ausgeliefert wird, wenn aktiviert) die Sensordaten per JSON abfragen. Das ist komfortabler und zukunftssicherer als das Parsen der HTML-Seite.

Hier ein PHP-Beispiel zum parsen der JSON-Daten welches z.B. auch per Cron aufgerufen werden kann:

/data.json');
$json_ergebnis=json_decode($json);

$PM10=$json_ergebnis->sensordatavalues[0]->value;
$PM25=$json_ergebnis->sensordatavalues[1]->value;
?>

Die Lösung aus Stuttgart unterstützt den Sleep-Mode des Sensors der in der Lösung der Make nicht genutzt wurde. D.h. die Messung und der Lüfter werden nur alle ~30 Sekunden gestartet anstatt dauerhaft zu laufen. Das erhöht die Lebenserwartung des Sensors die mit 8000 Betriebsstunden angesetzt ist. Nach dem Sommer werde ich mal die Luftkammer des Sensors öffnen und schauen was sich dort so angesammelt hat.

Die mittels JSON in einer Datenbank gesammelten Daten werte ich auf meiner Webseite aus. Das schaut dann wie folgt aus (zweimal war der Sensor nicht aktiv):

Die Weltgesundheitsorganisation (WHO) hat folgende Richtwerte für Feinstaubgrenzwerte heraus gegeben:

Somit sind wir hier trotz plattem Land schon recht nah (bzw. darüber -> Tagesmittel PM_2,5) an den Werten der WHO dran.

Die Initiative aus Stuttgart zur einfachen Feinstaubmessung finde ich eine super Sache! Vielleicht findet sich ja noch der ein oder andere Nachbauer um die Karte zu füllen.

Gruß Chris

Einer der beiden Raspis soll nun dem neuen Odroid weichen. Dabei entschied ich mich für den zweiten Raspi, da die ganzen PHP-Scripte erstmal nicht anzupassen sind. Das scheint mir der meiste Aufwand zu werden.

Pi-Hole umziehen

Auch wenn „Pi“ im Namen steckt, läuft die Installation mit dem curl-Script auf den Odroid genauso problemlos wie auf dem Raspberry. Daher ist der Artikel über Pi-Hole auch für den Odroid soweit noch aktuell. Eine positive Anmerkung ist, das man neben den bereits vorkonfigurierten DNS-Servern aus der Installationsroutine, in der aktuellen Version von Pi-Hole jetzt auch die eigene Fritzbox als DNS in den Einstellungen der Pi-Hole-Oberfläche bequem eingeben kann. Damit entfällt die manuelle Anpassung in der Datei /etc/dnsmasq.d/01–pihole.conf.

Beim Aufbau der Pi-Hole-Oberfläche ist der Odroid auch spürbar schneller als der Raspberry Pi. Im Netz merkt man keinen Unterschied.

Das Script für den Gaszählers umziehen

Beim Gaszähler nutze ich ein Python-Script, welches die Schließimpulse eines Reed-Kontaktes mitzählt. Also einfach mal Pythonscript kopiert, gestartet und … Fehlermeldungen angeschaut! Das Python auf dem Odroid hat die von mir genutzte RPi.GIOP-Klasse angemeckert was auch verständlich ist. Auf dem Odroid muss das gegen WiringPi2 getauscht werden.

1. WiringPi 2 für Python installieren

git clone https://github.com/hardkernel/WiringPi2-Python.git
cd WiringPi2-Python
git submodule init
git submodule update

2. Bauen & Installieren

sudo python setup.py install

Das angepaßte Script zum Auslesen des Gaszählers schaut dann für den Odroid wie folgt aus:

[cc lang=“python“ tab_size=“2″ lines=“50″]
import wiringpi2 as wpi
import time
import MySQLdb
import sys

wpi.wiringPiSetupPhys()
# GPIO definieren
REED_gas = 21
# definierten GPIO als Eingang setzen
# 0 output, 1 input, 2 PWM mode
wpi.pinMode(REED_gas,0)

lt = time.localtime()
dateiname=“gaszaehler_“+time.strftime(„%Y%m%d“,lt) +“.log“

logger = open(dateiname,“w“)
logger.write(„gestartet…“+“\n“)
logger.close()

status_alt=1
while True:
try:
dateiname=“gaszaehler_“+time.strftime(„%Y%m%d“,lt) +“.log“
logger = open(dateiname,“a“)
status_aktuell = wpi.digitalRead(REED_gas)
# KONTAKT -> geoeffnet
if status_aktuell == 1:
#logger.write(„Kontakt offen“+“\n“)
status_alt=wpi.digitalRead(REED_gas)
# KONTAKT -> geschlossen
elif status_aktuell==0:
logger.write(„Kontakt geschlossen“+“\n“)
if status_alt!=status_aktuell:
logger.write(„Impuls“+“\n“ )
status_alt=wpi.digitalRead(REED_gas)
# Datenbankverbindung
db = MySQLdb.connect(host=““, user=““, passwd=““, db=““)
# Impuls in Datenbank eintragen
cursor = db.cursor()
cursor.execute(„““INSERT INTO gaszaehler (timestamp,zaehlerstand) VALUES (CURRENT_TIMESTAMP,1)“““)
db.commit()
cursor.close()
logger.close()
except:
e = sys.exc_info()[0]
dateiname=“gaszaehler_“+time.strftime(„%Y%m%d“,lt) +“.log“
logger = open(dateiname,“a“)
logger.write(„Es ist ein Fehler aufgetreten: %s“ % e)
logger.close()
time.sleep(1)
[/cc]

Neben WiringPi habe ich auch die Verbindung zur DB in die while-Schleife gepackt. Vorher wurde die Verbindung einmal am Anfang hergestellt und in der Schleife nur noch die Daten per Insert eingetragen. Es zeigt sich aber, das der Odroid oder die Datenbank die noch auf dem anderen Pi läuft die Verbindung nach einer Zeit kappt und es zu Fehlern kam. Auch das Logging habe ich etwas abgeändert, da während das while lief nur Blockweise wenn gerade Zeit war in die Datei geschrieben wurde. Das störte bei der Fehlersuche.

Hier auch nochmal die Pinbelegung des Odroid C2 und deren Zusammenhang mit den PinModes von WiringPi2:

Das war es schon für die Anpassungen des Scriptes für den Gaszähler. Bei diesem Script gibt es keine Performanceunterschiede im Vergleich wenn es auf dem Raspi lief.

Das Script für den Wasserzähler umziehen

Als nächstes kam der Wasserzähler mit M-BUS an die Reihe. Hier habe ich mir die Quellen in der Version 0.8.0 von rScada gezogen und anschliessend versucht diese zu bauen. Dies führte schon beim ./configure zu Fehlermeldungen. Die Quellen waren zu alt und konnten die Prozessorarchitektur des Odroid (ARM) nicht ermitteln. Um das zu beheben benötigt man aktuelle Versionen der Dateien config.guess und config.sub. Diese sind unter den beiden folgenden Links zu finden.

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

Die beiden Dateien einfach gegen die bereit vorhanden ersetzen und ./configure läuft durch. make und make install laufen dann auch fehlerfrei durch wie im Artikel beschrieben.

Die Pins zum zum Anschluss des M-BUS-Master (Tx & Rx) sind gleich belegt wie auf dem Raspberry.

Die Scripte von rScada funktionieren identisch wie vorher. Mit mbus-serial-scan wurde der Wasserzähler auf fehlerfrei erkannt. Leider scheiterte anschliessend der Versuch mit mbus–serial–request–data die Daten aus dem vorher erkannten Zähler auszulesen. Nahc den ersten ausgelesenen Bytes verabschiedete sich mbus–serial–request–data mit einem Segmentation Fault. In den Systemlogs war nicht wirklich rauszufinden warum dem so ist. Nach ein kurzer Analyse dachte ich ein Versuch mit der vorherigen Version 0.7.0 kann nicht schaden. Damit tat es dann auch fehlerfrei. Was nun genau das Problem des Segfaults war, weiß ich nicht. Die Unterschiede zur Version 0.8.0 sind auch anscheinend nicht relevant da alles wie gewünscht funktioniert.

Soviel zu den ersten beiden „Umzügen“. Fehlen noch der DVB-S Empfänger mit tvheadend und dann geht´s schon an die Dinge die aktuell noch auf dem anderen Raspberry Pi laufen.

Gruß

Chris

Die Tage habe ich ein neues Spielzeug bekommen (nein, nicht zu Weihnachten). Es ist ein Odroid C2 mit eMMC-Speicherkarte. Den gab es im Komplettpaket mit Odroid, eMMC, Gehäuse und Netzteil für 70€. Der Odroid besitzt einen Quad-Core mit 1,5 GHz, 2 GB RAM und ein Gigabit-LAN welches er sich, im Gegensatz zur Raspberry-Architektur, nicht mit den USB-Ports teilen muss. Somit sollte die Gesamtleistung in allen Belangen deutlich höher ausfallen als die des Raspberry 2 oder 3. Auf der eMMC war ein Ubuntu 16.04 LTS mit Mate Desktop vorinstalliert.

Schneller Test versus schlampige Programmierung

Ein erster schneller Test sollte die Geschwindigkeitsmessung bei der Anzeige meiner Intranet-Seite für die mitgeloggten Daten (Temperaturen, Gasverbrauch, Stromverbrauch, …) sein. Die Tabellen sind in den letzten 3 Jahren teilweise doch recht groß geworden und der Raspberry 2 tut sich mit der Anzeige der ein oder anderen Auswertung merklich schwer. Zum Beispiel dauert die Abfrage des wöchentlichen Wasserverbrauches rund 38 Sekunden…nichts für ungeduldige Gemüter.

Also MySQL, Apache und PHP installiert. Dabei ließ sich MySQL nach der Installation nicht starten. Da scheint es einen bekannten Fehler zu geben. Ich habe mich dann einen halben Tag mit Versuchen rumgeschlagen es ans laufen zu bekommen. Letztendlich habe ich mich dann geschlagen gegeben und MariaDB installiert. MariaDB funktionierte auf Anhieb inkl. des Datenimportes der Daten aus der MySQL-Datenbank des Raspberrys. Die Installation von Apache und PHP 7 funktionierte auf Anhieb. Dann die PHP-Scripte auf den Odroid kopiert, einen Browser geöffnet und … nichts gesehen außer einer weißen Seite. Nach kurzem Blick in das Apache-Log dann die Ernüchterung: Einfach die Scripte kopieren ist nicht, da ich in der Vergangenheit schlampig programmiert hatte. So unterstützt PHP 7 unter anderem nur noch MySQLi (i wie improved). So hatte ich mir das nicht vorgestellt, aber es ist ein guter Anlass um den kompletten Code zu überarbeiten. Und ein Downgrade auf PHP 5.x ist wohl auch keine Alternative mehr.

Code-Korrektur

Um trotzdem die Geschwindigkeit testen zu können, habe ich die Seite zur Anzeige des wöchentlichen Wasserverbrauches PHP 7-tauglich gemacht. In dieser Seite wird eine kleine Datenbanktabelle mit ~ 700 Zeilen ausgelesen (den Wasserzähler habe ich noch nicht so lange). Die beiden SQL-Statements die im Script verwendet werden sehen folgendermaßen aus:

Folgendes Select liest den Gesamtzählerstand aus:

SELECT zaehlerstand FROM wasserzaehler

Das etwas länglichere Select liest den Verbrauch der letzten 7 Tage, gruppiert nach Wochentag, aus:

SELECT
CASE DATE_FORMAT(wz1.timestamp,'%w')
WHEN 0 THEN 'Sonntag'
WHEN 1 THEN 'Montag'
WHEN 2 THEN 'Dienstag'
WHEN 3 THEN 'Mittwoch'
WHEN 4 THEN 'Donnerstag'
WHEN 5 THEN 'Freitag'
WHEN 6 THEN 'Samstag'
ELSE 'fehler' END,
wz1.zaehlerstand - IFNULL(wz2.zaehlerstand, 0) AS verbrauch
FROM wasserzaehler wz1
LEFT JOIN wasserzaehler wz2
ON wz2.timestamp = (
SELECT MAX(timestamp) FROM wasserzaehler wz3 WHERE wz3.timestamp < wz1.timestamp
)
WHERE DATE(wz1.timestamp) >= DATE_SUB(NOW(),INTERVAL 7 DAY) GROUP BY day(wz1.timestamp)
ORDER BY wz1.timestamp";

Das Ergebnis ist eine Übersicht des Gesamtverbrauch und des Wasserverbrauches der letzten 7 Tage:

Warpgeschwindigkeit

Der Raspberry 2 benötigt bis zur Anzeige dieser Seite geschlagene 38 Sekunden. Der Odroid etwas mehr als 1 Sekunde! Diesen eklatanten Geschwindigkeitsunterschied hätte ich nicht erwartet. Allerdings weiß ich auch nicht, was den Raspberry bei der Auswertung dieser kleinen Tabelle genau überfordert. Es ist jedenfalls mal ein dicker Pluspunkt für den Odroid. Mal sehen wie er sich mit den anderen Abfragen schlägt sobald ich die restlichen PHP-Scripte angepasst habe.

Das wird allerdings neben der PHP-Problematik noch ein steiniger Weg werden, da ich die komplette FHEM-Implementierung irgendwie vom Raspberry auf den Odroid bekommen muss. Problem ist dabei wahrscheinlich weniger FHEM selber, sondern die COC-Hardware die auf den GPIOs des Raspberry sitzt und die GPIOs des Raspberry nicht kompatibel mit denen des Odroid sind. Dazu aber mehr, wenn es soweit ist.

Nebenbei habe ich bei dieser Gelegenheit auch noch kurz den Leistungsmesser dazwischen gehangen. Im Leerlauf (die Abfrage des Wasserzählers kann man nicht als mehr bezeichnen) konsumiert der Odroid etwa 3 Watt.

Gruß Chris