2022-12-14

Does Matter matter?
część 1

(Pre)historia

Około 1998 roku zaczął powstawać protokół → Zigbee przeznaczony do bezprzewodowej komunikacji urządzeń szeroko pojętej automatyki. Miał on stanowić alternatywę dla Wi-Fi i Bluetooth1), które co prawda były bardziej uniwersalne, ale wymagały wielokrotnie więcej energii, co w przypadku niewielkich, autonomicznych urządzeń było nie tylko niepożądane, ale wręcz blokowało ich rozwój. Cztery lata później powstała organizacja → Zigbee Alliance, której celem było ustandaryzowanie protokołu, co nastąpiło około 2003 roku. Wydawało się, że future was wide open i urządzenia różnych producentów będą mogły komunikować się w jednolity sposób, co pozwoli bezproblemowo łączyć je w większą całość. Szczególnie, że z biegiem czasu do Zigbee Alliance przystąpiło kilkaset firm, m.in. Legrand, Philips, Samsung czy IKEA. Niestety w większości przypadków, pomimo używania tego samego protokołu, powstawały zamknięte rozwiązania gdzie niezbędne były centralne elementy sterujące (np. Philips Hue Bridge, Samsung SmartThings Hub czy IKEA Trådfri Gateway) nie pozwalające na parowanie urządzeń innych firm. Co prawda większość tych mostków lub hubów posiada API pozwalające na dostęp do ich funkcji, ale są to API specyficzne dla każdego z producentów. Ich integracja za pomocą jednego software’owego sterownika jest co prawda możliwa, ale wymaga niemałego nakładu pracy. Przykładem może być istniejący od 2010 roku projekt → openHAB zapewniający obsługę prawie 300 różnych systemów smart home: ma on jeden z największych zespołów programistów w świecie open-source.

Współczesność

Dość sporo czasu zajęło firmom w ten czy inny sposób zaangażowanym w tworzenie i obsługę urządzeń smart home dojście do wniosku, że potrzebne jest jedno, wspólne i co więcej otwarte rozwiązanie. Dopiero w grudniu 2019 roku Alphabet, Amazon i Apple razem z Zigbee Alliance rozpoczęły pracę nad wspólnym standardem o nazwie → Matter (który początkowo nosił nazwę CHIP – Connected Home Over IP). Pierwsze zapowiedzi mówiły o udostępnieniu finalnej specyfikacji na koniec 2020 roku, potem miałby to być ostatni kwartał 2021. Ostatecznie → Matter 1.0.0 ujrzał światło dzienne 30 września 2022 roku a w międzyczasie, w maju 2022 roku, Zigbee Alliance stało się → Connectivity Standards Alliance. Zgodnie z zapowiedziami jest otwartym standardem: → repozytorium GitHub zawiera kody źródłowe, opis założeń i architektury oraz całkiem sporo przykładów dla różnych platform i języków programowania. Preferowanym protokołem sieciowym jest Thread2), jednak możliwa jest komunikacja za pomocą bardzo szerokiej gamy rozwiązań. Czy jednak najważniejszy selling point nowego standardu czyli unifikacja jest faktem i zamiast pięciu naklejek "Works with ..." zobaczymy już tylko jedną "Works with Matter"? Niestety, pomimo tego że mam w domu produkty kilku różnych firm, które zapowiedziały obsługę Matter, nie jestem jeszcze w stanie sprawdzić co nowy standard oznacza w praktyce.

Philips Hue

W maju 2021 Signify (firma odpowiedzialna za Philips Hue) zapowiedziała, że cała linia produktów będzie zgodna z Matter dzięki → aktualizacji oprogramowania. Na stronie Philipsa jest sekcja dedykowaną → Matter, ale to tylko ładna marketingowa ulotka, bez konkretnych dat wydania nowego firmware’u. Portal → The Verge ujawnia więcej niż sam producent: aktualizacja ma być dostępna do końca pierwszego kwartału 2023 roku, a na stronie dla developerów Hue można uzyskać dostęp do → wersji betaWarto jednak zwrócić uwagę na informację podaną drobnym drukiem: „obsługę protokołu Matter zapewnia mostek Philips Hue Bridge” - nie będzie więc oczekiwanej rewolucji i nadal niezbędny będzie dedykowany mostek a tylko komunikacja z nim będzie wykorzystywać nowy protokół. Szukając dalszych informacji na ten temat trafiłem na → wywiad z Georgem Yannim kierującym działem Hue. Mówi on między innymi o tym, że nie jest planowana w urządzeniach końcowych (żarówkach, przełącznikach, itp.) implementacja preferowanego przez Matter protokołu Thread a dodatkowo tylko podstawowe funkcje będą dostępne za pośrednictwem Matter, bardziej zaawansowane nadal przez dedykowane Hue API.

