Smarte Poolpumpe mit ESPHome und Home Assistant

Die Poolpumpe war ja schon öfters Thema hier im Blog. In der neuen Saison wurde nun endlich die Integration ins Hausnetz vorgenommen. Home Assistant und ESPHome haben sich hier ausgezeichnet.

Projekt: Smarte Poolpumpe
Kontakt: Boris Dirnfeldner

Ein wichtiger Schritt in praktisch jeder Automation ist die Integration von Sensoren und Aktoren in die Steuerung. Je nach Umfeld ist das dann mehr oder weniger einfach und mächtig.

Die Umwälzpumpe des Rundpools war bisher durch eine einfache Zeitschaltuhr gesteuert worden, die auf der Klemmschiene mit den Sicherungen am Pool in die Stromversorgung der Pumpe eingeschliffen war. Das Ganze mit wasserdichtem Gehäuse und einem Not-Aus Knopf zum vollständigen Abtrennen der Stromversorgung war das schon in Ordnung. Einfach mal kleine Anpassungen zu machen oder eine komplexere Logik waren aber so nicht drin. Daher war der Wunsch da, die Anbindung an die Haussteuerung zu bekommen.

Man hätte jetzt einfach ein fertiges Modul für ein Paar Euro reinschleifen können und das in den Home Assistant über die Automation anbinden. Allerdings zeigen die bisherigen Erfahrungen, dass die Wifi-Anbindungen zuweilen unzuverlässig sind und (wenn man nicht einfach einen Steckeradapter nehmen kann) auch preislich relevant.

Mit den guten Erfahrungen der letzten Zeit (und mit Blick auf meine Lagerbestände) wurde daher etwas Material einer sinnvollen Anwendung zugeführt. Konkret brauchte es einen ESP32 Controller, ein Relaismodul und ein Netzteil. Für die Montage noch ein Hutschienengehäuse und Kabel.

Die Logik ist mit ESPHome schnell erstellt. Nach den Problemen zuletzt mit Windows ist nun Linux als Entwicklungsumgebung in Anwendung. ESPHome kann auch als Docker-Instanz verwendet werden, da geht es dann schnell eine lauffähige Umgebung zu gestalten (nur Ubuntu und Docker müssen vorhanden sein).

Die Konfiguration in YAML ist trivial und sieht so aus:

esphome:
  name: poolpumpcontrol

esp32:
  board: wemos_d1_mini32
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: "XXX"

ota:
  - platform: esphome
    password: "XXX"

wifi:
  ssid: "XXX"
  password: "XXX"
  domain: ".fritz.box"

# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
  ssid: "Poolpumpcontrol Fallback Hotspot"
  password: "XXX"

captive_portal:

switch:
  - platform: gpio
    pin: GPIO12
    id: "pool_pump"
    name: "Pool Pump"
    icon: "mdi:pump"
    restore_mode: ALWAYS_ON

Um das Ganze auf den ESP32 zu bekommen, braucht es nur den folgenden Befehl:

sudo docker run --rm -v "${PWD}":/config --device=/dev/ttyUSB0 -it ghcr.io/esphome/esphome run poolpumpcontrol.yaml

Danach war der Controller bereit für den Einsatz. Beim Zusammenbau das übliche gefrickel, bis alles zusammenpasst und miteinander arbeitet. Zum Testen wurde erstmal alles offen aufgebaut, bis das System richtig funktioniert hat.


Im Detail war scheinbar das Relais-Modul defekt und wollte keinem Steuerkommando folgen. Nach Austausch war das aber ok. Dabei habe ich noch einen defekten Mikrocontroller gefunden (Wifi wollte da nicht hochkommen). Zumindest reduziert sich so der Elektroschrott im Bestand.


Das Hutschienengehäuse wollte nicht richtig in das Elektrogehäuse passen, da war auch etwas (mechanische) Nacharbeit erforderlich.

Im Home Assistant war das Gerät sofort sichtbar und steht nun für jeden Unsinn offen.

Und dann noch eine entsprechende Visualisierung für den geneigten Benutzer zu bekommen, war dann nur noch eine Fingerübung.

Damit steht ab sofort die Option offen, damit auch wesentlich intelligentere Logik zu nutzen. In nächster Zeit wird wohl die Logik des ESP aufgebohrt, damit er auch gut mit Offline-Zuständen und dem Aus- und Einschalten per Not-Aus umgehen kann. Die Benachrichtigung über Telegram ist schon drin, auch kann ich nun über OTA die Firmware jederzeit per Wifi aktualisieren und die Debug-Meldungen auslesen.

