Hallöchen,
Am Anfang war … nein, sie stand und zwar im Keller. Eine knapp 30 Jahre alte Gasheizung.
Bild 1: Ein uralter Gaskessel, den es zu regeln galt.
Die Motivation
Nachdem der Kessel auch im Sommer dauerhaft unter 70°C gehalten werden mußte, damit die Boilerpumpe ungefähr 3x am Tag den Warmwasserspeicher aufladen konnte, waren die Bereitstellungsverluste (5m³ Gas/Tag) enorm. Eine Regelung gab es eigentlich (fast) nicht. Allein einen Kesselthermostat, der diesen auf konstanter Temperatur hielt und einen Boilerthermostat, der die Boilerpumpe einschaltete, wenn das warme Wasser zu kühl war.
Der Zustand war natürlich dauerhaft nicht zu ertragen und musste abgestellt werden.
Obgleich ich den Lötkolben nicht als Gegner betrachte, versuche ich Funktionalität doch eher in Software zu gießen und auf käufliche Hardware-Komponenten auszuweichen. Vom Raspi hatte ich vor 3 Jahren auch schon gehört, entschloss mich aber aufgrund der bei SPS’en vorhandenen Schaltschrankfähigkeit zur Sie**ns Klein-SPS „Log*“. Ganz um’s Löten kam ich dennoch nicht, da ich irgendwie 4 Temperaturen messen musste (Außen-, Kessel-, Rücklauf- und Boilertemperatur). Die Sensor-addons für NTC/PTC waren mir allerdings erheblich zu teuer, weswegen ich auf den MCP9701A auswich, der bereits im Temperaturbereich von -10°C bis über 100°C vorverstärkte Signale zwischen 0,4-2,5V erzeugt. Nachdem die SPS mehrere 0..10V Eingänge besaß, spreizte ich das Signal nochmals per OP um den Faktor 4 auf. Das war’s dann aber auch schon. Nach weiteren Optimierungen, auf die ich hier nicht im Einzelnen weiter eingehen will, konnte ich meinen Gasverbrauch drastisch senken und liege jetzt in der gleichen Größenordnung wie die baugleichen Häuser der Nachbarschaft mit ihren Brennwertthermen.
Jetzt kam der Spieltrieb. Die Heizung sollte in’s Internet – nur wie? Die SPS hatte zwar einen Netzwerkanschluß – nur gab’s keine Protokollbeschreibung dafür. Vermutlich würde ich heute den Kompromiß eingehen und fertige Bibliotheken wie libnodave einsetzen, damals jedoch packte mich der Ehrgeiz, das 2. von der SPS gesprochene Protokoll zu analysieren. Wireshark war zu dieser Zeit mein bester Kumpel… So entstand LogoLib – die Bibliothek zur Kommunikation für die Sie**ns Log*. Jetzt fehlte nur noch ein Gerät, welches das Bindeglied zwischen SPS und Webserver herstellt. Zunächst fiel mir mein Router ein – der ist ja schließlich sowieso immer eingeschaltet (frisst also eh immer Strom) und hat einen Internetzugang. Zu blöd nur, dass es für mein Modell kein openWRT o.ä. gibt. Hm, der Ald* NAS-Server läuft ja auch immer… Also ARM Cross Compiler installiert und einen Proxy geschrieben, welcher zwischen SPS und Webserver vermittelt. Nachdem der Ald*-NAS bereits über einen Apache Webserver verfügt, sollte es eigentlich möglich sein, eigene php Scripte zu installieren und den Ofen per Web zu steuern. Aber da hatte ich die Rechnung ohne die Sicherheitsbeauftragten Ald*s gemacht. Der NAS bootet aus read only gemounteten Images, welche während des Bootens auch noch entpackt werden. Eigene php-Scripte lassen sich somit nicht erstellen (lediglich statische Web-Seiten). Eine Änderung der Images war mir zu heikel, weswegen ich auf einen freien Web-Hoster für mein Frontend umstieg und der SPS-Proxy lediglich als Daemon zwischen SPS und Web-Hoster vermittelt. Um nun nicht dauerhaften Traffic zwischen SPS und Web-Hoster zu erzeugen, ist das Ganze ereignisgetrieben, initiiert durch einen Aufruf der Webseite.
Fazit
Das ursprüngliche Problem der hohen Heizkosten war durch die SPS in den Griff zu bekommen. Mittels Ald* NAS-Server und Web-Hoster ließ sich der Weg in’s Internet erschließen. Klingt doch eigentlich nicht schlecht aber…
Kritik
Die Lösung ist so unendlich unelegant! Zwar ist die Heizungsregelung per SPS und analogen Temperatursensoren unumstritten robust. Ich hatte nie einen Ausfall innerhalb der 3 Jahre und Remanenz von Betriebszuständen nach einem Stromausfall ist etwas, was man wirklich zu schätzen lernt, wenn man ab und zu mal den FI-Schalter ausknipst, weil man noch an seinem Häuschen Kabel zieht. Dennoch, eine Kurvendiskussion zur Rücklauftemperatur implementiere ich lieber in C++ als in Flip-Flops, Zählern, Timern und Komperatoren. Auch bin ich mittlerweile an der Funktionsbausteingrenze der SPS angelangt. Ein weiterer Ausbau (Warmwasser-Zirkulationsoptimierung) würde schwierig werden …
Fällt mir mal der NAS-Server aus, dann wird es zwar nicht kalt, das Gateway zum Internet ist dann aber weg. Genauso verhält es sich mit der Verfügbarkeit des Web-Hosters. Ist der nicht erreichbar – nun ja, auch dann sieht man nicht viel (mit Ausnahme der Werte, welche das SPS Programm in dessen Display schreibt).
Komplexität reduzieren und vereinfachen
… so hieß das neue Motto, und der Raspberry Pi kam mir über den Weg gelaufen. Tatsächlich hatte ich auch den Arduino in die nähere Wahl gezogen, jedoch aus Performanzgründen wieder verworfen. Nachdem ich mir zum Ziel gesetzt hatte, ein offenes System zu schaffen (also eines welches nicht nur eine Heizung steuern kann, sondern auch weitere Aufgaben hinsichtlich eine Hausautomation übernehmen kann) schien mir der Raspberry Pi der geeignete Kandidat zu sein (wenngleich es auch noch viele andere gute Systeme auf dem Markt gibt). Mit einem TCP/IP Stack und der Vielfalt an Software entfallen damit die Umwege über NAS-Server und Web-Hoster.
Alles was dem Raspberry Pi fehlte, war eine Hardware, welche alle IO-Anforderungen vereint.
Das Pflichtenheft zur Hardware
Analoge Temperatursensoren als zuverlässige Datenquelle einer hardwarenahen Regelung von Brenner und Pumpen müssen möglich sein. 1wire ist ideal, wenn es um die gelegentliche Messung von Temperaturen an entfernten Stellen geht (Zimmertemperaturen). Beides ist also ein „Muß“ und kann nicht durch eine der anderen Technologien ersetzt werden. Das potentialfreie Schalten von Lasten muß ebenfalls möglich sein. Gleichzeitig bedarf es der Erfassung digitaler Signale von Tastern und Schaltern.
Robustheit ist ein weiterer wesentlicher Aspekt. D.h. Eingänge müssen einen gewissen Schutz gegenüber EMV Störungen (egal, ob aus dem 50Hz Netz oder einem getakteten Netzteil stammend) aufweisen. Eine Echtzeituhr ist unumgänglich und bestehende Hardware (Relaisplatinen, 1wire Verkabelung) sollte nach Möglichkeit wiederverwendet werden können. Kommt es doch mal zu einem ESD Schaden, so sollte man nicht zum Lötkolben greifen müssen und in der Lage sein, Probleme schnell und für wenig Geld beheben zu können.
Die Lösung muß einfach ausfallen, damit sie jedermann aufbauen, verwenden und warten kann. Zudem sollte sie erweiterbar sein, falls man später mal mehrere Ein- und Ausgänge benötigt.
Das beinahe Wichtigste zuletzt. Die Lösung muß in einem vernünftigen Gehäuse wohnen! Idealerweise etwas, was man im Schaltschrank „versenken“ kann.
Hubo – das Hutschienen IO Board für den Raspberry Pi war geboren
So also entstand Hubo, eine GPIO Hardwareerweiterung zum Raspberry Pi mit den folgenden Eckdaten:
• 8 x analoge Eingänge per MCP3208 und 12 Bit Auflösung (entspricht 0,61mV)
• 8 x digitale Eingänge per MCP23017
• 4 x digitale Relaisausgänge 5A 250VAC
• 3 (4) x Open Collector Ausgänge per ULN2803; 500mA/50V (bei Verzicht auf den 1wire Ausgang stehen 4 Open Collector Ausgänge zur Verfügung)
• 1 x 1wire Ausgang
• 1 x Steckoption für Real Time Clock Modul DS3231
• 1 x Steckoption für 8 Kanal Lastrelaiskarte 10A, 250VAC
• 1 x I2C Ausgang zur Kaskadierung weiterer Module
• Das Ganze in einem Formfaktor, dass es in ein Hutschienengehäuse paßt
Dank eines herausgeführten I2C-Buses erlaubt sich die Erweiterung des Digital IO’s auf bis zu 4 Module. Damit sind 32 digitale Eingänge, 16 Relaisausgänge und 16 Transistorausgänge mit offenem Kollektor möglich. Hat man bereits eine eigene Lastrelaisplatine (siehe Bild 2), will jedoch kein zweite Board kaskadieren, so besitzt Hubo eine Steckoption für eine solche 8 Kanal Lastrelaisplatine.
Bild 2: Hubo mit Lastrelaisoption
Hubo enthält ebenfalls einen Steckplatz für eine batteriegepufferte Echtzeituhr (Bild 3), welche es für unter 2€ in der ‚Bucht’ zu kaufen gibt. Damit verliert Hubo seine Zeit auch nach einem Stromausfall nicht. Ein „muß“ für Lösungen, welche sich nicht auf permanentes Netzwerk mit Zeitsynchronisation verlassen können.
Bild 3: Hubo mit DS3231 RTC Option
Das Board verfügt über einen 1wire Anschluß, womit sich u.a. auch Temperatursensoren des Typs DS18x20 direkt anschließen lassen. Hard- und Software wurde sowohl mit dem Raspberry Pi B, als auch dem B+ Modell getestet und sind zu diesen Modellen kompatibel. Das B+ Modell kann zudem im Deckel des Hutschienengehäuses integriert (Bild 4 rechts) werden. Die Notwendigkeit eines separaten Gehäuses für den Raspberry Pi entfällt hiermit.
Bild 4: Hubo und Raspberry Pi B+ im geöffneten Hutschienengehäuse
Software
Da Hubo auf der vielfach beschriebenen Hardware der beiden Chips MCP3208 und MCP23017 aufsetzt, ist es recht verständlich, dass bestehende Software entweder unmittelbar oder mit geringfügigen Anpassungen (z.B. Wahl des Chip-Select für den SPI Chip bzw. I2C-Adresse für den IO Expander) mit Hubo funktioniert.
Da ich persönlich eine relativ zeit-deterministische Lösung benötigte, um auch meine Heizungkomponenten regeln zu können, entwickelte ich eine, die Hardware etwas weiter abstrahierende Bibliothek in C++. Eine Interpreterspache wie Python schien mir hier nicht das richtige Konzept. Das Grundproblem welches ich lösen wollte war es, eine weitgehend CPU-lastunabhängige Möglichkeit des Hardwarezugriffs vorzuhalten. Das geht nur, wenn es eine einzige Instanz gibt, welche sich um Hardwarezugriffe kümmert und „Clients“ lediglich auf gepufferte Werte zugreifen. Das Problem wurde in ähnlicher Art bereits hier im Forum diskutiert. Zumindest für den multithreaded Betrieb innerhalb eines Prozesses ist das mit der Hubo C++-Lib gelungen. Zudem sollen Ereignisse von Änderungen am digitalen Input berichten, um einen pollenden Betrieb zu vermeiden.
Die in Doxygen dokumentierte Hubo-C++Lib kann >> hier << heruntergeladen werden.
Ausblick
Wie geht es jetzt weiter? Das ist eine gute Frage. Mittlerweile bin ich so weit, dass ich einige Bastelbeutel zusammengestellt habe, welche sich in etwa einer Stunde Lötarbeit zu einem Hubo zusammenlöten lassen.
Den Bastelbeutel, die Doku (Schaltplan, Löt- und Inbetriebnahmeanleitung, Tips und Tricks zur Verwendung bestehender Hardware, Hubo-C++Lib, Installscript…) einschließlich eines bereits vorinstallierten Raspbian Images habe ich mal in die ‚Bucht’ eingestellt.
Bastelbeutel in der 'Bucht':
http://www.ebay.de/itm/Hubo-Raspberry-Pi-IO-Erweiterung-1wire-analog-digital-Relais-I2C-/171964599490?hash=item2809e38cc2
Als nächstes stünde wohl ein weiterer Ausbau der C++Lib an – da hätte ich schon noch die eine oder andere Idee. Auch ein spezielles Relais- bzw. I2C-1wire Board wären denkbar als Slave zum Hubo. Elektronische Lastrelais…
Bin über jeden Vorschlag zur Verbesserung, neue Ideen usw. sehr dankbar!
Schöne Grüße
Schnasseldag
Nachtrag: Der Support aktueller Hard- und Software erfolgt über meiner >> Homepage << .
Also immer raus mit den Ideen.
) unter 
