O co chodzi z RTL-SDR?

RTL-SDR to odbiornik radiowy USB (pierwotnie tunery do telewizji cyfrowej DVB-T), który dzięki społecznościowym sterownikom da się przerobić na uniwersalny odbiornik radiowy szerokiego pasma. W praktyce: jeden mały dongiel potrafi „słuchać” niemal wszystkiego, co nadaje w zakresie kilkudziesięciu MHz do ponad 1 GHz — w tym popularne pasma ISM 433 MHz i 868 MHz, na których pracuje mnóstwo czujników, stacji pogodowych, pilotów czy liczników mediów.

Do dekodowania tych transmisji służy otwarte narzędzie rtl_433 — program, który rozpoznaje kilkadziesiąt popularnych protokołów urządzeń i zamienia surowy sygnał radiowy na czytelny JSON.

Konfiguracja: Docker + MQTT

Całość postawiłem w Dockerze na swoim domowym serwerze:

services:
  rtl_433:
    image: bademux/rtl_433tomqtt:latest
    container_name: rtl_433
    restart: unless-stopped
    volumes:
      - ./rtl_433.conf:/etc/rtl_433/rtl_433.conf:ro
      - /etc/localtime:/etc/localtime:ro
    devices:
      - /dev/bus/usb:/dev/bus/usb
    environment:
      - TZ=Europe/Warsaw

Konfigurację samego rtl_433 trzymam w prostym pliku tekstowym — częstotliwość, wzmocnienie i adres brokera MQTT:

output mqtt://192.168.0.125:1883,user=xxx,pass=xxx,retain=0,events=rtl_433[/model][/id]
device 0
frequency 868.3M
gain 0
report_meta time:local

Dane z każdego wykrytego urządzenia trafiają na osobny temat MQTT (np. rtl_433/Bresser-7in1/44028), co ułatwia dalszą obróbkę. Aplikacja ma szablony sygnałów dla prawie 200 urządzeń. Moje Garni INT 5 jest rebrandem jednego z obsługiwanych nadajników Bresser – 7in1

Pułapka, na którą warto uważać: RTL-SDR Blog V4

Tu natrafiłem na najciekawszy problem całego projektu. Mój dongiel to nowsza wersja RTL-SDR Blog V4_, która wymaga specjalnego, poprawionego sterownika – standardowa biblioteka librtlsdr dostępna w repozytoriach Ubuntu go nie obsługuje w pełni. Efekt? Odbiornik „widział” sygnał (potwierdziłem to wizualnie w programie SDR++ na Macu — wyraźna smuga w waterfallu co ~12 sekund, dokładnie zgodnie z cyklem transmisji stacji), ale rtl_433 uparcie nic nie dekodował.

Rozwiązanie: zbudowanie sterownika ze źródeł producenta i podmienienie systemowej biblioteki:

git clone https://github.com/rtlsdrblog/rtl-sdr-blog
cd rtl-sdr-blog && mkdir build && cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make && sudo make install
sudo cp ../rtl-sdr.rules /etc/udev/rules.d/
sudo ldconfig

Po tej zmianie dane popłynęły od razu — pierwszy poprawny odczyt: temperatura, wilgotność, wiatr, opady, UV, wszystko z poprawną sumą kontrolną CRC.

Wniosek: jeśli masz nowszy dongiel RTL-SDR Blog V4, a program „widzi” sygnał, ale nic nie dekoduje — sprawdź wersję sterownika, zanim zaczniesz podejrzewać config czy antenę.

Przez to, że kompilowanie sterownika i robienie swojego obrazu nie było w moim planie to zostawiłem zainstalowany rtl_433 bezpośrednio w systemie. Kiedyś będzie czas to faktycznie przygotuję obraz pod odpowiedni kontener. Możliwe jest też, że ktoś to w międzyczasie zrobi

Przygotowanie pliku rtl_433.service do automatycznego uruchamiania aplikacji przy starcie systemu:

[Unit]
Description=rtl_433 - RTL-SDR generic RF receiver and decoder
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=linux_user
ExecStart=/usr/bin/rtl_433 -c /iot/rtl433/rtl_433.conf
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Uruchomienie serwisu:

sudo cp rtl_433.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable rtl_433
sudo systemctl start rtl_433

Integracja z Home Assistant