Eve Systems

Eve Systems wydaje się mocno → wspierać nowy standard. Na 12 grudnia był zapowiedziany nowy firmware → obsługujący Matter, jednak nie dla wszystkich urządzeń - aktualizację miały dostać Eve Energy, Eve Motion i Eve Door & Window. Dla pozostałych, w tym stojącego u mnie na szafce Eve Room, nie ma konkretnej daty, jednak docelowo wszystkie urządzenia komunikujące się za pomocą protokołu Thread (druga generacja Eve Room obsługuje Thread) mają obsługiwać Matter. Warto zaznaczyć, że do przeprowadzenia aktualizacji konieczny będzie system iOS lub iPadOS ponieważ obecnie urządzenia Eve są zgodne tylko z Apple Home. Dodatkowo na chwilę obecną - jak można przeczytać w artykule na portalu → MacRumors - musi to być system w wersji 16.2 wydanej dosłownie kilka godzin temu, potrzebny jest router brzegowy Thread (w praktyce Apple TV lub głośnik Home Pod) i wymagane jest zarejestrowanie się w programie Early Access.

Tak czy inaczej, kierunek rozwoju urządzeń Eve wydaje się zdecydowanie ciekawszy niż w przypadku Hue: wszystkie nowe elementy systemu obsługujące Bluetooth już otrzymały albo niedługo otrzymają obsługę protokołu Thread a dotychczasowa obsługa protokołu HomeKit zostanie uzupełniona/zastąpiona o/przez Matter. W przyszłości, gdy poszczególne urządzenia będą sprzedawane od razu z firmwarem Matter zniknie też konieczność posiadania dostępu do systemu iOS/iPadOS/tvOS.

IKEA i Flic w części drugiej


1) Bluetooth w wersji Low Energy (LE) jeszcze nie istniał – standard został zatwierdzony w 2009 roku.

2) Thread to protokół działający w niższej warstwie niż Matter, ich wzajemną relację opisuje na przykład → ten artykuł.


2022-10-10

Raspberry Pi z dyskiem SSD

Jedno z moich Raspberry Pi działa z dyskiem SSD zamiast karty microSD. Nie jest to typowa konfiguracja i kiedy kilka dni temu eksperymentując z aktualizacjami popsułem system na tyle, iż jedynym rozwiązaniem wydawała się reinstalacja uświadomiłem sobie, że nie pamiętam szczegółów. Po wejściu na stronę https://www.raspberrypi.com/software/ przekonałem się, że świat Pi dość mocno zmienił się przez ostatnie lata: pojawiło się narzędzie Imager, które znacznie ułatwia taką operację. Co prawda bez karty microSD tak całkiem się nie obejdzie, ale będzie ona potrzebna tylko na chwilę. Po uruchomieniu Imagera klikamy przycisk CHOOSE OS, wybieramy z listy "Misc utility images", następnie "Bootloader" i "USB Boot". Po wybraniu docelowej karty (przycisk CHOOSE STORAGE) klikamy WRITE - na kartę trafi oprogramowanie, którego jedynym zadaniem jest skonfigurowanie bootloadera Raspberry Pi tak, aby w pierwszej kolejności próbował uruchomić system z dysku podłączonego do portu USB.
Zapis trwa dosłownie kilkanaście sekund, wyjmujemy kartę i uruchamiamy z niej Raspberry Pi. Jeżeli mamy podpięty monitor to należy poczekać aż ekran zrobi się zielony - będzie to oznaczało, że proces zapisu bootloadera zakończył się. Gdy nie mamy monitora czekamy aż zielona dioda zacznie migać.
Następnie zapisujemy na SSD obraz pełnego systemu. Jeżeli zdecydujemy się na wersję 64-bitową należy najpierw kliknąć "Raspberry Pi OS (Other)" a następnie wybrać odpowiadającą nam odmianę systemu. Jako docelowe urządzenie tym razem wskazujemy nie czytnik kart, ale dysk podpięty przez USB - warto dwa razy upewnić się, iż wybrany jest właściwy dysk. Przed rozpoczęciem zapisu warto kliknąć ikonkę koła zębatego - moim zdaniem to najciekawsza funkcja Imagera. Pozwala wybrać wiele użytecznych opcji, które zazwyczaj trzeba było konfigurować na piechotę już po nagraniu obrazu systemu na kartę lub dysk. Można m.in. ustawić nazwę hosta, włączyć dostęp przez SSH i ustawić domyślną strefę czasową.
Po kliknięciu WRITE i nieco dłuższym oczekiwaniu niż poprzednio przepinamy dysk do Raspberry Pi, wyjmujemy kartę microSD i pełni nadziei czekamy na uruchomienie się systemu. Po około minucie host pojawi się w sieci i będzie możliwe zalogowanie się przez SSH za pomocą hasła lub klucza ustawionych za pomocą Imagera.

