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

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

Die Anzeige aller im Haus gesammelter Daten über eine Webseite ist nett (siehe Screenshot), benötigt aber einen Rechner, Handy, Tablet etc. wo diese Seite im Browser anzeigt wird. Unschön dabei ist, das wenn man schnell die Außentemperatur wissen will, immer erst das Gerät anschalten oder aufwecken muss, einen Webbrowser öffnen muss, die Webseite aufruft und wartet bis die Seite geöffnet wird. Das ist für einen kurzen Blick auf die Temperatur eher unpraktisch.

Es musste eine Anzeigemöglichkeit für die wichtigsten Daten her, welche immer angeschaltet ist. Nach kurzer Recherche im Internet stellte sich ein Amazon Kindle als Statusdisplay aufgrund des E-Paper-Displays als stromsparender Anwärter auf diesen Job heraus. Also schnell einen Kindle 4 (kein Touch) im Internet für ~ 30€ besorgt (da ich bisher keinen besaß).

Lösungsansätze

Es gibt verschiedene Ansätze den Kindle als Statusdisplay (z.B. für Wetterinformationen) zu nutzen. Es gibt Lösungen wie hier beschrieben die den Browser des Kindle nutzen. Besser gefielen mir aber die Lösungen die den Bildschirmschoner des Kindle zur Anzeige eines Statusbildes nutzen. Das macht unter anderem die Lösung für FHEM, als auch die Lösung von Matthew Petroff (von dem die FHEM-Lösung wahrscheinlich auch abgeleitet ist). Basierend auf dieser Lösung ist ausserdem diese hier mit weiterführenden Erklärungen der nötigen Schritte.
Ich bevorzuge anstelle der FHEM-Lösung die ursprüngliche Version, da ich nicht nur Daten aus FHEM anzeigen will, sondern auch Daten aus meiner MySQL-Datenbank und zusätzliche Informationen die direkt aus dem Internet stammen.

Den Kindle habe ich übrigens mittels „Kindersicherung“ der FritzBox vom Internet gekappt falls Amazon auf komische Gedanken kommt und mir mit einem gutgemeinten Online-Update irgendwas zerschießt.

Die Lösung, den Bildschirmschoner des Kindle mit einem im Netzwerk bereitgestelltem Bild zu nutzen, benötigt verschiedene Anpassungen des Kindle als auch einige Komponenten die auf einem Server bereit gestellt werden müssen (bei mir der Raspberry PI).

Beschreibung

Die Beschreibung der nötigen Schritte und die benötigte Software sind hier (ursprüngliche Idee), hier (erweiterte Anleitung) und hier (ausführliche Anleitung) erklärt. Aus diesem Grund liste ich die nötigen Arbeitsschritte hier nur Stichpunktartig auf:

Kindle:

• Jailbreak des Kindle damit man damit auch anständig arbeiten kann
• SSH für Kindle (USBNetwork Hacks)
  • Root-Passwort für den Kindle ermitteln
• Kite installieren um nach dem Starten des Kindle das Init-Script (init_daten.sh) ausführen zu lassen
  • Stoppen von powerd
    • das ist nötig, da im Sleep-Mode der Cronjob nicht ausgeführt wird
    • („@reboot“ in crontab funktioniert leider auf dem Kindle nicht)
  • Stoppen von framework