In Summe wieder ein kleiner Schritt vorwärts. Nicht zwingend nötig, aber nett und ohne großen Aufwand.

Freiheit für Tuya-Geräte von der Cloud

So langsam wächst die Geräteanzahl und einige davon sind von Tuya. Die Zwangscloud ist nicht nur theoretisch ein Problem, sondern inzwischen ein konkretes Risiko geworden. Zigbee2MQTT und andere Helfer unterstützen mich bei der Befreiung einiger Geräte.
Projekt: Heimautomatisierung

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

In den letzten Wochen wurden einige Geräte angeschafft, zum Teil aus Spieltrieb, zum Teil aus Notwendigkeit. Es hat sich gezeigt, dass Tuya ein wichtiger Player im Bereich der Heimautomatisierung ist. Zum einen, weil die Komponenten erstaunlich günstig sind und trotzdem funktionieren, zum anderen, weil es einfach eine unglaubliche Fülle von Gerätearten gibt und man sich so die Anzahl der Herstellerbiotope wirklich übersichtlich halten kann. Allerdings darf nie vergessen werden, dass Tuya eine maximale Bindung an seine Cloud durchsetzt. Die funktioniert zwar sehr ordentlich, aber eine Garantie ist das nicht für immer.

Ich benutze als zentrale Basis den Home Assistant (Home Assistant (home-assistant.io)), eine wirklich schon ziemlich erwachsene Lösung mit einem riesigen Park an Integrationen zu den verschiedenen Herstellerbiotopen. Zusammen mit der Community und deren zusätzlichen Beiträgen kommt man schon ziemlich weit. Bei den Geräten nutze ich vorwiegend Tasmota und Tuya als Basisplattform, bei der Kommunikation primär Wifi und ZigBee.
Die Anbindung von Tasmota kann über die Integrationen mit Hilfe von MQTT als Schnittstelle sehr einfach erfolgen und funktioniert anstandslos. Bei Tuya läuft es über deren Cloud und deren Core API. Wäre an sich auch ok, zumindest diskutabel, hat aber einen konkreten Pferdefuß.

Tuya Core API: Goodwill oder 25.000$

Diese API erlaubt es der Integration im Home Assistant auf meine Geräte zuzugreifen. Dazu muss man sich als Entwickler anmelden, die Cloud mit dem eigenen Gerätepark (gemanagt über Handy App) verknüpfen und für eine Applikation freigeben. Da kann man dazu stehen, wie man will, Alternativen gibt es offiziell keine. Ein Problem dabei ist, dass die zentralste Komponente dabei, die Core API, kostenlos nur als Trial für 30 Tage erhältlich ist (anders als bei der Handy App). Damit ist diese Anbindung auf Gedeih und Verderb von der Lizenzpolitik von Tuya abhängig. Die Lizenz läuft auch aus und kann pro Account auch nur einmal beantragt werden. Es gibt zwar eine Möglichkeit, diese Trial um bis zu 6 Monate zu verlängern (auch ganz offiziell bei Tuya beschrieben), allerdings halt ohne Anspruch, nur Goodwill. Die kommerzielle Lizenz kostet mindestens 25.000$/Jahr und steht damit völlig außen vor. Zwar wird diese Verlängerung aktuell problemfrei gewährt, aber eine gute Lösung ist das so nicht.

Ich habe gerade meinen kompletten Park an Feuermeldern auf ZigBee mit einem Produkt von Tuya umgestellt, auch weil es keine echte Alternative dazu gibt die auch bezahlbar ist (und zwar um Dimensionen). Ich wollte die Signalisierung eines Alarms und die Batterieüberwachung integriert bekommen, da wird es dann schnell dünn mit Alternativen. Da ich also am Gerät nicht vorbeikomme, aber gleichzeitig die Cloud so nicht schätze, braucht es eine Alternative. Zwar funktionieren die Dinger auch autark, aber dann hätte ich auch bei günstigeren, dummen Geräten bleiben können.

Tuya Cloudfree

