Nachdem ich nun schon geraume Zeit stiller Mitleser bin, habe ich mich jetzt angemeldet und komme direkt schon mit einer Frage um die Ecke.
Ich nutze aktuell ein Home Assistant Green mit einem Sonnof P Dongle. Alles funktioniert hervorragend und ich bin sehr happy.
Nachdem nun ein größeres Update von Home Assistant selbst sowie das, momentan gefühlt hohe Wellen schlagende, große Update von Zigbee2MQTT bereit steht, frage ich mich:
Wie kann ich bestmöglich eine Testumgebung aufbauen, in der ich solche großen Updates zunächst einmal testen kann. Gedanklich stoße ich da an ein paar Herausforderungen. So müsste ich mir in meiner Theorie ja einen zweiten Dongle kaufen, oder? Ansonsten kann ich ja das Update für Zigbee nicht testen. Oder habe ich ja einen Denkfehler? Und wo baue ich mir diese Testumgebung am besten? Auf meiner Synology NAS in einer VM? Oder auf einem Raspberry Pi 3, den ich noch habe. Spiele ich dort dann ein Backup meines Green ein?
Ich hoffe, ich habe alle notwendigen Details genannt. Falls nicht: sorry dafür. Dann liefere ich nach.
Ich habe eine Virtualbox wodrin ich ein Backup laufen lasse.
Problem ist natürlich, die virtuelle Maschine greift auf physikalisch echte Aktoren/Sensoren zu.
wie schon von @phettsack vorgeschlagen wurde, irgendetwas wo Du virtualisieren kannst, aber alles was auf externe Hardware, z. B. USB-Sticks für Zigbee, Zwave oder, oder aufsetzt, kann man natürlich dann nur machen, wenn es auch doppelt vorhanden ist, es gibt Möglichkeiten das zu umgehen, führt mir hier aber zu weit, denn ich bin kein freund mehr von Testsystemen.
Achtung, das ist meine ganz persönliche Meinung, und muss keiner teilen
Ich würde lieber ein Vollbackup machen, es sicher außerhalb vom Green ablegen, dann die Updates machen, testen, wenn nicht ok dann Backup wieder zurück.
Auf einem Testsystem kann es nur minimal anders aussehen als auf Deinem Green und schon stimmen die Voraussetzungen nicht mehr, ich hatte früher erst zu ioBroker Zeiten auch zwei Systeme, nach kurzer Zeit waren sie auseinander gelaufen und jedes Mal erst wieder gleichstand herstellen, testen, dann einmal Update, testen, dann im produktiven System Update und der Test musste doch gemacht werden, das Gleiche ist mir dann auch bei HA aufgefallen, also habe ich nur noch ein System, das ich vor jeder Änderung Sichere, Update, Test.
Ich fahre gut damit.
Ich habe kein Testsystem aber habe auch schon darüber nachgedacht, was gemacht werden müßte um als nur Raspi Verwender etwas vorab testen zu können aber dann wieder verworfen wegen Aufwand und Nutzen. Die Vollbackmethode finde ich am einfachsten.
Bei Major Releases (also den großen Updates, wo die vordere Versionsnummer geändert wird), sollte man definitiv vorher die Release Notices und insbesondere die Breaking Changes lesen.
Die meisten Fehler, die bei den Leuten so auftreten, sind dort bereits, inkl. dem Grund und der Behebung, beschrieben.
Und dann zwingt Dich ja auch niemand, dass Du jedes Release augenblicklich installierst. Die neuen Versionen für Home Assistant erscheinen nach einem festen Terminplan. Zu Beginn des Monats das Major Release und danach dann wöchentliche Updates.
Wenn Du in den Breaking Changes nichts auf Dich zutreffendes gefunden hast, kannst Du trotzdem warten, bis die Version 2025.X.1 oder auch 2025.X.2 erschienen ist. Da werden recht sicher möglich Probleme bereits adressiert worden sein. Und die Maintainer von Integrationen hatten auch noch mal mehr Zeit ihren Code anzupassen.
Denn häufig ist nicht Home Assistant selbst, sondern eine Integration, ein Addon, eine Schnittstelle zu einem Drittanbieter oder sonst etwas das Problem. Ein Problem, das es bei anderer Software zum Teil nicht gibt, weil es dort diese Möglichkeiten einfach nicht gibt.
Ich kann sagen, dass ich Home Assistant seit Jahren einsetze und mich an keine nennenswerten Probleme bei meinem Ablauf erinnern kann.
bei mir läuft HomeAssistant auf einer VM (Proxmox), die Klone ich und mache dann die/das Update, wenn alles sauber läuft, lösche ich den Klone wieder.
Fullbackups werden jede Nacht extern gespeichert.
Über eine TestVM habe ich auch schon nachgedacht, wenn die aus dem selben Proxmox läuft wäre auch der Zugriff auf die angeschlossenen Hardwarekomponenten wie z.B. USV gegeben. Nur wie mache ich es dann mit der Zigbee/MQTT Umgebung?
So ein Testsystem kann natürlich tricky sein, vor allem weil man effektiv alles einrichten müsste um wirklich mögliche Fehler i zu finden.
Dann hat man aber über das Produktivsystem keinen Zugriff mehr darauf (in den meisten Fällen zumindest).
Willst Du also die Lampen in Deinem Zuhause erstmal testen, dann kannst Du sie solange nicht mehr über das Produktivsystem steuern usw.
Deshalb halte ich das für die meisten Leute für nicht praktikabel
auch wenn das mit Sicherheit schon in einigen Threads steht, eine kurze Zusammenfassung.
Alles, was möglich ist außerhalb von HA installieren, wenn Du, wie Du sagst, Proxmox nutzt, dann alles, Zwave, Zigbee2MQTT, MQTT Broker als LXC installieren, einrichten und gut ist.
produktiv HA einrichten, Du brauchst dann nur noch die Integration MQTT, die sich mit dem Broker verbindet und die Daten abholt.
Test HA installieren und Integration MQTT einrichten, HA holt sich dann die Daten vom Broker.
Bei Integrationen, die WLAN, LAN nutzen ist nichts weiter nötig.
Jetzt das große Aber, bei Automationen aufpassen, denn die kommen sich in die Quere, wenn sie auf die gleichen Geräte zugreifen.
Die beiden VMs müssen auch gepflegt werden, und das macht dann pauschal doppelte Arbeit, hingegen, wenn ich nur ein aktives System habe, und vor jedem Update einfach nur ein Snapshot, oder Proxmox Backup mache, dann das Update mache, habe ich nur die halbe Arbeit.
Ganz ehrlich ich bin kein freund von Testsystemen, da ich selbst festgestellt habe, dass man die nach kurzer Zeit wieder löscht, weil man dann doch im aktiven System die Änderungen macht.
Ich werde wieder Abstand vom Gedanken nehmen, ich habe im Moment so viele kleine Baustellen und dann möchte ich mir nicht noch mehr Arbeit beschaffen.
HA macht jede Nacht ja ein fullbackup, das dauert mit zum einspielen aber immer zu lange, daher mache ich nen Proxmox-Klone, fahre die produktiv VM runter und teste die Updates auf dem Klone, wenns soweit gut aussieht gibts dann das update im Produktiv und fertig.
ist es grundsätzlich nicht ein guter Ansatz Z2M, MQTT, etc. extern in LXC oder VM um zusetzten?
das liegt im Auge des Betrachters, es gibt Menschen, die haben Angst, dass sie einen zu hohen administrativen Aufwand haben, wenn sie alle nicht direkt, in HA gebrauchten Add-ons, in ressourcenschonenden LX Container oder in Docker Container auslagern.
Sie setzen dann lieber auf alles in einem Ansatz.
Ich, betreibe nur das in HA, was man da auch nur braucht, einen Editor, das Terminal Advanced ssh .., Let’s Encrypt, ISM7, wobei das wandert wohl auch noch in ein LXC, muss mal schauen wann, andere Tools wie Glances, SQLite Web, sind installiert aber inaktiv, werden nur gestartet, wenn ich sie brauche.
Nachteil, habe ich für mich nicht festgestellt, ich arbeite gerade daran eine Automation, Ansible, zu erstellen, wo ich mit einem Befehl alles LXC und VM Updaten kann.
Wer viel mit den Helferskripten arbeitet, soweit ich mich erinnere, gibt es da auch ein Skript, dann man auf seinem PVE laufenlässt, welches dann alle LXC updatet.
Die Container & VM’s werden automatisch heruntergefahren und nach dem Update wieder gestartet.
Dabei werden auch Container berücksichtigt, die gar nicht laufen.
Also meine Testumgebung ist ganz normal auf einem baugleichen Raspi4 mit SSD, so daß ich alles vorher testen kann selbst irgendwelche anderen Sachen, wie Blutooth-Proxy oder alles was mit ESP gesteuert werden kann. Das manchmal ein in der ,normalen Umgebung, Sensor sich anmeldet ist kein Problem da man den einfach wieder rauslöschen kann.
Für Updates wähle ich auch die von @dp20eic vorgeschlagene Voll-Backup-Methode.
Ein Testsystem habe ich nur noch für den Fall, dass ich mit irgendeiner Integration in irgendwelchem YAML-Code rumpfuschen muss, bis das so läuft, wie ich das gerne möchte.
Erst wenn das steht, integriere ich das in mein Produktivsystem.
Vorher ein volles Backup ist dabei aber auch Voraussetzung, dank Proxmox-VM aber auch kein großer Aufwand.
Das Testsystem wird dann wieder für den nächsten Versuch auf den Ursprungszustand “zurückgerestored” (geht so ein Denglish hier durch? ).
).