Am Dienstagabend rief Sandra aus Neusäß an, halb Panik, halb Neugier. Sie hatte den Newsletter zur 2026.8-Release am Wochenende gelesen, am Montag um Feierabend das Update in Home Assistant OS angeschoben und war um kurz nach neun am Küchentisch mit dem Tablet in der Hand geblieben. Alles war grün gelaufen, HA war neu gestartet, das Frontend sah aus wie immer, nur dass unter Übersicht in der Karte "Kameras Garten" ab sofort eine Zeile stand, die sie noch nie gesehen hatte: "Diese UniFi Protect Version ist zu alt". Darunter waren die vier Kachelplätze für ihre G4-Bullet-Kameras, den G5 Dome an der Terrasse und die G4-Türklingel im Eingangsbereich, aber die Bilder waren dunkel und die Buttons ausgegraut. In Einstellungen, Geräte und Dienste, war die UniFi Protect Integration gelb markiert. Sandra sagte in den Hörer: "Ich hab an nichts geschraubt, ich hab nur die HA-Update-Taste gedrückt, und jetzt sind alle sechs Kameras weg."

Sie war nicht die einzige. In den 96 Stunden nach dem 2026.8-Rollout haben in zwei separaten GitHub-Issues und im Home-Assistant-Forum insgesamt knapp fünfhundert Nutzer denselben Effekt gemeldet: Kameras verschwunden, "PublicCamera has no attribute has_package_camera" im Fehlerprotokoll, Integration setup-error. Ursache war nicht 2026.8 selbst, sondern eine kleine, im Newsletter kaum erwähnte Zeile im Changelog. Die UniFi Protect Integration verlangt ab sofort zwingend Protect Version 7.1 oder neuer. Wer auf einem älteren Stand steht, sieht seine Kameras nicht mehr. Punkt. Ich habe Sandra am Dienstagabend zwei Stunden lang durch das Update begleitet, wir haben ihren Cloud Key Gen2 Plus von 6.5.55 auf 7.1.87 gebracht, dabei zwei Dinge gelernt, die im offiziellen Ubiquiti-Guide fehlen, und ein paar Stunden später lief bei ihr wieder alles. Hier ist der Ablauf, den ich in den nächsten Wochen für einige Nachbarn und Leser mehrfach durchspielen werde, mit den echten Fallstricken statt der Hochglanz-Version.

Warum 7.1 jetzt wirklich Pflicht ist

Der Merge, um den es geht, ist Pull Request 177620 im home-assistant/core-Repository, eingereicht am 30. Juli 2026 von einem Entwickler mit dem GitHub-Handle RaHehl, sechs Stunden später gemergt, in die 2026.8-Beta übernommen, am 5. August im offiziellen Release gelandet. Der Titel ist trocken: "Require UniFi Protect 7.1". Der Diff ist mit +24/-10 in sieben Dateien absichtlich klein gehalten, aber im Kommentar erklärt der Autor genau, warum die Änderung sein muss und warum sie kein reines Aufräumen ist.

Der Hintergrund: Home Assistant ist seit dem Frühling 2026 dabei, die UniFi Protect Integration schrittweise von der alten privaten API (die Ubiquiti offiziell nie freigegeben hat, aber jahrelang stillschweigend gepflegt hat) auf die neue öffentliche Protect Public API umzustellen. Diese Public API ist mit Protect 7.0 im März 2026 gestartet, wurde mit 7.1 im Juni erweitert und wird von Ubiquiti künftig als die einzige stabile Schnittstelle für Drittanbieter-Software gepflegt. Die alte Private-API ist offiziell tot. Für Home Assistant heißt das: entweder auf die neue API umsteigen, oder mittelfristig gar keine UniFi-Kameras mehr unterstützen.

