Temperaturüberwachung mit 1-Wire, Raspberry Pi und FHEM

Ui, viel Zeit vergangen seit dem letzten Eintrag hier. Aber irgendwie habe ich auch nicht interessantes gemacht (außer studiert und so…). Jetzt gibt es aber mal wieder was neues:

Nach dem die Heizung meines Vaters ein wenig Probleme macht(e), kamen wir irgendwie auf die Idee, es wäre nett, die Temperaturen an den verschiedenen Rohren überwachen zu können. Aktuell benutzt er sowieso schon FHEM für ein paar Aktoren im Haus (aka „Smart Home“), daher wäre es ja nicht schlecht, die Sensoren da auch einzubinden.

IMG_0161

Momentan lief FHEM noch auf einer Fritz!Box, aber AVM mag ja keine fremden Skripte mehr (obwohl das FHEM-Image sogar von AVM war), daher stand auch ein Umzug auf unseren Rasperry Pi an (der aktuell schon private Cloud per ownCloud und Mail-Server spielt, und jetzt noch ein wenig mehr zu tun hat…). Nun mussten wir also uns noch irgendwelche Temperatursensoren suchen.

Ich bin dann auf das 1-Wire-System gestoßen, was ich recht nett fand: Die Daten laufen in Sende- und Empfangsrichtung über ein einziges Kabel (daher der Name), dazu braucht man dann allerdings noch eine Masse-Leitung… Coolerweise braucht man aber keine Stromversorgung: Der Bus liegt auf High, wenn er Idle ist, und die Sensoren haben einen Kondensator, der sie kurz am Leben halten kann, wenn gerade gesendet wird 😉 Wir haben uns dann allerdings doch für eine „richtige“ Stromversorgung entschieden, weil das System wohl ab 75 °C Probleme mit Leckströmen bekommen kann.

Die Sensoren selber sehen aus wie die üblichen Transistoren, mit drei Beinchen für GND, VCC und DQ. Der Bus ist extrem einfach aufgebaut: Man packt einfach alle Kabel zusammen 😀 Normalerweise braucht man noch einen Busmaster, der eben alles steuert (das ist ziemlich zeitkritisch), aber für den Rasperry Pi gibt es das Kernel-Modul „w1-gpio“, das einen solchen Busmaster auf einem GPIO-Pin realisiert (Default: GPIO4). Alles in allem also ein System, das perfekt auf unsere Anforderungen passte. Nachteil: Ein Sensor kostet um die fünf Euro, weil Dallas Semiconductors ein Patent drauf hat 🙁

Also schnell alles verkabelt und mit einem professionellen Stern-Bus-Verdratungs-System (aka Lüsterklemme) ausgestattet. (Das ganze ist extrem wakelig, mehr als die 6 Sensoren gehen auf die Weise nicht. Da würden sich vermutlich irgendwie RJ11 Stecker oder so anbieten…). Es ist auch noch ein Pull-Up-Wiederstand zu sehen, der ist nötig, wenn das System im parasitären Modus läuft, also ohne eigene Stromversorgung. Das hat bei uns funktioniert, aber wir hatten uns ja schon für ein vieradriges Kabel entschieden. (Der weiße Draht ist nicht belegt.). Das andere Ende (siehe oben), hat sogar richtige Buchen gebaut aus Buchsenleisten und Schrumpfschlauch… (BTW: Die Fotos habe ich mit dem iPhone meines Vater im Keller bei schlechten Licht gemacht, die Kamera in den iPhones ist ja mal richtig genial!)

IMG_0163Nun musste das ganze noch an den Rohren befestigt werden, die haben uns da für „Schlauchschellend“ entschieden, ich vermute, das „d“ war ein Druckfehler auf der Packung… Damit kann man die Sensoren recht gut an den Rohren befestigen. Die Kabel sind angelötet und dann mit Schrumpfschlauch isoliert (vorher für das Kabel schieben und so…). Sieht dann komplett so aus:

IMG_0162Tipp: Die IDs der Sensoren (s.u.) auf die Kabel kleben, das spart später Ärger 😉 Das ganze System ist dann ab den Verteiler mit ca. 20m Kabel mit dem Rasperry PI mit +3V3, GND und GPIO4 verbunden. Theoretisch brauchen die Sensoren 5V, aber das mag der Raspberry Pi ja nicht auf seinen GPIOs, und mit 3,3V klappt es auch.

Kommt jetzt also die Software: Ich gehe mal davon aus, das der Rasperry Pi soweit eingerichtet ist. Dann müssen als ersten die Kernel-Module geladen werden:


modprobe w1-gpio

modprobe w1-them

(Damit das immer automatisch passiert, die Modulnamen einfach in die /etc/modules eintragen)

