2 Punkte von GN⁺ 2025-01-26 | 1 Kommentare | Auf WhatsApp teilen
  • In 7 Jahren Betrieb von Home Assistant ist die Umgebung von kleiner Automatisierung rund um Raspberry Pi und SQLite zu einem Setup mit Home-Server-VM, MySQL, InfluxDB und mehr als 100 Geräten gewachsen
  • Im neuen Haus kamen mehr Räume und Leuchten hinzu; fast jede Glühbirne ist mit Home Assistant verbunden, und die smarten Leuchten sind einheitlich Produkte von IKEA
  • Die Lichtautomatisierung wurde von Flux auf Adaptive Lighting aus HACS umgestellt, wodurch Farbtemperatur und Helligkeit je nach Tageszeit feiner gesteuert werden; der Aufwand bleibt jedoch, jede Light-Entity direkt in der Konfiguration auflisten zu müssen
  • Cursor hilft mit einem Custom Parser zur Analyse der Lichtfunktionen über die Home Assistant API sowie bei der YAML-Erzeugung und reduziert so wiederkehrende Konfigurationsarbeit und Debugging-Zeit
  • Der nächste Schritt ist, Zigbee-basierte smarte TRVs an den Heizkörpern anzubringen und mit Nest-Temperaturdaten die raumweise Heizung über Home Assistant zu steuern

Vom kleinen Apartment zur Home-Server-VM

  • Die Nutzung von Home Assistant begann in einem kleinen Apartment damit, die Beleuchtung über den IKEA Smart Hub zu bündeln
  • Nachdem die Automatisierung vertrauter wurde, entstanden auch eigene Custom-Hardware-Lösungen wie Temperatur- und Feuchtigkeitssensoren
  • Mit mehr Geräten und Automatisierungen kam der Betrieb auf einem Raspberry Pi an seine Grenzen
    • Die Standarddatenbank SQLite wurde beim Verarbeiten vieler Sensordaten zum Flaschenhals
    • Spezielle Hardware für Home Assistant wurde nicht ausprobiert und daher nicht bewertet
  • Die aktuelle Konfiguration wurde auf eine VM auf dem Home Server migriert
    • Die Hauptdatenbank von Home Assistant wurde auf MySQL migriert
    • Für langfristige Metriken und historische Daten läuft ein separater InfluxDB-Server
    • Die Home-Server-Konfiguration ist in einem separaten Beitrag dokumentiert

Ausbau auf mehr als 100 Geräte im neuen Haus

  • Nach dem Umzug in ein Haus stieg die Zahl der Räume, Leuchten und Geräte insgesamt deutlich
  • Derzeit sind in Home Assistant mehr als 100 Geräte verbunden
  • Alle smarten Leuchten sind Produkte von IKEA, und nahezu jede Glühbirne im Haus ist in Home Assistant integriert

Wechsel von Flux zu Adaptive Lighting

  • Die zentrale Funktion der Lichtautomatisierung ist Adaptive Lighting
  • Zuvor wurde Flux genutzt, ein älterer Ansatz, der die Beleuchtung passend zur Tageszeit synchronisiert
  • Inzwischen wurde auf die über HACS (Home Assistant Community Store) bereitgestellte Integration Adaptive Lighting migriert
  • Die neue Integration steuert Farbtemperatur und Helligkeit im Tagesverlauf präziser
  • Der lästigste Punkt bei der Konfiguration ist, dass weder Flux noch Adaptive Lighting auf eine Light Group als Ziel angewendet werden können
    • Selbst wenn Dutzende Leuchten gemeinsam verwaltet werden sollen, muss jede Light-Entity in der Konfigurationsdatei explizit angegeben werden
    • Praktischer wäre es gewesen, eine Gruppe anzugeben und die darin enthaltenen Leuchten automatisch verarbeiten zu lassen
  • Auch wenn alle Glühbirnen von IKEA stammen, unterscheiden sich die unterstützten Funktionen
    • Damit Adaptive Lighting korrekt funktioniert, sind separate Einstellungen je Lampenkategorie erforderlich
  • Ziel ist eine automatische Farbtemperatur-Umstellung, die morgens und abends sanft zu warmem Gelb und mittags zu kühlerem Weiß und Blau wechselt