Zamiast automatycznego discovery, wybrałem prostsze podejście — zwykłe sensory MQTT z szablonami wyciągającymi konkretne wartości z JSON-a:

mqtt:
  sensor:
    - name: "Balkon Temperatura"
      state_topic: "rtl_433/Bresser-7in1/44028"
      value_template: "{{ value_json.temperature_C }}"
      unit_of_measurement: "°C"
      device_class: temperature
      state_class: measurement

Analogicznie dla wilgotności, wiatru, opadów i nasłonecznienia. Dodatkowo, template sensor zamienia kierunek wiatru ze stopni na czytelną różę wiatrów (N, NE, E…), żeby dashboard był bardziej czytelny na pierwszy rzut oka.

Stylizacja prezentacji danych

Tu dwie rzeczy do usprawnienia. Kierunek wiatru odbierany ze stacji jest w stopniach. Nie bardzo wiadomo w którą stronę wieje wiatr 252° Trzeba to sobie ograć template sensorem:

  - name: "Garni Kierunek Wiatru Róża"
    unique_id: balkon_bresser_wind_dir_rose
    state: >
      {% set deg = states('sensor.balkon_garni_kierunek_wiatru') | float(0) %}
      {% set kierunki = ['N','NNE','NE','ENE','E','ESE','SE','SSE',
                          'S','SSW','SW','WSW','W','WNW','NW','NNW'] %}
      {{ kierunki[ ((deg + 11.25) / 22.5) | int % 16 ] }}

W przyszłości chciałbym zrobić różę wiatru z obracającą się igłą i miniaturą mieszkania. Dzięki czemu będzie można od razu wyobrazić sobie, z której strony wieje wiatr

Drugi temat do dopieszczenia to opady. Miernik opadów nalicza narastająco opady. Nie zeruje ich co dobę, tydzień czy miesiąc. Tu Home Assistant przychodzi z pomocą i swoimi utility_meter:

utility_meter:
  balkon_opady_dzienne:
    source: sensor.balkon_garni_opady
    unique_id: balkon_opady_dzienne
    cycle: daily
  balkon_opady_miesieczne:
    source: sensor.balkon_garni_opady
    unique_id: balkon_opady_miesieczne
    cycle: monthly

W ten sposób mamy kolejne dwie encje, które agregują dane dzienne i miesięczne. Ułatwia to prezentację danych na dashboardach.

Kwestia zasięgu

Ostatnia przeszkoda była czysto fizyczna: dongiel stał w korytarzu, a stacja na balkonie — kilka metrów i ściana wystarczyły, żeby sygnał zniknął. Zamiast stawiać osobne urządzenie (miałem pod ręką wolne Raspberry Pi Zero, ale wolałem zostać przy jednym punkcie zarządzania), rozwiązaniem okazało się po prostu wydłużenie kabla USB w stronę balkonu i… zmiana wzmocnienia z ustawionego na sztywno na tryb automatyczny. Czasem najprostsze rozwiązanie leży najbliżej.

Co dalej

Ten sam dongiel, ten sam pipeline (rtl_433 → MQTT → Home Assistant) obsłuży w praktyce dowolne urządzenie nadające w pasmach ISM — kolejne czujniki, piloty, a nawet niektóre liczniki mediów (choć te bywają szyfrowane, o czym może przy okazji innego artykułu). Do obsługi 433 MHz osobno planuję jeszcze przerobiony Sonoff RF Bridge z firmware ESPHome — ale to już temat na kolejny wpis.

Masz w domu jakieś radiowe urządzenie, które chciałbyś wciągnąć do swojego Home Assistant? Napisz w komentarzu — może da się je podsłuchać tą samą metodą.

Automatyczna bateria w zlewie zamiast miski z wodą czy fontanny

Koty od natury wolą pić wodę płynącą — w dziczy stojąca woda kojarzy się z zastałą i potencjalnie niebezpieczną. Haker od początku miał problem z piciem ze zwykłej miski. Musieliśmy mu, przy okazji wizyt w łazience przy których zawsze nam towarzyszył, odkręcać delikatnie kran i wtedy sobie pił.

Automatyczny podajnik karmy — Xiaomi Smart Pet Food Feeder 2

