Aus dem Maschinenraum

20. Dezember 2025

Ich dachte eigentlich, ich hätte eine gute Backup-Strategie, aber hier hat sie mich dann mal im Stich gelassen. Wie meist in solchen Fällen passiert irgendwann ein Fehler genau da, wo es versäumt wurde, ihn gebührend abzufangen. Diese Lücke ist nun gestopft, aber ganz sicher vor solchen Fällen ist man wohl nie. 

Der originale Beitrag zu folgendem Thema ist leider nicht mehr herstellbar und es lässt sich auch nicht nachstellen, wie er eigentlich verloren ging. Also schreibe ich einfach erneut auf, was dazu zu sagen ist.

#

Zur Zeit arbeite ich wieder mehr an meinem eigenen kleinen Schaltprogramm, eine Software, mit der sich Geräte ein- und ausschalten lassen. Ich verwende sehr gerne Shelly-Produkte, besonders, weil sie einfach via WLAN schaltbar sind und kein besonderes Funk-Kommunikationsprotokoll erfordern wie etwa Zigbee o.ä.

Das funktioniert tadellos, weshalb ich für folgende Eigenschaften bislang gut ohne so etwas wie Home Assistant auskam.

Eigenschaften

Das Schaltprogramm, genauer dessen Client, erscheint mit einem »Tap« auf dem Smartphone und zeigt in diesem einen Schritt gleich eine Gesamtliste aller schaltbarer Geräte an. Diese Übersicht macht für jedes Gerät kenntlich, ob es erreichbar ist oder nicht (online/offline), ob es ein- oder ausgeschaltet ist und welche Leistungsdaten wie z.B. Stromverbrauch, Temperatur, Luftfeuchtigkeit aktuell anliegen. Die Leistungsdaten werden »live« aktualisiert, so wie sie sich jeweils ändern, solange die Übersicht angezeigt wird. Wo es die Geräte erlauben, erfolgt die Aktualisierung der Leistungsdaten im »push«-Verfahren immer nur dann, wenn sich etwas ändert und nicht per »Polling«, das z.B. alle paar Sekunden eine Abfrage macht.

Eine neue Anforderung und zugleich eine zusätzliche Herausforderung stellt hierbei die Einbindung batteriebetriebener Geräte von Shelly wie dem Temperature & Humidity Sensor dar. Sie gehen über lange Zeit in eine Tiefschlafphase und sparen so Batteriekapazität, sind aber weder für Abfragen erreichbar (offline) noch bieten sie einen permanent offenen Datenkanal für push-Nachrichten zu ihrem Status. Jene Geräte konnten bisher nur über ein »outbound WebSocket« eingebunden werden, was einen WebSocket Server im Schaltprogramm erforderte.

Ein weiterer Sonderfall sind Shelly-Geräte der ersten Generation. Sie unterstützen keine push-Nachrichten über WebSockets und sind für die Übermittlung den Einschaltzustands über »Webhooks« und für die kontinuierliche Abfrage des Stromverbrauchs über einen Timer-gesteuerten Polling-Mechanismus via HTTP GET an das Schaltprogramm angebunden. Der Polling-Mechanismus ist zwar ein Bruch der Anforderung, keinen solchen einzusetzen, ließ sich aber bei besagten Gen.-1-Geräten nicht anders machen. 

Winzige Lösung

Das eigene Schaltprogramm mit den zuvor beschriebenen Eigenschaften erfordert eine Java Ablaufumgebung, der Client ist geräteunabhängig als Webapplikation in HTML, CSS und vanilla JavaScript erstellt. Die Serverkomponente muss nicht über einen App Store installiert werden sondern wird einfach auf den Zielrechner kopiert und dort gestartet. Mitsamt aller Drittbibliotheken, darunter Neon, Gson und WebSockets, erreicht alles gerade einmal 829 KB. Die geringe Größe ist hierbei auch der Nutzung von Neon zu verdanken, die einen Verzicht auf Brimborium wie JavaEE, Spring, Tomcat, Glassfish, usw. ermöglicht. 

Mit zunehmender Zahl genutzter IoT-Geräte ergab sich nun der Bedarf, einmal einen Vergleich anzustellen, welche anderen Lösungen diese Erfordernisse abdecken und eine eigene Entwicklung ersetzen könnten.

Vergleich

Als Kandidaten wurden die Shelly App und Home Assistant herangezogen. Sowohl die Shelly App als auch Home Assistant lassen sich einfach in Betrieb nehmen: Einfach aus dem App Store die Shelly und Home Assistant App installieren. Für Home Assistant habe ich zudem die Installation der Server-Seite als Docker-Container gewählt. Die Shelly App basiert hingegen auf dem Cloud-Angebot des Herstellers.

Die Bedienoberfläche zur Konfiguration ist schick gemacht, aber eine größere Zahl an Geräten darüber einzurichten ist recht langwierig. Stattdessen pro Gerät einmalig eine JSON-Konfigurationsdatei anzulegen geht schneller und funktioniert bei meinem Schaltprogramm ziemlich einfach. Noch dazu ist auf diese Weise nur eine ganz schlanke Persistenzschicht und keine Datenbank nötig. Die Macher von Home Assistant haben hierfür wohl etwas Ähnliches in Form von YAML in petto, habe ich aber auf die Schnelle nicht genutzt.