YAML-Konfiguration mit Cursor beschleunigen

  • Eine große Veränderung in diesem Jahr war der Einsatz von Cursor, um wiederkehrende und mühsame Arbeiten an der YAML-Konfiguration von Home Assistant zu erledigen
  • Da nicht genug Zeit war, die DSL von Home Assistant und alle Details der Konfigurationsdateien zu lernen, wurde ein KI-Coding-Assistent für die Konfigurationsarbeit genutzt
  • Als Erstes entstand ein Custom Script, das alle Leuchten parst, Lampentypen und Funktionen analysiert und Debugging-Informationen ausgibt
  • Dieses Skript verbindet sich mit der Home Assistant API und klassifiziert Leuchten nach ihren Funktionen
    • Es sammelt Entities, die mit light. beginnen
    • Es prüft aktuellen Zustand, Helligkeit, Farbtemperatur, unterstützte Farbmodi und unterstützte Funktionen
    • Es gibt Warnungen aus, wenn Adaptive-Lighting-Einstellungen nicht zu den Funktionen einer Leuchte passen
    • Es gibt minimale, maximale und durchschnittliche Helligkeit eingeschalteter Leuchten sowie Listen nach Leuchtentyp aus
  • Der Arbeitsablauf besteht aus drei Schritten
    • Den Custom Parser in der Home-Assistant-Umgebung ausführen, um eine Liste der Lampen und Funktionen zu erzeugen
    • Die Ausgabe und die bestehende Konfiguration in den Agent Mode von Cursor oder einen ähnlichen Modus eingeben
    • Cursor erzeugt YAML für das neue Adaptive-Lighting-System
  • Bei Problemen werden Home-Assistant-Logs in Cursor eingefügt und um Korrekturen der Fehler gebeten, wodurch auch das Debugging unterstützt wird

Adaptive-Lighting-Einstellungen je IKEA-Lampe

  • Nach umfangreichen Tests wurden die Adaptive-Lighting-Einstellungen je IKEA-Lampentyp optimiert
  • Dimmable white spectrum

    • Ziel sind LED bulb GU10 345 lumen, smart/wireless dimmable white spectrum-Lampen
    • Das Konfigurationsbeispiel verwendet min_brightness: 50, max_brightness: 100, min_color_temp: 2202, max_color_temp: 4000
    • Enthalten sind sleep_brightness: 1, sleep_color_temp: 2202, transition: 45, interval: 90, initial_transition: 1, prefer_rgb_color: false
  • Dimmable color and white spectrum

    • Ziel sind LED bulb E27 806 lumen, wireless dimmable color and white spectrum/globe opal white-Lampen
    • Das Konfigurationsbeispiel verwendet min_brightness: 70, max_brightness: 100, min_color_temp: 2000, max_color_temp: 6535
    • Enthalten sind sleep_brightness: 1, sleep_color_temp: 2000, transition: 45, interval: 90, initial_transition: 1, prefer_rgb_color: false
  • Dimmable warm white

    • Ziel sind einfache LED bulb GU10 345 lumen, smart/wireless dimmable warm white-Lampen
    • Ohne Farbtemperatur-Einstellungen wird helligkeitszentriert min_brightness: 50, max_brightness: 100, sleep_brightness: 1 verwendet
    • Enthalten sind transition: 45, interval: 90, initial_transition: 1

Nächster Schritt: smarte Zigbee-TRVs

  • Nachdem die Lichtautomatisierung stabil läuft, ist das nächste Projekt, alle Heizkörper mit Zigbee-basierten smarten TRVs aufzurüsten
  • Ziel ist, die Temperaturdaten des zentralen Nest-Thermostats auszulesen, damit jeder Raum eine passende Temperatur hält
  • In älteren britischen Häusern ist die Temperaturregelung wenig fein abgestimmt; eine Regelung pro Heizkörper kann Komfort und Effizienz erhöhen
  • TRVs wurden bereits gekauft, aber noch nicht eingerichtet
  • Die geplante Konfiguration sieht wie folgt aus
    • TRVs mit dem Zigbee-Netzwerk koppeln
    • Temperaturdaten vom Nest-Thermostat abrufen
    • Home-Assistant-Automatisierungen erstellen, die Heizkörperventile je nach Zieltemperatur pro Raum öffnen oder schließen
  • Das erwartete Ergebnis ist, das in britischen Häusern verbreitete Problem abzumildern, dass manche Räume zu warm sind und andere nicht ausreichend warm werden

