Cześć
W chwili obecnej swojego Home Assistanta zainstalowanego mam na RPi3 na karcie SD. Przyznam się że narazie testowo działa tam kilka integracji. Sprzęt testuję już od września czyli jakieś 7 miesięcy. Nie zauważyłem żadnych problemów z działaniem karty SD. Jednak przyszłościowo myśląc chciałbym zainstalować dysk SSD i może przesiąść się na RPi 4 w niedługim czasie. Mam pytanie odnośnie adapterów pod USB SSD. Macie jakieś sprawdzone i godne uwagi adaptery? W jednym z tematów widziałem że kolega Marcin Domański chwali Axagon ADSA-1S6. Są jeszcze jakieś alternatywy?
Alternatywy to są, tylko Chińczycy często walą w ciula sprzedając ten sam model z różnymi flakami (w przypadku brandu Axagon, jak na razie nie spotkałem się z takim zachowaniem, tylko że jest niemiłosiernie drogi w porównaniu z konkurencją, ale np. w przypadku również znanego Orico jak najbardziej bywały takie sytuacje).
Najważniejszy jest mostek, który jest w środku a nie konkretny model obudowy czy “przejściówki”.
Przykro mi, ale nie mogę nawet napisać “kup to albo tamto”
z RPi4 używam konstrukcji na mostku Realtek RTL9210 i bootuje z USB3, czyli zasadniczy cel został osiągnięty, to jest akurat Orico (ale firmware było przygotowane “na kolanie” by_id: '/dev/disk/by-id/usb-Realtek_RTL9210_NVME_012345678902-0:0'
numer seryjny 012345678902 świadczy o tym dość dobitnie - prawdopodobnie każdy egzemplarz ma ten sam numer seryjny, a to bywa źródłem problemów)
https://www.aliexpress.com/item/1005001285329572.html
(ale UWAGA nie sprawdzałem czy RPi3 z tego zabootuje, bo to że RPi4 daje radę nie jest jednoznaczne z tym że RPi3 też da radę i wzajemnie, bo mają bootlodery “z innych światów”) to jest mostek do nvme.
Odradzam konstrukcje na mostkach Norel Sys oraz JMicron - przykładowo JMS583 (też do nvme) na RPi4 bootuje tylko z USB2 i ten problem jest nie do przeskoczenia (a aby podsystem dyskowy miał przyzwoitą wydajność używając HAssOS trzeba bootować z USB3, pomijam tu rozwiązania z systemem na oddzielnym nośniku, a danymi na oddzielnym, bo są możliwe, ale są problematyczne w aktualizacjach).
Skoro używasz HA już 7 m-cy to sugeruję sklonować kartę TF na nową lub po prostu zrobić świeżą instalację na nowej karcie i dane przenieść snapshotem (chyba że dotychczasowa to przemysłówka lub dostosowana do DVR karta High Endurance) i zacząć używać dalej na nowej a starą przeznaczyć na mniej krytyczne zastosowania.
To że karta padnie prędzej czy później jest pewne, ale to kiedy padnie zależy od kilku czynników (jej rozmiaru, technologii, ilości wolnego miejsca, a przede wszytkom od tego jak bardzo masz rozbudowaną instalację HA - rozmiar bazy i częstość zapisów)
Przy okazji zmiany platformy i świeżej instalacji możesz sobie zrobić migrację na 64-bitową wersję systemu jeśli nie używasz GPIO (i nie planujesz) a RPi4 będzie w wersji przynajmniej 2GB RAM (jeśli to ma być bardziej przyszłościowe rozwiązanie użyłbym jednak wersji 4|GB), na RPi3 wersja 64-bit może nie być do końca optymalna, bo 1GB to jednak nieco mało RAMu (ale może monitorujesz jego wykorzystanie, to będziesz wiedział, jak to wygląda w twojej instalacji).
edit 3 lata później - 32-bitowe systemy dziś już nie mają sensu, więc kierunek obecnie jest taki by na nowe instalacje używać srzęt tylko i wyłącznie mający przynajmniej 4GB RAM (2GB często to już za mało, a konstrukcje z 3GB to co najmniej “dziwaki”)
Przed przejściem na RPI4 z bootowaniem z SSD polecam zapoznanie się z materiałem z poniższego linku:
Home Assistant na RPI4 SSD
W tytule artykułu jest mowa co prawda o RPI4 z 8GB RAM ale generalnie temat dotyczy także i tych z mniejszą ilością pamięci. Znajdziesz tam między innymi polecane i na pewno działające z RPI4 adaptery USB do SSD.
Model RPi4B w sensie ilości RAMu nie ma znaczenia pod względem obsługi mostków USB-hdd/ssd (jakkolwiek dla wersji 8GB jest bezwzględnie wymagany system 64-bitowy).
Przed instalacją HassOS trzeba zrobić aktualizacje bootloadrea z poziomu RPiOS (bo możliwość update w HassOS została wyłączona jakiś czas temu).
Kwestia RPi3B/3B+ jest diametralnie inna - tam wstępny bootloader jest zaszyty na stałe i nie można go uaktualnić (więc pracuje z mostkami, które bodajże w pełni spełniają specyfikację USB-MSD przynajmniej w trybie USB2, co oczywiste bo nie ma porrtów USB3, ale co ciekawsze RPi4 może obsłużyć niektóre z tych które są niezgodne z kluczowymi specyfikacjami, a RPi3 tego nie zrobi).
Piszesz o czymś o czym ja doskonale wiem. Zaznaczyłem jedynie iż w tytule tematu, do którego podałem odnośnik, jest mowa o 8GB RAM.
Żeby zaktualizować bootloader w RPi4 nie potrzeba wcale RPiOS. Można to zrobić posługując się odpowiednio przygotowaną za pomocą Raspberry Pi Imager’a kartą SD z którą odpalasz malinę. Operacja trwa max kilka sekund.
A to, że będziesz miał najnowszą wersję rpi-eepromu nie gwarantuje wcale bezproblemowego startu Home Assistanta z SSD.
Start Raspbiana z SSD a start Home Assistanta z tegoż samego urządzenia to dwie różne bajki.
Tak, domyślam się, że wiesz; zapomniałem wywołać wątkotwórcę
jeśli zacytuje się czyjąś wypowiedź to daje wrażenie odpowiedzi tej osobie (nawet forum tak to oznacza).
Spokojnie ja też to wszystko czytam.
Widzę że w takim razie całą modernizację muszę rozpocząć od wymiany na RPi4B ( chyba najlepiej 8GB Ram) a później dopiero SSD i adapter. Spodziewałem się że otrzymam od Was info że adapter musi obsługiwać TRIM i coś USAPi czy coś tam innego i na tym się skończy. Pewnie skończy się na tym że kupię Axagona.
Jak zacząłem czytać Wasze odpowiedzi to uświadomiłem że w styczniu miałem f…ck up’a i instalowałem nowy system już chyba 64bit. Wtedy chyba też zmieniłem karty SD.
Co do użycia pamięci to w tej chwili mam 50 - 60% ale nie mam zbyt wielu integracji.
Tak, właśnie ma poprawnie odsługiwać TRIM i UAS problem jest jednak inny, szukając na podstawie modelu można się władować na minę - tak było w przypadku przynajmniej jednego modelu Orico (sprzedawanego z tym samym oznaczeniem modelu, a z różnymi mostkami w środku).
Mostki na chipsetach Norel Sys i JMicron można w ciemno wrzucić na “czarną listę”, tj niektóre działają poprawnie, a niektóre są strzałem w kolano (o ile na RPi4 zabootujesz często nawet z trefnego sprzętu, to jednak bootowanie z portu USB2 nie ma żadnego sensu, w przypadku niektórych można stosować obejście z użyciem quirks, ale mi się nie udało - konkretnie wyłączenie UAS i tak nie umożliwiło bootowania na porcie USB3 w przypadku bodajże obudowy na JMicron JMS578?) co gorsza nawet firmware mostka może mieć wpływ (ale np. do starszych chipsetów AsMedia poprawione firmware jest dostępne w sieci, a dla JMicrona (tym razem bodajże JMS583?) mimo usilnych poszukiwań nie znalazłem… tzn. znalazłem tak poprawione, że teraz już nie bootuje nic, za to ssd się mniej grzeje przy pracy tylko już nie z maliną).
Ten model, który zalinkowałem wyżej (na Realteku i działa mimo “firmware na kolanie”), ale w sklepie, gdzie kupowałem jest akurat niedostępny - poszukaj w innych sklepach na Ali (o ile masz nvme).
Próbowałem kiedyś (jeszcze jak była wersja RPi4 1GB, a nie było 8GB) korzystać z wtedy istniejącej bazy kompatybilnych wyrobów z RPI4 ale po prostu albo ceny były absurdalnie wysokie, albo dany model nigdzie niedostępny.
Ostatecznie skończyło się tak, że kupowałem “na pałę” w ChRL rożne tańsze obudowy (w dobie tanich ssd i tak wszystkie są wykorzystane - mnóstwo ludzi w starszych laptopach wrzucało ssd i potrzebowali obudowy na hdd), niestety nie zrobiłem własnej “bazy informacji” o nich, ale też normalnie nie mam tyle czasu na zabawę - teraz tkwię od miesiąca w domu po przechorowanym ciężko covidzie, to mam czas (i tak jako takie dojście do siebie zajęło mi parę tygodni, więc tak naprawdę coś robię w ramach hobby może od tygodnia, ale w końcu pod koniec tego tygodnia wracam do pracy).
I na koniec - ponieważ bootloader w RPi4 jest nadal w fazie rozwoju, to bywały sytuacje, że na danej wersji firmware RPI4 jakiś sprzęt działał, a na innej (nowszej) nie - to jest powód dla którego w HassOS zrezygnowano z automatycznego update’owania bootloadera, natomiast podejrzewam, że chodziło wyłącznie o trefne mostki nie spełniające specyfikacji dla których próbowano zrobić gotowe obejścia w firmware RPi.
Dziękuję Ci w takim razie za wyczerpującą odpowiedź i życzę szybkiego powrotu do zdrowia.
Zapytam jeszcze w woli ścisłości, jest sens kupować RPi4 z 8GB Ram na pokładzie?
Zależy jak dużo urządzeń, jakich urządzeń (np. kamery) i jak wiele z nimi związanych automatyzacji.
Tak wygląda zazwyczaj użycie RPi4 z 4GB RAM przy kilkunastu urządzeniach na zigbee, do tego kilka z Tasmotą, integracje telefonów, multimediów (TV, NAS, drukarka, androidbox, SAT, audio) i dość dużo wokół tego automatyzacji głównie przy użyciu NodeRED’a.
W większości czasu “malinka” odpoczywa.
“Malina” to zwykły komputer (może nie do końca, bo to SBC), więc rządzi się zasadniczo tymi samymi prawami co każdy inny komputer, tylko w tym wypadku nie ma slotu na kość pamięci, więc jej nie wymienimy ani nie dołożymy…
W tamtym poście na 1 wykresiku widać właśnie RPi4B 4GB, ale w tej instalacji nie używam żadnych pamięciożernych dodatków (a może powinienem zacząć? skoro to instalacja testowa )
ze względu na wykorzystanie zasobów nawet zastanawiałem się nad “downgrade”, czyli de facto na fizycznej podmianie sprzętu na wersję 2GB (która pracuje u mnie w innym projekcie), UWAGA tu nikogo nie namawiam do kupna niedoszacowanego sprzętu!, wręcz jeśli sprzęt ma być wykorzystywany długoterminowo to lepiej mieć spory nadmiar zasobów niż ich nie mieć (np. swoje instalacje oparte o NUCe planowałem z założeniem 10-letniej trwałości i tam zapobiegawczo wrzuciłem po 8GB RAMu, a teraz - po ponad roku - zaczynam przypuszczać, że mogłem się wstrzymać o parę lat z taką rozbudową).
W przypadku zbyt małej ilości pamięci system będzie musiał zacząć korzystać ze swap i to po prostu zrobi (podejrzewam, że to właśnie jest jedna z przyczyn częstych problemów z kartami TF w przypadku RPi3 i rozbudowanej konfiguracji HA, niestety z tamtych czasów nie zostawiłem sobie za dużo na pamiątkę)
Może trochę więcej powie kilka screenshotów (w przygotowaniu - dam najpierw normalnie popracować tym instalacjom, bo przed chwilą były aktualizacje i inne zmiany), wszystkie systemy pracują na “bare metal” HassOS (czyli sposób instalacji z obrazu gotowego systemu typowy dla RPi bez dodatkowej warstwy wirtualizacji), wszystkie te systemy w wersji 64-bit (są nieco bardziej zasobożerne od 32-bit, ale równocześnie podejrzewam, że systemy 32-bitowe na RPi i podobnych platformach nie mają już za długiej przyszłości, jedyny wyjątek to wykorzystanie GPIO, ale tak naprawdę z tego rozwiązania pod HA korzysta znikomy ułamek procenta użytkowników - przy okazji - podziękujmy za te dane analityce wprowadzonej w ostatnich wersjach HA, oczywiście by był z tych danych statystycznych jakiś sensowniejszy użytek, użytkownicy muszą się zgodzić na przesyłanie danych analitycznych, ja sugeruję ich przesyłanie i to w “pełnej wersji” czyli 4 checkbox’y - dane są i tak anonimizowane).
-
Realny w miarę rozbudowany system; NUC 8GB RAM
-
Realny dość minimalistyczny system; NUC 8GB RAM
-
System testowy (nie jest rozbudowany, wręcz minimalistyczny jak na system testowy); RPi4B 4GB RAM
-
System czysto eksperymentalny, póki co brak konfiguracji oddającej realne obciążenie (niemal “pusty” HA - po pierwsze ten system ma 1 dzień, a po drugie ssd to zaledwie 16GB !); Samsung TC241 2GB RAM
edit: długo nie musiałem czekać by pobudzić swap do działania na systemie z 2GB RAMu - wystarczyło kilka zasobożernych dodatków + jeden trefny komponent niestandardowy (ma wyciek pamięci, co przy odpowiednio długiej pracy bez restartów spowoduje zajęcie dowolnej ilości RAM a potem wykorzystanie całego swapa i maszyna się zawiesi), na obrazku oczywiście restartowałem HA, ale może pozostawię na dłużej - niech sobie popracuje, tylko może się nie udać wykonać screenshota gdy przegapię moment krytyczny)
Skąd masz te encje z raspberry?
Może to będzie pomocne - Monitoring Raspberry Pi.