Das Szenario mit der zweiten Instanz klingt für mich plausible. 
Ansonsten habe ich keinerlei Ärger mit der Vollintegration. 
1 „Gefällt mir“
Im Grunde laufen die meisten HA stabil, aber z.B. gestern habe ich wieder so einen Fall gehabt. ich habe auf die 2026.3.4 hochgezogen und habe aber vergessen gehabt, dass meine Miner Integration da nicht mehr geht.
Dachte OK kein Problem einfach per HA Backup auf die Vorversion zurück! Pustekuchen das letzte Backup war anscheinend defekt und HA hat nicht mehr gestartet! Habe es dann über die Konsole wieder hingebogen, nur bei dem letzten Backup war kein Hinweis das es defekt ist erst nach der misslungenen Wiederherstellung kam die Meldung!
Wenn man dann nicht weiß wie man sich helfen kann, hast du eine Baustelle. In Proxmox hast du dann auch immer noch die Möglichkeit von dort die Backup zurück zuspielen.
1 „Gefällt mir“
Spannende Diskussion! Für mich ist die Entscheidung mittlerweile klarer: Separater Docker-Container.
Der Hauptgrund ist die Ausfallsicherheit für mein Sicherheitsnetzwerk (z. B. Garagentor-Steuerung und Gefrierschrank-Überwachung). Wenn ich Home Assistant mal updaten oder neu starten muss, bleibt das Zigbee-Netzwerk im Hintergrund zu 100 % stabil und aktiv. Die Geräte müssen sich nicht nach jedem HA-Restart neu finden, und kritische Alarme gehen nicht ins Leere.
Da ich einen SMLIGHT Stick (Netzwerk-basiert via LAN) nutze, ist das Setup im Docker sogar noch einfacher: Ich muss mich nicht mit USB-Passthrough herumschlagen, sondern binde den Stick einfach über die IP-Adresse in die configuration.yaml von Zigbee2MQTT ein.
So habe ich ein extrem robustes System, das völlig autark neben Home Assistant läuft. Wie handhabt ihr das bei kritischen Sensoren – vertraut ihr da voll auf das HA-Add-on oder trennt ihr das auch lieber?
Welchen Einfluss hat ein reiner HA-Neustart auf das Zigbee-Netzwerk?
Eigentlich interessiert das Zigbee Netzwerk den Neustart überhaupt nicht.
Da ja der Koordinator das Netzwerk verwaltet.
Ich denke da kommt es eher darauf an, was der Neustart mit dem verwendeten USB Port macht. ??
Da du ja über ein Netzwerk-Stick gehst, sollte das keinen Einfluss haben.
So einen Nutze ich auch, da konnte ich ihn besser im Haus positionieren, in Sachen Empfang.
Als USB in der Server-Ecke wäre das etwas Problematischer geworden.
So wirklich „kritische“ Sensoren habe ich nicht.
Kühlschrank/Gefrierschrank nicht über geschaltete Dosen..
.
Das einzige was ich überwache, ist mein Internett Zugang und mit meinem Testsystem das Hauptsystem.
Wenn da was über eine bestimmte Zeit nicht erreichbar ist geht eine Bestimmte Lampe auf Rot..
Achja. Erreichbarkeit meiner PV-Wechselrichter sind da auch überwacht.
Gute Frage! Man muss hier zwischen dem Funknetzwerk und der Datenverarbeitung unterscheiden:
Die Funkschicht (SMLIGHT Stick): Da mein SMLIGHT Koordinator per LAN angebunden ist, bleibt das Zigbee-Mesh (die Verbindung zwischen den Geräten) physisch bestehen, solange der Stick Strom hat. Ein Neustart von Home Assistant stört das Funknetz an sich nicht.
Die Datenschicht (Zigbee2MQTT): Hier liegt der entscheidende Unterschied. Wenn Z2M als Add-on in HA läuft, wird der Dienst bei jedem HA-Update/Neustart mit beendet. In dieser Zeit ist das System ‚blind‘. Kritische Sensoren (wie mein Gefrierschrank-Alarm) können zwar funken, aber niemand nimmt die Nachricht an oder verarbeitet sie.
Der Einfluss auf HA: Durch den separaten Docker-Container auf meinem Ugreen NAS entkopple ich das komplett. Der Einfluss ist positiv: HA startet schneller, weil es nicht auf den Start des Zigbee-Stacks warten muss. Sobald HA hochgefahren ist, liegen alle aktuellen Gerätestatus bereits im MQTT-Broker bereit und werden sofort übernommen.
Für mein Sicherheitsnetzwerk (Garagentor/Gefrierschrank) bedeutet das: Null Ausfallzeit in der Überwachung, selbst wenn ich an der Home Assistant Konfiguration bastle. Wie seht ihr das – ist euch die Trennung der Dienste bei kritischen Sensoren auch so wichtig?
Sorry, das ist nicht richtig. Bei einem reinen HA-Neustart laufen die Add-ons (neu Apps) weiter.
Nur wenn du das ganze System (HAOS) neustartest, dann werden auch die Apps neugestartet, also auch Mosquito und Z2M.
Doch das ist vergleichbar mit einem Neustart eines Container-Wirtsystems.
Richtig ist, dass ohne laufendes HA keine Reaktionen/Aktionen bzgl der Zigbee-Geräte stattfinden. Doch auch das gilt für ein separat laufendes Z2M.
Dies ist ein Screenshot mit Glances, was ebenso wie Mosquitto und Z2M als App läuft
1 „Gefällt mir“
Guter Punkt, danke für die Klarstellung! Du hast recht: Beim reinen Core-Neustart laufen die Add-ons im Hintergrund weiter.
Der entscheidende Vorteil der Trennung auf mein Ugreen NAS ist für mich aber die logische und physische Unabhängigkeit:
Updates & Wartung: Muss ich das gesamte System (HAOS) updaten oder den Host neustarten, ist bei der Add-on-Lösung alles weg. Mein separater Z2M-Container merkt davon nichts.
Sicherheit bei Abstürzen: Wenn der HA-Supervisor mal ein Problem hat (was leider vorkommt), reißt er oft die Add-ons mit oder macht den Zugriff schwierig.
Ressourcen: Ich entlaste die HA-Maschine und habe Z2M als dedizierten Dienst, den ich unabhängig sichern und updaten kann, ohne mein Hauptsystem anzufassen.
Gerade wegen des SMLIGHT LAN-Sticks finde ich es genial, dass Zigbee bei mir ein eigenständiger Netzwerk-Dienst ist und kein ‚Anhängsel‘ einer Smart Home Software. Aber wie du sagst: Für viele reicht die Add-on-Lösung völlig aus – je nachdem, wie kritisch man die Trennung sieht.
Da die Meldungen über HA ausgelöst werden, werden zwar die Werte weiter erfasst und in Zigbee2MQTT gespeichert, aber solange HA nicht funktioniert, erfolgt doch auch keine Meldung, falls was ausfällt, oder sehe ich das falsch? Es gibt immer ein für und wider und je nach Umgebung UND “GESCHMACK” sieht das jeder anders. Ein 100%iges Richtig, wird es vermutlich auch hier nicht geben.
Fällt mein HA aus und mein Zigbee2MQTT läuft als App auf HA, bekomme ich keine Meldung, dass der Gefrierschrank nicht mehr geht. Läuft es als separater LXC, werden die Daten gespeichert, aber nicht verarbeitet und ich bekomme ebenso keine Meldung. Also? Ob sich ein Mehraufwand bei der Konfiguration lohnt (separate LXC auf Proxmox anzulegen) oder nicht, muss jeder selbst entscheiden. Natürlich kann man alles (Zigbee2MQTT/Mosiquitto Broker, Grafana usw.) in separaten Containern auf Proxmox laufen lassen. Dann gilt es aber auch, die Firewall Regeln entsprechend zu setzen und netzwerktechnische auch den Überblick zu behalten. Vorteil der Backups/Snapshots in Proxmox sind jedoch klar von Vorteil. Zusatzaufwand wäre der Nachteil. Ich muss mich halt bei allen Containers separat anmelden und updaten. Und von der Übergabe bzw. Übernahme eines Systems im Notfall (lange Krankheit oder Tod), möchte ich noch gar nicht reden.
Meine MariaDB für Home Assistant läuft auch separat in einem LXC, weil ich die MariaDB noch für andere Sachen nutze. Hier war meine Intention, dass die Updates/Backups von HA schneller gehen, weil beim Backup keine Datenbank mit gebackupt werden muss.
Zum Schluss ist das aber nur meine persönliche Meinung in meiner Betriebsumgebung. Das kann bei Anderen schon anders aussehen, weil das Grundgerüst oder/und die Kenntnisse ganz andere sind.
Häufiger als andere Container-Wirtssysteme?!
Gilt auch für jedes andere Container-Wirtssystem (Proxmox et al)
als App aktualisiere ich Z2M völlig unabhängig von HA.
und mit Automatic Backup sichere ich z.B. Z2M und Mosquitto als dediziertes Backup
Ich hab nix gegen Container-Wirtssystem, eher etwas dafür. Ich habe nur etwas gegen unvollständige bis inkorrekte Informationen
Danke Nicknol für den Deep-Dive! Du hast völlig recht: Der reine Core-Restart lässt die Add-ons (Docker-Container) meistens unberührt. Das hatte ich in der Hitze des Gefechts etwas zu pauschal formuliert.
Mein eigentlicher Punkt für die Meinungsumfrage war aber ein anderer: Die physische und logische Entkoppelung.
Durch meinen SMLIGHT LAN-Stick ist Zigbee bei mir kein lokales USB-Anhängsel mehr, sondern ein eigenständiger Netzwerk-Dienst. Wenn ich Zigbee2MQTT in einem separaten Docker (auf meinem Ugreen NAS) laufen lasse, erreiche ich eine Ausfallsicherheit, die ein All-in-One-System systembedingt nicht hat:
Wartungsfreiheit: Ich kann mein komplettes Home Assistant System (oder die VM/den Host) updaten, neu aufsetzen oder Hardware-technisch umziehen – mein Zigbee-Netzwerk im Docker bekommt davon nichts mit und läuft 24/7 durch.
Multi-Client: Die Daten landen im MQTT-Broker. Ich kann sie in HA nutzen, aber gleichzeitig auch in anderen Tools (InfluxDB, Node-RED, Notfall-Dashboards), selbst wenn HA gerade wegen eines fehlerhaften Updates komplett steht.
Hardware-Flexibilität: Mein NAS steht im Keller, der SMLIGHT Stick per LAN optimal platziert im EG. Ich brauche keine USB-Verlängerungen oder Sorgen wegen Funkstörungen am Server.
Für mich ist das eher eine Architektur-Frage: ‚Zentrales System‘ (einfach, alles in einer Hand) vs. ‚Modulare Infrastruktur‘ (maximale Freiheit). Mich würde interessieren: Gibt es hier noch mehr Leute, die ihre Funk-Infrastruktur bewusst physisch von der Logik-Ebene (HA) trennen, oder ist euch das zu viel Administrationsaufwand?
Mehr fragen/Fragen, mehr unterschiedlichen Antworten . Wie ich schon sagte: Hat alles Vor- aber auch Nachteile.
Zigbee ist dann bei dir ein abhängiger Netzwerkdienst. Abhängig von:
- Netzteil des SM-Light-LAN-Sticks, das ist sicher nicht redundant
- oder, falls du ihn per PoE betreibst, abhängig vom PoE-Switch und des Netzteils, vermutlich nicht redunddant
- deinem Router. falls der ausfällt wegen HW-Schaden, Firmware-Upgrade, Problem mit dem Netzteil, hast du kein Zigbee
der USB-Zigbee-Coordinator ist unabhängig von sämtlichen Netzwerkelementen, sondern nur vom HA-System. Welches bei mir mit einem 3h-Akku recht sicher vor Stromausfällen läuft.
Dein Z2M im NAS ist unabhängig von der HA-Hardware, ist aber abhängig vom NAS. Hat das 2 Netzteile? an 2 Stromkreisen? oder eine USV?
Wo wird dein Z2M gesichert? Vermutlich auf dem NAS. Falls das NAS ausfällt (HW-Schaden, fehlgeschlagenes Upgrade, ..) hast du weder Z2M noch ein Backup von Z2M.
Bei mir liegt das Z2M Backup lokal, auf dem NAS und in meiner Cloud.
Der MQTT-Broker stellt die Daten immer „allen“ zur Verfügung, unabhängig auf welchem Wirt er läuft
Ist gerade bei Zigbee kein echtes Thema, die vielen Zigbee Router (Lichter, Steckdosen, …) bringen das Zigbee-Netz überall hin, da braucht es nicht unbedingt einen zentral platzierten Coordinator - der natürlich hilfreich ist.
Die Ausfallsicherheit des Gesamtsystems ist das Produkt der Ausfallsicherheiten der Einzelsysteme.
Je weniger Systeme desto höher ist die Ausfallsicherheit. Pure Mathematik.
Es gib kein non-plus-ultra-System, doch eine holistische Betrachtung ist sinnvoll, danach kann eine Bewertung unter der Berücksichtigung der eigenen Vorlieben erfolgen.
1 „Gefällt mir“
Von mir mal eine andere Betrachtungsweise:
In meinem System ist alles voll integriert
Demnach Antwort auf die Eingangsfrage : A
Läuft super, sehr stabil und performant. CPU-Last 1% mit Mini-PC
- Frage : Wann “fällt” HA aus? Bei mir nur durch Neustarts:
- Wie oft? Bei mir ca. 2x pro Monat
- Wie lange? Bei mir ca. 1 Minute pro Neustart.
- Ist das schlimm? Nein!
Unsere 3 Kühl- bzw. Gefriergeräte machen im Zeitraum von einer Minute keine Problem, Dort habe ich auch eine Hosenträger mit Gürtel - Automation bzw. Überwachung. Leistungsaufnahme, Temperatursensor und Türkontakt. Wenn HA “wiederkommt” kommen auch alle Sensoren Aktoren und Automationen, sowie Notifys wieder.
Die Garagentore werden nicht mit HA gesteuert (Öffnen/Schließen) sondern nur überwacht und gemeldet.
Ok, Bewegungsmelder zB. machen in der einen Minute kein Licht mehr an oder aus.
Aber ich muss auch nicht bei Dunkelheit, oder wenn “wichtige” Dinge laufen, mein HA neu starten.
Wenn der Server abraucht, geht so oder so nix mehr. Es sei denn, man hat Redundanzen oder Cluster.
Ein vorstellbares Szenario wäre, folgende Komponenten auszulagern:
- Nod-RED
- Mosquitto
- Z2M
Die könnten dann im eigenen Saft, unabhängig von HA laufen und funktionieren.
Aber auch nur zu einem hohen Prozentsatz, weil Notify auf’s Handy, oder gerätespezifische Sensoren, wie zB. von einer Auto-Integration funzen dann auch nicht mehr.
Trotzdem werde ich irgendwann wieder Proxmox aufsetzen - weil’s einfach cool ist.
1 „Gefällt mir“
Starke Punkte, Nicknol! Deine mathematische Herleitung zur Ausfallsicherheit ist absolut logisch – weniger Glieder in der Kette bedeuten weniger potenzielle Fehlerquellen. Da hast du mich eiskalt beim Wort genommen.
Ich sehe schon, wir verfolgen da einfach zwei unterschiedliche Philosophien: Dein hochoptimiertes All-in-One-System vs. mein modulares Netzwerk-Design. Beides hat Hand und Fuß, je nachdem, was man priorisiert.
Ich bleibe bei meiner ‚Spielerei‘ auf dem Ugreen, einfach weil ich die physische Trennung der Dienste mag. Danke für den tiefen technischen Austausch, das hat den Thread hier extrem bereichert! 
Ich setze auf ein dezentrales System. Bestimmte “Dienste”, die mir wichtig seind und für das Gesamtsystem benötigt werden, laufen auf eigenen Servern.
Auf Proxmox:
Zigbee2MQTT
Lorawan (ChirpStack)
Node-red
InfluxDB2
InfluxDB3
Grafana
MariaDB
Andere Server laufen auf einer Synology DS
Mosquitto
Proxmox Backup Server
Proxmox Datacenter
OpenCCU (ehemalig Raspberrymatik)
EVCC
Meine Hauptserver laufen auf Proxmox:
3 ioBroker (Master, Slave und Test)
HomeAssistant
Die Schnittstellen sind soweit wie möglich in das LAN/WLAN eingebunden:
Für Homematic das HB-EF-ETH
Für Zigbee der Coordinator SLZB-06M
Stromzähler Hichi
Ich setze drei Proxmox Hosts ein. Die VMs bzw. LXC lassen sich bei Wartungsarbeiten locker auf ein anderen Host verschieben.
Das Gesamtsystem ist relativ wartungsarm und bei Updates werden nur bestimmte Komponenten kurz runtergefahren. OpenCCU und Mosquitto werden sowohl von HomeAssistant als auch vom ioBroker benötigt. Daher hatte ich mich entschlossen, diese Server auf die DS zu verlagern. Hier sind Updates relativ seltenener als bei Debian / Proxmox.
Bisher bin ich mit dem Gesamtkonstrukt sehr zufrieden. Natürlich werkelt eine USV für die Server inkl. Fritzbox und Router. Die Fritzbox hat nun auch einen LTE Stick für Internet-Ausfall bekommen.
1 „Gefällt mir“