Szukałem podajnika, który będzie wyglądał stylowo, a jednocześnie będę mógł go maksymalnie sensownie wysterować Home Assistantem. Aktualnie podajnik działa według harmonogramu: mamy 3 karmienia na dobę. Dodatkowo, jeżeli Haker danego dnia zje więcej i waga karmy w miseczce spadnie poniżej 3g, to automatycznie dosypujemy porcję. Porcja nie jest tutaj mierzona według wagi, a w ilości obrotów ślimaka podającego. Więc, ile karmy wyleci, zależy w dużej mierze od kształtu, rozmiaru i wagi pojedynczego chrupka. W przypadku karmy Hakera, czyli Acana Indoor entrée pojedyncza porcja to 8g.

Niektóre karmniki posiadają wbudowaną kamerę, ten nie posiadał, więc wzbogaciłem trochę możliwości tego podajnika i dokupiłem kamerkę Wi-Fi TP-LINK Tapo C110 i zamontowałem nad urządzeniem. Działa to zdecydowanie lepiej niż kamery wbudowane gdzieś przy miseczce, gdzie nie widać nawet zawartości miseczki, a głowę kota

Logowanie każdego wydania porcji — przydatne, jeśli kot jest na diecie i kilka osób w domu go dokarmia „przy okazji”. Powiadomienie push, gdy poziom karmy jest niski, Zarówno w miseczce jak i w podajniku.

Kontaktron w drzwiach łazienki i czujnik położenia klapy WC + głosowe ostrzeżenie

To jedna z moich ulubionych automatyzacji i jedna z tych, co najczęściej szokuje gości, bo pokazuje, jak smart home może rozwiązywać problemy międzyludzkie (a właściwie międzygatunkowe).

Kuweta w łazience, drzwi się zamykają, gasi się światło — i mamy kota uwięzionego w łazience albo kota, który w razie potrzeby, będzie miał problem z załatwieniem swoich potrzeb. Automatyzacja:

1. Czujnik kontaktron (Satel Integra) wbudowany w drzwi łazienki, tak samo, jak zresztą we wszystkich drzwiach
2. Wyzwalacz: wyłączenie światła w łazience przy zamkniętych drzwiach.
3. Akcja: komunikat głosowy „Nie zamykaj drzwi, kot ma tam kuwetę”.

Drugim tematem, analizowanym podczas gaszenia światła w łazience, jest sprawdzenie, czy klapa została opuszczona. Jak kot był młodszy to zdarzyło mu się wskoczyć z rozpędu do otwartej toalety. I tu, analogicznie, leci komunikat głosowy, jeżeli ktoś deski nie opuści. Dzięki temu kot może bez problemu wskakiwać na pralkę, czy do zlewu, korzystając z toalety jako podestu

Sprzątanie po kocie – automatyczne i doraźne

Kuweta to nie tylko piasek do wymiany, ale też nieunikniony bałagan wokół – a to akurat świetnie nadaje się do automatyzacji na dwóch poziomach.

Sprzątanie ogólne – codzienne, całościowe odkurzanie mieszkania robi Dreame X40 Master według standardowego harmonogramu. To poziom „porządek na co dzień”, niezwiązany bezpośrednio z kotem, ale mający też znaczenie przy alergiach na sierść czy pyłek z kuwety.

Sprzątanie doraźne – do szybkich, punktowych interwencji wokół kuwety (rozsypany żwirek, ślady łapek) lub podajnika karmy sięgam po Xiaomi Vacuum Cleaner G20 Lite – ręczny odkurzacz pionowy. Nie fatyguję robota. To świadomy wybór: zamiast czekać, aż robot dojedzie i zrobi rundę po całym pokoju, biorę odkurzacz do ręki i w kilka sekund sprzątam konkretny fragment podłogi tuż przy kuwecie. Przy rozsypanym żwirku to po prostu szybsze i skuteczniejsze rozwiązanie niż automatyzacja.

Podział ról między tymi dwoma sprzętami sprawdza się lepiej niż poleganie tylko na jednym rozwiązaniu – X40 Master robi swoje, generalne sprzątanie na harmonogramie, a G20 Lite jest pod ręką na te sytuacje, gdzie liczy się refleks, nie automatyzacja.

Analiza innych danych