• Cronjob einrichten um alle x Minuten/Stunden ein aktualisiertes Bild per wget zu laden
  • vi /etc/crontab/root
  • */10 5-22 * * * /mnt/us/anzeige/zeige_daten.sh (alle 10 Minuten zwischen 5 und 22 Uhr

Server:

• Python-Script anpassen
  • Das Python-Script sammelt die Daten, ersetzt die Platzhalter im SVG und erstellt daraus das PNG mittels rsvg-convert und pngcrush
• Cronjob zur Ausführung des Python-Script anlegen
  • */3 * * * * /var/www/kindle/daten-script.sh &> /dev/null
• SVG-Template anpassen (mit Editor und/oder Inkscape)
  • hier mein SVG für die Datenanzeige und
  • hier für zwischen 23 und 5 Uhr
  • bei Änderungen mit Inkscape nicht im „Inkscape-Format“ abspeichern sondern als „Normales SVG“
• rsvg-convert installieren (sudo apt-get install librsvg2-bin)
• pngcrush installieren (sudo apt-get install pngcrush)

(Achtung! Die Dateinamen der Scripte in den Cron-Beispielen und die Dateinamen der SVG´s sind anders als in den oben verlinkten Anleitungen)

Python-Script

Das ursprüngliche Python-Script holt das Wetter von einer Webseite aus den USA. Das Wetter dort hat mich nicht wirklich interessiert und so habe ich das Script etwas angepaßt und verschiedene Wetterdaten und Statusinformationen aus meinen eigenen Quellen (FHEM und MySQL) gezogen.
Zur Anzeige der Wettericons nutze ich teilweise die Bilder aus dem ursprünglichen SVG. Einige habe ich allerdings gelöscht da ich hier z.B. keinen Blizzard erwarte. Die Werte für den Luftdruck und die Windstärke sowie die Auswahl des aktuellen Wetter-Icon erfolgt über die „condition“ des FHEM-Yahoo-Wetter-Moduls.

Mein Pythonscript sieht wie folgt aus:

Bitte das Update im nachfolgendem Artikel beachten!!

#!/usr/bin/python2

import codecs
import telnetlib
import MySQLdb
from datetime import datetime, time

################
# Hole FHEM data
################
tnet_host= "localhost"
tnet_port= 7072
def fhem_task(fcmd):
    tc= telnetlib.Telnet(tnet_host,tnet_port)
    tc.write(fcmd)
    erg= tc.read_until( "\n" )
    tc.close()
    return erg

# Abwesenheit
if "off" in fhem_task("list ABWESENHEIT STATE\r\n"):
    abwesenheit="nicht gesetzt"
if "on" in fhem_task("list ABWESENHEIT STATE\r\n"):
    abwesenheit="gesetzt"

# Fenster
anz_fenster_offen=0;
if "open" in fhem_task("get FensterHeizung param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterKeller param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterGaestezimmer1 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterGaestezimmer2 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterBuero1 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterBuero2 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterWohnen1 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterWohnen2 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterWohnen3 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterWohnen4 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterGaestebad param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterSpind param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get FensterBad1 param STATE\r\n"):
    anz_fenster_offen += 1
if "open" in fhem_task("get Garagentor param STATE\r\n"):
    stat_garage="offen"
else:
    stat_garage="geschlossen"

# Wetter
try:
    condition=str.split(fhem_task("get MeinWetter condition\r\n"))
    if len(condition)==5:
        wetter_icon=condition[3] + " " + condition[4]
    else:
        wetter_icon=condition[3]
except:
    wetter_icon="Fehler"


luftdruck=str.split(fhem_task("get MeinWetter pressure\r\n"))
tendenz=str.split(fhem_task("get MeinWetter pressure_trend_txt\r\n"))
wind=str.split(fhem_task("get MeinWetter wind_speed\r\n"))

####################
# Datenbank auslesen
####################
db = MySQLdb.connect(host="localhost", user="", passwd="", db="")        		
cur = db.cursor()
cur.execute("SELECT MIN(aussentemperatur), MAX(aussentemperatur) FROM temperaturen WHERE timestamp >= DATE(NOW()) ORDER BY timestamp")
for row in cur.fetchall():
    mintemp=round(row[0],2)
    maxtemp=round(row[1],2)

db.close()


################
# Preprocess SVG
################
now = datetime.now()
now_time = now.time()
if time(5,50) <= now.time() <= time(22,50):  
    # Open SVG to process
    output = codecs.open('daten_script_preprocess.svg', 'r', encoding='utf-8').read()
    # Insert icons and temperatures
    output = output.replace('ICON_ONE',wetter_icon.decode("utf-8"))
    output = output.replace('WETTER_BESCHR',wetter_icon.decode("utf-8"))
    output = output.replace('TEMP_A',fhem_task("get Aussenthermometer param temperature\r\n"))
    output = output.replace('LUFT_A',fhem_task("get Aussenthermometer param humidity\r\n"))
    output = output.replace('MIN_TEMP',str(mintemp))
    output = output.replace('MAX_TEMP',str(maxtemp))
    output = output.replace('DRUCK_A',luftdruck[3])
    output = output.replace('TENDENZ',tendenz[3])
    output = output.replace('WIND_A',wind[3])
    output = output.replace('ANZ_FENSTER',str(anz_fenster_offen))
    output = output.replace('STAT_ABWESENHEIT',abwesenheit)
    output = output.replace('STAT_GARAGE',stat_garage)
    output = output.replace('DATUM_UHRZEIT',datetime.strftime(datetime.now(), '%d.%m.%Y %H:%M:%S'))
    # Write output
    codecs.open('daten_script_output.svg', 'w', encoding='utf-8').write(output)
else:
    # Open SVG to process
    output = codecs.open('sleep_preprocess.svg', 'r', encoding='utf-8').read()
    output = output.replace('DATUM_UHRZEIT',datetime.strftime(datetime.now(), '%d.%m.%Y %H:%M:%S'))
    # Write output
    codecs.open('daten_script_output.svg', 'w', encoding='utf-8').write(output)

Es werden verschiedene Information aus FHEM mittels Telnet abgefragt und Daten aus einer MySQL-Datenbank (min/max-Werte) ermittelt. Neben Temperaturwerten zeige ich z.B. auch noch den Status der Fenster, des Garagentores und der Abwesenheitssteuerung an. Zwischen 5:50 und 22:50 Uhr wird alle 10 Minuten ein aktualisiertes Bild der Statusinformationen angezeigt, in der anderen Zeit ein Bild eines schlafenden Männchens. In dieser Zeit fragt der Kindle auch kein neues Bild per wget ab.

Ergebnis

Im Ergebnis schaut es dann so aus:

Und hier die Anzeige für Nachts:

Als Erweiterung werde ich evtl. noch während der Heizperiode mit dem Kachelofen oder abhängig der Puffertemperatur, die obere und untere Temperatur des Pufferspeichers anstelle des Luftdruckes und der Windinformation anzeigen. Die Puffertemperatur ist in der Regel unser Maßstab ob Holz nachgelegt werden muss oder nicht.

Es könnte z.B. auch eine Display füllende Information ausgegeben werden wenn eine der Batterien der Fensterkontakte leer ist oder ein Warnhinweis falls die Heizung eine Störung oder anstehende Wartung anzeigt. Im Python-Script würde ich dann analog dem "Schlaf-Bild" ein spezielles PNG aus einem weiteren SVG erzeugen.
 

Chris

Die Wiedergabe ist nun absolut synchron auf der Musicbox Air von Canton und dem Kodi-Wohnzimmer PC!

Auch wenn ich es in dem ersten Multiroom-Artikel nur als „nice-to-have“ bezeichnet habe, hat mich das Problem mit der asynchronen Wiedergabe bzw. dem hochwahrscheinlichen Auseinanderdriften doch nicht in Ruhe gelassen.

Synchrones Multiroom

Martin, der Entwickler der App „AirAudio“ hat mich dann von sich aus dankenswerterweise darauf hingewiesen, das die aktuelle Airplay-Implementierung von Kodi keine Audio-Synchronisierung unterstützt. Solange dem so ist, werden alle meine Versuche bzgl. einer synchronen Wiedergabe auf dem mit Kodi-betriebenen Wohnzimmer-PC scheitern – und das unabhängig vom Zuspieler! Also auch die Nutzung von Whaale hätte kein Unterschied gemacht.

Statt der Airplay-Implementierung von Kodi selbst, sollte ich shairplay-sync als AirPlay-Abspieler auf dem Wohnzimmer-PC installieren. Bei shairplay-sync handelt es sich um ein Fork von shairplay. shairplay-sync unterstützt aber zusätzlich die Implementierung der synchronen Audiowiedergabe mittels Airplay.

Für die Installation von shairplay-sync gibt es neben den GIT-Quellen auch ein Paket für verschiedene Linux-Versionen. Da ich beim Wohnzimmer-PC (immer noch) ein Ubuntu 14.04 LTS nutze, konnte ich die Installation mittels PPA durchführen, da hiefür ein Paket bereitgestellt wird. Bei einem Raspberry kann bei der Installation z.B. nach der Anleitung von mikebrady Verfahren werden.

Installation von shairplay-sync

Mit folgendem Befehl werden die von dantheperson bereitgestellten Paketquellen von shairplay-sync im Ubuntu hinzugefügt:

sudo add-apt-repository ppa:dantheperson/shairplay-sync

Das Update der Paketquellen und die eigentliche Installation erfolgt dann wie folgt:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install shairport-sync

Die Konfig-Datei von shairport-sync ist nach erfolgreicher Installation im Verzeichnis etc zu finden. Hier müssen ggf. noch ein paar Anpassungen vorgenommen werden.

sudo vim /etc/shairport-sync.conf

In der Konfig-Datei kann z.B. unter general der Name des „AirPlay-Gerätes“ konfiguriert werden.

Audiogerät und -Ausgang ermitteln

Wichtiger sind aber die Einstellungen unter dem Punkt alsa. Hier muss das Device für die Audioausgabe eingetragen werden. So musste ich z.B. schauen, das der S/PDIF-Ausgang genutzt wird.

alsa =
{
    output_device = "hw:0,1";
    mixer_control_name = "PCM";
    mixer_device = "hw:0";
//  audio_backend_latency_offset = 0;
//  audio_backend_buffer_desired_length = 6615;
};

Die entsprechende Hardware für output_device kann über den Alsamixer herausgefunden werden:

alsamixer

Mit F6 werden alle im System verfügbaren Soundkarten angezeigt. Bei mir ist das HDA Intel mit der Nummer „0“. (Ich denke, das die Grafikkarte „1“ hier auch wegen der möglichen Audioausgabe über HDMI angezeigt wird).

Nun fehlt noch der passende Audioausgang. Dazu mit F2 in den im Bild gezeigten Dialog und den Eintrag mit „devices“ auswählen.

Im Ergebnis werden alle Audio-Geräte inklusive den vorhandenen Schnittstellen wie S/PDIF oder Klinke ausgegeben. Leider wird dieser Unterschied (zumindest bei mir) nicht in der Übersicht angezeigt.

Also heißt es ausprobieren. Es sind ja nur zwei Möglichkeiten geblieben da das eigentliche Gerät mit „0“ ja schon bekannt ist. Bleibt in der shairplay-sync-Konfiguration unter output_device nur noch hw:0,0 oder hw:0,1 zu testen. In meinem Fall war der S/PDIF-Ausgang hw:0,1. Die Mixer-Kontrolle ist unter 6 zu finden und in der Konfiguration entsprechend mit hw:0 anzugeben.

Andere Einstellungen habe ich in der Konfiguration nicht verändert. Evtl. paßt aber auch abhängig von der Hardware schon die Default-EInstellung und es sind keine Änderungen an der Konfiguration von shairplay-sync nötig.

Die nötigen Einstellungen können zum Testen auch direkt beim manuellen Start von shairplay-sync mittels Argument mitgegeben werden. Dazu erstmal ein bereits laufendes shairplay-sync mit folgendem Befehl stoppen:

sudo shairport-sync -k

Folgender Aufruf beinhaltet u.a. die von mir angepaßten Parameter:

sudo shairport-sync -vvv -a "Wohnzimmer" -d hw:0,1 -m hw:0 -c PCM

-v schreibt Debuginformationen zur Analyse von Problemen. -vv oder -vvv gibt mehr Informationen preis.
-a definiert den im AirPlay-Zuspieler angezeigten Namen
-d definiert das Gerät zur Audioausgabe. Hier kann dann mit dem im alsamixer gefundenen Geräten experimentiert werden
-c definiert den zu nutzenden Mixer. Dieser gehört in der Regel zum genutzten Gerät.

Eine komplette Liste aller Parameter von shairport-sync ist in der Hilfe oder in den man-Pages zu finden.

shairport-sync -h

man shairport-sync

Ergebnis

Im Ergebnis bin ich nun sehr zufrieden mit meiner Multiroom-Lösung. Neben den schon im ersten Artikel gut funktionierenden Punkten, kam jetzt das absolut synchrone Abspielen auf mehrere Lautsprecher hinzu. Die ganze Lösung ist immer noch sehr anwenderfreundlich. Fehlt mir jetzt noch ein kleiner portabler AirPlay-Lautsprecher für die Terrasse.

Vielen Dank nochmal an Martin von AirAudio für die sehr gute und schnelle Unterstützung!

Gruß
Chris

Gut, alleine mit dem Kauf des Canton-Lautsprechers war ich noch weit weg von Multiroom. Irgendwie muß „Multiroom“ in meiner bereits vorhandenen Infrastruktur umgesetzt werden. Diese besteht aus einem mit Kodi betriebenem Wohnzimmer-PC und daran angeschlossenem 5.1 Receiver mit 5 Lautsprechern.

Was bedeutet Multiroom?

Für den einen bedeutet Multiroom die Wiedergabe der gleichen Tonquelle auf beliebig vielen Lautsprechern. Oder aber auch die Wiedergabe verschiedener Quellen auf einzelne Lautsprecher oder auch gruppiert auf unterschiedliche Lautsprecher.

Multiroom ist aber auch die Möglichkeit zur Auswahl der Wiedergabe von einer Tonquelle auf einem bestimmten Lautsprecher. Im ersten Anlauf tendiere ich zu diesem Ansatz, da ich nicht das komplette Haus beschallen muss und mich meistens in einem Raum aufhalte.

Die verschiedenen Hersteller wollen natürlich auch alle ein Stück vom Kuchen den Sonos mit seiner „PLAY“-Reihe angeschnitten hat und beschert dem Markt verschiedenen Mutliroom-Lösungen. Neben Sonos wäre da z.B. Teufel mit seiner Raumfeld-Reihe, Denon mit „HEOS“, Yamaha mit MusiCast und vielen mehr zu nennen.

Da ich im Wohnzimmer mit einem Denon-Receiver und den ELAC-Lautsprechern schon eine vernünftige Basis habe, schied für mich ein neues Komplettset der oben genannten Kandidaten aus. Ausser der Raumfeld-Reihe haben die meisten Multiroom-Sets auch eher „Plastik-Charm“, weshalb ich die ELAC-Lautsprecher bevorzuge.

Bedeutet Multiroom synchrone Musikwiedergabe?

Im Fall der oben beschriebenen Multiroom-Lösungen sollte der Ton schon synchron aus den Lautsprechern kommen. Schliesslich soll damit unter anderem auch 5.1/7.1/usw. umgesetzt werden. Das erledigt bei mir der Denon-Receiver ja schon. Bleibt noch die Synchronität zwischen Lautsprechern die z.B. in verschiedenen Räumen aufgestellt sind. Primär die Räume, die auch „akustisch verbunden“ sind. Das war erstmal nicht mein Ziel, da es mir im ersten Anlauf um die Beschallung des Wohnzimmers oder der Küche basierend auf der Musikdatenbank des Wohnzimmer-PCs geht. Bei Filmen benötige ich den Ton nicht in der Küche oder sonstwo im Haus. Natürlich habe ich mich auch mit dem synchronen Abspielen der Musik beschäftigt aber dazu später mehr.

Erste Ansätze

Meine erste Idee war die Steuerung aller Lautsprecher mittels des Wohnzimmer-PCs. Kodi selber gibt da aber meines Wissens bisher nichts her. Daher war der erste Versuch mit Linuxmitteln und PulseAudio. Damit PulseAudio auch mit Airplay-Geräten umgehen kann, bedarf es der Installation zweier Pakete:

• pulseaudio-module-raop
• paprefs

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install pulseaudio-module-raop
sudo apt-get install paprefs

Danach ist in den PusleAudio-Einstellungen die Unterstützung von Airplay-Lautsprechern vorhanden.

Der Airplay-Lautsprecher in der Küche wurde gefunden und ich konnte die Audiowiedergabe mittels der PulseAudio-Einstellungen entweder im Wohnzimmer oder in der Küche hören. Diese Lösung hatte einen extrem niedrigen WAF und war mir selber auch zu umständlich, da immer zwischen Kodi und den Audio-Einstellungen gewechselt werden musste. Zudem funktioniert RAOP nicht mit Airplay2-Lautsprechern. Mit diesem Manko beschäftigt sich RAOP2 was mir aber noch zu experimentell ist. Vom Wohnzimmer-PC wird mittlerweile eine 24/7-Verfügbarkeit erwartet ;-).

