Alles fing mit meiner neuen Heizung an, die meinem Gefühl nach nicht richtig funktionierte. Zwar besaß diese Anlage eine Datenschnittstelle, aber der Hersteller wollte mir auf Nachfrage weder geeignete Software, noch eine Spezifikation dafür geben. Weil mit das Risiko, die Heizung beim Reverse Engeneering versehentlich zu beschädigen, zu hoch war, habe ich mich entschlossen, einfach selbst ein paar zusätzliche Temperatursensoren in die Anlage einzubauen. Ich begab mich also auf die Suche nach einer Möglichkeit, Temperaturen mit dem Computer zu messen und deren Verlauf zu visualisieren. Bei der Recherche, was man da heute so hernimmt, stieß ich auf 1-Wire.
Der 1-Wire-Bus
1-Wire ist ein serielles Busprotokoll der Firma Dallas Semiconductors. Die Schnittstelle kommt (neben der Masse-Verbindung) mit einer einzelnen Datenleitung aus. Über diese Datenleitung kann gleichermaßen gesendet und empfangen werden. Ein Sensor, der im sog. "parasitären Modus" an den Bus angeschlossen ist, kann über die Datenleitung sogar mit Strom versorgt werden. Die Übertragung funktioniert nach dem Master-/Slave Prinzip. Neben der Steuereinheit (Master) können bis zu 100 Slaves (Sensoren, Speicherbausteine, etc.) über einen einzigen Bus adressiert werden. Für die Länge des gesamten Busses mit Abzweigungen gibt es bestimmte Einschränkungen, ebenso wie für Slaves im parasitäten Modus.
Informationen dazu findet man z.B. in den Guidelines for Reliable Long Line 1-Wire Networks.
Der Sensor: DS18S20
Der Sensor misst Temperaturen von -55 °C bis +125 °C mit hoher Genauigkeit (±0.5°C im Bereich von -10°C bis +85°C), kann im parasitären Modus betrieben werden, hat die Bauform eines Transistors (TO-92), und ist sehr günstig.
Ein DS18S20 kostet bei Pollin ca. 2.50 Euro. Der größte Vorteil für mich - gegenüber den üblichen auf Widerstandsmessung basierten analogen Sensoren (z.B. PT-1000) - ist, dass ich ihn nicht auf die Kabellänge kalibrieren muss, und dass ich viele davon an einem einzigen 2-Adern-Bus betreiben kann. Das macht die Verkabelung leichter, und das ganze System schön flexibel. Jeder Sensor wird auf dem Bus über eine eindeutige 48-Bit Adresse adressiert, die fest eingebrannt und auf das Gehäuse gelasert ist (siehe links auf dem Bild).
Im parasitären Modus bezieht der Sensor seine Energie aus den Impulsen der Datenleitung, die er in einem kleinen eigebauten Kondensator zwischenspeichert. Um den Sensor im parasitären Modus zu betreiben, reicht es, die Datenleitung (DQ) mit VCC zu verbinden. Mehr dazu im Datenblatt.
Update: In meinem Blogeintrag Bus-Pirate plaudert mit DS1820 hab ich später mit einem Bus-Pirate mit dem DS18S20 gesprochen.
Der Master
Da die Messwerte meiner Sensoren am Ende irgendwie im heimischen Ethernet verfügbar sein sollen, habe ich mich für ein Mikrocontroller-Board mit Ethernet-Controller entschieden. Und weil ich die Sensoren sowieso schon bei Pollin bestellt hatte, fiel die Wahl auf das AVR Net-IO-Board von Pollin. Prinzipiell ist es aber völlig egal, wie und womit man das macht.
Auf dem Net-IO-Board verwende ich Ethersex als Firmware, weil sie zum Einen 1-wire Support schon mitbringt, und zum Anderen IPv6 unterstüzt, und das gleich mal eine gute Gelegenheit ist, einen Service mal IPv6-only in Betrieb zu nehmen. Im Ethersex-Wiki wird auch beschrieben, wie man die Firmware für 1-Wire konfiguriert, und wie der Bus angeschlossen wird. Neben ganz viel Kabel für den Bus, benötigt man dafür nur einen 4.7k Widerstand als Pulldown zusätzlich. Für die Verkabelung verwende ich ein geschirmtes Telefonkabel. Oft werden auch einfach Cat.5 Kabel verwendet, der Einfachheit halber oft auch gleich mit RJ-45 Steckern. Auf hobbyboards.com gibt es z.B. relativ viel fertige 1-Wire Hardware mit RJ-45 Buchsen.
Links eine Abzweigung im Telefonkabel, und Rechts ein DS18S20, der im parasitären Modus in einer Lüsterklemme steckt. Beides zum Testen.
Ein Testsetup mit einem Net-IO-Board und einem kurzen 1-Wire Bus mit 2 Sensoren. Einmal der Lüsterklemmensensor, und einmal ein DS18S20 in einem Gehäuse eines PT-1000 Sensors, den ich noch herumliegen hatte.
Für den "Produktivbetrieb" hab ich etwa 20 Meter Kabel in meinem Heizungskeller verlegt, und Sensoren an verschiedenen Stellen in die Anlage gebastelt: Heizkreis Vor- und Rücklauf, Warmwasser Vor- und Rücklauf, Solaranlage Vor- und Rücklauf, ein Sensor an der Umwälzpumpe für das warme Wasser, und ein Sensor im Gehäuse des Außensensors der Heizung. Später kam dann noch ein Sensor für die Innentemperatur im Flur dazu.
Ich habe gerade keinen Heimserver am Start der immer online wäre, und ich möchte wegen dieses Projekts auch nicht unbedingt einen installieren, wegen des aufs Jahr gesehen relativ hohen Stromverbrauchs. Deshalb verwende ich zum Speichern der Werte einfach meinen gemieteten Server im Internet, auf dem auch diese Homepage läuft: Zuhause hört das Net-IO-Board auf einer statischen IPv6-Adresse, zu der sich ein Script auf dem Server alle 2 Minuten eine Verbindung aufbaut und die aktuellen Werte holt.
Hier noch IPv4 + DynDNS von meinem Notebook aus. Die hexadezimalen Nummern sind jeweils die Adressen der einzelnen Sensoren.
Das Script speichert die Werte in einer MySQL-Datenbank, wo meine Homepage sie wieder abholt und via Javascript und der Highcharts Bibliothek einen ansprechen Graphen zaubert.
Das Ergebnis
Das hier sind die Livedaten. Insgesamt bin ich sehr zufrieden mit dem Ergebnis. Wenn man die Anlage kennt, sieht man sofort, wenn irgendetwas nicht wie erwartet läuft. Ich fand auch schon direkt zwei Fehler in der Anlage. Einmal ein seitens des Installateurs vertauschter Sensor, und einige Zeit später einen undichten Sensor mit Kurzschluss, der ebenfalls den Regelkreis störte. Ich frage mich nur, wie normale Menschen solche Fehler selbst finden sollen. Es ist ja nicht so, dass die Anlage dann nicht funktionieren würde - in meinem Fall wäre sie nur ziemlich ineffizient gewesen.
Update
Inzwischen hab ich das Net-IO-Board mit Ethersex gegen einen Raspberry Pi getauscht. Ich habe inzwischen ein paar mehr 1-wire Sensoren am Bus (unter anderem einen 1-wire Geigerzähler) und ein paar nicht-1-wire Sensoren zur Strommessung, und auf Dauer war es mir zu aufwendig, immer Plugins für Ethersex in μC dafür zu schreiben. So ein Linux drunter ist halt schon was feines. Allerdings halt nicht echtzeitfähig, was für die Strommessung z.B. ärgerlich war, aber irgendwas ist ja immer. :-)
Prinzipiell blieb aber alles beim Alten: Auf dem Raspi läuft ein Daemon, der regelmässig die Sensoren abfrägt und die Werte der letzten Messung als JSON-Frame auf Anfrage per IPv6 dem Client im Internet (also dieser Homepage) mitteilt.