Smart Home – Do it Yourself
Read Time:8 Minute, 9 Second

Smart Home – Do it Yourself

0 0

Das gibt es ja schon alles!

Der informierte Häuslbauer und Renovierer kennt sie alle: KNX, Loxone, TELENOT (warum nennt man eine Firma so???), Rademacher HomePilot, Home&Smart (+1 für den aussagekräftigen Namen), sogar ELV mischt mit. Und noch viele, viele andere. Dann gibt es noch die Datenkraken à la Google Alexa, die man natürlich auch ans Haus bzw. dessen Technik andocken kann. Update 2022: Inzwischen muss man wohl auch Matter ernst nehmen. Und unendlich viele kleinere Systeme, die sich um spezielle Bereiche kümmern: Rollläden mit Eigenleben, wasser- und windscheue Markisen, Garagentore, die mit Autos reden, Kühlschränke, die einkaufen gehen (hoffentlich immun gegen Bulimie), you name it.

Wie so oft in unserer Welt gibt es schon alles, was man sich zu diesem Thema nur irgendwie überlegen kann, weil irgendjemand auf diesem Globus hofft, damit Geld verdienen zu können. An sich gut, weil man aus dem Vollen schöpfen kann, dann aber doch nur bedingt gut, weil:

  • Selbst die Systeme, die sich offen nennen, bieten gerne alles aus einer Hand an. Wenn man ein Haus neu baut und ein ausreichend fettes Budget für die Haustechnik hat, kann man natürlich alles, von der Wärmepumpensteuerung bis zum letzten Lichtschalter, von einem Hersteller oder zumindest passend zum gleichen Standard, kaufen und verbauen. Im Altbestand wird das ungleich schwieriger. Oder wenn die Lieblingswaschmaschine nur mit System ABC kann, die Wärmepumpe jedoch DEF spricht und die Rollläden eine XYZ-Sprachenklave bilden.
  • Das mit den standardisierten Protokollen ist so eine Sache. Siehe xkcd.
  • Firmen gehen manchmal bankrott oder beschließen einfach aus einem bestimmten Geschäftsfeld auszusteigen. Bei den Großen im Smart Home Geschäft weniger Gefahr, wenn man sich für ein “innovativeres System” entschließt, sollte man aber auch daran denken.
  • Will deine “Smart Home Control Unit” eine Internetverbindung? Die meisten neueren Systeme schon. Wenn du vom Handy aus dein Nachtkastllamperl ein- und ausschalten willst, muss das wohl auch so sein. Zumindest, wenn das auch von extern funktionieren soll. Und für Updates, ja klar. Und eine externe backup / restore Funktion vielleicht? Oder eine Datenbank mit den Messwerten aus dem Haus, die lustigerweise auch verfügbar ist, wenn der Controller down ist? Ihr seht schon, wo die Reise hingeht: Weiß man als Anwender eigentlich noch, welche Daten zu Hause bleiben und was auf einem externen Server landet? Oder welche Funktionen nur dann verfügbar sind, wenn der externe Server erreichbar ist? Klar gibt es Anbieter, die explizit darauf eingehen (z.B. TELENOT) aber die können halt auch nicht alles.

In der Liste findet sich absichtlich nicht der Kostenaspekt. Ganz ehrlich: Das Aufsmarten eines Hauses ist Luxus und / oder Hobby und folglich tut der Preis nicht wirklich ‘was zur Sache. Wenn es dir zu teuer ist, lass es bleiben und du wirst auch gut leben. (Bei manchen, nicht so einfach zu konfigurierenden Systemen, vielleicht sogar besser.)

In welcher Hinsicht glaubt der kleine Dietmar es nun besser zu können? Mit einer Eigenbaulösung ist geradezu sichergestellt, dass man nichts findet, das kompatibel zum Eigenbausystem ist, oder? Und der Support hört auf, sobald einem die Zeit oder das Interesse abhanden kommt. Stimmt, alles vollkommen richtig.

Tu es, weil du es tun kannst

Mein stärkstes Argument für do-it-yourself (eigentlich develop-it-yourself) ist ein zärtliches, geradezu hingebungsvolles Streicheln des Techniker-Egos. Beweise, dass du es kannst. Ein bisserl in der Art, die ein Baumarkt in seiner Werbung gerne verwendet. Ich bin mir nicht sicher, ob das bei jedem techniklastigen Hobby so ist. Mein Entschluss ein eigenes Smart Home-System zu entwickeln wurde aber ganz sicher von diesem Ehrgeiz mit getrieben. Dass ich das System jetzt genau so bauen kann, wie ich es mir vorstelle, ist eigentlich nur ein angenehmer Nebeneffekt.