2022-06-11

Upgrade openHABa

Niedawno postanowiłem zrobić upgrade domowego openHABa z wersji 3.1.0 na 3.2.0. Moja instalacja działa na Raspberry Pi w kontenerze Dockerowym, a ponieważ jako katalogi z konfiguracją, pluginami i danymi mam montowane katalogi hosta, to zgodnie z oficjalną instrukcją aktualizacja powinna być banalna. Trzeba zatrzymać i usunąć kontener z aktualną wersją (wszystkie istotne dane zostają na hoście) a następnie ściągnąć i uruchomić nową. Dla porządku po usunięciu kontenera skasowałem logi z userdata/logs. Obraz wersji 3.2.0-debian ściągnął się bez problemów, zaczął uruchamiać i zawiesił się. Kontener co prawda był widoczny:
$ docker ps
CONTAINER ID   IMAGE                        ... CREATED         STATUS
e2906859d033   openhab/openhab:3.2.0-debian ... 2 minutes ago   Up 2 minutes (health: starting)
w logu userdata/update.log zapisało się:
...
Replacing userdata system files with newer versions...
Clearing cache...

Performing post-update tasks for version 3.2.0:

SUCCESS: openHAB updated from 3.1.0 to 3.2.0
ale już w logu userdata/logs/openhab.log było pusto, a po kilkunastu minutach Docker jednak uznał kontener za niezdrów:
$ docker ps
CONTAINER ID   IMAGE                        ... CREATED          STATUS
e2906859d033   openhab/openhab:3.2.0-debian ... 19 minutes ago   Up 19 minutes (unhealthy)
Komenda docker stop co prawda zadziałała, ale zapisała do syslogu mało zachęcające:
Container failed to exit within 10s of signal 15 - using the force
Przyznam się, że na tym etapie zatrzymałem się na dłuższą chwilę - nie mając nic w logach ciężko było znaleźć jakiś punkt zaczepienia. W końcu uruchomiłem kontener nie jako usługę, ale po prostu w terminalu za pomocą docker run ... dodatkowo usuwając z opcji --detach aby widzieć co dokładnie się dzieje. I stała się światłość - w ostanie linii logów, po wypisaniu której proces się zawieszał, było:
OpenJDK Client VM warning: No monotonic clock was available - timed services may be 
adversely affected if the time-of-day clock changes
na co Google od razu znalazł radę na forum openHABa i na Stack Overflow. Okazało się, że winna była zbyt stara biblioteka libseccomp2 zawarta w Debianie Buster (chodzi o hosta, nie kontener). Oczywistym rozwiązaniem byłby upgrade całego systemu do Bullseye, ale trochę obawiałem się tak radykalnej operacji, szczególnie że na oficjalnej stronie Raspberry Pi jest wprost napisane "we don’t support or recommend this". Dlatego zdecydowałem się na użycie repozytorium buster-backports, w którym jest już zaktualizowana wersja libseccomp2. Aby dodać repozytorium do systemu trzeba wykonać standardową procedurę:
$ sudo apt-key adv --keyserver keyserver.ubuntu.com \
 --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
$ echo 'deb http://httpredir.debian.org/debian buster-backports main contrib non-free' \
 | sudo tee -a /etc/apt/sources.list.d/debian-backports.list
a następnie, po aktualizacji listy pakietów za pomocą:
$ sudo apt update
można zainstalować nową wersję biblioteki wskazując źródło pakietu za pomocą opcji -t:
$ sudo apt install libseccomp2 -t buster-backports
Po tej operacji ponowne uruchomienie kontenera openHAB kończy się spodziewanym:
[INFO ] [org.openhab.ui.internal.UIService   ] - Started UI on port 8080
Czekam z niecierpliwością na niespodzianki w zapowiadanej na 27. czerwca wersji 3.3.0 😅

P.S.
 
O co właściwie chodzi z owym monotonicznym zegarem? Okazuje się, że zarówno openHAB jak i Java są niewinne. W Debianie i wywodzących się z niego systemach, dla architektury arm32v7 (Raspberry Pi) kombinacja Dockera starszego niż 19.03.9 i biblioteki libseccom starszej niż 2.4.2 powoduje, iż w kontenerze nie jest dostępny poprawnie działający zegar. Wpływa to na cały system, w tym nawet komendę date (przykład ze zgłoszenia w projekcie Ubuntu):
$ docker run --rm -it --entrypoint /bin/bash ubuntu:20.04
root@8543aa82ff05:/# date
Thu Feb 26 08:20:11 UTC 1970

P.P.S.

Pierwszy wpis od 2756 dni. Z jednej strony fajnie, ale jednak trochę strasznie.
© The Useful Pot To Keep Things In
Maira Gall