Kleine Probleme

Einzig meine gewohnte Freiluftverdrahtung mit einem Gummi der den Reedkontakt am Zähler festhält (der die Klebeband-Halterung ablöste) wurde regelmäßig porös und der Reedkontakt fiel runter. Meistens merkte ich das erst Tage später. Da ich mir Ende letzten Jahres einen 3D-Drucker angeschafft habe, wollte ich bei diesem Projekt mein erstes ordentliches Gehäuse für meine Sensoren erstellen wo mal nichts irgendwo einfach nur herum baumelt.

Bei Makerworld, Printables & Co gibt es sehr viele fertige Modelle für entsprechende Halterungen. Danke an die kreativen Designer! Manche sind für den NodeMCU inklusive Reedkontakt, manche für einen Wemos D1 inklusive Reedkontakt und manche nur für verschiedene Reedkontakte alleine. Ich habe ein Gehäuse für beides gesucht. Nachdem ich ein passendes Model gefunden und ausgedruckt hatte, ging es an die Montage. Die meisten dieser fertig designten Gehäuse nutzen einen axialen Reedkontakt. Diese haben meistens nur einen simplen Glaskörper. Hier war schon mein erstes Problem das diese Glasreeds echt empfindlich sind wenn man mal an den Beinchen biegt. Ich bin wahrscheinlich zu grobmotorisch aber sie sind ja billig…

Das größere Problem war aber, dass diese Reedkontakte nicht oder unzuverlässig anziehen wenn der Magnet des Zählers vorbei kommt da dieser recht schwach ist (Stichwort Anzugsempfindlichkeit). Auch hundertmaliges Ausrichten in der Öffnung des Zählers, Ausrichten des Reedkontaktes parallel zum Magneten, testen verschiedene andere Reedkontakte (aus zylinderförmig eingegossene Exemplare) etc. war nicht zielführend und raubte mir den letzten Nerv weil alles ja schon mal gut funktionierte. Nur mein alter Meder MK471 funktionierte zuverlässig.

Das neue Gehäuse

Der MK471 passt aber in fast alle fertigen Gehäusedesigns nicht rein. Und die wenigen Gehäuse die den MK471 beherbergen können, passten nicht an meinen Gaszähler. Also hab ich mir ein schönes Gehäuse für den Wemos D1 Mini als Basis gesucht und mit FreeCad (ich komme mit dem 3D-Drucker eh nicht drumherum das zu lernen) entsprechende Anpassungen gemacht damit anstatt einem axialen Reedkontakt der MK471 rein passt. Das war nicht wirklich schwer und sehr viel Mühe hab ich auch nicht rein gesteckt. Die STL-Datei muss in Freecad einen Festkörper gewandelt werden und danach einfach die Aufnahme für den axialen Reedkontakt mittels „Pocket“ mit einem passenden Rechteck aus dem Sketch „durchbohrt“. Da klemmt sich der MK471 jetzt ohne Probleme fest.

Neue Softwareversion

Neben dem Gehäuse hab ich dann doch noch ein bisschen den Quellcode erneuert. Ich musste ja noch die LED die im Gehäuse vorgesehen ist einprogrammieren. Bisher blinke nur die interne LED des Mikrocontrollers. Aber die sieht man ja im Gehäuse nicht mehr. Dazu gab es noch ein paar andere kleine Korrekturen und Verbesserungen. Die LED muss mit Vorwiderstand an D3, der Reedkontakt bleibt wie gehabt an D4 wo jetzt per Software auch der interne Pullup aktiviert wird. Einen Plan für die Verdrahtung hab ich dafür hier nicht gemacht.

Aber wirklich schlecht implementiert hatte ich das Senden der Impulse an den MQTT-Server. Hier hatte ich bei jedem Impuls eine neue Verbindung zum Server geöffnet und dann das Publish gesendet. Das dauerte gefühlt immer ewig und war auch der Grund warum in der Vergangenheit der ein oder andere Impuls in Richtung MQTT verschluckt wurde.

Der neue Ansatz baut nun einmal bei Start die Verbindung zum MQTT auf, prüft im Loop ob diese Verbindung noch besteht und macht ggf. ein Reconnect. Bei einem Impuls durch den Reedkontakt wird dann nur noch der Impuls per Publish an den MQTT-Server gesendet. Viel besser

Den aktuellen Quellcode für die Version 1008 inkl. vorkompiliertem Binary gibt es wie immer auf Github:

https://github.com/diefenbecker/opengasmeter

Viel Spaß damit
Gruß Chris

Hier findet ihr das Github-Repository: https://github.com/diefenbecker/zisternenmessung

Aber auch bei den Funktionen gibt es Neuigkeiten. Die Version 1030 unterstützt jetzt einen schaltbaren Ausgang an D4 mit dem z.B. eine Pumpe über eine Relais-Platine angesteuert werden kann. Gesteuert wird das über zwei prozentuale Werte die in der Konfigurationsseite zu finden sind.