Küchentablet

Zweiter Versuch war eine Lösung über unser Küchentablet welches hauptsächlich für Chefkoch-Rezepte genutzt wurde. Aber es ist ja auch schick die Musik in der Küche, auch aus der Küche steuern zu können. Mit lokal auf dem Tablet gespeicherter Musik war es keine große Herausforderung den neuen Küchenlautsprecher zu nutzen. Die Canton-Musicbox taucht in allen Audioplayern mittels „Abspielen mit“-Menüs im Android auf.

Ich wollte aber auf die komplette Musikdatenbank vom Kodi zugreifen. Also Yatse zur Fernsteuerung vom Kodi auf dem Tablet installiert und weiter getestet. Im Yatse gab es aber leider keine Möglichkeit zur Audioausgabe auf vorhandenen WLAN-Lautsprechern. Entweder konnte die Musik im Wohnzimmer, wo Kodi selbst läuft, gesteuert werden oder die Musik konnte lokal auf dem Tablet über dessen Lautsprecher wiedergegeben werden. Das will aber nun wirklich niemand hören.

Wenn der Ton aber nun schon auf dem Tablet ist, muss man ihn doch auch irgendwo anders abspielen können? Da kommt die App AirAudio in Spiel. Diese „hijacked“ den am Tablet ausgegebenen Ton und kann diesen dann mittels verschiedener Protokolle (Airplay, DLNA, Sonos, ….) an dem Tablet bekannte Lautsprecher streamen. Dazu muss allerdings das Tablet gerooted werden da Android dieses „abgreifen“ der Audioausgabe normalerweise nicht zulässt. Bei dem alten Samsung Tab 3 geht das Rooten zum Glück relativ einfach.