Die Shelly App und Home Assistant bieten ansonsten eine geradezu überbordende Funktions- und Möglichkeitenvielfalt, die abzubilden ein eigenes Programm kaum in der Lage wäre. Aber das ist auch nicht das primäre Ziel. Jedenfalls wären nach Abschluss des Vergleichs beide Apps gute Kanditaten für einen Einsatz.

Stolpersteine

Dennoch sprechen gewichtige Gründe gegen einen Einsatz. Die Shelly App funktioniert nur mit der Shelly Cloud. Heimische Geräte funken pausenlos ihren Status in der Weltgeschichte herum und sorgen für einen stetig anwachsenden Datenberg auf den Servern von Shelly. Home Assistant erfordert in einer virtuellen Maschine mindestens 2 GB RAM, 2 CPUs und 32 GB Plattenplatz. Alternativ kommt ein Raspberry Pi Model 4 oder 5 in Frage, ebenfalls mit mindestens 2 GB RAM und einer 32 GB Speicherkarte. Auf dem Raspberry Pi soll für Home Assistant ein ganzes eigenes Home-Assistant-Betriebssystem aufgespielt werden, d.h. der betreffende Raspi läuft dann dediziert als Home Assistant Server. 

Das simple Schalten von Geräten soll aber weder eine permanente Cloud-Anbindung heimischer Geräte noch einen permanent laufenden »großen« Rechner erfordern.

Zielarchitektur

Bei mir ist es so, dass als einziges »immer an« Gerät ein Raspberry Pi Zero 2W läuft. Auf diesem muss sich das Schaltprogramm befinden, denn es ermöglicht das gezielte Ein- und Ausschalten von Geräten nach Bedarf, also auch einem »großen« Rechner oder Server, wenn er benötigt wird. Auf dem Zero laufen auch noch andere »immer an«-Prozesse wie z.B. einer zur Überwachung der IP-Adresse, die vom Internet-Provider täglich neu vergeben wird, sowie ein Lighttpd als Reverse Proxy.

Der Raspberry Pi Zero 2W hat eine 256 MB SD-Karte, 512 MB RAM und eine 1GHz 4-Kern-CPU und verbraucht im Dauerbetrieb unübertreffliche 0,87 Watt.

Anmerkung: Die 256 MB Karte hatte ich noch, solche werden gar nicht mehr hergestellt. Sie wird hier verwendet, um im produktiven Betrieb die minimalen Laufzeitvoraussetzungen zu erproben.  

Fazit

Home Assistant erfordert selbst bei Verwendung eines Raspberry Pi drei bis viermal mehr Kosten für Hardware sowie fünfmal mehr Strom. 

Schon in diesem sehr kleinen Maßstab zeigt sich der Mangel an Effizienz bzw. umgekehrt formuliert die nicht ausgeschöpfte Möglichkeit zur Einsparung von Ressourcen durch den Einsatz effizienterer Software sehr deutlich. Quot erat demonstrandum.

Gleichermaßen in großem Rahmen gilt: Indem es in der Informationstechnologie versäumt wird, effizientere und ressourcenschonendere Software herzustellen, ergibt sich bei der Skalierung der resultierenden Systeme auf große Maßstäbe eine gewaltige Verlust- und Fehlleistung, die sich mit der Schaffung immer größerer und komplexerer System- und Rechnerarchitekturen immer weiter exponentiell erhöht.

Allzuoft wird »besser« fälschlicherweise gleichgesetzt mit »mehr«, wo doch das tatsächliche Potential in der Einsparung von Ressourcen und der Erhöhung der Effizienz liegt.

Hierbei tritt ein weiteres Missverständnis zutage. Einsparungen werden nicht durch das Weglassen von Leistungen erzielt, das sind einfach Kürzungen. Kürzungen können Sinn ergeben, wenn Leistungen nicht mehr benötigt werden. Echte Einsparungen entstehen dagegen erst mit höherer Leistung unter Beibehaltung oder Verringerung des Aufwands.

Echte Einsparungen und Leistungssteigerungen werden nur durch höhere Effizienz erzielt. 

Auch die Abhängigkeit von den USA und China wird fortwährend beklagt, aber von der Industrie beispielsweise in Deutschland bislang nicht zum Anlaß genommen, dem abzuhelfen. Dabei zeigt eine wie hier vorgestellte Lösung im kleinen Maßstab wie es gehen kann. Die Kernkomponente des Raspberry Pi Zero 2W, die RP3A0-Einheit, ist ein eigens erstelltes »System-in-Package« designed von Raspberry Pi in Großbritannien und wird wie der ganze Rechner auch in Großbritannien gefertigt. Lediglich Standardkomponenten werden weltweit zugekauft.

Wo stehen die deutsche Politik, die Regierung, die deutsche Wirtschaft und deren zahlreiche Verbände, ja selbst Experten in diesem Punkt? Jeder darf sich selbst ein Bild machen. Es dürfte kläglich ausfallen.