Komputer jednopłytkowy, karta microSD z ostrzeżeniem, migracja na SSD i urządzenia smart home

Home Assistant zwykle psuje się w mało widowiskowy sposób. Żarówki nadal są sparowane, koordynator Zigbee jest wpięty, automatyzacje istnieją, ale po zaniku zasilania albo aktualizacji system nie startuje poprawnie. Czasem uszkodzona jest baza danych. Czasem system plików przechodzi w tryb tylko do odczytu. Czasem log pokazuje błędy I/O i właściciel odkrywa, że cały smart home wisiał na karcie microSD albo tanim pendrivie.

To nie tyle błąd początkującego, ile pułapka dla początkujących. Prosta ścieżka z Raspberry Pi jest potrzebna: nagrać Home Assistant OS, włożyć microSD, uruchomić i dodawać urządzenia. Na start to działa. Ale prawdziwa instalacja szybko rośnie. Historia, energia, add-ony, kopie, kamery, logi i recorder zmieniają małą płytkę w serwer działający całą dobę.

Dzisiejszy problem nie kończy się na haśle "karty SD się zużywają". Nowsze dyskusje o Raspberry Pi, bootowaniu z SSD/NVMe, firmware i HAOS 18 pokazują coś ważniejszego: SSD zwykle jest dobrym kierunkiem, ale nie jest magią. Zasilanie, adapter, USB boot, recorder i kopie zapasowe nadal decydują o stabilności.

Dlaczego słaby nośnik cierpi

Home Assistant ciągle zapisuje dane. Recorder przechowuje stany i statystyki. Panel energii zbiera pomiary. Add-ony tworzą pliki. Backup najpierw powstaje lokalnie. Logi rosną. Kamery i głośne integracje dokładają kolejne zapisy. Kilka żarówek to nie to samo co dom z czujnikami, ogrzewaniem, Zigbee, Matter i obecnością.

Dobra microSD może działać, szczególnie A2 albo high-endurance. Oficjalna dokumentacja dla Raspberry Pi nadal wspomina o karcie minimum 32 GB, najlepiej Application Class 2, dobrym zasilaczu i Ethernecie. To rozsądny start. Nie oznacza to, że każda karta wytrzyma lata pracy jako dysk serwera.

Tanie pendrive'y bywają gorsze. Są robione do przenoszenia plików, nie do ciągłych losowych zapisów. Ich awaria wygląda różnie: wolny start, restarty, uszkodzona baza, system działający jeden dzień po twardym reboocie.

Objawy mylą

Chory nośnik rzadko mówi wprost, że umiera. Może uszkodzić się home-assistant_v2.db. Add-ony mogą nie startować. Interfejs znika. W logach pojawia się read-only filesystem, mmc0, blk_update_request, I/O errors albo nieudane zapisy podczas aktualizacji.

W jednym przypadku użytkownik Raspberry Pi 5 z hatem NVMe i WD_BLACK SN770M miał regularną korupcję bazy. Pierwsze pytanie społeczności dotyczyło zasilania. Słusznie: szybki SSD nie pomoże, jeśli płytka, hat i dysk mają za mało prądu.

Nowsze issues HAOS pokazują też problemy z update na SSD, niestabilnością Pi 5 z NVMe, USB3 boot, który nie działa mimo działania USB2, oraz EEPROM wymagającym pełnego odłączenia zasilania. To nie argument przeciw SSD. To argument za ostrożną migracją.

Najpierw backup

Przed migracją zrób pełny backup i pobierz go poza urządzenie: laptop, NAS, chmura, inny komputer. Nie ta sama karta.

Z backupem nieudana migracja jest kłopotem. Bez backupu jest operacją bez siatki bezpieczeństwa. Dobra rutyna oznacza automatyczne kopie, zewnętrzne miejsce i okazjonalny test odtworzenia.

Jeśli system już się sypie, nie nadpisuj starego nośnika. Spróbuj skopiować /config, backupy i własne pliki. Jeśli uszkodzona jest tylko baza recorder, przeniesienie home-assistant_v2.db może pozwolić wystartować bez historii, ale z konfiguracją.

Zostawić Pi, przenieść dane na SSD

Dla wielu instalacji Raspberry Pi najlepszym pierwszym krokiem jest zewnętrzny SSD jako data disk. Home Assistant OS opisuje taki scenariusz i ostrzega, że SSD przez USB może wymagać mocniejszego zasilania albo aktywnego huba.

Kolejność: backup, sensowny SSD, sprawdzona obudowa USB-SATA lub USB-NVMe, zasilanie, migracja data disk przez aktualny UI lub CLI, kontrola czy konfiguracja, add-ony i baza są na SSD. Potem kilka dni obserwacji.

To zmniejsza zapis na karcie bez zmuszania wszystkich do USB boot albo NVMe hatów. Nie zastępuje backupów i nie naprawi złego zasilacza.

Boot z SSD lub NVMe

Pełny boot z SSD/NVMe ma sens, gdy chcesz całkiem pozbyć się microSD. Na Raspberry Pi 4 lub 5, z dobrym adapterem i zasilaniem, może to przyspieszyć system i usunąć częsty punkt awarii.

Plan powinien być ostrożny: backup, bootloader/EEPROM, obraz HAOS na SSD, start, restore, obserwacja logów i pierwszej aktualizacji. Nie każdy adapter działa tak samo. USB2 może bootować, USB3 nie. Firmware może wymagać zimnego restartu. W urządzeniu bez monitora to ważne.

Orange Pi i mini PC

Orange Pi jest kuszący, ale nie jest po prostu tańszym Raspberry Pi. Wiele modeli nie ma oficjalnego wsparcia HAOS. Home Assistant Container na Debianie lub Armbianie może działać, ale to nie jest doświadczenie HAOS z Supervisorem i add-onami.

Jeśli lubisz Linux i Docker, to dobra opcja. Jeśli chcesz prostego appliance, spokojniejsze będą Home Assistant Green/Yellow, wspierany sprzęt albo mały komputer x86.

Używany mini PC bywa prostszy niż Pi z zasilaczem, obudową, SSD, adapterem, hatem i godzinami diagnozy. Zajmuje więcej miejsca i czasem pobiera więcej energii, ale daje normalny SSD, UEFI, więcej RAM i mniej dziwnych problemów z bootowaniem.

Detale robią różnicę

Warto ograniczyć recorder, wykluczyć głośne encje i pilnować wielkości bazy. MariaDB może pomóc w dużych instalacjach, ale nie jest obowiązkowa dla początkujących. Najpierw dobre zasilanie, SSD, rozsądny recorder i backup poza urządzeniem.

Zigbee lub Z-Wave trzymaj na przedłużaczu z dala od USB3 i SSD. Zakłócenia USB3 w paśmie 2,4 GHz mogą wyglądać jak problem automatyzacji. Ethernet jest lepszy niż Wi-Fi. Oznacz zasilacz i kable.

Home Assistant może być bardzo stabilny. Ale jeśli steruje światłem, ogrzewaniem, zamkami albo czujnikami zalania, nośnik danych nie jest drobiazgiem. Jest częścią domu.