Wenn ich zurück denke an die Anfänge – damals hatte ich gar nicht vor das alles zu bauen. Ich wollte nur mal etwas Lustiges mit einem Raspberry Pi machen. Ein Tutorial nachspielen ist ja fade. Es soll schon etwas Sinnvolles tun. Naja, es tat dann halt auch etwas Sinnvolles getan. Das war der Keim, der angewachsen ist.

Da ich im Sinne eines Hobbys keinen Stundensatz zugrunde lege, kostet das Zeug auch relativ wenig. Ich kann mit vielfach überdimensionierter Hardware arbeiten und es kostet immer noch einen Bruchteil von einem gekauften System. Das heißt, ich such mir die Entwicklungsumgebung aus, die mir gefällt, ich verwende Rechnerknoten mit so viel Speicher, dass ich nie Byteknausern muss, ich baue Halbleiterrelais ein, wenn auch nur der leiseste Verdacht besteht, dass ein mechanisches Relais mühsam werden könnte. Es soll ja Spaß machen.

Und das tut es auch.

Was kann das Zeug?

Soviel zur Motivation. Da wir die Warum-Frage aus dem Weg geräumt haben, ein paar Worte zu den Designgrundsätzen des Systems.

Die Topologie: Verteilte Intelligenz

Da ich ein altes Haus aufsmarte, war von Anfang an klar, ich werde keine strikte Stern-Topologie einbauen können. Leitungen von einem zentralen Punkt zu allen Sensoren und Aktuatoren – da könnte ich das Haus gleich abreißen und neu bauen. Außerdem ist niemand so ein Planungsgenie, dass er / sie anfangs schon wirklich an alle Funktionen denkt. Irgendeine Leitung fehlt also sicher. Das tut immer weh, in einer Stern-Topologie jedoch am meisten.

Eine Lösung wäre wireless direkt am Endpunkt. Protokolle gibt es ja genug, manche sogar genau für diesen Zweck entwickelt, z.B. Zigbee oder Z-Wave. Oder man nimmt einfach WLAN oder bluetooth. Damit kann man sich um die Verkabelungsfrage herum schummeln, man braucht nur eine Energieversorgung am Endpunkt.

In der Praxis funktioniert das nur, wenn der Controller am Endpunkt super klein ist. Lichtschalter sind da besonders gemein: Wenig Platz in der Dose, meistens keine echte Stromversorgung, weil eine Leitung ja zum Verbraucher geht (oder noch schlimmer bei Kreuzschaltern) und dann auch noch Designwünsche, weil man das Ding ja jeden Tag anschaut und angreift. Aus diesen und ähnlichen Gründen, kommt mir eine strikte wireless-dezentral “Topologie” auch mühsam vor, zumindest für den Eigenbau. Miniaturisieren macht den Selbstbau recht aufwendig.

Was bleibt ist ein gerüttelter Mischmasch: In der Nähe der Sensoren und Aktuatoren eine klassische Verkabelung, sozusagen ein kleiner, lokaler Stern. Diese Sternchen reden dann untereinander in einem Netzwerk. Meine Erfahrung beim Renovieren: In jedem Zimmer findet man irgendwo ein strategisch gut gelegenes Platzerl für so einen Sternchenmittelpunkt. Sei es in der Zwischendecke, neben dem Heizkreisverteiler, in einer überdimensionierten Verteilerdose. In meiner Küche wurde der “tote Hohlraum” unter der Sitzbank in Beschlag genommen. Jedes Sternchen ist für sich intelligent. Echte Zentrale gibt es keine, die Sternchen sind sozusagen gleichberechtigt.

Wo wird gedacht?

Mir war schnell klar, dass der Mittelpunkt eines Sternchens ganz schön clever sein muss. Algorithmen werden dort laufen und die Sternchen müssen sich untereinander austauschen. Das ganze muss robust funktionieren: Kurzzeitige Verbindungsfehler oder einzelne defekte Einheiten dürfen das Gesamtsystem nicht mehr beeinträchtigen als unbedingt nötig. Nach einem Stromausfall müssen sich alle wieder zusammenfinden, auch wenn einer mal länger zum booten benötigt. Man braucht sicher eine Art Remote-Diagnose und Remote-Zugriff, man will ja nicht in die Zwischendecke kriechen oder die Sitzbank zerlegen, nur um die neue Software aufzuspielen.