Tuya wird in der Gemeinschaft sehr aktiv diskutiert und einige Freiwillige haben sich tief in die Plattform reingegraben. Wie bei Sonoff und Tasmota hat der Hersteller natürlich gar kein Interesse an einer alternativen Lösung, daher ist das wirklich Reverse-Engineering in Bestform. Im Zuge der Aktivitäten haben sich zwei Wege aus der Cloud gebildet: Local Tuya (GitHub – rospogrigio/localtuya: local handling for Tuya devices) und Zigbee2MQTT (Home | Zigbee2MQTT). Daneben gibt es noch die Option, Geräte wie mit Tasmota eine alternative Firmware zu verpassen, z.B. mit Tuya-Convert (Tuya Convert – Tasmota). Local Tuya bietet sich vor allen für Wifi-basierte Geräte an, Zigbee2MQTT (wie der Name schon sagt) für die Zigbee-basierte Variante. Beide sind gut im Home Assistant integriert.

Die Nutzung von Tuya-Convert ist eingeschränkt überschaubar einfach und ergibt am Ende ein Tasmota-Gerät. Wenn es klappt mit Sicherheit die beste Option, geht aber mit nur wenigen Geräteklassen und da auch nur, wenn ein ESP-Chip eingebaut ist. Ansonsten fällt die Lösung flach.

Local Tuya ist hier an sich flexibler und übernimmt die Geräteverwaltung aus der Cloud lokal. An sich eine elegante Lösung. Allerdings ist das Übernehmen der Geräte nicht trivial, da es keine echte Produktdatenbank gibt und man so manuell die einzelnen Sensoren/Aktoren konfigurieren und zuweisen muss. Das ist nicht immer einfach, manchmal eine eigene Forschungsaufgabe. Obgleich ich die Lösung als einen echten Kandidaten ansehe, tue ich mir diese Bastelei vorerst noch nicht an.

Ganz anders gibt sich hier Zigbee2MQTT. In der Lösung integriert ist eine ziemlich umfangreiche Produktdatenbank, die es erlaubt (für die unterstützten Geräte) ein eigenes Netz aufzubauen und lokal zu verwalten. Da hier auch eine stattliche Anzahl von Tuya-Geräten unterstützt werden, z.B. auch mein Feuermelder (PA-44Z), ist das wahrlich ein Befreiungsschlag.
Die Software lässt sich einfach in einem Docker-Container starten und erleichtert mir damit die Administration erheblich. Zwingend erforderlich ist auch ein Koordinator. Ich habe mich für einen ConBee-II entschieden. Ursprünglich wollte ich damit direkt im Home Assistent mit einer ZigBee Integration arbeiten, aber da bin ich an den Tuya-Eigenheiten gescheitert. Mit der Herstellerdatenbank von Zigbee2MQTT geht das nun ziemlich einfach und sehr gut. An sich reduziert sich alles auf ein neues Pairing mit dem eigenen Coordinator und schon sind die unterstützen Geräte verfügbar und Cloudfrei betreibbar.
In der Praxis funktioniert das nicht immer (ein Umweltsensor zeigte danach falsche Zeit/Datum an), und das Einbinden des Coordinator-Sticks in Docker auf einer Synology DS220+ ist auch ein eigenes Kapitel. Bei den Feuermeldern und meinen beiden Dosen von Tuya klappte aber alles super und schnell.

Obgleich nicht kriegsentscheidend, sollte man noch anmerken, dass auch Zigbee2MQTT eine Oberfläche anbietet, die bei Problemen sehr hilfreich sein kann. ZigBee ist eigentlich ein toller Kommunikationsweg, aber im Detail dann doch wieder mit vielen Ecken, Kanten und Ösen versehen. Da hilft es dann doch, etwas näher und tiefer ranzukommen im Fehlerfall.
Konkret war bei mir die Abtrennung vom 2.4 Ghz Wifi nicht ganz so gut gelaufen wie erforderlich. Daher musste ZigBee auf einen anderen Kanal ausweichen. Auch sind die Repeater erheblich weniger leistungsstark als der Coordinator-Stick, was beim Aufbau zu Kommunikationsverlusten und verlorenen Geräten geführt hat. Ohne die Oberfläche wäre das Eingrenzen und Prüfen eine sehr mühsame Geschichte geworden.

Zusammenfassend kann man also durchaus auch herstellergebundene Geräte aus den jeweiligen Clouds lösen, falls gewünscht oder sogar erforderlich. Zwar wird das nicht immer gelingen, auch nicht immer gleich gut, aber wie im richtigen Leben gilt auch hier: „Ein bisschen Schwund ist immer.“ Und dafür, dass die Lösungen primär durch Freiwillige aufgebaut wurden mit viel Arbeit und Herzblut, ist das ganze inzwischen schon toll ineinander verzahnt.

Vielen Dank dafür von meiner Seite!