1 Kommentare

 
GN⁺ 2025-01-26
Meinungen auf Hacker News
  • Ich bin der Gründer von Home Assistant. Wenn ihr Fragen zum Projekt oder zur Open Home Foundation habt, könnt ihr sie gern stellen.
    Die Open Home Foundation besitzt inzwischen Home Assistant, ESPHome usw.

    • Ich nutze Home Assistant seit über 10 Jahren und frage mich, ob ihr schon einmal erwogen habt, die Release-Regeln zu ändern.
      Monatliche Releases sind gut, aber wenn es jedes Mal Breaking Changes gibt, wird das zur Belastung. Wenn man Breaking Changes auf ein- oder zweimal pro Jahr begrenzen würde, könnten Nutzer leichter Schritt halten.
      Ich versuche jedes Mal, die Liste der Breaking Changes zu lesen, aber manchmal fasse ich HA monatelang nicht an. Wenn ich mich danach wieder einlogge, haben sich viele Änderungen angesammelt, die ich prüfen muss, sodass ich das Upgrade aufschiebe und das Problem größer wird. Wenn Upgrades ohne Breaking Changes klar erkennbar wären, wäre es wohl einfacher, aktuell zu bleiben.
    • Ich sehe Home Assistant als ein großartiges Beispiel dafür, selbst die Kontrolle über Elektronikgeräte zu behalten, statt Datensammelunternehmen dafür zu bezahlen.
      Solche großen Datensammler dürften diese Technologie nicht mögen; mich würde interessieren, wie oft es tatsächlich Druck wie Unterlassungsaufforderungen gab oder Fälle, gegen die ihr euch verteidigen musstet.
    • Geräte zu organisieren und Automatisierungen zu erstellen ist immer noch ziemlich mühsam.
      Es wäre schön, wenn man ein neues Gerät hinzufügen und seinen Standort und seine Rolle beschreiben könnte, und HA es dann automatisch in bestehende Automatisierungen integriert oder mit anderen Sensoren kombiniert. Dafür ließen sich wohl auch LLMs nutzen.
      Wenn ich zum Beispiel sage, dass ich einen neuen Lecksensor in der Waschküche installiert habe, wäre es gut, wenn eine Automatisierung für Benachrichtigungen bei Lecks erstellt würde; wenn ich einen Temperatursensor im Wohnzimmer hinzufüge, sollte er mit anderen Sensoren zusammengeführt werden, um die Durchschnittstemperatur im Wohnzimmer zu aktualisieren.
    • Mich würde interessieren, welche Marke von Smart Bulbs ihr verwendet.
    • Mich würde interessieren, ob es Pläne für Automatisierungen auf Basis von Personen und Bereichen (Areas) gibt. Ich meine Areas, nicht Zones.
      Ein Projekt namens Bermuda[0] erzeugt auf Basis von Bluetooth-Geräten Ereignisse, wenn eine Person einen Bereich betritt oder verlässt; in Tests mit einem über Shelly-Schalter verfolgten Smartphone funktioniert das gut. Allerdings ist es schwer herauszufinden, wie man mit diesen Ereignissen tatsächlich Aktionen auslöst.
      Es wäre besser, wenn man nicht für jeden Bereich einzelne Automatisierungen erstellen müsste, sondern etwas sagen könnte wie: „Wenn nach Sonnenuntergang jemand hereinkommt, schalte das Licht in diesem Bereich auf 20 % ein.“
      [0] https://github.com/agittins/bermuda
  • Vor etwa 10 Jahren habe ich ein KNX-basiertes Haus gebaut und bin immer noch ziemlich zufrieden damit.
    Lichtschalter ins Smartphone zu packen macht das Ganze nicht intelligenter, sondern meist nur komplizierter.
    Die wertvollsten Automatisierungen waren automatische Jalousien, raumweise Beleuchtung, die bei Bewegung im Dunkeln angeht, und ein Nachtmodus. Die Jalousien fahren herunter, wenn die Sonne zu stark ist, fahren herunter, wenn es draußen dunkel ist, und fahren hoch, wenn der Wind zu stark ist. Dadurch muss ich mir keine Sorgen machen, nach der Arbeit in ein überhitztes Wohnzimmer zurückzukommen, und ich brauchte keine Klimaanlage; im Winter und Frühjahr kann aber automatisch direkte Sonne hereingelassen werden.
    Es gibt auch spielerische Automatisierungen. In leeren Räumen schließen sich die Jalousien vollständig; wenn jemand da ist, werden sie halb geneigt und folgen dem Sonnenwinkel, um ohne direkte Sonneneinstrahlung möglichst viel Tageslicht hereinzulassen. Wenn der Fernseher eingeschaltet wird, fahren die hinteren Jalousien herunter, die Spiegelungen verursachen; wenn die Terrassentür geöffnet wird, werden die Jalousien geöffnet und die Innenbeleuchtung ausgeschaltet, um weniger Mücken anzulocken. Der Bewegungssensor in der Dusche schaltet die Lüftung stark ein, einige Steckdosen werden für Weihnachtsbeleuchtung ein- und ausgeschaltet, und Geräte-, Wasser-, Lüftungs- und Heizungsdaten werden ebenfalls protokolliert.
    Mir gefällt, dass die Low-Level-Funktionen von KNX ohne zentralen Hub funktionieren, aber für High-Level-Funktionen braucht es zusätzliche Intelligenz, daher plane ich, dieses Jahr zu Home Assistant zu wechseln.

    • Mich würde interessieren, ob Bewegungssensoren im Vergleich zu eigenständigen Bewegungs- oder Feuchtigkeitssensoren einen praktischen Mehrwert bieten.
      Mit einfachen eigenständigen Bewegungssensoren ließe sich vermutlich schon ein großer Teil eines Smart Homes zu geringeren Kosten und ohne Wi-Fi-Abhängigkeit erreichen.
    • Mücken werden eigentlich nicht von Licht angezogen; andere Insekten werden von Licht angezogen. Soweit ich weiß, werden Mücken von CO2, Atem, Blut und Schweiß angezogen.
  • Ich mag Home Assistant wirklich sehr, sehe es aber eher als sehr unterhaltsames Hobby.
    Wartung, Dashboard-Konfiguration und die Integration drahtloser lokaler Netzwerkstandards werden sehr schnell zu technischen Aufgaben. Trotzdem hat mich die Nutzung dazu gebracht, Haushaltsgeräte mit einer offenen Verwaltungsplattform zu bevorzugen.
    Ich habe weiterhin das Gefühl, dass man, wenn man nur die passende Nerd-Hardware kauft, ein Smart Home außerhalb der Cloud halten und trotzdem gute Automatisierungen bauen kann.

    • Ich nutze Home Assistant schon seit der Zeit vor der Lovelace UI, und es hat sich stark weiterentwickelt, aber es braucht weiterhin laufende Wartung. Weniger als früher, aber nicht null.
      Der eigentliche Zweck von HA und seinem Ökosystem liegt meiner Meinung nach darin, offene Verwaltungsplattformen voranzubringen. Ähnlich wie Matter die IPv6-Adoption auf Mikrocontroller-Seite vorantreibt.
      Jedes Jahr zum Jahresende kaufe ich günstige Geräte bei AliExpress und zerlege sie; 2024 habe ich zum ersten Mal gesehen, dass Hersteller es fast stolz herausstellen, wenn GPIO-Pins beschriftet sind und Programmierschnittstellen offenliegen. Wenn man will, kann man eigene Firmware aufspielen, und sie werben damit, WLED nativ zu unterstützen. Neu ist, dass Hersteller tatsächlich beginnen, sich auf die Free-Open-Source-, DIY- und „ich nutze nicht deine Cloud, ich habe meine eigene Cloud zu Hause“-Bewegung einzustellen.
    • Seit ich vor etwa 10 Jahren mit HA angefangen habe, lautete die erste Regel der Heimautomatisierung: offline.
      Inzwischen sind Hunderte Geräte verbunden, aber die einzige Cloud-Integration, die ich nutze, ist aus offensichtlichen Gründen Spotify. Beim Kauf smarter Geräte achte ich genau darauf, ob sie vollständig offline funktionieren, und wenn etwas smart ist, aber nicht ausschließlich offline, beschränke ich mich auf „dumme“ Haushaltsgeräte.
      Zum Beispiel hatte mein neuer Geschirrspüler bei Wi-Fi-Verbindung Smart-Funktionen, aber ich habe das Wartungsmenü gefunden, die Netzwerkschnittstelle komplett ausgeschaltet und nutze ihn nun nur als normalen Geschirrspüler. Das gefällt mir.
    • Ich habe das gelöst, indem ich die meisten HA-Entitäten über die integrierte HomeKit-Bridge in HomeKit verfügbar gemacht habe.
      Dadurch sind sie nahtlos in Siri integriert und auch für Nicht-Techniker leicht zu steuern, während ich gleichzeitig stärkere Automatisierungen nutzen kann.
      Zum Beispiel funktioniert die Anwesenheitserkennung tatsächlich als HomeKit-Automatisierung, die einen von HA bereitgestellten Binärsensor invertiert.
  • Das wichtigste Prinzip ist, „Smartness“ als Zusatzfunktion zu behandeln und die normalen Arten, mit dem Haus zu interagieren, nicht zu verändern
    Das dient der Akzeptanz durch den Partner bzw. die Partnerin und soll Besucher, insbesondere ältere Menschen wie die eigenen Eltern, nicht verwirren
    Konkret müssen Lichtschalter so funktionieren wie erwartet, die Temperatur muss sich am TRV regeln lassen, und die Grundfunktionen müssen weiterlaufen, selbst wenn die HA-Instanz abraucht
    Deshalb gibt es in manchen Räumen Bewegungssensoren, die nach Mitternacht das Hauptlicht oder eine kleine Lampe einschalten; der Lichtschalter schaltet aber immer das Hauptlicht ein und aus. Wenn X Minuten lang keine Bewegung erkannt wird, gehen alle Lichter aus
    Wenn meine Mutter abends friert, dreht sie einfach am Regler, so wie sie es ihr Leben lang getan hat. Keine App, keine Touch-Tasten am TRV, kein „hey Google … nein, sori? Siri? Sohn, hilf mir!“. Die Smartness steckt im Gesamtzeitplan und im Bewegungssensor, der den TRV nach einer manuellen Änderung wieder auf den Zeitplan zurücksetzt, wenn 15 Minuten lang keine Bewegung erkannt wurde
    Deshalb setze ich statt smarter Glühbirnen Relais in die Lichtschalter und betreibe sie nicht im entkoppelten Modus. TRVs haben einen Drehregler, daher funktioniert dieser Ansatz dort natürlich

    • Persönlich halte ich einen DIY-Thermostat ohne Tasten zum Ändern der Temperatur für ein Feature, aber Menschen haben ein unterschiedliches Gefühl dafür, wer einen Thermostat einstellen können sollte; deshalb sind Optionen gut
    • Viele gute smarte Glühbirnen haben die Option, sich an einem normalen Lichtschalter wie eine normale Glühbirne zu verhalten
      Manche kehren nach Wiederherstellung der Stromversorgung zum letzten Zustand zurück, andere schalten sich in einem einfachen, gewöhnlichen Lichtzustand ein. Solche Optionen und Einstellungen wie „nach Stromrückkehr ausgeschaltet bleiben“ lassen sich leicht ändern; deshalb kaufe ich weiterhin teurere smarte Glühbirnen. So lässt sich etwa vermeiden, dass das Schlafzimmerlicht nach einem nächtlichen Stromausfall „aufblitzt“ und einen aufweckt
      Selbst wenn die Glühbirne das nicht richtig unterstützt, kann der Hub, wenn er erkennt, dass ein Licht aus dem Netzwerk verschwunden ist und wieder auftaucht, per Software bis zu einem gewissen Grad einen sinnvollen Standardzustand nachbilden
    • TRV steht für Thermostatic Radiator Valve, also thermostatisches Heizkörperventil
  • Zu Hause fahre ich Automatisierung auf diesem Niveau gerade zurück
    Höchstens denke ich noch über ein smartes Panel nach, das im gesamten Hauptwohnbereich einfache, nicht-smarte LED-Lampen ein- und ausschaltet sowie dimmt
    Derzeit habe ich 14 damals teure GU10-LIFX-Lampen, die inzwischen schwer zu bekommen sind und nach einer Änderung der Wi-Fi-Konfiguration nicht mehr sinnvoll über die Wandschalter ein- und ausgeschaltet betrieben werden. Ich hatte keine Lust, die Lampen manuell zurückzusetzen, herauszuschrauben und sie dann langsam und schmerzhaft wieder ins Wi-Fi einzubinden. Das ist zu einem großen Teil selbstverschuldeter Schmerz, denn ich hätte von Anfang an eine unveränderte SSID nur für diese Infrastruktur verwenden sollen
    Während die smarten Glühbirnen zu dummen Glühbirnen geworden waren, hatte ich tatsächlich kaum Bedarf, die Helligkeit zu reduzieren, Farben zu ändern oder Smart-Funktionen zu nutzen. Am Ende klingt es nach einer guten Idee, aber ich glaube, ich habe die einfache Aufgabe „Licht einschalten“ überdacht

    • Die meiste Smart-Home-Technik verkauft sich nicht, weil sie wirklich hilft, sondern weil sie cool aussieht oder plausibel klingt
      Smarte Glühbirnen sind zum Beispiel dumm, weil sie die offensichtlichste und richtige Steuerungsmöglichkeit im Haus kaputtmachen: den Lichtschalter. Smarte Schalter sind eine viel bessere Idee und akzeptieren die Realität, dass der beste Zeitpunkt zum Einschalten des Lichts in den meisten Räumen der Moment ist, in dem man hereinkommt und den Schalter drückt
      Monitoring kann wirklich nützlich sein, und dezente Zeitsteuerung ist ebenfalls gut, aber die Leute übertreiben es auf wirklich dumme Weise
    • Für aktivere Anforderungen baue ich gerade ein lokales LLM-Sensor-Array auf. Dabei bekommt jedes Sensor-Bündel einen eigenen Thread
      Ich will keine else-Bedingungen, und ich will auch nicht, dass das Licht angeht, wenn ich x oder y tue. Sensoren sind bei AliExpress billig und reichlich vorhanden, und etwas wie ein esp32-s3 reicht aus
      Ein Smart Home sollte statt nach vordefinierten Bedingungen zu handeln meine Bedürfnisse dynamisch vorhersagen und mehr können als „mach das Wohnzimmer rot“
    • Wenn ich eine dedizierte SSID für diese Infrastruktur hätte verwenden können, hätte ich Telefon und Laptop einfach auf eine neue 5-GHz-SSID umgezogen
      Dann wäre das bestehende 2,4-GHz-Netz für IoT da
    • Der Hauptzweck smarter Glühbirnen scheint darin zu liegen, eine Zeitschaltuhr für Lampen mit Wandschalter zu haben. Aber das geht auch mit einem smarten Dimmer
      Schade, dass so viele „smarte“ Geräte verlangen, zum Einschalten des Lichts zwingend mit einem chinesischen Server oder irgendeinem Server außerhalb meines LAN zu kommunizieren
  • Die 99-Dollar-Hardware von Home Assistant funktioniert sehr gut
    Manche Geräte sind gesprächig, aber mit zwei Zeilen in der Startkonfiguration lässt sich das meiste herausfiltern, ohne nützliche Funktionen zu verlieren
    Es wäre erstaunlich, wenn die im Wohnzimmer erzeugten Daten SQLite auf eMMC überfordern würden
    Home Assistant ist eines der wenigen jüngeren Produkte, bei denen mir der Einrichtungsprozess Spaß gemacht hat. Die Menge an seltsamen Geräten, die es im Netzwerk gefunden hat, war beeindruckend; noch beeindruckender war, wie viele davon verschwanden, als verschiedene Cloud-Anbieter begannen, sie abzuriegeln. Das hat meine künftigen Kaufentscheidungen definitiv beeinflusst und mich zur Vereinfachung gebracht

    • Früher gab es das Problem, dass beim Herunterfahren die SQLite-Datenbank beschädigt wurde. Seit dem Umzug auf eine PostgreSQL-Datenbank in derselben VM ist es in Ordnung
    • Wenn HA und Raspberry Pi zusammen erwähnt werden, ist die größte Beschwerde immer die Zerstörung von SD-Karten
  • Ich frage mich, ob SQLite wirklich nicht durchhält. Das Problem scheint eher bei der Konfiguration oder im Code zu liegen als bei der Datenbank selbst
    Selbst ein älterer Raspberry sollte Tausende Schreibvorgänge pro Sekunde schaffen
    Für diesen Einsatzzweck könnte man wahrscheinlich pro Sensortyp eine eigene Schreibwarteschlange anlegen und Batch-Inserts verwenden

    • Darüber würde ich gern mehr wissen. Ich vermute, nicht SQLite war der Flaschenhals, sondern etwas anderes
      Ich kann mir kaum vorstellen, dass ein einzelner Haushalt SQLite[0] überfordert. Es sei denn, es gibt Tausende Geräte, die gleichzeitig schreiben wollen und nicht in einer Warteschlange auf ihre Reihe warten können
      [0] https://sqlite.org/whentouse.html
    • Ich bin der Autor des Originals. Sobald die Zahl der Sensoren zu wachsen begann, war SQLite das Problem
      Damals war es ein Pi 3; heute mag es besser sein, und ich weiß, dass es auch Verbesserungen bei der SQLite-Performance gab. In meinem Fall war es aber gelöst, als ich Zeitreihendaten nach Influx und die Datenbank nach MySQL verschoben habe
      Und egal wie gut eine SD-Karte ist: Bei so vielen Schreibvorgängen geht sie irgendwann kaputt
    • Diese Behauptung macht mich skeptisch. Ich verstehe nicht recht, wie mehrere Sensoren so viele Daten erzeugen können, dass sie einen Raspberry Pi überfordern
      Vielleicht lag das Problem darin, dass die Datenbank auf einer sehr langsamen microSD-Karte lag
  • So gut Home Assistant auch ist und so sehr es immer besser wird: Am Ende verwaltet man 10, 20, 50 oder mehr Geräte, die Updates bekommen können und im Netzwerk hängen.
    Ob Wi-Fi oder Zigbee – jedes hat seine eigenen Probleme, sie stören sich gegenseitig oder gehen einfach kaputt.
    Ich mag die Möglichkeiten, oft beruhigt es mich und es lässt sich gut vorführen, aber wie bei jeder persönlichen Infrastruktur wachsen mit den versunkenen Kosten auch Übelkeit und Reue.

    • Ich betreibe HA seit etwa einem Jahr, und es war sehr stabil. Zusätzlichen Aufwand machen eher die fehlerhaften Geräte.
    • Wenn wir kein echtes Standardprotokoll bekommen, das alle verwenden, brauchen wir vermutlich eher containerisierte Integrationen. Keine Ahnung, ob Matter sich durchsetzen kann.
      WebAssembly wirkt wie eine ziemlich plausible Möglichkeit, Plugins zu bauen, die keine laufende Wartung benötigen.
    • Ich frage mich, ob das eine typische Erfahrung für HA-Nutzer ist.
      Ich interessiere mich für HA, nutze derzeit aber HomeKit und Homebridge und fasse sie zwischen dem Hinzufügen oder Neukonfigurieren von Geräten kaum an.
  • Ich habe vor ein paar Jahren fast dieselben Schritte wie der ursprüngliche Autor durchlaufen und finde es schön zu sehen, dass er zur gleichen Schlussfolgerung gekommen ist.
    Statt einer VM habe ich dedizierte Hardware gekauft, weil ich es vollständig von meinem Homeserver trennen wollte, auf dem unwichtige Aufgaben laufen. Ich habe einen Minisforum-Mini-PC gekauft; für HA sind Leistung, RAM und Speicherplatz völlig überdimensioniert, aber genau so mache ich das eben.
    Bei über 100 Geräten bin ich auf MariaDB und Influx umgestiegen, und die Heizung habe ich schon vor ein paar Jahren gelöst. In jedem Raum des Hauses steht ein BLE-Temperatursensor Switchbot Meter Plus, und an jedem Heizkörper sitzt ein Z-Wave-TRV. Ich gruppiere die Werte nach Obergeschoss und Erdgeschoss sowie Tag/Nacht, mit einer Homeoffice-Ausnahme, und berechne daraus eine Art Durchschnittstemperatur.
    Ein Skript mit Hysterese schaltet die gesamte Heizung ein, wenn die Durchschnittstemperatur unter Solltemperatur -0,2 °C fällt, und aus, wenn sie über Solltemperatur +0,3 °C liegt. Jeder Raum hat seine eigene Solltemperatur; wenn die Raumtemperatur darüber liegt, wird das TRV geschlossen, und wenn sie darunter fällt, wieder geöffnet. Auch hier gibt es eine leichte Hysterese.
    Außerdem gibt es Automatisierungen für Tag-/Nacht-/Abwesenheitsmodi, die je nach Situation andere Solltemperaturen und Ein/Aus-Zustände pro Raum anwenden.
    Für die Beleuchtung nutze ich Circadian Lighting; es unterstützt Lichtgruppen, sodass man in YAML nur die Gruppe angeben muss und die ganze Gruppe verarbeitet wird. Einige Funktionen des Adaptive-Lighting-Plugins fehlen vielleicht, aber ich musste mich nicht um Unterschiede zwischen Lampentypen kümmern; etwa 80 % sind Hue, dazu kommen gemischte weiße und farbige IKEA-Lampen.

    • Ich bin der ursprüngliche Autor. Bei Flux oder Adaptive Lighting konnte ich Gruppen nicht zum Laufen bringen.
      Warum, weiß ich nicht, und ehrlich gesagt habe ich nicht viel Zeit investiert. Die Heizungsidee klingt gut, ich werde sie mir ansehen.
    • Wenn du einschaltest, sobald die Durchschnittstemperatur unter Sollwert -0,2 °C liegt, und ausschaltest, sobald sie über +0,3 °C liegt, ist das im Grunde der Ansatz, den ich hatte, bevor ich den generic thermostat helper entdeckt habe.
  • Ich wollte HA eigentlich nur nutzen, um von eingeschränkten oder schlechten Smart-Home-Apps wegzukommen, aber nachdem ich es zu Hause etwa sechs Monate lang für ein paar Dinge eingesetzt habe, gefällt es mir sehr gut.
    Dieses Jahr werde ich wohl ernsthaft mit Schaltern, Sensoren und Ähnlichem ausbauen.
    Das Projekt, in das ich am tiefsten einsteigen werde, ist das Verdrahten temperaturabhängiger PWM-Lüfter in einem IKEA-Schrank, in dem technische Geräte wie Spielkonsolen, Spannungswandler, Modem, Router, HA-Maschine und Laserdrucker stehen, damit nichts überhitzt. Ich freue mich darauf, loszulegen.
    Außerdem plane ich drahtlose Pflanzengießsensoren, die Steuerung von Jalousien und Vorhängen sowie eine Lüftungssteuerung auf Basis von Feinstaub, VOC und CO2.
    Smart Locks, Türklingelkameras oder normale Kameras reizen mich nicht besonders. Es ist ein bisschen unheimlich, aber ich verstehe den Reiz.

    • Für Kameras und Türklingelkameras nutze ich Frigate; je nach Konfiguration kann es Menschen, Tiere usw. erkennen.
      Die Türklingelkamera habe ich so eingerichtet, dass sie per TTS ansagt, wie viele Personen sich nähern, noch bevor sie nahe an der Tür sind und klingeln. Das ist praktisch für Lieferfahrer, die Pakete vor die Tür stellen, ohne zu klingeln, und auch allgemein nützlich für die Sicherheit.