Der Umstieg auf die Public API ist im Gange, und in Version 2026.8 sind bereits mehrere Entitäten migriert. Konkret betroffen sind zwei Felder, an denen sich die 7.1-Pflicht entzündet hat: hasPackageCamera (das Feld, das anzeigt, ob eine G4 Doorbell Pro die zweite untere Kamera hat, die Pakete am Boden erkennt) und wirelessConnectionState (der Verbindungsstatus für batteriebetriebene Smart Sensoren, der als Grundlage für die Batteriezustands-Sensoren dient). Beide Felder existieren in der Public API erst ab Protect 7.1. Wer auf 7.0 oder älter läuft, bekommt vom UniFi-Controller ein Camera-Objekt, dem diese Felder fehlen, und die uiprotect-Bibliothek in Home Assistant baut das Objekt trotzdem, weil sie mit model_construct arbeitet, das Pflichtfelder mit Defaults füllt. In dem Moment, wo Home Assistant dann camera.has_package_camera ausliest, wirft Python einen AttributeError, und die Integration setzt komplett aus. Kein einzelnes Kamera-Entity mehr sichtbar, ganze Config-Entry im Setup-Error-Zustand.

Das ist genau das Fehlerbild aus Issue #177577, das der PR-Autor als Auslöser für die Version-Anhebung angibt. Er hatte die Wahl zwischen zwei Lösungen. Erstens: In der uiprotect-Library alle Felder mit falschen Defaults füllen, sodass die Integration nicht abstürzt. Das hätte den Vorteil, dass es keine Breaking Change gibt, aber den fatalen Nachteil, dass für jede G4 Doorbell Pro der Wert has_package_camera=False gesetzt würde, obwohl die Kamera in Wirklichkeit eine hat. Das Paket-Camera-Entity wäre komplett verschwunden, ohne dass es einen Hinweis gäbe. Ähnlich beim Batteriesensor: wirelessConnectionState würde als leerer String zurückkommen, der Batteriesensor bliebe leer, und der Nutzer sähe keinen Fehler, sondern nur einen leeren Wert. Der PR-Autor hat das im Kommentar präzise beschrieben: "Es tauscht einen lauten Fehler gegen eine leise falsche Antwort". Die zweite Lösung, für die er sich entschieden hat, ist die Anhebung der Mindestversion auf 7.1, mit einer klaren Meldung "Version ist zu alt", die der Nutzer sofort verstehen und beheben kann.

Der Kommentar schließt mit einem Satz, der mir persönlich zeigt, dass hier jemand mitgedacht hat: "Ich kenne keinen UniFi-Controller, der auf 6.x läuft und nicht auf 7.1 aktualisierbar wäre, deswegen kostet der Floor kein Hardware und ersetzt Rätselraten mit einer Meldung, auf die der Nutzer reagieren kann." Das ist keine leichtfertige Entscheidung, sondern eine bewusste Abwägung, die dem Ziel dient, dass Home Assistant weiter zuverlässig funktioniert und nicht in stille Fehlermeldungen abrutscht.

Wer betroffen ist und wer nicht