https://www.pexels.com/de-de/foto/dunen-des-death-valley-17108927/

Freiheit für Tuya-Geräte von der Cloud

So langsam wächst die Geräteanzahl und einige davon sind von Tuya. Die Zwangscloud ist nicht nur theoretisch ein Problem, sondern ...

ESPHome – Home Automation mit ESP32 mal wirklich ganz einfach

Mit jedem Tag zeigt sich, dass Home Automation ein sehr mächtiges Werkzeug geworden ist. Im Zuge der Tests bin ich ...
https://www.pexels.com/de-de/foto/bunte-zahnrader-171198/

Hausautomatisierung – jetzt aber richtig!

Nach inzwischen doch schon einigen mehr oder weniger erfolglosen Versuchen, das eigene Heim etwas intelligenter zu gestalten, ist nun ein ...

ESPHome – Home Automation mit ESP32 mal wirklich ganz einfach

Mit jedem Tag zeigt sich, dass Home Automation ein sehr mächtiges Werkzeug geworden ist. Im Zuge der Tests bin ich auf ESPHome gestoßen, und jetzt geht es so richtig los.

Projekt: Heimautomatisierung

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Da ich viel mit ESP32 gearbeitet habe, möchte ich diese Erfahrungen gerne auch in der Hausautomation verwenden. Obwohl es schon viele Teile zu kaufen gibt, sind halt nicht alle Wünsche mit Kaufteilen zu erfüllen oder manchmal dann doch zu teuer. Ein gutes Beispiel sind Helligkeitssensoren, die als Kaufteile mir einfach zu teuer sind. Mit ESPHome fand sich aber eine Lösung, die mir eine sehr einfache Anbindung von solchen Kleinstlösungen erlaubt ohne sich mit den vielen kleinen dafür erforderlichen Schritten beschäftigen zu müssen (wie z.B. Crosscompiler, Apps, Bibliotheken, Fehlerbeseitigung).

https://esphome.io/

Grundsätzlich kann man über mehrere Wege mit ESPHome arbeiten, allerdings sind auch Voraussetzungen zu beachten. Richtig komfortabel wäre die Integration, wenn man Home Assistant im eigenen OS Supervidord am Laufen hat, z.B. am Raspberry. Dann könnte man die Integration von dort laden und komplett über Home Assistant arbeiten.
Ich habe Home Assistant Core unter Docker am Laufen was den Durchgriff auf das drunter liegende Betriebssystem erheblich erschwert, daher funktioniert das so nicht.
Daher bleibt der Weg über die Kommandozeile manuell und später nur das fertige Gerät zu integrieren. 

Installing ESPHome Manually.

Meine Umgebung ist ein Windows 10 PC und Python 3.10 installiert über Windows Store. Auf einem Linux geht das praktisch genauso.
Auf der Kommandozeile kann ich damit die benötigten Packages nachinstallieren.

pip3 install wheel

pip3 install esphome

Anmerkung dazu: Ich würde empfehlen, eine eigene Installation von Python aufzubauen, die Store-Variante ist später eklig im Handling.
z.B. findet sich bei mir nach der Installation das Kommando esphome in C:\Users\User\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\Scripts
Ob alles geklappt hat, kann man einfach mit einem Aufruf prüfen:

esphome version
Version: 2023.05.04

So weit ist also alles gut, nun geht es an das eigentliche „Programm“.

Getting Started with the ESPHome Command Line — ESPHome
Physically Connecting to your Device — ESPHome

Aus einem früheren Projekt hatte ich schon ein fertig aufgebautes System ESP32 (Wemos D1 Mini) mit BME280 Sensor mit einer eigenen Software.
Der hätte für Home Assistant erweitert hätte werden müssen und dann entsprechend einkonfiguriert. Das ist mein Testobjekt oder Opfer.

Um ESPHome auf den ESP zu bekommen, muss zuerst ein geeignetes YAML erstellt werden.
Die Basiskonfiguration kann man leicht über den Wizard vom Kommandozeilentool erstellt bekommen.

esphome wizard test.yaml

Mit der damit erstellen Datei kann man dann die Konfiguration für die Peripherie dazu packen. Bei mir wäre das der I2C Bus (über den der Sensor kommuniziert) und natürlich der Sensor selbst.

BME280 Temperature+Pressure+Humidity Sensor — ESPHome

I²C Bus — ESPHome

esphome:
  name: esphome-00001
 
esp32:
  board: wemos_d1_mini32
  framework:
    type: arduino
 
# Enable logging
logger:
 
