Co w 433 MHz piszczy?

Wpis na blogu o termometrach zewnętrznych przypomniał mi o pewnym zakupie, który jakiś czas temu poczyniłem. Chodzi o termometr bezprzewodowy z Jula. Nieco spontaniczny zakup, by mieć pretekst do zabawy urządzeniami pracującymi w paśmie 433 MHz. Z drugiej strony nawet gdyby nie udało się dobrać do danych z komputera, to jakaś tam potrzeba poznania temperatury w różnych miejscach w mieszkaniu była.

Do zabawy nie doszło, nie pamiętam dlaczego. Z tego co pamiętam chciałem pójść bardziej w stronę dedykowanego odbiornika (i transmitera…) 433 MHz, nie SDR. I trochę utknąłem na zakupie, a w zasadzie na zastanawianiu się nad podłączeniem tego – lub czegoś podobnego – do zwykłego komputera, najchętniej przez USB.

rtl_433

W każdym razie wpis zwrócił moją uwagę na program rtl_433 i możliwość odczytu danych przez SDR. Wersja docelowa to może nie będzie, w rozmowie ze znajomymi z pracy mieliśmy nieco obawy co do jakości sygnału, ale skoro tak łatwo dostępne, to warto spróbować. Okazało się, że pakiet rtl-433, który jest dostępny w Debianie SID, mam już zainstalowany. Zupełnie nie przypominam sobie, bym go używał, ale może to z czasów kiedy instalowałem wszelki soft do SDR?

Uruchomiłem i… to działa, po prostu, od kopa. Okazało się, że termometr z Jula, który kupiłem, jest wspierany. Okazało się także, że podobny czujnik jest gdzieś w okolicy. Najciekawsze zaś jest, że wykrytych zostało sporo innych czujników. Z których wiele udostępnia nie tylko dane o temperaturze, ale także o wilgotności.

Ilość widocznych czujników naprawdę mnie zaskoczyła. Z fabryczną, biedną anteną ustawioną w losowym miejscu na biurku SDR widzi kilka. W tym – sądząc po nazwach – trochę czujników temperatury i ciśnienia powietrza z samochodów.

Zastosowanie

W oparciu o Raspberry Pi lub podobną płytkę można łatwo można zrobić sobie własną stację pogodową, z dowolną ilością czujników. Wariant udostępniający dane po WWW jest trywialny i zapewne w tę stronę pójdę. Nic nie stoi jednak na przeszkodzie by dołożyć wyświetlacz i na nim prezentować dane, tworząc odpowiednik prawdziwej stacji.

Dodatkowo opisywane rozwiązanie daje możliwość skorzystania z danych z cudzych czujników. Mój czujnik zdalny jest w innym pomieszczeniu, niż stacja. Trochę miałem dylemat, czy nie umieścić go za oknem. Ale skoro sąsiad ma na zewnątrz, to ja już nie potrzebuję… Tracimy co prawda kontrolę nad umiejscowieniem czujnika, który może np. znajdować się w nasłonecznionym miejscu, ale darowanemu koniowi w zęby się nie zagląda.

Rozglądam się teraz i myślę jaki termometr bezprzewodowy kupić. Póki co znalazłem ładny moduł do stacji pogodowej za 34 zł, kuszą jednak inne moduły do stacji pogodowych, które zapewniają pomiar wilgotności. Co prawda nie mam pewności czy będą obsługiwane przez rtl_433, ale zakładam, że tak. Ewentualnie można dopisać ich obsługę.

Noworoczne porządki

Postanowień noworocznych brak, ale zmiana roku na 2022 to dobry moment na porządki informatyczne z jednej strony, a na ich zapowiedź – w roli motywatora – z drugiej.

PUM

Zaczęło się od informacji na IRCu, że PUM przestał działać[1]. Przyczyną okazała się cicha zmiana API przez Uptime Robot. API v2 to większe zmiany, niż sądziłem – część danych przekazywana jest teraz w payload w POST, pojawił się limit zapytań w czasie, lekkie zmiany formatu danych. Nie wiem, czy pierwsza wersja umiała zwracać dane w JSON, v2 potrafi. Rzut oka na Perla i wiedziałem, że raczej do przepisania na Pythona[2], przy okazji parę zmian i… trochę utknąłem. Mam „większą połowę” zrobioną, obecnie jestem rozdarty między chęcią zachowania dokładnej starej funkcjonalności, a napisaniem tego bardziej elegancko. W ogóle trochę uderza mnie oglądana z perspektywy zwięzłość Perla.

Zrobiłem. Nie jestem w 100% zadowolony, ale pum.pl is dead, long live pum.py!

Nextbike

Monitoring ilości rowerów Nextbike na stacjach zacząłem w roku 2013. W roku 2017 skrypt został przepisany na zgrabniejszego Pythona. O ile na początku zaglądałem regularnie, to obecnie praktycznie nie korzystam. Powód jest prosty: rzadko kiedy korzystam z rowerów na stacjach. Odkąd pojawiły się rowery z odbiornikiem GPS, niemal zawsze w praktyce biorę rower „z ulicy”, nie ze stacji. I tak go zostawiam. Po prostu niemal zawsze bliżej mam jakiś rower luzem. No i rzadko moja trasa kończy się na stacji Nextbike.

Co się udało w tym projekciku? Całkiem sporo: działał i był użyteczny, przynajmniej dla mnie, przynajmniej przez pewien czas. Pozwoliły poćwiczyć Pythona i zapoznałem się w praktyce z jinja2. Nauczyłem się, ile (nie)warte są „darmowe” domeny (tu: .tk).

Co się nie udało? Liczyłem, że stanie się popularniejszy. Nie udał się eksperyment z automatycznym SEO. Liczyłem, że dobrze otagowane strony z konkretnymi informacjami trafią wysoko w pozycje w wyszukiwarce Google. Nie było całkiem źle, ale gorzej, niż liczyłem, biorąc pod uwagę otagowanie metadanymi. Chęć zachowania maksymalnej prostoty i automatyzacji spowodowały, że nie dodawałem dodatkowej treści, mogącej pozytywnie wpłynąć na pozycjonowanie.

Wkrótce projekt przestanie istnieć – skrypt zostanie wyłączony i zapewne trafi na GH.

Hosting

Szykuje się zmiana platformy, na której utrzymuję hosting. VPS w Aruba Cloud podrożał jakiś czas temu i od tamtego czasu rozglądałem się niespiesznie za czymś innym. W zasadzie decyzja już zapadła i była pierwsza próba, niestety, weryfikacja kart w nowym miejscu jest lekko przesadzona. Ma szansę być szybciej, bo znacznie większe zasoby, ma szansę być wesoło, bo szykuje się przesiadka na architekturę ARM. Nie rozwijam tematu, bo zapewne zasłuży na osobny wpis.

Tyle z większych planowanych zmian. Od dawna wisi temat lekko przestarzałego softu do tworzenia Planety Joggera, ale na razie się nie pali – póki co system posiada jeszcze wsparcie.

[1] Tak, jest pomysł na drobną modyfikację we wszystkich skryptach tak, by przy błędzie wykonana powiadamiały np. mailem. Bo nie jest to pierwszy raz, kiedy o padzie czegoś z powodu zmian po stronie źródła dowiaduję się po długim czasie. Inna sprawa, że to nic krytycznego.
[2] Nazwa zostanie bo Perl Uptime Monitor -> Python Uptime Monitor.