W Home Assistant, poza sprzętową obsługą, mam kilka ciekawych bajerów. Poza monitoringiem stanu miseczki dodatkowo obliczam: ile dzisiaj wsypano do miseczki, ile kot zjadł oraz ile średnio zjada w ostatnim tygodniu. Na podstawie średniego spożycia obliczam na ile dni starczy karmy w podajniku. Jest też utworzony pomocnik, przetrzymujący obecność kota w domu. Jak kot jest poza domem, wyłączamy harmonogram i alerty. Mam też KiciLog, czyli log zdarzeń z HA dotyczących kocich spraw, oraz licznik czasu od wymiany kuwety z przypomnieniem o konieczności wymiany. Są też guziczki do obsługi listy zakupów.

Tak, jak wszystkim pozostałym mieszkańcom staram się życie ułatwić, tak i życie kota musi być maksymalnie wypieszczone. Nie trzeba się martwić o picie, bo jest pod dostatkiem, karma zawsze w miseczce, drzwi do łazienki zawsze otwarte. Czego chcieć więcej?

Wejście do mieszkania to jedno z tych miejsc, które w większości smart home traktuje się po macoszemu — może jakiś inteligentny zamek, może kamera, i tyle. U mnie to osobny, przemyślany projekt, złożony z kilku elementów, które razem dają coś więcej niż suma części.

Punkt wyjścia

Chciałem czegoś, co realnie ułatwia życie (koniec z szukaniem kluczy), ale jednocześnie nie robi kompromisu na bezpieczeństwie i nie jest zależne od jednego producenta czy jednej chmury. Zamiast kupować gotowy, zamknięty ekosystem, połączyłem kilka sprawdzonych elementów własnym kodem.

Z czego się to składa

UniFi Doorbell G4 Pro PoE — wideodomofon z czytnikiem odcisku palca i NFC. To pierwszy punkt styku: rozpoznaje, kto stoi pod drzwiami, zanim jeszcze dotknie klamki. Atutem jest zasilanie PoE wparte UPS więc domofon działa nawet jak zabraknie prądu.

Zamek Tedee Pro — elektroniczny zamek, który fizycznie otwiera i zamyka drzwi na sygnał, bez majstrowania przy oryginalnym mechanizmie. Sam zamek sygnowany przez Gerdę – polskie przedsiębiorstwo działające na rynku zabezpieczeń od 1987 roku. Dodatkowym atutem i cechą, która była kluczowa przy wyborze jest sterowanie lokalne po adresie IP. Totalna odporność na awarię chmury czy brak internetu.

Kontaktrony przy zamkach na ryglach — proste, ale niezawodne czujniki magnetyczne monitorujące stan samego zamknięcia (czy rygle są faktycznie zatrzaśnięte), niezależnie od tego, co „myśli” sam zamek elektroniczny. Kontagtrony podpięte do systemu alarmowego Satel Integra.

Kontaktron monitorujący otwarcie drzwi — osobny czujnik na samym skrzydle drzwiowym, który mówi systemowi po prostu: drzwi są otwarte albo zamknięte, tu i teraz. Tak jak kontaktrony od rygli wpuszczone w futrynę. Z zewnątrz totalnie nic nie widać, estetyka na najwyższym poziomie.

Kamera robiąca snapshot po wejściu — automatyczne zdjęcie w momencie wejścia do mieszkania, trafiające prosto do mojego systemu powiadomień.

Jak to wszystko się spina

Sercem układu sterującego zamkiem jest Raspberry Pi z własnym mostkiem napisanym w PHP. Ścieżka wygląda tak: dzwonek (G4) rozpoznaje palec albo kartę → Unifi Protect uruchamia lokalnie webhookiem skrypt na Raspberry Pi → stamtąd leci do lokalnego API bridge’a Tedee, które fizycznie otwiera zamek. Nie potrzeba internetu, żeby wszystko działało.

W Unifi Protect mam skonfigurowane różne eventy w zależności czyj token lub palec został zeskanowany. Dzięki temu wiemy kto wchodzi. W przypadku zeskanowania palca przez osobę trzecią doorbell ma konfigurowany oddzielny event przy okazji którego dostajemy informację, że ktoś majstruje przy zamku.

Świadomie zaprojektowałem to jako niezależną ścieżkę krytyczną — działa poza moim głównym stosem Proxmox/Docker/Home Assistant. Jeśli coś padnie w reszcie infrastruktury (aktualizacja, restart kontenera, cokolwiek), wejście do własnego mieszkania i tak działa.