# Enable Home Assistant API
api:
  password: „“
 
ota:
  password: „“
 
wifi:
  ssid: „XXX“
  password: „XXX“
 
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: „Esphome-00001 Fallback Hotspot“
    password: „XXX“
 
captive_portal:
 
# Ergänzung nach Wizard
i2c:
  sda: 21
  scl: 22
  scan: true
  id: bus_a
 
sensor:
  – platform: bme280
    temperature:
      name: „BME280 Temperature“
      oversampling: 16x
    pressure:
      name: „BME280 Pressure“
    humidity:
      name: „BME280 Humidity“
    address: 0x77
    update_interval: 60s

Mit dem nun vorhandenen YAML kann man auf das ESP installieren. Da bei mir kein OTA-Code vorhanden war, musste der ESP am Rechner per USB verbunden werden (Serieller Port vom Typ CCxxxx wird im Gerätemanager angezeigt).

esphome run test.yaml

Damit wird dann im Hintergrund die Firmware zusammengestellt und kompiliert. Die erforderlichen Teile wie Libraries, Compiler etc. holt sich das Programm selbst aus dem Internet. Das war für mich schon komfortabel, weil mich gerade diese Tätigkeiten extrem anöden (zumal sowas ja auch gepflegt werden muss).
Wenn der ESP korrekt im Betriebssystem angemeldet ist (als serieller Port), wird dann vom Skript gefragt, über welchen Weg man die Firmware installieren will. Zur Auswahl steht dann der Port oder OTA. Da der ESP noch kein OTA kann, wird der serielle Port ausgewählt.
Das Tool flasht dann die Firmware, bootet den ESP und zeigt danach die Debug-Meldungen vom ESP als Ausgabe. Wenn was schief geht, kann man es hier mitbekommen.
Ich hatte z.B. das Wifi nicht Case-Sensitiv eingegeben und prompt ging das Anmelden nicht. Kein Problem, weil ich ja unmittelbar über die Meldungen das Problem sehen konnte und ein angepasstes YAML neu drüber installieren lassen.
Wenn alles geklappt hat, ist ab sofort im Heimnetz ein neuer Teilnehmer registriert und aktiv.
Für mich das absolut beste war aber, dass mein ESP gleich vom Home Assistant als neues Gerät erkannt wurde und über die Erweiterung ESPHome direkt eingebunden wurde. Keine weiteren Konfigurationen notwendig, sofort Gerät und 3 Entitäten verfügbar.

Ebenso einfach ist es ab sofort ein Update von der Firmware zu machen. Das geht nun direkt über OTA ohne Kabel per Netzwerk.
Wenn ich die Supervisord-Variante von Home Assistent hätte (nicht die Core-Variante im Docker Container), könnte ich das ganze sogar über die Oberfläche triggern. Mir ist es aber wichtiger so mit Docker weiterzumachen, daher bleibe ich bei der Kommandozeile und der eingeschränkten UI.

 

 

Nachtrag:

Die ganze Geschichte mit den Voraussetzungen schaffen hat mich nun doch nochmal eingeholt. Bei der Umstellung auf ExpressIf als Plattform (wegen Bluetooth) wurde der Pfad-String zu lange und konnte nicht mehr kompiliert werden. Bei der Einzelinstallation von Python ohne AppStore ging das Thema dann.
Danach konnte aber eine Abhängigkeit wegen einer angeblich geblockten Datei nicht aufgelöst werden. Tatsächlich aber auch kein Problem von ESPHome, sondern von ExpressIf selbst. Da scheint es mit 5.x-Versionen Probleme unter Windows zu geben. Mit einem alternativen Paket über GitHub 4.x war dann alles wieder ok.
Es bleibt also immer noch so, dass man sich irgendwann in den Tiefen durchwursteln muss. ESPHome versucht das aber sehr gut zu deckeln, bis halt gar nix mehr geht.
Und wenn es in Drittpaketen knallt, wäre es unfair das ESPHome zuzuordnen.
Ich würde auch stark darauf tippen, dass es unter Linux hier keine Probleme gegeben hätte. Wer kann, sollte vielleicht gleich damit starten. Ich denke das umschifft dann viele Klippen.

https://www.pexels.com/de-de/foto/dunen-des-death-valley-17108927/

Freiheit für Tuya-Geräte von der Cloud

So langsam wächst die Geräteanzahl und einige davon sind von Tuya. Die Zwangscloud ist nicht nur theoretisch ein Problem, sondern ...