Bei mir wurde das zweite automatisch geladen, aber es kann ja nicht schaden. Jetzt ist das Modul aktiv, und unter /sys/bus/w1/ sollte sich die Steuerung finden. Interessant ist da vor allem /devices, dort ist für jeden 1-Wire-Slave (und den Master), ein Ordner vorhanden. Die Ordner sind nach der weltweit eindeutigen ID benannt, daher macht es Sinn, die Slaves einer nach dem anderen anzuschließen und die ID an das Kabel zu schreiben. Anschließen während des Betriebs ist kein Problem. Leider ist die ID nicht auf die Geräte aufgedruckt oder so… (Tipp: Zwei Leute + Rufen ist eine effektive Lösung für „WLAN geht im Keller nicht“ 😉 ) In dem Ordner jedes Gerätes werden die Eigenschaften jedes Gerätes in bester UNIX-Philosophie in Dateien gemappt. Dort ist vor allem „w1_slave“ von Interesse, dort stehen die Daten des Gerätes (werden live abgerufen, dauert also etwas) Das sieht dann in etwa so aus:


pi@mini-cloud /sys/bus/w1/devices/10-000802b593d7 $ cat w1_slave
42 00 4b 46 ff ff 10 10 7f : crc=7f YES
42 00 4b 46 ff ff 10 10 7f t=32750

Die Übertragung war erfolgreich (crc YES), und es ist etwa 32,750 °C warm. (Die Genauigkeit beträgt aber nur etwa 0,5 °C). Alles sehr easy 😉 Damit kann man schon mal nette Sachen machen, aber das ganze sollte ja auch noch in FHEM eingebunden werden. Dazu sollte man inzwischen wohl eigentlich das Modul OWSERVER benutzen, dann auf einen 1-Wire-Server zugreift, der von den Dateisystem auf einen TCP-Service umsetzt (und damit auch übers Netzwerk funktioniert). Leider wollte das Modul bei mir nicht, und hat nur Perl-Fehler produziert. Ich habe das das Modul GPIO4 benutzt, das allerdings nur auf dem Rasperry Pi funktioniert, und wohl auch nur Temperatursensoren unterstützt.

Da Modul muss dazu erst mal aus /opt/fhem/contrib nach ../FHEM kopiert werden. Danach ist es recht einfach zu benutzen:


define hz_rueck_brauchw GPIO4 10-000802b593d7
attr hz_rueck_brauchw alias Rücklauf Brauchwasser
attr hz_rueck_brauchw group Sensoren
attr hz_rueck_brauchw model DS1820
attr hz_rueck_brauchw pollingInterval 300
attr hz_rueck_brauchw room Heizung
attr hz_rueck_brauchw stateFormat {sprintf "%.1f °C", ReadingsVal($name, "temperature", 0)}

In das define kommt die ID des Gerätes, danach wird noch ein Alias, eine Gruppe etc. gesetzt. Ich habe das Abfrageintervall noch auf 5min (300 sec) gesetzt und ein „State Format“ eingetragen. Dieser Perl-Code formatiert die Ausgabe mit einer Stelle hinter dem Komma, das sieht etwas schöner aus (ja, der Code habe ich irgendwo geklaut).

Wir loggen inzwischen alles in eine Datenbank (über das Modul DbLog), was sehr gut funktioniert, damit sind die Graphen auch in annehmbarer Zeit fertig (mit FileLog brauchen die ewig!). Das sieht dann in etwa so aus:

Home, Sweet Home_2014-10-21_20-18-59(Ich habe gerade irgendwie FHEM gekillt, und hatte schon wieder vergessen, die Konfiguration zu speichern… 🙁 Schon wieder die Graphen neu zusammen klicken!)

Fazit: Es läuft, und es war eigentlich einfacher als gedacht. Ich würde gerne noch das OWSERVER-Modul zum Laufen bekommen, aber das klappt ja vielleicht auch noch. Das 1-Wire-System ist ziemlich genial. FHEM auf dem Rasperry Pi läuft, könnte aber schneller sein. Vielleicht kommt da mal ein Cubietruck oder so…

Ein Gedanke zu „Temperaturüberwachung mit 1-Wire, Raspberry Pi und FHEM

  1. hallo niklas,

    interessanter artikel. ich setze mich grade auch mit 1wire am fhem auseinander um heizung u.a. zu überwachen. hast mir ordentlich weiter geholfen 😉

    nur eins:
    „modprobe w1-them“
    sollte sicherlich modprobe w1-therm “ bedeuten 🙂
    nicht, dass jemand an dem punkt hängen bleibt beim nachbauen ;D

    gruß
    florian

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.