Więcej niż jeden czynnik

Rozpoznanie nie opiera się na jednej metodzie. Odcisk palca, karta NFC (DESFire) i dodatkowo heurystyka obecności po Wi-Fi razem budują coś w rodzaju dwuskładnikowej weryfikacji — nie wystarczy jedna metoda, żeby system uznał, że to naprawdę ja.

Kontaktrony dokładają do tego kolejną warstwę — niezależnie od tego, co zgłasza elektronika zamka, fizyczny czujnik magnetyczny potwierdza rzeczywisty stan rygli i samych drzwi. To rozdzielenie „co system myśli, że się stało” od „co faktycznie się stało” jest moim zdaniem kluczowe w każdym systemie bezpieczeństwa.

Powiadomienia i pełny obraz sytuacji

Wszystkie zdarzenia — otwarcie, zamknięcie, rozpoznanie na dzwonku, snapshot z kamery — trafiają do mojego własnego huba powiadomień, który napisałem, bo żadne gotowe rozwiązanie nie ogarniało tego w sposób, jakiego szukałem. Telegram, powiadomienia push z Home Assistanta, komunikaty głosowe — wszystko z jednego miejsca, ze zdjęciem z kamery dołączonym automatycznie do zdarzenia wejścia.

W Home Assistant dodatkowo dzwonek wywołuje popup z podglądem kamery na tablecie ściennym czy telefonie — więc zanim ktokolwiek otworzy drzwi, widzę, kto stoi na progu.

Detal, który pokazuje, że to naprawdę projekt pasji

Sam bridge do zamka Tedee siedzi w customowym, drukowanym na własnej drukarce 3D uchwycie ściennym — który przeszedł przez kilkanaście iteracji, zanim pasował dokładnie tak, jak chciałem. Bo skoro już się robi coś porządnie, to porządnie do samego końca.

Efekt końcowy

Wchodzę do mieszkania palcem albo kartą, drzwi się otwierają, system wie, że to ja, kontaktrony potwierdzają, że wszystko fizycznie się domknęło, a ja dostaję zdjęcie i powiadomienie — wszystko bez jednej chmurowej zależności, którą mógłby wyłączyć jakiś producent następnym update’em.

Dwa rzepy na plecy i tablet wisi. Byłem wstępnie na taką okoliczność przygotowany ale mimo wszystko układ kart wymagał podszlifowania. Dla bezpiecznej obsługi tabletu na ścianie, musiałem uniemożliwić osobom postronnym grzebanie w ustawieniach tabletu jak i samego HomeAssistanta. Samo „zabezpieczenie” HA to utworzenie nowego użytkownika z odpowiednimi uprawnieniami. Do zablokowania dostępu poza aplilacją użyłem Fully Kiosk Browser.

Fully Kiosk Browser

Sama konfiguracja aplikacji jest bardzo prosta. Podajemy lokalny adres naszego homassistanta, logujemy się i już
Home assistant wykryje instancje aplikacji i doda nam do systemu encje z nią związane.
możemy włączać lub wyłączać ekran, możemy sterować funkcją wykrywania ruchu. I co najważniejsze mamy dostęp do encji monitorującej stan baterii tabletu.

Dzięki tym wymienionym encjom możemy wykonać w pełni zautomatyzowany proces obsługi ładowania ekranu. Wiadomym jest, że tablet musi być na stałe podłączone do ładowarki, żeby nie trzeba było pamiętać o ładowaniu. Wiemy też, że urządzenie nie może być ciągle ładowane bo zabija to baterie. Nowe urządzenia mają co prawda rozwiązane to programowo i same przestają się ładować.

Mój tablet niby reguluje sobie ładowanie sam jednak mimo to chciałem zrobić to tak jak internet poleca, czyli odcinam prąd jak poziom baterii przekroczy 80% i zaczynam ładować jak spadnie poniżej 20%.

Sterowanie wybudzaniem ekranu