ESPHome – Home Automation mit ESP32 mal wirklich ganz einfach

Mit jedem Tag zeigt sich, dass Home Automation ein sehr mächtiges Werkzeug geworden ist. Im Zuge der Tests bin ich ...
https://www.pexels.com/de-de/foto/bunte-zahnrader-171198/

Hausautomatisierung – jetzt aber richtig!

Nach inzwischen doch schon einigen mehr oder weniger erfolglosen Versuchen, das eigene Heim etwas intelligenter zu gestalten, ist nun ein ...

Hausautomatisierung – jetzt aber richtig!

Nach inzwischen doch schon einigen mehr oder weniger erfolglosen Versuchen, das eigene Heim etwas intelligenter zu gestalten, ist nun ein neuer Versuch fällig. Primärer Grund dafür ist vor allen das Angebot an reifen Komponenten und eine ziemlich gute Software.

Projekt: Heimautomatisierung

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Obwohl ich mich durchaus als experimentierfreudig ansehe, und auch kein Problem damit habe, mal tiefer in Eingeweiden von Lösungen rumzuwursteln, war es doch bisher sehr mühsam und teuer eine einigermaßen vernünftige Lösung für ein intelligentes Zuhause zu bauen. Das ist immer noch in Teilen richtig, allerdings kann man doch ein Paar Lichtblicke erkennen.

In den letzten Wochen habe ich mich tiefer in eine Softwareumgebung mit Namen „Home Assistant“ reingefuchst. Das Teil ist inzwischen ziemlich erwachsen und, vor allen auch durch die starken Integrationen in die Lösungen anderer Hersteller, sehr mächtig. Tatsächlich geht der Aufbau auch gut von der Hand, wenn man mal ein paar Dinge beachtet.

Ein blödes Thema ist bisher immer gewesen, dass sich zwar schnell eine Lösung zusammenbasteln ließ, manchmal sogar gar nicht so schlecht, am Ende aber immer irgendwo Stückwerk geblieben ist. Alle Versuche, diese Teile vernünftig zu integrieren, sind an einer geeigneten Lösung und vor allen an Zeit gescheitert.

Inzwischen haben sich in meiner Haus-IT einige Dinge geändert, damit auch die Basis für andere Projekte. Zum einen habe ich meinen Webserver und den Emailserver auch Docker umgestellt, um die Administration dieser Schlüsselfunktionen zu vereinfachen. Im Zuge dieser Arbeiten wurde das inzwischen doch schon ältere NAS von Synology wurde durch ein deutlich leistungsstärkeres Gerät DS220+ ergänzt. Dieses ist auch in der Lage, kleine Docker Instanzen ausreichend performant zu betreiben. Auf dem NAS läuft unter Docker auch ein MQTT-Server für diverse kleine Projekte als Kommunikationsmittel. Ebenso ist das Haus gut mit Laptops, PCs, Android Tablets und Smartphones ausgestattet. Flächendeckendes WLAN ist ebenfalls gegeben.

Durch das Solaranlagen-Projekt ist die Elektrik auch deutlich besser vernetzt, vor allen durch ein Smart Meter mit RS485 Schnittstellen und einem RS485-to-WIFI Gateway.

Am Markt gibt es inzwischen auch massig Bausteine zur Hausautomation. Je nach Geschmack mit oder ohne Cloud. Leider primär mit, aber dazu später mehr. Was sich aber definitiv geändert hat, sind die aufgerufenen Preise und die Gefälligkeit der Teile. Alles ist inzwischen merklich kompakter und auch günstiger geworden, damit auch attraktiver.

Grundsätzlich bin ich absolut kein Freund von Herstellerclouds mit all ihren Konsequenzen. Jeder, der sich die Mühe macht diese komplett zu umschiffen (und das auch hinbekommt), meinen Glückwunsch, Chapeau!

Ich für meinen Teil bin dabei inzwischen weniger grundsätzlich unterwegs, trotzdem aber weiterhin bewusst. Manche Dinge sind aber weiterhin praktisch unmöglich ohne Herstellerbindung zu realisieren. Und als Hacker tauge ich nicht, schon einfach, weil mir dafür die Zeit und Grundmotivation fehlt. In der Konsequenz gehe ich das erst mal offen an, allerdings mit einem deutlichen Blick auf die Problematik.