Nach dem Start von AirAudio erscheinen dort nun alle gefunden Lautsprecher. Natürlich auch die Musicbox als Airplay-Lautsprecher. Damit Kodi auch als Airplay-Lautsprecher gefunden wird, muss die Airplay-Unterstützung in den Kodi-Einstellungen aktiviert werden.

In AirAudio kann nun per Fingertip auf das Airplay-Symbol vor dem gefunden Lautsprecher der Ton des Tablets umgeleitet werden. Die Lautstärke jedes Lautsprechers ist auch einzeln regelbar. Das funktioniert alles sehr gut, da stimmt der WAF und ich hatte meine erste Anforderung an Multiroom gelöst. Es lassen sich natürlich problemlos zusätzliche Airplay-fähige Geräte hinzufügen.

Synchrone Musikwiedergabe

Interessant wird es jetzt, wenn zwei oder mehr Lautsprecher ausgewählt werden! Das funktioniert auch. Hier kommt jetzt aber das mit der Synchronität nochmal ins Spiel. Schon wenigen Millisekunden Unterschied in der Wiedergabe sind für das menschliche Ohr zu erkennen und auch sehr unangenehm für den Zuhörer.

Solch ein Unterschied ist leider auch bei der Wiedergabe über AirAudio auf mehrere Lautsprecher vorhanden. Dafür bietet die App aber die Möglichkeit, die Verzögerung (in Millisekunden) jedes Lautsprechers zu ändern.

Nach längerem Ausprobieren bekommt man den Ton dann wirklich synchron auf den Lautsprechern ausgegeben. Leider ist das Vergnügen nur von kurzer Dauer da es nach einer Weile wieder auseinander driftet und nach dem nächsten Start der App wieder komplett asynchron läuft. Somit ist eine synchrones Abspielen mittels AirAudio, zumindest bei mir, bisher nicht möglich.

Nett an der Lösung mit AirAudio ist aber noch, das neben der Ausgabe von Yatse auch Amazon Prime Musik, Spotify und Co. auf den verfügbaren Lautsprechern wieder gegeben werden können. Viele dieser Musik-Streaming Apps lassen normalerweise nur eine lokale Wiedergabe des Tons zu und verfügen nicht über „Abspielen mit“-Funktionalität.

Synchronität die Zweite

So richtig lies mich das Problem mit der Synchronität aber doch nicht los. Nach etwas Recherche im Internet gab es da noch die App Whaale. Diese gab es damals aber nur für Apple-Geräte. Ich war dann kurz versucht mir ein iPad zu beschaffen, konnte mich dann aber grade noch so zurückhalten als ich die Preise für gebrauchte iPad2 gesehen habe. Den Kram kann Apple behalten.

Zwischenzeitlich ist auch eine Android-Version verfügbar. Leider verabschiedet sich Kodi auf dem Linux-Rechner augenblicklich mit einem Segmentation-Fault sobald Whaale versucht, Kodi als Airplay-Lautsprecher zu nutzen. Entweder ist nun die Whaale-Version für Android noch fehlerhaft oder meinem Kodi (v15.2 “Isengard”) ist irgendwas nicht genehm. Nun warte ich auf Updates von Whaale und die neue Kodi Version „Jarvis“. Dort muss man dann wahrscheinlich nur noch „Jarvis, Spiele Musik im Wohnzimmer ab“ sagen.