Hier die bin-Datei zum direkten Download:

http://www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin

Viel Spaß damit! Das kommende Wochende verspricht wettertechnisch ja den Einsatz der Zisterne…

Gruß

Chris

In der Webseite der Software kann in den Einstellungen zwischen den beiden Sensoren gewählt werden. Neu ist zudem noch der frei wählbare Name für den Sensor welcher auf der Sensor-Webseite oben links angezeigt wird. Hiermit kann man nun beim Einsatz mehrerer Sensoren in verschiedenen Zisternen unterscheiden oder auch einen Öltank-Füllstandssensor korrekt benennen.

Der ToF-Sensor besitzt eine I2C-Schnittstelle und wird an die gleichen PINs wie der Ultraschallsensor angeschlossen. Es geht aber nicht mit beiden Sensoren parallel, sondern nur der eine oder der andere!

Der ToF-Sensor wird wie folgt angeschlossen:

Die beiden übrigen Anschlüsse bleiben frei.

Hier gibt es die neue Version zum Download:
http://www.bubux.de/heimautomatisierung/ota/zisterne_1028.bin

Hier findet ihr die vorherigen Artikel zur Zisterne mit den grundlegenden Anleitungen und Anschlussschema.

Gruß
Chris

Hier gibt es die aktuelle Version zum Download:
http://www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin

Zur Installation etc. bitte wieder in die älteren Artikeln schauen!

Das Update enthält unter anderem:

• DHT22-Temperatur-Sensor an D5 (statt des bereits durch das Display genutzten D6)
• Darstellung der Werte auf der Webseite nicht mehr als TABLE sondern als DIV-Boxen damit es auf kleinen Displays auch besser passt
• Bei Erstinstallation und Einrichtung des WLAN per Access Point wird nur die Konfiguration der WLAN-Daten angezeigt was hoffeltnlich das Problem mit dem „fehlenden“ Speicher-Button beseitigt. Hier wäre ich über Erfahrungen dankbar!
• TITLE-Tag eingebaut
• ein paar Kleinigkeiten…

Hier das Schaubild der aktuellen Verdrahtung. Bei Ultraschallsensor, Display und Schalter bleibt alles wie gehabt. Der DHT22 kommt nun an D5 damit dieser mit dem Display parallel betrieben werden kann.

Die Weboberfläche ist durch die Verwendung der DIVs anstatt TABLE nun auch auf kleinen Display (z.B. Handy) besser dargestellt und die Boxen passen sich der Breite des Bildschirms an.

Dann möchte ich nochmal allen Danken die etwas gespenden haben. Das Geld ging wie immer an Bärenherz in Wiesbaden.
Viel Spaß mit der neuen Version. Der Frühling ist ja schon im Anmarsch und die Zisterne muss für das sommerliche Bewässern startklar werden!

Gruß
Chris

• Eine weitere Zisternenbauform (liegender Zylinder)
• Temperatur- und Luftfeuchterfassung mittels DHT22
• Literanzahl, Temperatur und Luftfeuchte mit in die MQTT-Topics aufgenommen

Falls ein Temperatursensor angeschlossen und aktiviert ist, werden dessen Messwerte auf der Startseite angezeigt. Die Anzeige der Temperaturdaten wird alle 60 Sekunden abgefragt und zeigt daher im ersten Moment nach Neustart keine Werte an.

Aktuell kann als Temperatursensor ein DHT22 genutzt werden (weitere Sensoren sind in Arbeit). Aktiviert wird der Sensor in der Konfiguration.

Die neuen MQTT-Topics können ebenfalls in der Konfiguration hinterlegt werden.

Die neue Zisternenbauform ist auch in der Konfiguration zu finden. Die Berechnung funktioniert bei einer runden liegenden Zisterne. Eine ovale Form wird aktuell nicht unterstützt.

Hier gibt es die aktuelle Version zum Download:
http://www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin

Für den genauen Aufbau (Anschluss Sensor, Anschluss Diplay etc.) bitte die vorherigen Artikel beachten.

Dann euch noch einen guten Rutsch ins neue Jahr!

Gruß

Chris

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

Heute ein kleines Update für die Füllstandsmessung der Zisterne mittels Ultraschall und dem ESP8266.

In der neuen Version v1016 gibt es jetzt eine Abfragemöglichkeit der gemessenen Werte mittels JSON.

Dazu einfach /json hinter die Web-Adresse eures ESP hängen (z.B. http://zisterne/json). Folgende Werte werden aktuell übermittelt:

Hier der Link zum aktuellen BIN: www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin. Im vorherigen Artikel werden die restlichen Funktionalitäten und das Flashen auf den ESP erklärt.

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

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