Fangen wir mal mit der Software an. „Home Assistant“ kann als Server komfortabel unter Docker installiert und betrieben werden. Damit ist für mich schon mal viel gewonnen, weil nicht wieder ein Raspi irgendwo rumliegt, aber kritisch zu nennen ist. Mir wurde schon mit den ersten Versuchen klar, dass ich nach den Umbauten ziemlich hiervon abhängig sein werde. Daher gefällt mir das so schon sehr gut.
Die Integration diverser Herstellerlösungen und Standards bieten einen Blumenstrauß an Optionen, vor allen die gemeinsame Verwaltung in nur einer Software. Damit bin ich zwar nicht herstellerunabhängig von den Schnittstellen, wohl aber in der Logik der Steuerung. Konkret waren schon am ersten Tag die Synology-NAS, Fritz!Boxen mit allen vorhandenen Smart-Geräten, beide Drucker und das Smartmeter eingebunden.
Genutzt werden kann das System per Browser, App, API und Assistent. Die Oberfläche per Web und App ist wirklich gut gelungen, komfortabel und die mitgelieferten Elemente sind intuitiv verwendbar und auf beiden Wegen gleichartig.
Man kommt aber auch trotzdem gut „unter die Motorhaube“, wenn man will oder muss. Python ist hier das Mittel der Wahl und liegt damit perfekt auf meiner Linie. Automationen können grafisch oder per YAML gebaut werden uns sind ziemlich einfach zu schaffen. Ich persönlich bin davon begeistert, die Lernkurve ist steil und bisher konnte ich alles Lösen. Im Detail wird das wohl später ein eigener Artikel.

Bei den Geräten ist es durchwachsener. Steckdosen lassen sich durch den MQTT-Server gut auf Basis von TASMOTA realisieren. Das geht dann komplett ohne Herstellercloud, allerdings sind die Geräte zum einen spärlich, zum anderen auch teurer als manche andere Lösung (mit Cloudbindung). Im Vergleich zu „früher“, als es noch als Sonoff-Hack vermarktet wurde, ist die Umgebung doch deutlich bekannter und teilweise sogar von Herstellern angeboten. Ich habe z.B. Schaltleisten und Dosen von „Nous“ bereits mit TASMOTA kaufen können und bin eigentlich sehr zufrieden damit.
Ein ganz extremes Beispiel für Herstellercloud und -bindung ist das Umfeld Tuya. Alle Geräte brauchen zwingend eine chinesische Cloud und den Hersteller. Dafür gibt es einen unglaublichen Gerätepark mit sehr guter Integration und Steuerungsmöglichkeiten. Nicht zu vergessen, sind die Teile mit Abstand am günstigsten. Manche Geräte können per „Tuyaconvert“ zu TASMOTA bekehrt werden, längst nicht aber alle. Über die Entwicklungsumgebung des Herstellers und dessen API können die Geräte super eingebunden werden und bieten wirklich umfangreiche Daten für die Automation an. Ich hatte mir vor einem Jahr versehentlich einen Staubsaugerrobot mit solch einer Anbindung zugelegt. Am Gerät ist nichts falsch, daher bin ich vorerst dabeigeblieben und damit war ich hier etwas offenherziger als sonst üblich.
Ich habe hier zum Ausprobieren einzelne Dosen auf Basis von Wifi und Zigbee beschafft, dazu Thermometer und Rauchmelder. Tatsächlich gibt es speziell für letzteres keine Alternative, daher werde ich wohl für Sensoren und unkritische Schalter die Dinger weiter betreiben und damit auch die Cloudbindung brauchen. Sollte der Hersteller (aus welchen Gründen auch immer) ausfallen oder unbenutzbar werden, verliere ich zwar praktische Anteile der Umgebung, aber nichts Wichtiges. Kritische Schalter und Messstellen werden davon grundsätzlich unabhängig aufgebaut (z.B. mit TASMOTA).
Jedes Gerät wird so angeschafft, dass die Basisfunktion auch ohne Automation weiter gegeben ist. Die Schalter lassen sich alle per Knopf manuell schalten, die Feuermelder funktionieren auch autark und die Temperatursensoren haben ein Display. Damit kann man notfalls auch isoliert noch arbeiten.

Aktuell integriere ich schrittweise vor allen die kräftigen Verbraucher und teste mich sonst langsam voran. Eine Motivation für die Automatisierung war die intelligente Steuerung von Verbrauchern unter Berücksichtigung der Solarleistung oder des Speicherladestands, also ein Energiemanagementsystem. Das erscheint nun sehr gut möglich, wenngleich es wohl noch ein paar Wochen braucht, bis ich da wirklich volle Kontrolle habe.