Mit Whaale kann ausserdem nur lokal gespeicherte Musik und das Angebot einiger Streamingdienste wiedergegeben werden.

Ich bleibe aber an der Sache dran. Es macht ja auch viel mehr Spaß als ein fertiges System von Sonos welches wahrscheinlich einwandfrei funktioniert…

Synchronität Update

Mittlerweile funktioniert das synchrone Abspielen einwandfrei! Wie genau es umgesetzt wurde, ist in diesem Artikel beschrieben.

Gruß

Chris

After the adjustments to restart the network interface as described in post „Stabiler 24/7 Betrieb des Raspberry„, the Raspberry PI runs just fine for 100 days now. Very good!

Chris

Der M-Bus-Master sollte in meinem Fall aus dem Raspberry und einem Pegelwandler bestehen. Pegelwandler gibt es fertig von verschiedenen Herstellen (Relay, Wachendorff). Diese sind aber, je nachdem für wieviele Slaves sie ausgelegt sind, relativ teuer.

Mein erster Ansatz war daher der Selbstbau eines Pegelwandlers inkl. RS232-Schnittstelle zum Anschluss an den Raspberry Pi. Im Netz gibt es verschiedene Beschreibungen einer einfachen Schaltung und einige wenige Forumseinträge die sich mit dem Selbstbau eines Pegelwandlers bzw. generell mit M-Bus beschäftigen. Leider habe ich in keinem Forum eine Diskussion gefunden die bis zu einem funktionierenden System verfolgt wurde. Egal, ich habe es trotzdem mal versucht…

Selbstbau Pegelwandler

Auf der Platine ist der Pegelwandler inkl. einer RSA232 Schnittstelle die aus einem MAX3232 besteht. Die +/-15 Volt für den Pegelwandler habe ich mittels DCDC-Wandler IH0515S der Fa. XP Power erzeugt. Dieses Bauteil kann man z.B. bei Farnell beziehen. Dann das Ganze auf Lochraster zusammen gelötet und mit dem Raspi und dem Wärmemengenzähler verbunden.

Damit der Raspberry das M-Bus Protokoll versteht bzw. auch den Pegelwandler korrekt anspricht, habe ich die Bibliotheken von rSCADA genutzt. Die Quellen liessen sich problemlos auf dem Raspberry kompilieren. Im Ergebnis wurden verschiedene Binaries erzeugt um mit Slaves im Bus zu kommunizieren.

Meine ersten Versuche waren jedoch nicht von Erfolg gekrönt. Es wurde kein M-Bus-Gerät gefunden. Bei der Fehlersuche habe ich zuerst die serielle Schnittstelle separat getestet und mit Minicom über den Raspberry mit einem anderen Linux-Rechner kommuniziert. Das hat funktioniert. Die weitere Fehlersuche z.B. am M-Bus-Ausgang sind allerdings am fehlenden Oszilloskop gescheitert, da das Multimeter mich nicht wirklich weiter brachte.

Etwas niedergeschlagen habe ich dann nach drei Tagen erfolgloser Fehlersuche nochmal nach fertigen Pegelwandlern gesucht und ein relativ preiswertes Gerät gefunden und kurzerhand gekauft. Damit fiel die Fehlerquelle „Pegelwandler“ schon mal weg.

Versuch mit gekauftem Pegelwandler

Der neue Pegelwandler benötigt zum Anschluss an den Raspberry Pi auch eine RS232 Schnittstelle. Um mir diesmal das Löten zu ersparen, hab ich erstmal den kompletten Versuchsaufbau auf einem Breadboard gesteckt. Der Pegelwandler läuft mit einer Spannung von 12-24 V DC weshalb ich den DCDC-Wandler aus dem ersten Versich auch nicht benötige.

Die Binaries von rSCADA unterscheiden zwischen TCP- und seriell angeschlossenen M-Bus-Pegelwandlern. Da meiner seriell angeschlossen ist, benutze ich „mbus-serial-scan“ um nach angeschlossenen Slaves im Bus zu suchen.
Als Argumente übergebe ich „-d“ für den Debugmodus, „-b 2400“ um 2400 Baud zu nutzen und „/dev/ttyAMA0“ als serielle Schnittstelle des Pi.

Zu meiner Überraschung wurde direkt ein Slave (der Wasserzähler) erkannt. Sehr schön…

pi@raspberry2 ~/libmbus-0.8.0/bin $ ./mbus-serial-scan -d -b 2400 /dev/ttyAMA0
Scanning primary addresses:
0 [2014-12-13 13:59:21] SEND (005): 10 40 00 40 16
[2014-12-13 13:59:21] RECV (001): E5

Found a M-Bus device at address 0
1 [2014-12-13 13:59:22] SEND (005): 10 40 01 41 16
2 [2014-12-13 13:59:22] SEND (005): 10 40 02 42 16
3 [2014-12-13 13:59:22] SEND (005): 10 40 03 43 16
4 [2014-12-13 13:59:22] SEND (005): 10 40 04 44 16
5 [2014-12-13 13:59:23] SEND (005): 10 40 05 45 16
6 [2014-12-13 13:59:23] SEND (005): 10 40 06 46 16
7 [2014-12-13 13:59:23] SEND (005): 10 40 07 47 16
...

Hat man alle angeschlossenen M-Bus-Geräte per Scan identifiziert, können mit einem weiteren Programm die Daten des Gerätes ausgelesen werden. Auch hier gibt es wieder das Argument „-d“ für den Debugmodus, „-b“ zur Einstellung der Baudrate, das Device der seriellen Schnittstelle und die vom Scan ermittelte Device-Nummer. Im Fall meines Wasserzählers ist das die „0“. Die Daten der Slaves werden in einer einfachen XML-Struktur zurück geliefert.

./mbus-serial-request-data -d -b 2400 /dev/ttyAMA0 0
[2014-12-13 14:06:46] SEND (005): 10 5B 00 5B 16
[2014-12-13 14:06:47] RECV (084): 68 4E 4E 68 08 00 72 12 37 16 46 68 50 49 07 B6 00 00 00 0C 14 53 42 00 00 8C 10 12 35 53 42 00 0B 3B 00 00 00 8C 20 14 53 42 00 00 8C 30 14 00 00 00 00 04 6D 21 0F CD 1C 4C 14 02 00 00 00 42 6C BF 1C 42 EC 7E DF 1C 0A 92 2A 00 10 0A 92 2B 00 10 3E 16
mbus_frame_print: Dumping M-Bus frame [type 4, 84 bytes]: 68 4E 4E 68 08 00 72 12 37 16 46 68 50 49 07 B6 00 00 00 0C 14 53 42 00 00 8C 10 12 35 53 42 00 0B 3B 00 00 00 8C 20 14 53 42 00 00 8C 30 14 00 00 00 00 04 6D 21 0F CD 1C 4C 14 02 00 00 00 42 6C BF 1C 42 EC 7E DF 1C 0A 92 2A 00 10 0A 92 2B 00 10 3E 16