All das will in einer richtigen Hochsprache programmiert werden. Sicher kein Assembler und wohl auch kein “halbweiches” Arduino C++. Passend zu meinem Vorwissen ist es daher GNU C++ auf einem linux-System geworden. Da gibt es eine große Auswahl von Einplatinensystemen, typischerweise mit ARM-basierten Prozessoren mit erstklassiger Compilerunterstützung. Meine Wahl fiel damals auf den Raspberry Pi. Aus heutiger Perspektive nicht ganz glücklich, weil der Pi sich zu oft ändert und die alten Versionen wirklich nicht mehr verfügbar sind. Das Team, das den Pi Kernel pflegt, ist “a bisserl seltsam” (die Kernel Sourcen zu einem Raspbian – sorry, Raspberry Pi OS – build zu finden ist eine Aufgabe für den CIA) und Broadcom (der Hersteller des zentralen System-on-a-chip im Raspi) ist nicht besonders freundlich, was Doku und Support angeht. An der Oberfläche sieht ja alles immer schön aufpoliert aus, sobald man dem Pi aber tiefer in die Innereien greift – naja.

Nichts desto trotz, der Pi hat alles an Bord, was man als Kommunikationsdrehscheibe braucht. Hängt direkt im LAN, je nach baulichen Möglichkeiten am Kabel oder im WLAN. Hat eine Menge GPIOs, SPI, I2C und serielle Schnittstellen gibt es auch, manche Protokolle werden von Kernelmodulen via bit-banging vergleichsweise bequem eingebunden (z.B. one-wire). Wermutstropfen: Es gibt kein freies out-of-the-box Echtzeit-OS für den Pi. Es gibt viele Umbaulösungen; alle die ich angesehen habe, sind aber hoch spezifisch auf genau eine Pi-Version. Das tue ich mir nicht an, das würde den Spaßfaktor deutlich verringern. Bit-Fieseln aus einem User-space Programm funktioniert also nicht immer. Für viele Aufgaben, wo einzelne “glitches” akzeptabel sind, aber gut genug.

Auf jedem RasPi läuft also ein Serverprozess, der über LAN mit den Kollegen spricht und seine lokale Hardware versorgt. Die (kompilierte) Software ist auf jedem Knoten gleich, Funktion und Hardwareumgebung wird über Konfigurationsfiles definiert.

Die Schnittstelle zum System

Irgendwie muss man auch noch mit den ganzen Sternchen sprechen. Als Mensch, von außen sozusagen. Natürlich könnte man sich auf jedem System einlogen und sich alles ansehen, was man wissen will. Schlussendlich sind das ja lauter normale linux-Rechner, die im LAN hängen. Das ist aber mühsam. Deswegen gibt es ein Client, der das viel bequemer macht. Dieser Client bietet auch einen Programm-Editor, mit dem man die Konfigurationsfiles so in der Art von Labview erstellen kann. Leute, die mich besser kennen, wissen, dass ich immer über Labview als Programmiersprache fluche. Ist schon lustig, dass ich jetzt eine Art Mikro-Labview-Editor selbst gebaut habe. So spielt das Leben…

Pi@Home

Bevor ich zu sehr in die Details abdrifte: Das Kind hat auch einen Namen, nämlich Pi@Home. Die Software ist – wie es sich für ein Open Source Projekt gehört – natürlich frei zugänglich, gehostet auf gitlab:

git@gitlab.com:dwk/Pi_at_home.git

Wenn ich Rückmeldung bekomme, schreib ich vielleicht mal mehr darüber. Für heute muss das reichen.

Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

One thought on “Smart Home – Do it Yourself

  1. Deine Beschreibung vom dezentral gesteuerten Smart Home System kenn ich gut. Maschinen- und Anlagenbau machens ja oft recht ähnlich, zwar auf anderer Basis aber aus ähnlichen Gründen wie du. 😉 Ein Bericht übers fertige System mit Infos über Anzahl der Pi´s und deren Funktionen wär sehr spannend! Daumen hoch!

Leave a Reply

Your email address will not be published. Required fields are marked *

Previous post Wir gehen alle unsren Weg
Next post Guglhupf oder Gugelhupf? Öl oder Butter?