Durch die gute Kameraintegration bieten sich nun gute Möglichkeiten zur Geländeüberwachung und zur Reaktion auf Besucher. Das Thema hatte ich vorerst vertagt, mangels geeigneter Umgebung. Jetzt ist das ganz was anderes. Erste Versuche mit einer KI-Objekterkennung mit einem Yolo8-Modell und Python erscheinen ziemlich erfolgversprechend.
Nach einigen schlechten Erfahrungen mit billigen China-Cams bin ich nun auf bessere, aber auch teurere Geräte umgesattelt. Für den Eingang ist z.B. eine HIKVision beschafft worden und zeigt doch deutlich, was ein Paar Euro Unterschied ausmachen. Die Bildqualität ist deutlich besser und vor allen sind die Geräte autark betreibbar und ONVIF-kompatibel. Wieder eine Cloud umschifft. Meine Bilder will ich definitiv nicht über China verarbeiten. Die anderen Versuchsgeräte lassen sich meist nur gut über die Apps nutzen und werden wohl verkauft. Gibt sicher Nutznießer dafür, bei mir wird das so aber nichts.

Damit das Ganze auch für die Familie nutzbar wird (auch ohne App oder Browser), wurde ein altes Tablet zum Hausterminal umgewidmet. Die App läuft auf dem Samsung Galaxy S Altgerät gut. In Verbindung mit der App „Fully Kiosk Browser“ kann die App sogar exklusiv betrieben werden und das drunter liegende Android geschützt werden. Das Teil ist einen eigenen Artikel wert, daher hier nur als Randbemerkung.

Von den gängigen Sprachassistenten wie Alexa & Co halte ich mich weiter fern. Die Dinger sind mir an sich zu blöd (weil man sich die Syntax der Systeme anlernen muss) und auch schwierig unter Kontrolle zu halten. Allerdings schaue ich mir die Optionen an, die mir der Home Assistant hier bietet. Die aktuell stark in der Entwicklung befindliche Komponente des Assistenten ist an sich unfähig. Allerdings erlaubt mir die Software hier auch die Einbindung stärkerer Systeme. Da dies auch aktuelle KI-Systeme wie ChatGPT beinhaltet, ist das Interface also in der Theorie beliebig mächtig. Hier ist wohl am meisten Potential und auch am meisten Unsinn zu veranstalten, daher gehe ich es erstmal langsam in Trippelschritten an.

Da sich hier gerade in Summe wieder eine riesige Welt an Möglichkeiten aufgetan hat, ist das kaum in ein Paar Textzeilen zu pressen. Aktuell ist das immer noch eine Spiel- und Testphase. Allerdings kommt immer mehr Hardware dazu und auch sonst wird das Haus immer mehr in diese Richtung gedrückt.

Ich baue mir die nächsten Wochen das System weiter aus und werde immer wieder mal zu Details Artikel schreiben. Ich glaube aber, dass diesmal tatsächlich was Sinnvolles dabei rauskommt und ich wirklich (neben der Bastelei) auch einen echten Mehrwert generiere. Meine Familie zeigt sich auch recht ruhig, auch in kritischen oder grundsätzlichen Fragen, was ein gutes Zeichen ist. Wir werden sehen, wie es dann am Ende des Jahres aussieht, wenn also Teilprojekt ineinandergreifen und das Haus sich aktiver in unseren Alltag einbringt.

https://www.pexels.com/de-de/foto/dunen-des-death-valley-17108927/

Freiheit für Tuya-Geräte von der Cloud

So langsam wächst die Geräteanzahl und einige davon sind von Tuya. Die Zwangscloud ist nicht nur theoretisch ein Problem, sondern ...

ESPHome – Home Automation mit ESP32 mal wirklich ganz einfach

Mit jedem Tag zeigt sich, dass Home Automation ein sehr mächtiges Werkzeug geworden ist. Im Zuge der Tests bin ich ...
https://www.pexels.com/de-de/foto/bunte-zahnrader-171198/

Hausautomatisierung – jetzt aber richtig!

Nach inzwischen doch schon einigen mehr oder weniger erfolglosen Versuchen, das eigene Heim etwas intelligenter zu gestalten, ist nun ein ...

Wir benutzen Cookies und Logs mit personenbezogenen Daten ausschließlich für essentielle Funktionen wie z.B. bei der Benutzeranmeldung oder der Fehlersuche. Für Videos werden weitere Cookies von Drittanbietern benötigt. Details finden sie unter dem Link "Weitere Informationen".