46163712
TCH
73

Water
182
00
0000



Instantaneous value
Volume (1e-2  m^3)
4253
2014-12-13T14:06:47



Instantaneous value
Volume (1e-4  m^3)
425335
2014-12-13T14:06:47

...

Da es auf Anhieb funktioniert hat, habe ich die serielle Schnittstelle auf Lochraster gebannt und der Pegelwandler wird mittels kleinem 12V-Netzteil betrieben. Dann Raspberry Pi, Pegelwandler und Platine im Netzwerkschrank verstauen…

Software

Den Stand des Wasserzählers protokolliere ich nun einmal täglich um 23:59 Uhr. Das wird per Cronjob und einem kleinen PHP-Script erledigt. Warum PHP? Weil ich zu ungeduldig war und das schnell umsetzen wollte und schon das ein oder andere ähnliche PHP-Script fertig hatte.

Das Script ruft das Binary wie oben erklärt per shell_exec auf. Ab dem XML-Teil parse ich die Ausgabe und extrahiere die relevanten Informationen die dann in eine MySQL-Tabelle geschrieben werden.

[cc lang=“php“]
‚));
$xmloutput = new SimpleXMLElement($xmloutput);
$zaehlerID=$xmloutput->SlaveInformation->Id;
$zaehlerStand=$xmloutput->DataRecord[1]->Value/10000;

$mysqlhost=““;
$mysqluser=““;
$mysqlpwd=““;
$connection=mysql_connect($mysqlhost,$mysqluser,$mysqlpwd) or die („Verbindungsversuch fehlgeschlagen“);
$mysqldb=““;
mysql_select_db($mysqldb,$connection) or die(„Konnte die Datenbank nicht waehlen.“);
$sql = „INSERT INTO wasserzaehler (timestamp,zaehlerid,zaehlerstand) VALUES (CURRENT_TIMESTAMP,$zaehlerID,$zaehlerStand)“;
$query = mysql_query($sql) or die(„Anfrage 1 nicht erfolgreich“);
?>;
[/cc]

Da ich auf meiner Webseite aber nicht nur den absoluten Wasserverbrauch darstellen möchte sondern auch den Tagesverbrauch, kommt folgendes SQL zum Einsatz. Hier werden die Einträge aus zwei aufeinanderfolgenden Zeilen subtrahiert um die Differenz zum Vortag zu bestimmen.

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
   )
ORDER BY wz1.timestamp

Das Ergbnis sieht dann wie folgt aus. Ich war etwas erschreckt wieviel Wasser man an machen Tagen verbraucht!

Selbstgebauter Pegelwandler

Da ich ja nun weiß das es generell funktioniert und der Fehler meiner ersten Lösung definitiv im selbstgebauten Pegelwandler liegt, werde ich den Versuch mit dem Selbstbau demnächst nochmal angehen.

Sobald der Wärmemengenzähler in den Wasserlauf des Kachelofens eingebaut ist, werde ich nochmal einen kurzen Beitrag schreiben. Das Prinzip des Auslesens ist ja analog zum Wasserzähler aber vielleicht gibt es in den zurückgelieferten Daten unterschiede.

Viel Spaß mit dem M-Bus!

Chris

Siehe z.B.: hier oder hier

Unter anderem wird auch immer wieder der Hardware-Watchdog des PI genannt. Diesen Watchdog hab ich auch aktiviert, da ich in der Vergangenheit immer wieder Probleme mit dem Netzwerk (Stichwort smsc95xx errors und weiterführende Links) hatte. Dies äusserte sich immer wieder mit dem Einfrieren des PI. Der Watchdog machte im Fehlerfall einen Restart und gut war. Nach den letzten Firmwareupdates hat sich die Frequenz der Restarts auch stark verringert.

Dann aber war mein Raspi plötzlich per SSH nicht mehr erreichbar und auch die Webseite wurde nicht mehr angezeigt. Seltsamerweise erfolgte kein Neustart durch den Watchdog. Da ich den Raspi Headless betreibe, blieb mir nicht viel anderes übrig als ihn einfach vom Strom zu trennen und wieder anzuschliessen. Danach lief alles wieder einwandfrei. Leider häuften sich diese Probleme so das es mir zu nervig wurde, ständig den Strom zu kappen. Schliesslich ist mein Raspi ja ein Server und soll gescheit laufen.

Nach den Neustarts ist mir aber auch aufgefallen, das die Daten der Leseköpfe lückenlos in die Datenbank geschrieben wurden. Anscheind lief der Raspi noch und nur das Netzwerk war nicht verfügbar.

Das Problem war teilweise im Message-Log zu sehen:


Nov 22 12:51:10 raspberrypi kernel: [1279051.095475] usb 1-1: USB disconnect, device number 10
Nov 22 12:51:10 raspberrypi kernel: [1279051.095493] usb 1-1.1: USB disconnect, device number 11
Nov 22 12:51:10 raspberrypi kernel: [1279051.095887] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet
Nov 22 12:51:10 raspberrypi kernel: [1279051.095954] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Nov 22 12:51:10 raspberrypi kernel: [1279051.136136] usb 1-1.2: USB disconnect, device number 12
Nov 22 12:51:10 raspberrypi kernel: [1279051.136650] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
Nov 22 12:51:10 raspberrypi kernel: [1279051.136748] cp210x 1-1.2:1.0: device disconnected
Nov 22 12:51:10 raspberrypi kernel: [1279051.137275] usb 1-1.3: USB disconnect, device number 13
Nov 22 12:51:10 raspberrypi kernel: [1279051.137769] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
Nov 22 12:51:10 raspberrypi kernel: [1279051.137876] ftdi_sio 1-1.3:1.0: device disconnected
Nov 22 12:51:10 raspberrypi kernel: [1279051.295583] Indeed it is in host mode hprt0 = 00021501
Nov 22 12:51:11 raspberrypi kernel: [1279051.575374] usb 1-1: new full-speed USB device number 14 using dwc_otg
Nov 22 12:51:11 raspberrypi kernel: [1279051.575636] Indeed it is in host mode hprt0 = 00021501
Nov 22 12:51:11 raspberrypi kernel: [1279051.825598] usb 1-1: not running at top speed; connect to a high speed hub
Nov 22 12:51:11 raspberrypi kernel: [1279051.825950] usb 1-1: New USB device found, idVendor=0424, idProduct=9512
Nov 22 12:51:11 raspberrypi kernel: [1279051.825971] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Nov 22 12:51:11 raspberrypi kernel: [1279051.836520] hub 1-1:1.0: USB hub found
Nov 22 12:51:11 raspberrypi kernel: [1279051.836765] hub 1-1:1.0: 3 ports detected
Nov 22 12:51:11 raspberrypi kernel: [1279052.115374] usb 1-1.1: new full-speed USB device number 15 using dwc_otg
Nov 22 12:51:11 raspberrypi kernel: [1279052.215553] usb 1-1.1: not running at top speed; connect to a high speed hub
Nov 22 12:51:11 raspberrypi kernel: [1279052.215947] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
Nov 22 12:51:11 raspberrypi kernel: [1279052.215973] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Nov 22 12:51:11 raspberrypi kernel: [1279052.219107] smsc95xx v1.0.4
Nov 22 12:51:11 raspberrypi kernel: [1279052.280966] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:bd:01:0b
Nov 22 12:51:12 raspberrypi kernel: [1279052.375552] usb 1-1.2: new full-speed USB device number 16 using dwc_otg
Nov 22 12:51:12 raspberrypi kernel: [1279052.477284] usb 1-1.2: New USB device found, idVendor=10c4, idProduct=ea60
Nov 22 12:51:12 raspberrypi kernel: [1279052.477318] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 22 12:51:12 raspberrypi kernel: [1279052.477334] usb 1-1.2: Product: CP2104 USB to UART Bridge Controller
Nov 22 12:51:12 raspberrypi kernel: [1279052.477349] usb 1-1.2: Manufacturer: Silicon Labs
Nov 22 12:51:12 raspberrypi kernel: [1279052.477362] usb 1-1.2: SerialNumber: 0065B522
Nov 22 12:51:12 raspberrypi kernel: [1279052.479039] cp210x 1-1.2:1.0: cp210x converter detected
Nov 22 12:51:12 raspberrypi kernel: [1279052.479519] usb 1-1.2: cp210x converter now attached to ttyUSB0
Nov 22 12:51:12 raspberrypi kernel: [1279052.491197] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Nov 22 12:51:12 raspberrypi kernel: [1279052.535606] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Nov 22 12:51:12 raspberrypi kernel: [1279052.555550] usb 1-1.3: new full-speed USB device number 17 using dwc_otg
Nov 22 12:51:12 raspberrypi kernel: [1279052.640093] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Nov 22 12:51:12 raspberrypi kernel: [1279052.661511] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
Nov 22 12:51:12 raspberrypi kernel: [1279052.661547] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 22 12:51:12 raspberrypi kernel: [1279052.661563] usb 1-1.3: Product: FT232R USB UART
Nov 22 12:51:12 raspberrypi kernel: [1279052.661577] usb 1-1.3: Manufacturer: FTDI
Nov 22 12:51:12 raspberrypi kernel: [1279052.661590] usb 1-1.3: SerialNumber: A4009G5A
Nov 22 12:51:12 raspberrypi kernel: [1279052.664914] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
Nov 22 12:51:12 raspberrypi kernel: [1279052.665117] usb 1-1.3: Detected FT232RL
Nov 22 12:51:12 raspberrypi kernel: [1279052.665314] usb 1-1.3: Number of endpoints 2
Nov 22 12:51:12 raspberrypi kernel: [1279052.665337] usb 1-1.3: Endpoint 1 MaxPacketSize 64
Nov 22 12:51:12 raspberrypi kernel: [1279052.665353] usb 1-1.3: Endpoint 2 MaxPacketSize 64
Nov 22 12:51:12 raspberrypi kernel: [1279052.665367] usb 1-1.3: Setting MaxPacketSize 64
Nov 22 12:51:12 raspberrypi kernel: [1279052.667714] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1
Nov 22 12:51:13 raspberrypi kernel: [1279054.248030] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1


An dem Raspi hängt der Lesekopf für den Stromzähler und für die Heizung. Der Raspi scheint die USB-Ports aus irgendwelchen Gründen unmotiviert neu zu starten. Das funktioniert für die USB-Ports immer erfolgreich, aber das Netzwerk blieb dabei gelegentlich auf der Strecke (obwohl in der letzten Zeile gegenteiliges behauptet wird). Das hängt anscheinend immer noch mit Fehlern im smsc95xx zusammen.

Neustart des Netzwerkinterfaces

Nun gut…dann muss das Netzwerk halt nochmal gestartet werden. Folgendes Bash-Script rufe ich alle 10 Minuten per Cron auf. Ist das Netzwerk verfügbar, passiert nichts. Ist das Netzwerk nicht verfügbar wird versucht des Interface neu zu starten. Gelingt auch das nicht, wird der Raspi rebootet. Mittels logger wird der Neustart in /var/log/messages geloggt.

[cc lang=“bash“ lines=“40″]
#!/bin/sh
IP_TO_TEST=““
PING_COUNT=1
PING=“/bin/ping“
IFUP=“/sbin/ifup“
IFDOWN=“/sbin/ifdown –force“
INTERFACE=“eth0″ #Device angeben welches geprüft werden soll
LOCKF=“/opt/lockf“
$PING -c $PING_COUNT $IP_TO_TEST > /dev/null 2> /dev/null
if [ $? -ge 1 ]
then
logger „$INTERFACE scheint unten zu sein, versuche restart…“
if [ -e $LOCKF]
then
logger „$INTERFACE immer noch unten, NEUSTART…“
rm -f $LOCKF 2>/dev/null
sudo reboot
else
touch $LOCKF
logger $(sudo $IFDOWN $INTERFACE)
sleep 10
logger $(sudo $IFUP $INTERFACE)
fi
else
#logger „$INTERFACE laueft“
rm -f $LOCKF 2>/dev/null
fi
[/cc]

Im Log sieht man dann den erfolgreichen Neustart des Netzwerkinterfaces durch das obige Bach-Script.


