Home Assistant richtig aufbauen: welche Ebene macht was ? 
14.9.
-19.9.2026 21 Antworten 10 Autoren
|
|
||
|
Ich find das grad wahnsinnig spannend zu lesen - vorallem weil ich das cool fände, wenn man sich da auch innerhalb des Forums bisschen austauschen könnte. Was mich vorallem interessiert (und eine Frage die mich schon länger umtreibt auf die ich aber noch keine befriedigende Antwort gefunden habe): Warum Home Assistant? Warum nicht FHEM, iobroker, openhab oder was es noch alles gibt? Bzw. wo würdest du die einzelnen Vor-/Nachteile sehen? |
||
|
||
|
Ich benutze HA seit 2022, wie ich vor kurzem feststellen konnte. Ich hatte das Problem unterschiedlicher Standards und Vendor Lock-in's. Da ich ganz gut in Programmieren bin, habe ich diverse Sachen ausprobiert und bin bei HA hängen geblieben, aber nicht so dogmatisch wie oben beschrieben. Bei mir ist es sukzessive gewachsen. Erst WLAN Steckdosen, dann Unterhaltungsgeräte, dann Stromzähler, dann Smart Meter, dann Wärmepumpe, dann PV, dann Wallbox. Meine Kenntnisse sind mit gewachsen, ich habe viel Community gelesen und inzwischen habe ich ein eecht umfangreiches System mit Peak Saving, Urlaubsmodus, Überschussladung, Alarmanlage etc Ich würde aber noch lange nicht von einem out-of-the-box System sprechen, ohne große Kenntnisse was IT und Algorithmen betrifft tut man sich vermutlich schon schwer, trotz KI und insbesondere bei der Fehlersuche. Aber der Invest lohnt sich, wenn man genug unterstützte Geräte hat. |
||
|
||
|
Danke für die Übersicht. Tatsächlich habe ich das beim Neubau (letzte Woche Dach gestellt, kabel für KNX also schon verlegt) so geplant. Grunddinge funktionieren direkt über den Bus, sobald Intelligenz gebraucht wird oder etwas nicht KNX kann über HA. |
||
|
|
||
|
||
|
Angefangen habe ich mit Homematic und ioBroker, weil es damals schlicht nichts anderes gab. Für mich gibt es seither zwei Kriterien, und die sind bis heute gleich geblieben: Das Smart Home muss stabil laufen und es muss einfach zu bedienen sein. Einfach heißt: Auch der Rest der Familie kommt damit zurecht, ohne mich zu fragen. Lange war Loxone für mich das Einzige, das diesen Spagat geschafft hat – offen genug, um etwas damit zu machen, und trotzdem eine Oberfläche, die man niemandem erklären muss. Mittlerweile kann Home Assistant genau das. Es spricht über fertige Integrationen einfach mit allen Geräten, und die Oberfläche ist so weit, dass man sie einem Laien in die Hand geben kann. Genau das fehlt mir bei ioBroker: Das System ist offen und kann viel, aber eine Oberfläche, die einfach zu bedienen ist, bekomme ich dort nicht geschenkt – die baue ich mir selbst zusammen. Bei FHEM gilt das noch stärker, bei openHAB ist das Konzept sauberer, aber die Gerätevielfalt kommt später an. Der für mich wichtigste Punkt ist aber ein anderer: Womit neue Hersteller heute werben. Ob X-Sense Rauchmelder oder Samsung Waschmaschine – auf der Verpackung steht „works with Home Assistant", nicht „kompatibel mit KNX" oder „Loxone-ready". Vor fünf Jahren war das undenkbar. Das ist für mich das klarste Signal, wohin sich der Markt bewegt, und ein guter Teil der Antwort auf deine Frage: Nicht weil HA technisch das Eleganteste ist, sondern weil dort die Geräte ankommen. |
||
|
||
In Zeiten von AI und Cybersecurity-Problemen durch diese möchte ich noch einen weiteren Punkt hinzufügen:
Ansonsten arbeite ich aktuell an einer kleinen Spielerei: Jarvis, das AI-Haus 😂Eine "lokale AI" hat Zugriff auf alle Datenpunkte und kann über Lautsprecher in fast allen Räumen Sprache ausgeben. Außerdem haben wir an vielen Stellen die HA-Voice Assistants geplant. So lassen sich viele nette Dinge bauen, von Intercom über Erinnerungen, Sprachsteuerung, etc. |
||
|
||
|
@TobiK welchen Zutritt hast du bei der Haustür gewählt ? Wenn du Tailscale nutzt und dort die Freigabe auf die Geräte begrenzt die wirklich auf das Haus zugreifen dürfen, ist fremden der Weg über das Internet schon mal verhindert. Die größten 2 Schwachstellen sind meistens das Zutrittsterminal und lokales Wlan. Dabei empfehle ich immer VLAN-fähige Access Points, managed Switches damit du ein "Maschinennetz" und Heimnetz errichten kannst. Damit kannst du alle smarten Geräte trennen von deinem Heimnetz. Die smarten Geräte bekommen dann zb. bei den TP-Link Omada Access Points die ich verbaue einen eigenen Wlan-Schlüssel pro Gerät. Damit sperrst du das Wlan komplett gegenüber fremden ab weil es nicht ein Wlan Passwort gibt und er kann auf deine Geräte zugreifen sondern jedes Gerät bekommt ein eigenes Wlan-Passwort zugewiesen. Natürlich brauchst du das für die Waschmaschine nicht, aber zB. das KFV Genius Motorschloss das du in der Haustür hast kann auch Wlan ;) |
||
|
||
|
Wir haben UniFi jetzt recht stark im Einsatz und dann Unifi Access geplant. Das ist m.E. das einzige System, dass nicht wirklich cloud-abhängig (= keine Subscription Costs + weniger Abhängikeit), günstig ist und Apple Wallet für den Zugang supported. Ich will keine App am Handy aufmachen, um die Tür zu öffnen, sondern nur die Uhr oder Smartphone an den Leser halten. Fingerprint ist auch eher nervig, das funktioniert oft nicht richtig. Zutrittsterminal meinst du fürs Motorschloss? Zumindest dann, wenn man einfach die Relais-Kontakte nach außen geführt hat... 😬Dass jemand im EFH anfängt, irgendwelche proprietären Protokolle der Hersteller anzugreifen, halte ich für recht unwahrscheinlich, zumindest aktuell noch. D.h. du verwendest für jeden PSK ein eigenes VLAN? Wäre natürlich das Maximum an Mikrosegmentierung. Nur eigener PSK und irgendeine TP-Link-eigene "Isolierung" würde ich erst einmal kritisch sehen. Ggü. Fremden sehe ich das anders: natürlich macht es Sinn, ein eigenes VLAN/SSID oder gar mehrere für IOT-Devices zu machen und am besten auch ein Gäste-WiFi, aber pro Gerät ein PSK und VLAN halte ich für etwas übertrieben. Schaden tuts aber nicht😁 Das Motorschloss gehört für mich grundlegend in kein WiFi. Siegenia ist jetzt kein kleiner Hersteller, aber DormaKaba z.B. auch nicht. Und DormaKaba ist aus Security-Sicht eine Katastrophe. Ich habe in einer Security-Analyse mittels Reverse-Engineering div. Schwachstellen analysiert. Das war sehr simpel, denn deren eigenes Protokoll hat einfach gar keine Sicherheitsmechanismen implementiert und stammt aus der Zeit, als alles über RS485 ging. Ich möchte auch keine augenscheinlich billig hergestellten Apps und Cloud-Dienste, die meine Haustür steuern können😊 |
||
|
||
|
Selbst Uhr oder smartphone an den Leser halten ist imho zu nervig. Ich nutze ein switchbot ultra vision lock. Auf dem Weg zur Tür einfach in den Leser "reinschauen" und in 2 Sek. ist die Tür offen. Funktioniert perfekt und eben auch mit den Einkaufssackln in den Händen. Will nichts anderes mehr! |
||
|
||
|
Ja, das kann das UniFi zeug auch, bin da nur etwas skeptisch mit Gesichtserkennung. Muss ich mir im Detail noch anschauen, aber das wäre vom Komfort natürlich noch besser. Das Switchbot-Teil ist leider ultrahässlich 😀 |
||
|
||
|
das is richtig - mir aber vollkommen wurscht ...bzw. find ich jedes kastl eher nicht schön, aber wie gesagt - egal |
||
|
||
|
Eine SSID je Gerät? Ich kenne die TP-Link-Geräte nicht (das ist mir zu Consumer, tbh), aber auch diese werden relativ schnell an ihr Limit kommen, was die Anzahl an möglichen SSIDs je AP betrifft. Die liegt doch idR irgendwo zwischen 4 und 16 SSIDs. Davon abgesehen, dass es absolut nicht empfohlen wird, so viele SSIDs auszusenden. Don't get me wrong: Ich würd die Segmentierung, die im LAN mit VLANs möglich ist, im WLAN auch gerne so machen, aber da gibts leider Grenzen. Ich segmentiere meine "smarten" Geräte (Wechselrichter, Wallbox, Heizung, ...) in jeweils eigene VLANs und achte halt auch darauf, dass alle verkabelt werden können. Hab jetzt grad ein Bastelprojekt mit einem Füllstandmesser für die Zisterne laufen und da muss ich den ESP32 "leider" auch verkabeln, sonst müsst ich echt mit WLAN anfangen. |
||
|
||
|
Nein, eine SSID und mehrere PPSK. Du kannst dann je nach Setup einen PPSK ein jeweils unterschiedliches/eigenes VLAN zuweisen und damit eine Mikrosegmentierung umsetzen. Dann brauchst eben noch eine Firewall, in der du für die jeweiligen Devices wieder Verbindungen erlaubst. Technisch gehts genauso, muss eben nur supported werden von der WiFi-Infrastruktur. TP-Link Omada hat nichts mit den Consumer-Geräten zu tun, mein Geschmack ist es aber auch nicht. Was versprichst du dir davon? Es schadet ja nichts, aber in der Praxis wird eher die HA-Instant gehacked, die dann eh mit allen Geräten sprechen darf. |
||
|
||
|
Wie soll dieser Hack aussehen? Zero Day Exploits? Brute Force? Social Engineering? Ich finde da wenig oder fast nichts dazu...? |
||
|
||
|
OTOT [Off Topic]: Und ich ergänze gerne um Poolpumpe, Smart Locks, Grillthermometer, Statusabfrage von Kochfeld, Backofen und Trockner, ... Nur Kamera (nicht vorhanden) und Staubsaugroboter sind bei mir derzeit extra, alles andere ist nativ in Loxone eingebunden bzw. wird von dort auch angesteuert. (wobei die Haupthaustechnik auch standalone bzw. bei Ausfall von Loxone weiterläuft.) Aber ich verstehe prinzipiell die Intention schon. |
||
|
||
|
Am gängigsten sind wohl die Kombination aus "öffentlich" erreichbaren HA-Instanzen (einschließlich der, die mit dem Nabu Casa-Proxy veröffentlicht sind) und gestohlene Session Cookies / Zugangsdaten ("Inofstealer"). Da HA AFAIK im Standard immer noch kein MFA enforced und die Sessions aus nachvollziehbaren Gründen sehr lang laufend bzw. gar unlimitiert sind, ist der Weg besonders einfach. Also am besten die HA-Instanz nicht öffentlich erreichbar machen (nur per VPN) + MFA aktivieren sowie immer brav updates installieren. Das wäre aus meiner Sicht immernoch der beste Weg, solange die Funktionen ausreichen. Damit ist man am unabhängigsten von Software, die eher ausfällt, Update-Zyklen, defekter Server-Hardware oder RasbPis etc. Ich bin gespannt, ob es mir irgendwann geht wie meinen Eltern, die sagen "möglichst wenig Technik im Haus, die kaputt gehen kann". |
||
|
||
|
Eine SSID je Gerät? Nein das stimmt das wäre übertrieben. Du hast 2 SSID dann zu Hause, Heimnetz und Smarthome. Beim Smarthome Netz wird das Feature bei Omada PPSK (Private Pre-Shared Key) aktiviert. Damit bekommt jedes Gerät (oder jede Gerätegruppe) im selben SSID ein eigenes Passwort. Passphrase, VLAN und die MAC-Adresse(n) des Geräts lassen sich dabei miteinander verknüpfen, sodass sich nur das festgelegte Gerät mit dieser Passphrase anmelden kann. Damit hat jedes Gerät sein eigenes WLAN - Passwort für das Netz Smarthome. Kritische Geräte (Wallbox, Wechselrichter, Klima, Türschloss) bekommen einen eigenen Schlüssel mit MAC-Bindung. Unkritische Geräte (Steckdosen, Lampen, Sensoren) können sich einen gemeinsamen Gruppenschlüssel ohne MAC-Bindung teilen. Damit du nicht 50 Passworter speichern musst. Der Vorteil ist aber, dass viele smarten Geräte teilweise das Passwort unverschlüsselt speichern. Sobald jemand das Passwort hat, kann er auf alle Geräte im Grunde zugreifen. Beim PPSK setup erhält er nur das Passwort des einen Geräts und kommt nicht weiter. Man kann das Thema natürlich auf die Spitzte treiben, aber das ist finde ich ein guter Kompromiss zumal anständiges Netzwerk für ein EFH bei TP-Link Omada mittlerweile im Bereich 1.000-1.500€ VK bereits zu haben ist. Unify kann das auch nur muss hier min. Faktor 1.5 drauf gerechnet werden. |
||
|
||
|
Super - genau so solls laufen. Das Hausbussystem ist kein Ersatz für HA und alles was ich da günstig reinbekomme wird natürlich direkt über das Bussystem angesteuert. Kann dir gerne auch die Loxone Integration empfehlen damit du entweder die Visu und Logikeben dann im HA fährst oder die Geräte einfach in die Loxone bekommst. In den Screenshots auf Git sind beide Wege erklärt. https://github.com/smartmacherei/Loxone-Integration |
||
|
||
|
Hab mir gerade die Integration angeschaut. Die Werte die dann nach Loxone übermittelt werden, kann man da auch das 5 Minuten Intervall kürzer einstellen? Übrigens, als ich HA mit Duckdns + Reverse Proxy öffentlich ins Internet hatte (für Zugriff am Handy von unterwegs), war ich am Anfang erschrocken wie oft probiert wird da zu zugreifen. Ich habe ein Unifi Netzwerk und da sieht man das ja genau. Da waren stündlich mehrere Zugriffe. Habe dann umgestellt auf Tailscale und seitdem ist mehr oder weniger Ruhe eingekehrt. Gan ganz selten, dass ich da eine Benachrichtigung bekomme wegen einem möglichen externen Zugriff. |
||
|
||
|
Wo genau liegt denn der Mehrwert zu Pyloxone? Ich bin seit 2022 mit Home Assistant und Loxone unterwegs - viel genanntes aus dem Thread kann ich unterschreiben, das macht alles Spaß, Sinn. Man sollte nur die Aufwand-Seite nicht vergessen - für uns Nerds alles fein, aber hatte in den Jahren auch so manche Probleme. pyloxone war noch nicht so toll und regelmäßig gewartet wie heute, ich war dann echt verzweifelt weil mit jedem Home Assistant Upgrade auf neuere Version ging Loxone nicht mehr. Kurz davor gewesen, alle Rollos auf Shelly Pro umzulegen im Schaltschrank, dann mit HA komplett neu losgelegt, und irgendwie wieder die Schnittstelle zum Laufen gebracht - also manche Stunden hätt ich mir da auch sparen können. Die Kombination ist toll und so auch nur in HA möglich... ich nenn mal ein aktuelles Beispiel: Die Leuchte eines Nebengebäudes hängt an einem Shelly. Der Auslöser für 1min ist "Tier erkannt" der Ubiquiti Kamera, Auslöser für 30min Licht ein ist wiederum "Fahrzeug oder Person erkannt". Solche übergreifenden Experimente stell ich mir rein in Loxone schwierig vor. Früher hatte ich per Webhook/UDP Befehl auch shellys über Loxone angesteuert, doch das geht ja in HA bei weitem einfacher. Mittlerweile so viele Einzelsysteme am Laufen, die wunderbar in HA zusammenfinden, hoffe das geht die nächsten Jahre so weiter! Die Geräteeigene Visu und auch Loxone Visu wird überhaupt nicht genutzt, alles über HA. Damit passt dann auch der WAF. 😉 |
||
|
||
|
Servus! Homeassistant bitte nur mit Tailscale nach außen freigeben. Hier müssen keine Ports dafür geöffnet werden. Die Werte werden per UDP von Loxone nach HA übertragen, d.h. in der Regel passiert das in Echtzeit sobald sich der Wert in Loxone ändert. |
||
|
||
|
Servus, danke für den Erfahrungsbericht. Genau die Stellen waren bei mir der Anlass. Der Unterschied ist im Kern: PyLoxone sieht das, was in der Visualisierung steht. Meine Version liest zusätzlich das Miniserver-Programm und findet die physischen Ein- und Ausgänge — du musst also nicht an jeder Klemme „In Visualisierung verwenden" setzen. In HA landen sie nach Gerät gruppiert statt als flache Entitätsliste, und die Loxone-Visu bleibt auf das beschränkt, was du dort wirklich brauchst. Damit solche Klemmen auch in Echtzeit kommen, richtet die Integration die UDP-Logger im Miniserver-Programm selbst ein. Da liegt der Plug&Play-Teil, aber auch das Risiko: Das Programm wird geändert. Deshalb wird vorher das vollständige Original gesichert und geprüft — scheitert die Sicherung, gibt es weder Upload noch Neustart. Ohne den Weg bleibt es beim 30-Sekunden-Polling. Die Gegenrichtung gibt's auch, und da passt dein Kamerabeispiel gut. Statt Webhook oder UDP von Hand: der HA-Entität das Label loxone geben, einmal den Knopf drücken, danach steht der Wert in Loxone Config unter den virtuellen Eingängen und wird wie jeder andere Befehl auf die Seite gezogen. Das ist neu in 1.7.0 und bei mir noch nicht auf fremder Hardware abgenommen. Gateway/Client mit mehreren Miniservern läuft, an einer Anlage mit vier Stück bestätigt. Abfragen sind gedeckelt, deaktivierte Entitäten werden gar nicht abgefragt, und loxone_event feuert nicht mehr auf den Bus — das hält die Recorder-DB klein. Zu den HA-Upgrades: versprechen kann ich dir da nichts. Was ich mache, ist einen Miniserver gegen echtes HA laufen zu lassen. Rückmeldungen von Anlagen, die anders aussehen als meine, helfen mir dabei am meisten. https://github.com/smartmacherei/Loxone-Integration |
Beitrag schreiben / Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]