Sterowanie wybudzaniem ekranu opiera się o 2 czujniki ruchu. Czujnik ruchu w salonie oraz czujnik ruchu z kamery tabletu. Wyłączyłem włączanie ekranu w aplikacji a jedynie przekazuję stan z czujnika ruchu w tablecie. Dzięki takiemu zabiegowy mam pełną kontrolę nad wybudzaniem ekranu. Dodatkowo wybudzenie jest uzależnione od kilku pomocników. Między innymi jest blokada wybudzania w godzinach nocnych oraz podczas zajęć.

Sprzęt użyty do wykonania projektu

Tablet Lenovo Tab m10, który leżał zapomniany w komodzie dostał nowe życie. W końcu stał się przydatny. Jako uchwyt do tabletu wykorzystałem plecki od etui z klapką. Rewelacyjnie się spisały w tej roli. Bardzo dobrze trzyma tablet. Nie wiem nawet czy nie za mocno i czy on w ogóle jest jeszcze wyciągalny

Do obsługi zasilania użyłem zbmini Extreme od sonoff. Działa bez zarzutu po integracji zigbee2mqtt. Wszystko co mogę puszczam przez mqtt pomaga to w znaczny sposób ograniczyć ilość integracji podpiętych do homeassistanta.

No i ostatnim elementem jest kostka ładowarki. Nie ma tu potrzeby w sumie kupowania takiego elementu ale, żeby zaoszczędzić trochę miejsca, nie robić gniazda i używać zwykłej ładowarki znalazła się na liście zakupów. Jeszcze zapomniałem o kabelku kątowym micro usb, którego użyłem aby zminimalizować przestrzeń, którą zajmuje cała instalacja.

Montaż tabletu na ścianie

Jestem programistą z mocno rozbudowanymi umiejętnościami remontowymi jak już nie raz napomniałem. Mam też strasznie mocno wyczulone poczucie estetyki związanej z rurkami i kablami prowadzonymi natynkowo. Wszystko musi być wkute w ścianę. Nie mogłem wobec tego zostawić tabletu na rzepach z wiszącą ładowarką.

Pierwsze koty za płoty. Podkułem tynk na wymiar tabletu. I stało się to czego w sumie się spodziewałem czyli kable, które skutecznie utrudniły zadanie zlicowania tabletu ze ścianą. Na szczęście udało się podkuć pod przewodami i cofnąć je oraz dołożyć przewód do ładowarki. Osadzenie puszki z miejscem na ładowarkę i sonoffa poszło bardzo sprawnie. Gipsowanie, osadzanie narożników, gładziowanie, szlifowanie oraz malowanie zajęło praktycznie cały weekend. Było warto.
Poniżej fotorelacja z prac remontowych:

Oto efekt prac remontowo budowlanych. Koszt z jakim trzeba się liczyć, zakładając, że mamy tablet to około 200zł. Moduł sonoff, plus ładowarka i kabelek kontowy to około 100zł. Druga stówka na materiały: gips, gładź, kawałek przewodu, puszka, narożnik.

Jeżeli natomiast nie mamy tabletu do dyspozycji to koszt takiego dashboard’u jest uzależniony od tego jakiej klasy urządzenie się kupi. Trzeba jednak pamiętać, że najtańsze tablety będą działać i zniszczy to cały efekt.

Brakuje jeszcze estetycznej ramki… niestety jestem teraz na etapie myślenia o wymianie włączników więc ramka musi poczekać aż zdecydujemy się na włączniki, żeby ramka tabletu była jak najbardziej zbliżona do osprzętu elektroinstalacyjnego.

Domyśliłem się, że to są wszystkie dockerowe obrazy i inne rzeczy, które docker tworzy przy okazji uruchamiania kontenera. Szybki rzut okiem na google i już po chwili miałem w ręku potężne narzędzie

pi@raspberrypi:~ $ sudo docker system prune -a
WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all images without at least one container associated to them
        - all build cache
Are you sure you want to continue? [y/N]

Proste polecenie a odzyskało 7GB pamięci :). Po tym zabiegu wszystko wróciło do normy i zajętość miejsca na karcie oscyluje w okolicy 42%. Nie jak przed pielęgnacją dockera 71%

Mam porobione w HA wykresy zużycia zasobów raspberry, do których od czasu do czasu zaglądam. Gdyby nie to mógłbym przegapić mement, w którym się karta zapcha. Mogłoby dojść do tego, że przy przypadkowym resecie system już by się nie podniósł. Na szczęście byłem czujny