Nov 22 12:51:12 raspberrypi kernel: [1279052.665353] usb 1-1.3: Endpoint 2 MaxPacketSize 64
Nov 22 12:51:12 raspberrypi kernel: [1279052.665367] usb 1-1.3: Setting MaxPacketSize 64
Nov 22 12:51:12 raspberrypi kernel: [1279052.667714] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1
Nov 22 12:51:13 raspberrypi kernel: [1279054.248030] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
Nov 22 13:00:02 raspberrypi logger: eth0 scheint unten zu sein, versuche restart...
Nov 22 13:00:09 raspberrypi kernel: [1279589.925658] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Nov 22 13:00:09 raspberrypi kernel: [1279590.124240] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Nov 22 13:00:09 raspberrypi logger: Stopping NTP server: ntpd. Starting NTP server: ntpd.
Nov 22 13:00:11 raspberrypi kernel: [1279591.726167] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
Nov 22 13:00:32 raspberrypi logger: Stopping NTP server: ntpd. Starting NTP server: ntpd.


Seitdem läuft mein PI seit 16 Tagen durch. Mal sehen wie lange er ohne Neustart durchhält!

Gruß
Chris

Als ich dann endlich den vor langer Zeit bestellten Reed-Kontakt mk 471 b (z.B. bei Reichelt) wieder gefunden habe, konnte es losgehen.

Der Gaszähler hat an der letzten Stelle des Zählwerkes bei der „0“ einen Magneten wodurch der Reedkontakt bei jeder vollen Umdrehung einmal geschlossen wird. Diese Impulse gilt es mit einem Raspberry über einen GPIO zu zählen.

Den Reedkontakt habe ich natürlich wieder professionell mit Klebeband fixiert…hält!

Angeschlossen ist der Reedkontakt über eine Zwillingslitze direkt an einen GPIO und Ground des Raspberry PI. Pull-Up braucht es keinen. Dieser wird per Software aktiviert.

Den GPIO lese ich mit einem Python-Script aus welches in einer Endlosschleife ausgeführt wird und den GPIO (im Beispiel Pin „21“) jede Sekunde abfragt. Sekundenweise sollte reichen, da ich nicht hoffe das unser Gaszähler so schnell läuft. Immer wenn der Reed geschlossen wird, wird eine „1“ und der Zeitstempel in die Spalten „timestamp“ und „zaehlerstand“ einer MySQL-Tabelle geschrieben. Das passiert immer nur beim Wechsel des Reed von „Offen“ nach „Geschlossen“. Sollte der Zähler genau mit dem Magnet am Reed stehen bleiben, passiert nichts.

[cc lang=“python“]

import RPi.GPIO as GPIO
import time
import MySQLdb

GPIO.setmode(GPIO.BOARD)
GPIO.setwarnings(False)

# GPIO definieren
REED_gas = 21
# definierten GPIO als Eingang setzen
GPIO.setup(REED_gas, GPIO.IN, pull_up_down=GPIO.PUD_UP)

status_alt=1
while True:
status_aktuell = GPIO.input(REED_gas)
# REEDKONTAKT geoeffnet
if status_aktuell == 1:
#print „Kontakt offen“
status_alt=GPIO.input(REED_gas)
# REEDKONTAKT geschlossen
elif status_aktuell==0:
#print „Kontakt geschlossen“
if status_alt!=status_aktuell:
status_alt=GPIO.input(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()
time.sleep(1)
[/cc]

Da das Python-Script sich ab und an mal verabschiedet, starte ich es per Cronjob wieder neu falls der Prozess nicht mehr vorhanden ist. Ich sollte vielleicht lieber das Problem im Python-Script suchen und das ein oder andere Try&Catch einbauen, aber es geht auch erstmal so…

#!/bin/sh
if ps -ef | grep -v grep | grep gaszaehler.py ; then
    exit 0
else
    sudo python /usr/local/bin/gaszaehler.py &
    logger "gaszaehler.py neu gestartet"
    exit 0
fi

Zur Auswertung benutze ich dann folgende SQL-Querys:

SELECT sum(zaehlerstand) FROM gaszaehler

Hiermit werden alle gespeicherten „Ticks“ summiert. Dazu muss noch ein Startwert addiert werden da der Gaszähler ja schon eine zeitlang lief.
Dieser Startwert muss ggf. ab und an mal korrigiert werden falls der Raspi mal einen Umlauf des Zählers nicht mitbekommt weil z.B. der unwahrscheinliche Fall eintritt, dass das Klebeband nicht gehalten hat oder wahrscheinlicher, das Python-Script bzw. der ganze Raspi nicht mehr läuft. Den Startwert gebe ich als eine Zahl inkl. der drei Nachkommastellen an und addiere das Ergebnis der SQL-Query dazu. Um die richtige „Einheit“ kümmere ich mich in der Ausgabe auf der PHP-Seite mit folgender PHP-Zeile:

[cc lang=“php“]
$sql = „SELECT sum(zaehlerstand) FROM gaszaehler“;
$query = mysql_query($sql) or die(„Anfrage nicht erfolgreich“);
while ($wert = mysql_fetch_array($query)) {
$gesamtwert=($wert[0]*10)+$gas_startwert;
}
$gesamtwert=substr($gesamtwert,0,-3).“.“.substr($gesamtwert,-3,2);
[/cc]

Der Faktor 10 muss hier beachtet werden, da ja nur alle 0,01m³ Impulse gezählt werden und ich den Startwert mit allen drei Nachkommastellen angegeben habe. Die zweite Zeile setzt das Komma in der Ausgabe an die richtige Stelle.

Eine tägliche Auswertung funktioniert z.B. mit folgender SQL-Query:

SELECT CASE DATE_FORMAT(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,
          sum(zaehlerstand)
FROM gaszaehler
WHERE DATE(timestamp)>=DATE_SUB(NOW(),INTERVAL 7 DAY)
GROUP BY day(timestamp)
ORDER BY timestamp

Auch hier bekommt man den korrekten Wert in m³ durch einfache Kommaverschieberei in der Ausgabe. Den Faktor 10 benötigt man bei der täglichen Auswertung nicht:

[cc lang=“php“]substr(($wert[1]),0,-2).“.“.substr(($wert[1]),-2)[/cc]

In der Webseite sieht das folgendermaßen aus:

Das alles läuft erst drei Tage und es gibt bestimmt noch Verbesserungspotential aber ein Anfang ist gemacht.

Gruß
Chris