Der einfachste Test dauert dreißig Sekunden. Öffne im Browser die Adresse deines UniFi-Controllers (also https://192.168.1.1 oder was auch immer die IP deines Cloud Keys, deiner UDM Pro oder deines Dream Machines ist), logge dich als Admin ein und schau oben in der Kopfzeile nach der Versionsnummer. Bei einem Cloud Key steht dort neben dem Ubiquiti-Logo eine Zeichenkette wie "UniFi OS 3.1.14, Protect 7.1.87". Bei einer UDM Pro sieht es fast identisch aus. Wenn die Protect-Version mit 7.1. anfängt, bist du safe. Wenn dort 7.0 steht, oder gar 6.5, 5.14 oder noch älter, hast du das Problem.

Hardware-seitig gibt es folgende Kategorien:

Cloud Key Gen2 Plus (UCK-G2-PLUS): Alle Geräte können auf UniFi OS 3.x und damit auf Protect 7.1 aktualisiert werden. Die Ubiquiti-Community meldet für diese Gerätegruppe seit Juni 2026 stabile 7.1.87-Installationen, wenn der Sprung sauber gemacht wird. Wichtig: Cloud Key Gen1 (ohne Plus) unterstützt Protect gar nicht mehr, dort ist der Zug in der Firmware 3.x abgefahren.

UniFi Dream Machine (UDM, UDM Pro, UDM Pro Max, UDM SE): Alle Modelle laufen mit aktueller Firmware auf UniFi OS 4.x und unterstützen Protect 7.1 nativ. Wer eine UDM Pro hat, drückt in den Einstellungen unter Updates einmal auf "Install", und in fünfzehn Minuten läuft 7.1.

UNVR (UniFi Network Video Recorder) und UNVR-Pro: Die dedizierten NVR-Geräte, die Ubiquiti in den letzten drei Jahren für Kamera-Only-Setups verkauft, laufen von Werk aus auf modernen UniFi-OS-Versionen und sind in der Regel schon auf 7.1 oder höher. Falls nicht, ist der Update-Weg identisch zur UDM.

Legacy-Setups auf Windows- oder Linux-Servern mit Protect-Installation als Docker-Container: Hier hängt es davon ab, welches Image gepflegt wird. Die von der Community gepflegten Protect-Docker-Container von unifi-in-docker sind ab Juni 2026 auf Protect 7.1.x, wer noch die alte Bitninja- oder Jacobalberty-Version fährt, muss selbst upgraden oder auf 7.1.-fähige Images wechseln.

Der saubere Update-Weg von 6.x auf 7.1.87

Sandras Cloud Key Gen2 Plus stand vor dem Update auf UniFi OS 2.5.11 mit Protect 6.5.55. Das ist die Kombination, die im Frühling 2025 als "stabil und langsam" galt und bei vielen Nutzern seit anderthalb Jahren einfach lief. Der Update-Weg besteht aus drei sauberen Schritten, die in genau dieser Reihenfolge gemacht werden müssen, weil Ubiquiti keine direkten Sprünge über mehrere UniFi-OS-Hauptversionen erlaubt.

Schritt eins: Backup ziehen. Im UniFi-OS-Portal unter Console Settings, Backup, "Backup Now" klicken und die entstehende .unf-Datei herunterladen. Die Datei ist ein Voll-Backup aller Applikationen (Network, Protect, Talk, Access), inklusive Config und Nutzer, und je nach Setup zwischen 50 MB und 2 GB groß. Wichtig: Kein Wolken-Backup, sondern eine lokale Kopie, die du auf dem Laptop oder auf einem NAS ablegst. Sandra hatte das aus alter Gewohnheit gemacht, aber es passiert regelmäßig, dass Nutzer bei Firmware-Updates den Cloud Key so stark reboot-schleifen, dass er zurückgesetzt werden muss, und ohne lokales Backup ist dann alles weg, inklusive Aufzeichnungshistorie der Kameras.

Schritt zwei: UniFi OS auf 3.x heben. Bei Cloud Key Gen2 Plus geht das nur über einen expliziten Zwischenschritt. Von 2.5.x aus muss man laut Ubiquiti Community Diskussion zur SAFE-Update-Reihenfolge zunächst auf UniFi OS 2.5.15 aktualisieren (falls noch nicht drauf), dann in einem separaten Update auf 3.0.15, dann auf 3.1.x. Kein direkter Sprung von 2.5 auf 3.1, weil der Migrations-Prozess dazwischen mehrfach die interne Datenbank umbauen muss und bei einem Doppel-Sprung Inkonsistenzen entstehen können, die im schlimmsten Fall zum No-Disk-Fehler führen, den Andre van den Berg im CloudAdmin-Blog im März dokumentiert hat.

Bei Sandra ist Schritt zwei sauber durchgelaufen, jeder Sub-Sprung hat etwa acht Minuten gedauert, dazwischen zwei Reboots, und nach knapp einer halben Stunde stand der Cloud Key auf UniFi OS 3.1.14. Das ist die Version, die Protect 7.1.87 als Applikation laufen lässt.

Schritt drei: Innerhalb der Protect-Applikation von der alten Version auf 7.1.87 updaten. In der UniFi-OS-Oberfläche links auf Protect, dann oben auf das Update-Symbol, und Ubiquiti bietet den Sprung automatisch an. Das eigentliche Protect-Update dauert weitere fünf Minuten, dabei ist die Web-Oberfläche kurz nicht erreichbar, und die laufenden Aufzeichnungen der Kameras pausieren für die Dauer des Updates. Nach dem Neustart der Protect-Applikation ist alles wieder da, und die Version steht auf 7.1.87.

Sandra hat die drei Schritte in insgesamt fünfundvierzig Minuten durchgezogen, inklusive der drei Kaffee-Pausen zwischen den Firmware-Reboots und einer kurzen Verwirrung, als das UniFi-OS-Portal nach dem 3.0.15-Update auf einer weißen Seite hängengeblieben ist und wir den Browser-Cache leeren mussten. Kein Datenverlust, keine Kamera hat sich neu registrieren müssen, keine Aufzeichnungshistorie ist verloren gegangen.

Home Assistant wieder verbinden: der stille Nachschritt

Nach dem erfolgreichen Update auf Protect 7.1.87 haben wir kurz gehofft, dass Home Assistant von allein wieder anspringt. Das war naiv. Die UniFi Protect Integration hatte sich beim ersten Fehler in den Config-Entry-Setup-Error verabschiedet, und sie versucht standardmäßig alle fünf Minuten einen Reconnect, aber sie erkennt die neue Version erst nach einem expliziten Reload. Also: In Home Assistant unter Einstellungen, Geräte und Dienste, den UniFi-Protect-Eintrag anklicken, oben rechts auf die drei Punkte, "Neu laden" auswählen. Nach zehn Sekunden verschwand bei Sandra das rote Ausrufezeichen, die sechs Kameras tauchten wieder auf, und im Dashboard waren die Live-Bilder zurück.

Ein Punkt, der uns beide überrascht hat: Die Integration hat sich nicht nur reconnected, sondern hat gleichzeitig zwei neue Entitäten zu jeder Kamera hinzugefügt, die es in Protect 6.5 noch nicht gab. Das eine ist ein Event-Entity für Package Detection (die Erkennung eines abgestellten Pakets im Kamerabild), das jetzt eigenständig als Event-Trigger nutzbar ist, statt wie früher als undokumentierter Binary Sensor. Das zweite ist ein Sensor für den WLAN-Verbindungsstatus bei den batteriebetriebenen Smart Sensoren, der bei Sandras UP-Sense-Sensor im Keller endlich anzeigt, dass das Ding gerade nur zwei Balken hat und in den nächsten Wochen mal geladen werden sollte.

Wer Automationen aus der alten Protect-Zeit gebaut hat, die auf den früheren Binary-Sensor "Package Detected" hörten, muss diese jetzt umbauen. Der Sensor existiert nicht mehr, an seiner Stelle steht ein Event-Trigger vom Typ event.package_detected, den man in einer Automation über den Auslösertyp "Ereignis" ansprechen muss. Das ist eine echte Breaking Change, die auch in den Release Notes zu 2026.8 erwähnt ist, aber leicht überlesen wird. Wer regelmäßig eine Paket-Push-Nachricht auf dem Handy bekommt, sollte die betroffene Automation heute prüfen und den Trigger anpassen, sonst kommt am nächsten Tag der Amazon-Bote und die Nachricht bleibt aus.

Die zwei stillen Fallstricke, die in keinem Guide stehen

Zwei Punkte, die Sandra und ich am Dienstag auf die harte Tour gelernt haben und die in keiner offiziellen Ubiquiti-Anleitung stehen.

Fallstrick eins: Wer die UniFi Protect Integration in Home Assistant mit dem alten "Local User + API Key"-Verfahren eingerichtet hat, muss nach dem Sprung auf Protect 7.1 den API-Key möglicherweise neu erzeugen. Ubiquiti hat mit Protect 7.1 die Struktur der API-Berechtigungen leicht überarbeitet, und alte API-Keys aus 6.x-Setups laufen zwar formal weiter, verlieren aber teilweise Zugriff auf die neuen Endpunkte (Package Detection, Wireless Sensor Status). Das Symptom ist tückisch: Die Integration verbindet sich, alle Kameras sind sichtbar, aber die neuen Event-Entities bleiben unavailable. Fix: In UniFi OS unter Settings, Control Plane, Integrations, einen neuen API-Key erzeugen (etwa "Home Assistant 7.1"), den alten löschen, und in Home Assistant den Integrations-Eintrag mit "Neu konfigurieren" auf den neuen Key umstellen. Bei Sandra hat dieser Nach-Schritt zehn Minuten gekostet, aber ohne ihn hätte die Package-Detection auf ihrer G4 Doorbell nie funktioniert.

Fallstrick zwei: Wer einen älteren Router als Cloud Key nutzt, sollte vor dem Sprung auf UniFi OS 3.x prüfen, ob genug freier Speicher auf dem internen Datenträger ist. Das Update braucht temporär rund 4 GB freien Platz auf dem Cloud Key, und wer eine 32-GB-microSD-Karte mit vollen Aufzeichnungen betreibt, läuft in den Update-Prozess und bekommt in der Mitte einen Abbruch mit "insufficient disk space". Das ist unangenehm, weil der Cloud Key an dieser Stelle in einem halb-migrierten Zustand steckt und dann laut Community-Berichten in eine Reboot-Schleife gehen kann. Sandra hatte 60 GB freien Platz auf ihrer Ersatz-SSD, uns hat es nicht getroffen, aber in mehreren Threads der Ubiquiti-Community sind Nutzer über genau dieses Problem gestolpert und mussten den Cloud Key zurücksetzen. Vorher ins Protect-Menü, unter Storage, kurz nachschauen und im Zweifel eine Woche alter Aufzeichnungen löschen, bevor der Update-Prozess anrollt.

Was das für die nächsten Wochen bedeutet

Die Version-Anhebung auf Protect 7.1 ist ein Signal, das über den einzelnen Fall hinausreicht. Das Home-Assistant-Team hat in ihrem Blog-Post zur Release-Ausrichtung im Sommer angekündigt, dass die schrittweise Migration der UniFi Protect Integration auf die Public API in den nächsten zwei Releases weitergeht. Für 2026.9 (voraussichtlich Anfang September) ist die Migration der Kamera-Snapshot-URLs geplant, für 2026.10 im Oktober die letzten offenen Punkte bei den Smart-Sensor-Batterien und den PTZ-Bewegungssteuerungen. Es ist zu erwarten, dass es dabei noch ein oder zwei weitere Mindestversions-Sprünge geben wird, in Richtung Protect 7.2 oder 7.3, die Ubiquiti für Ende 2026 auf der Roadmap hat.

Konkret heißt das: Wer eine UniFi-Umgebung hat und nicht regelmäßig aktualisiert, sollte spätestens jetzt eine kleine Update-Routine einführen. Einmal im Monat, sagen wir am ersten Sonntagabend, ein Blick ins UniFi-OS-Portal, ein Blick ins Protect-Menü, und wenn ein Update angeboten wird, ein sauberes Backup vorher und dann das Update anschieben. Der Zeitaufwand ist zwanzig Minuten, und er verhindert, dass ein Home-Assistant-Release wie 2026.8 die eigene Kamera-Wand ohne Vorwarnung schwarz stellt.

Sandra hat mir am Mittwochmorgen geschrieben, alles läuft wieder, die G4-Doorbell schickt Push-Nachrichten wenn der Postbote klingelt, die G5 Dome hat einen neuen Package-Detection-Trigger gerichtet auf die Bienen, die im letzten Sommer im Kiesbeet ihre Nester gebaut hatten (mal sehen, ob der Amazon-Bote die Bienen jetzt als Paket erkennt, wir werden es sehen). Sie hat den Nachmittag danach nochmal genutzt, um in ihre alten Automatisierungen zu schauen, hat drei davon auf die neuen Event-Trigger umgestellt, und sagt, dass Home Assistant sich seit dem Update spürbar aufgeräumter anfühlt. Das ist ein Kompliment, das ich in den letzten Jahren selten von jemandem gehört habe, der gerade drei Stunden mit einem Cloud-Key-Firmware-Update verbracht hat.

Wer den Update-Weg noch vor sich hat, plant im Kalender zwei Stunden ein, zieht vorher ein sauberes Backup, macht die drei Sprünge bewusst in Reihenfolge, und ist am Ende in einem Setup, das sowohl mit 2026.8 als auch mit den nächsten drei Home-Assistant-Releases sauber laufen wird. Für Sandra war es ein Dienstagabend, für die eigene Kamera-Wand vielleicht die Investition der Woche.