Projekt Gom Dżabbar


Jakby ktoś nie wiedział (impossible!) to w tym roku będzie miał premierę film Diuna, reżyserem jest Denis Villeneuve (pan zrobił Arrival, Blade Runner 2049, Sicario itp).

Oryginalny sześcioksiąg Diuny przeczytałem dwa razy; najpierw w okolicach 7. klasy podstawówki, natomiast drugie podejście piętnaście lat temu. Wychowalem sie na tym uniwersum: Dune 2 (The Building of a Dynasty… wciąż słyszę The planet Arrakis, known as Dune z intra), książkach i filmie Lyncha. Może by sobie odświeżyć?

(nota bene, przed Lynchem Diunę próbował ekranizować Alejandro Jodorowsky. Nie udało się, ale ekipa wzięła przygotowane pomysły i stylistykę i poszła nakręcić Obcego w 1979).

Wracając do książek. Oryginalną serię dokończył syn Franka Herberta z kolegą, dopisując Hunters of Dune oraz Sandworms of Dune. Tych jeszcze nie czytałem, więc również trafiły do kolejki. Ale poza sequelami powstało też kilka prequeli. Czyż więc wspaniałym pomysłem nie byłoby przeczytanie wszystkiego w kolejności wydarzeń w uniwersum? Tak jak zrobiłem np. z cyklem Fundacji czy Enderem? W internetach można znaleźć pomocną listę z chronologią. Tak zrodził się mój prywatny Projekt Gom Dżabbar.

Na razie przeczytałem 3,5 książki oraz 3 opowiadania. Recenzje (o ile miałem siłę) znajdują się na Lubimy Czytać. Ogólnie – dramat, głównie fabularnie, warsztatowo też słabo. Z niecierpliwością wyczekuję, aż dobrnę do oryginałów Herberta. Na razie kryptonim projektu oddaje w 100% odczucia towarzyszące czytaniu książek autorstwa Briana Herberta i Kevina J. Andersona.

Do premieru filmu zostało 10 miesięcy i 4 dni.

W 2019 nastąpił koniec


Nastąpił koniec sporej liczby seriali. Nie przypominam sobie roku z aż taką kumulacją finałów. A pożegnaliśmy się m. in. z:

  • The Affair – ciekawy eksperyment z pokazywaniem tych samych wydarzeń z różnych perspektyw dał radę na 5 sezonów
  • The Big Bang Theory
  • Designated Survivor – pomysł OK, dalej niestety generic political procedural
  • Elementary
  • Man in the High Castle
  • Mr Robot
  • Game of Thrones – meh
  • Orange is the New Black – everybody loses
  • Preacher
  • Silicon Valley – końcówka bardziej smutna niż śmieszna
  • Suits – tu był nawet jeden odcinek, w którym wszyscy nazwzajem na siebie NIE krzyczeli

Zakończył się też wielki, 11-letni rozdział z Avengers. W sumie dobrze, bo trudno odcinki marvelowego film-serialu odróżnić od siebie, a i Tony Stark już nie taki żywy jak na początku.

Time needed to dist-upgrade Fedora


Every couple of months I upgrade my main home computer to the latest Fedora. As this process is not instantaneous, this means some time without internet, wifi, smart home controls etc. This time I decided to measure how long it takes exactly.

Hardware is mid-range home server: Core i5 CPU, 16GiB of RAM, storage is 2x HDD in btrfs raid1, over LUKS, bcached on NVMe drive.

I've used dnf system-upgrade to download packages, then I rebooted and started counting time.

Wallclock Time since start Time Δ Phase
10:50
System booted. This will take a while displayed.
11:06 16m +16m Upgrade started. 5294 steps to finish.
11:23 33m +17m First thousand steps done.
11:41 51m +18m Second thousand steps done.
11:59 1h09m +18m Third thousand steps done.
12:11 1h21m +12m Fourth thousand steps done.
12:26 1h36m +15m Fifth thousand steps done.
12:29 1h39m +3m 5294 steps done. Running scriptlets begin.
12:31 1h41m +2m Scriptlets done. Verification begin.
12:36 1h46m +5m Verification done. No messages for few minutes.
12:42 1h52m +6m Upgrade done, rebooting.

Basically, full distribution upgrade from Fedora 30 to 31 takes about 2 hours. This is with bcache mode set to writeback. With safer writethrough, upgrade takes couple more hours, but I don't have specific number.

It's election time in Fedora-land


It's time to influence the course of our beloved project – Fedora Linux. Before 5th of December 2019 we have a chance to select people for:

  • Fedora Engineering Steering Committee (FESCo)
  • Fedora Council
  • Mindshare (community groomers)

So, go read candidate interviews at Community Blog, think about them and cast the vote at https://elections.fedoraproject.org/

Over few iterations, I've noticed that my choice is little influenced by the interviews; I put more weight to what I remember about individuals from the mailing list traffic. I mean mainly fedora-devel, although I follow -infrastructure and -server, too. That in turns means, I won't be voting for Haralds, Kevins and Johns juniors haunting those lists, no matter how awesome their interview may be. Abrasive people should be extinguished, not promoted.

There's a minority of people I know personally. Often I do respect their skills, so Zbigniew got my vote.

But over the last few elections, interviews gave me hints who not to vote for. Candidate putting too much weight on modularity raises a red flag, and quickly falls into “do not vote” bucket.

There's a lot to unpack why modularity was like a sand thrown into Fedora's gears. Mailing list threads reached Debian's proportions, overshadowing discussions we had when we were considering systemd. Hard to read them all. Here's a shortcut – go read excellent Fedora's modularity mess at LWN.net. This summary is prime example of LWN's high writing standard. I urge you to pay for subscription to LWN – it's really worth it.

https://badges.fedoraproject.org/pngs/ivoted-f31.png

OpenShift's haproxy as IPv6 ingress


Kubernetes networking always struck me as some PoC mistakenly put into production. Among questionable design choices, Internet Protocol version 6 is hardly supported. But when using OpenShift's default router – haproxy – you can easily handle IPv6 at your ingress.

With recent version is even easier than before. I've started following Customizing HAProxy Router Guide, but after extracting config template I've discovered that all the ground work has been prepared already, for v3.7 and up.

OpenShift's HAProxy container reacts to ROUTER_IP_V4_V6_MODE environment variable. When set to v4v6, the router will gladly accept connections in both IP versions, legacy and v6.

You should oc -n default edit dc/router and in the long block of envvars add this:

- name: ROUTER_IP_V4_V6_MODE
  value: "v4v6"

While editing this, you may want to add ROUTER_ENABLE_HTTP2=true, too.

Gdzie się podziało to pół roku…


Huh. Ostatnie sześć miesięcy zniknęło mi nie wiem gdzie.

Po części to wina zmian zawodowych. Powiedziałem YOLO, wyszedłem poza strefę komfortu, i od lipca dołożyłem sobie obowiązków. Teraz jestem Head of DevOps w naszym kawałku NRD, czyli w Group Data Management Office. Dalej robię jakieś automatyzacje przy Big Data, chociaż bardziej to mój zespół robi. I pamiętajcie dzieci, DevOps to podejście, nie stanowisko.

Strava uprzejmie wypomniała mi, jak się zapuściłem. Dostałem świetny filmik z żałosnymi wynikami. A przeniesienie biura do Gdyni bardzo źle odbiło się na wspinaczce w Elewatorze. Wstyd.

Czas zjadła mi też nauka i certyfikacja. Certified Kubernetes Administrator, Certified Specialist in OpenShift Administration, SAFe Advanced Scrum Master (no joke!).

Pilnowanie fachowca urządzającego mieszkanie, oraz związane z tym wcześniejsze przygotowania też zabrały swoje.

A na koniec roku mały sukces. W końcu, po raz pierwszy udało mi się wylądować w F29 Retaliator. Wcześniej chyba się po prostu nie przykładałem.

F29 na lotnisku

Tak, po 25 latach od kiedy pierwszy w to zagrałem. Kolejny cel: wylądowanie w T.F.X.

Szaleństwem jest robić wciąż to samo i oczekiwać różnych rezultatów (BO2019 Gdańsk)


A ja robię. Po raz kolejny zgłosiłem do Budżetu Obywatelskiego w Gdańsku mój projekt – Ścieżkę rolkowo-biegowo-pieszą wokół zbiornika retencyjnego Jabłoniowa. Dostał numer 11 wśród projektów dzielnicowych dla Jasienia. I tym razem projekt wygra :)

Potrzebne są tylko głosy, które można oddawać od 10 do 24 września br. Jeśli mieszkacie w Gdańsku, to wejdźcie proszę na https://gdansk.zetwibo.pl/voting/info i oddajcie 5 głosów na jedenastkę. A jeśli nie mieszkacie, to zachęćcie znajomych stąd.

Głosować można na projekty w innych dzielnicach niż swoja. Nie trzeba mieć meldunku – wystarczy oświadczenie o byciu mieszkańcem Gdańska.

Dzięki!

Quick note: openHAB/ESPEasy/MQTT and easy fading


Connecting ESPEasy's GPIO outputs to switch elements in openHAB, using MQTT is quite simple:

Switch sD1MINI02MOS "Countertop light [%s]" <whites> {
  mqtt=">[motherqtt:/d1mini02/gpio/5:command:ON:1],>[motherqtt:/d1mini02/gpio/5:command:OFF:0]"
}

MQTT binding field explanations:

motherqtt
broker's name (defined in openhab.cfg)
/d1mini02/
ESPEasy %sysname%. Basically, a module name
gpio/5
GPIO number to control
command
openHAB will send a command
ON:1
what to send (“1”) when state changes to on
OFF:0
ditto when switching off

Switching ON/OFF gets boring quite fast. Luckily, ESPEasy exposes PWM (pulse width modulation) control of GPIO outputs. This gives possibility to vary brightness of light sources controlled by GPIOs. Let's modify the item definition to have light dimmed when set to OFF (not turned fully off):

Switch sD1MINI02MOS "Countertop light [%s]" <whites> {
  mqtt=">[motherqtt:/d1mini02/pwm/5:command:ON:1023],>[motherqtt:/d1mini02/pwm/5:command:OFF:128]"
}

Compared to direct gpio control: gpio became pwm, and 1/0 for ON/OFF became 1023 (fully filled impulse) and 128 (one eighth of full brightness).

Two things to remember: while ESPEasy's range of PWM is 0÷1023, openHAB's dimmer type only works support 0÷100 (like in percents). You cannot directly drive /pwm/ with openHAB's values, you need transforms. Second, when you start using /pwm/, standard /gpio/ stops working. You need to set /pwm/ to 0 to have /gpio/ control work again.

PWM fading is quite nice, but with binary ON/OFF state not very useful. But! Look closely at ESPEasy GPIO command set. There's a PWM command version with <duration>. This is useful for having lights turn on and off softly, instead of abruptly.

This requires slightly more complicated definition. We cannot use /pwm/ directly, instead control the /cmd endpoint:

Switch sD1MINI02MOS "Countertop light [%s]" <whites> {
  mqtt=">[motherqtt:/d1mini02/cmd:command:ON:PWM,5,1023,200],>[motherqtt:/d1mini02/cmd:command:OFF:PWM,5,0,600]"
}

Above definition will give pleasant, 200ms long fade in when turned ON, and 600ms long fade out when turned OFF. Compared to first definition, following has changed:

  • /gpio/5 (or /pwm/5) became /cmd
  • 1 (or 1023) for ON became PWM,5,1023,200 – control PWM, on GPIO number 5, set fill to 1023 during 200ms
  • symetrically, 0 (or 128) for OFF became PWM,5,0,600 – fade GPIO 5 to 0 during 600 ms

You provide final PWM value, fade starts from current value. Happy fading! :)

Dwa kroki do przodu, jeden wstecz. Extract!


W postępującem smartyzacji mieszkania na razie najwięcej czasu zeszło mi na podłączeniu okapu kuchennego. Obmyśliłem kilka podejść, a to co wdrożyłem musiałem poprawiać. Utrudniłem sobie założeniem, że dodatkowe sterowanie musi być rownoległe z oryginalnym. Żeby nie psuć istniejących funkcji i nie musieć wyrabiać nowych nawyków.

Ale na początek. Przypadki użycia:

  • podświetlenie; dwie halogenowe lampki świecące do garnków są z pewnością przydatne. Z kolei mało przydatne, a nawet turbo-wkurzające jest wymyślone przez producenta sterowanie. O ile włączenie dotknięciem jest OK, to żeby je wyłączyć trzeba przytrzymać pole kontrolne dokładnie przez 1,21 sekundy. Milisekunda mniej lub więcej i światło nie reaguje, albo tylko zmniejsza się jasność. Uproszczenie wyłączania wystarczyło mi za motywację do lutowania;
  • sterowanie wyciągiem; miałem już sytuację, że jestem po łokcie zajęty robieniem jedzenia, a na patelni obok coś zaczyna mocno dymić. I żeby zwiększyć obroty wyciągu muszę się odkopać i wyczyścić jeden palec (bo sterowanie panelem dotykowym!). Marzyło mi się po prostu powiedzieć „Jarvis^W Aleksiej, włącz wyciąg na 3”.
  • lampki pod sufitem; to bonusowo, bo skoro już mam esp8226 w pobliżu zasilania, to mogę tam podpiąć sterowanie (i zrezygnować z jednego z gniazdek na pilota z Biedronki).

Dla ustalenie uwagi, jeszcze parę słów o okapie. Silnik wyciągu ma 3 biegi i jest zasilany z 230V. Co ciekawe, każdy bieg ma osobne uzwojenie, tj. przy włączeniu biegu 2 zasilane powinno być tylko uzwojenie nr 2. Wolałem nie sprawdzać co się dzieje po podaniu zasilania na więcej niż jedno uzwojenie – czy spali się w potoku iskier, czy tylko oderwie się od ściany i odleci.

Lampki halogenowe zasilane 12V, poprzez transformator elektroniczny Shark60. Jest na nim napisane „dimmable by trailing or leading edge dimmer”, ale za wiele mi to nie mówi.

Interfejs użytkownika to panel dotykowy z wyświetlaczem 7 segmentowym. 4 pola dotykowe: bieg wyciągu + i -, timer (nigdy nie użyłem) i pojedyncze pole sterowania oświetleniem (patrz 1. przypadek użycia). Podłączony do sterownika 10 przewodami. Niestety nie udało mi się znaleźć rozpiski co i jak, więc nie wykorzystałem tego interfejsu samemu. Może kiedyś.

Kontroler. Dość prosta płytka, najważniejszy jest mikrokontroler atmega8l. Do jego wyprowadzeń podłączone m. in. zasilanie 5V (via regulator napięcia 7805) i bank tranzystorów w układzie ULN2003.

Na tej bazie wyklarowały mi się trzy scenariusze w jaki sposób mógłbym dołożyć swoje sterowanie.

Plan 1: bezpośrednie sterowanie 230V

W pierwszym przybliżeniu rozważałem całkowite olanie istniejącego sterownika i powielenie jego funkcji w moim układzie. To oznacza konieczność sterowania 230V – specjalnie się do tego nie palę, ale kilka przekaźników albo triaków załatwi sprawę.

Uciążliwości jest jednak całkiem sporo. Potrzebuję dodatkowo zasilacza z 230V na 12V (do halogenów) i 5V/3.3V (klony d1mini, które mam, można zasilać z obu napięć). To zajmuje miejsce, a w okapie wcale go dużo nie ma. Do tego trzeba pilnować, żeby nie włączyć uzwojenia dwóch biegów okapu na raz.

Więcej przeszkód niż zalet. Może jednak zobaczyć, co się kryje w firmowym kontrolerze.

Plan 2: sterowanie przekaźnikami

/dżogstaff/2018.04.02-1.płytka.thumbnail.jpg

Płytka jest bardzo prosta i dokładnie widać co się święci. Projektant przy prawie wszystkich elementach napisał ich model – wielkie kudos! Po kolei:

  • złącze po prawej: tutaj przychodzi zasilanie (dolne 3 piny), wychodzi zasilanie uzwojeń silnika (środkowe piny) i wychodzi 230V doprowadzone do tranzystora sterującego oświetlenie (górne dwa piny)
  • na środku 3 przekaźniki odpowiadające za sterowanie silnikiem:
    • jest miejsce na 4 przekaźnik w modelach z dodatkowym biegiem
    • przekaźniki są sprytnie połączone: włączenie niższego biegu odcina zasilanie od przekaźników wyższych biegów. Dzięki temu niemożliwe jest włączenie naraz dwóch lub trzech biegów w silniku
  • w górnej części optoizolator MOC3052, triak BTA-12, cewka – układ sterowania oświetleniem halogenów z możliwością redukcji jasności (współpracuje z Shark60).
  • po lewej – 7805, przetwarzający napięcie 12V (do sterowania przekaźnikami) na 5V (dla mikrokontrolera)
  • po drugiej stronie płytki, pod naklejką z kodem paskowym – wspomniana atmega8l i scalaczek z tranzystorami.

W zasadzie perfekcyjnie. Obecne na płytce 5V zapewnia mi zasilanie dla esp8226 na d1mini. Do sterowania oświetleniem mógłbym wpiąć się pod gotowy optoizolator. Układ przekaźników zabezpiecza przed nieprawidłowym włączeniem. Tylko do ich sterowania (12V!) potrzebowałbym jakiegoś układu z tranzystorami. Ale czy nie wspominałem, że doszedłem do 3 scenariuszy?

Plan 3: Mimikra do atmegi

Planuję użyć mikrokontrolera do sterowania wyższymi napięciami. A przecież już jest taki mikrontroler na tej płytce. I ma swoje tranzystory, optoizolator. Najprościej będzie się po prostu wpiąć w miejsca, gdzie już jest podłączony.

Przekaźniki jedną nóżkę mają podłączoną pod +12V, druga idzie do zestawu tranzystorów zamkniętych w układzie ULN2003. Sygnał z GPIO atmegi steruje tranzystorami, powodując zwarcie do masy i w ten sposób zamknięcie obwodu zasilającego przekaźnik.

Podobnie optoizolator: ten z kolei na stałe jest przylutowany do masy, natomiast sterowanie z mikrokontrolera zapewnia zasilanie wbudowanej diody LED.

Pora lutowania – plan 3

/dżogstaff/2018.04.02-2.plan3.thumbnail.jpg

Wszystko ładnie pięknie, tylko nie działa. Przekaźniki w ogóle nie reagują, włączenie światła po chwili powoduje reset mikrokontrolerów. Pora się zastanowić, co poszło nie tak.

Po pierwsze to niezgodność zasilania. Atmega działa na 5V. Esp8226 na 3,3V. Co prawda ESP ma złącza gpio 5V-tolerant, ale to oznacza tylko tyle, że się nie spali przy takim napięciu. Samo więcej niż 3,3V nie poda.

Po drugie port GPIO ma albo stan wysoki (max 3,3V na ESP), albo zwarty do masy. A jak dwa mikrokontrolery są spięte swoimi portami, i jeden ustawi sobie stan niski, a drugi akurat chce wysoki, to w efekcie wspólna masa jest zwierana do napięcia zasilania. Not good.

Zabawny efekt powstał przy włączeniu oświetlenia – znikała możliwość zmiany biegu na inny niż aktualnie ustawiony, ani przez ESP, ani panelem dotykowym (przez atmegę; co podwójnie ciekawe, cyfrę biegu na wyświetlaczu dało się zmienić). Wyłączenie oświetlenia powodowało, że wybrany bieg „wskakiwał“.

Co prędzej odłączyłem moją konstrukcję i przemyślałem podejście.

Krok w tył - plan 2

Spróbowałem więc z planem pośrednim. Własnoręczne sterowanie przekaźnikami wymagało kilku elementów więcej. Na kawałku płytki zamocowałem 3 MOSFETy i doprowadziłem do nich GPIO z ESP. O dziwo, zadziałało poprawnie od razu. W obudowie oryginalnego kontrolera znalazło się miejsce na tranzystory. D1mini zostawiłem na zewnątrz – i tak metalowa obudowa dookoła nie jest najlepsza dla komunikacji po wifi.

/dżogstaff/2018.04.02-3.plan2.thumbnail.jpg

W dalszym ciągu jednak nie działało w pełni sterowanie oświetleniem. Przyczyna ta sama co poprzednio: jeden kontroler zwierał do masy stan wysoki drugiego. Z tym sobie poradziłem lutując na oryginalnym optoizolatorze mój, z nóżką zasilania podłączoną tylko do ESP:

/dżogstaff/2018.04.02-4.optosandwich.thumbnail.jpg

Logika sterowania

Stronę oprogramowania miałem już przećwiczoną kilka razy wcześniej. Poza mnóstwem ruchomych elementów – Mosquitto (MQTT), OpenHAB, ha-bridge, Alexa – nic specjalnie skomplikowanego. W interfejsach (webowym, komórkowym, aleksowym) nie mam bezpośredniego sterowania uzwojeniami biegów wyciągu. Jest tylko jeden element, któremu można ustawić zadany bieg, i on pilnuje żeby tylko jedno uzwojenie było włączone. Dublując zresztą zabezpieczenie wynikające z podłączenia przekaźników, ale im więcej tym lepiej.

Poniekąd przez to, że w ha-bridge cały okap udaje żarówkę (…) to nie można Aleksie wydać polecenia „ustaw wyciąg na 2”. A może to ograniczenie aleksy. W każdym razie biegi mam zmapowane dwojako: 1% włącza bieg 1, 2% drugi a 3% trzeci; pewne poziomy procentowe włączają konkretny bieg, np. 20% włącza bieg pierwszy. Można więc powiedzieć „włącz wyciąg na 20%”:

Satysfakcja 99% procent. Założenia spełnione, a brakujący 1% pojawi się, jeśli rozgryzę oryginalny dotykowy panel sterowniczy.

Hokus, pokus, jesteśmy dworcem


Pisane na kolanie absurdalne ustawy inspirują działania rodem z Monthy Pythona. Bez większego komentarza, garść artykułów:

Na zakupy do sklepu lepiej wziąć walizkę.

Stay tuned for more absurd.

Alt-historia z zacięciem sci-fi


Utwory opisujące inną rzeczywistość. Podawane w formie układanki, do samodzielnego montażu motywów. To lubię. Temu wpływowi się poddaję.

A colder war. Przeczytałem. Dwukrotnie. Teraz, gdy pracuję z domu, w komunikatorze jako lokalizację mam wpisane XK MASADA.

Krótkometrażówki Blomkampa to w większości meh. Rakka, Zygote, Gdansk, Kapture, Bill, Adam. Meh. Ale nie Firebase. To ma coś w sobie. Zmusza do zastanowienia. Kadry same się przypominają.

W dyskusji o powyższym ktoś wspomniał The Flesh Interface Series. Oryginalnie publikowane jako komentarze na Reddicie. Jakaś dobra dusza zrobiła kompilację wszystkich postów. Wsiąkłem. Czytam. Składam.

There's a red LED on Sonoff Basic


Sonoff Basic is quite a nifty gadget. For less than $5 you get a WiFi-controlled mains switch, build around popular ESP8226 chip. That's right, an ESP, a relay, power supply, plastic shell and a green LED. Strangely enough, the LED has 3 connectors.

ITEAD, the manufacturer, was kind enough to provide electrical schematics for this gadget. Comparison with circuit board shows that the LED is infact a dual-color one. Red pin is used in 433MHz version of Sonoff (the RF). On the wifi module red pin is not connected to the chip, but quite accesible.

Notice how the traces go. On one side, the trace from LED goes to R3, and then to the place for Q3. The MOSFET is missing, but it's soldering pads are in place. Remember this location.

/dżogstaff/2017.09.28-sonoff-red-led.1.thumbnail.jpg

The trace for LED goes in another direction, too. First to R23 (missing on my board), then through a via to other side of board. Flip the board and the trace hits the place for Q4 MOSFET, also missing.

/dżogstaff/2017.09.28-sonoff-red-led.2.thumbnail.jpg/dżogstaff/2017.09.28-sonoff-red-led.3.thumbnail.jpg

I suggest soldering a wire to Q3's contact. The resistor R3 is already in place, you need only a connection to GPIO. Either use exposed GPIO14 on 5-pin header, or – if you feel brave – you can solder the wire to GPIOs directly on ESP chip. You can see details on last 3 photos on Evert Dekker's site.

Now you can blink Sonoff's Basic LED in green and red.

Maico + Sonoff + DHT22


Smart Home to świetne hobby. Co może być lepszego, niż pielęgnowanie lenistwa? Temat SH w zeszłym roku przybliżałem na Zimowisku TLUG.

W mieszkaniu muszę się mierzyć z oszczędnościami poczynionymi przez projektanta i dewelopera. Maksymalizując stosunek powierzchni technicznej (niesprzedawalnej) do metrów kwadratowych mieszkania, zminimalizowali powierzchnię kominów wentylacyjnych. Przez to wentylacja musi być wspomagana mechanicznie. Inna oszczędność: zamiast zbiorczego wyciągu na dachu – indywidualne wiatraki w mieszkaniach.

Wentylatory są dwubiegowe. Pierwszy bieg musi być cały czas włączony, żeby spełnić warunki techniczne wentylacji. Drugi można włączyć np. po kąpieli, żeby wyciągnać wilgość. I nie wyhodować grzyba na ścianie. A czy wyższy bieg nie mógłby się sam załączać? Mógłby, ale przyoszczędzono i wybrano wkład wentylatora bez czujnika wilgotności. Można oczywiście wymienić (koszt ok. tysiąca zł), ale fajniej jest wziąć lutownicę w łapę i zrobić samemu.

Sprzęcior

Za niecałe 5 dolców sztuka nabyłem od skośnookiego producenta wifi-włączniki Sonoff Basic. Składają się z popularnego układu ESP8266, przekaźnika i układu zasilającego całość. Oryginalnie przychodzą z jakąś appką i komunikują się ze statkiem macierzystym w Chinach, ale sam producent pokazuje na swoich stronach gdzie przylutować kabelki i jak zmienić oprogramowanie.

Popularność ww. chipa zaowocowała wysypem różnych hobbystycznych firmware. Po pomoc w zmianie softu zwróciłem się do Przemka i otrzymałem do zabawy sztukę z wgranym ESPEasy.

Alternatywny soft daje obsługę różnych dodatkowych urządzeń podłączonych pod dostępne GPIO. Tak, włącznik prądu ma dostępne programowalne piny wejścia/wyjścia. Witamy w przyszłości.

Podłączyłem więc czujnik wilgotności DHT22 i skonfigurowałem wysyłanie jego odczytów.

Sofcior

Przy okazji researchu bardzo spodobał mi się protokół MQTT i jego implementacji w postaci serwera Mosquitto. Protokół działa na zasadzie szyny danych. Różne urządzenia wrzucają do niej dane pod ustalonymi adresami, a kto jest zainteresowany może dowolne dane (z dokładnością do ACL) czytać i przetwarzać. I całkiem dobrze integruje się z OpenHAB, którym automatyzuję mieszkanie.

Swoją drogą dawno nie widziałem takiego działającego „od ręki” oprogramowania. Nawet zmostkowanie drugiego serwera (do testów w czasie wolnym w biurze) poszło jak z płatka.

Fuzja

Wiatrak dwa biegi ma zrealizowane przez dwa uzwojenia, na które podajemy napięcie. Pierwsze jest z założenia cały czas pod prądem – to daje 230V, które wykorzystałem do zasilania Sonoffa. Włącznik drugiego biegu podłącza fazę pod drugie uzwojenie. Równoległe do tradycyjnego podłączyłem wifi-włącznik – dzięki włącznik nie traci funkcjonalności i wciąż można ręcznie wymusić wyższy bieg.

Regułka w OpenHAB jest dłuższa niż minimalna. For fun steruję jasnością diodki na Sonoffie – gdy wilgotność jest w obszarze histerezy, diodka świeci się coraz mocniej przy zbliżaniu się do granicy załączenia:

val int h_low = 55
val int h_high = 65

rule "Włącz wiatrak przy dużej wilgotności"
when
    Item h_lazienka received update
then

    if (h_lazienka.state > h_high) {
            /* wlaczyc wiatrak i diodke  */
            sSONOFF03.sendCommand(ON)
            dSONOFF03LED.sendCommand(0)

    else if (h_lazienka.state < h_low) {
            sSONOFF03.sendCommand(OFF)
            dSONOFF03LED.sendCommand(1023)

    else {
            /* pomiedzy 55 a 65 */
            val h_lazienka_int = h_lazienka.state as Number
            var led_pwm = (h_high - h_lazienka_int) * ( 1023 / (h_high - h_low) )
            if (led_pwm < 0) { led_pwm = 0 }

            dSONOFF03LED.sendCommand(led_pwm)
    }
end

Wszystkie etapy przykręcania kabelków zostały udokumentowane fotograficznie. W starym interfejsie OpenHABa przybyło mi:

https://lh3.googleusercontent.com/nd8iZuUiX3GfQT7Jo1n3Xi8_Grj4qkHZuIwRPptF3wUElU4CDLNZvIr4aaGCdc5ISijXsi-mynUpDMvJ9ixm9JuOrE0Y9tqIqTlADUthXym4WziSG_kM-g9HMQt0IJdI7O1VUYUb2_-I_na-mZmSXa7GkYMj5uuCFNJCeAyf7EbDQx_LZADY57K9FHSho-Bv3PcR2p6ZEug8dZ01yY6tnKFl8Xinf3mWGvqFuKftWsHRdLNQEB0f7Q__JNyi-CQYpDsP_dUnecQ_Q-J7bt7eMyPpP_5elIBhcGW9lWZxSQYZ452Jhx2TLy9Q1cxIwji4UJ6dKzn03W-S2Z8bIWh3XYjLMZUPt_hBRuv9nrWUoKZLnYIuTNP7KXR2pSSlyrUfAHxXfZPuGWDxZTw3mgWhuxz6cOX47jUFIPrpe4dF_IK8sDipcvcHUb6CyizbWLilZ9F_dBO9z1iz6wRAO86C5PI--FsSJbvMqLbDOXJYpUhL7sjB3VXz49uXMaxUIa2EVTvgZ3eLyMKTT_2fjXAslxUByqhGZlzy5q2iEdApoAXlfJ_O3wKuqU_mrVuhtobHigMwnbN4F-BXujabPTPOv9N_p8zzW9qFUJI0lyFD8yoKyO8uaiJHZUKHt3uXHtuigCdVzN_ZzR5eKNVm3W2MtISwF9YzJt20vIY=w322-h219-no

Czym flashować, jak żyć?

Który firmware wybrać? Na początku skłaniałem się ku Tasmota. Opisywany jest jako „dedykowany” do Sonoffów. Przemek skierował moją uwagę na ESPEasy, który jest ogólniejszy, za to ma więcej możliwości konfiguracji (np. sterowanie PWM) i oferuje sensowniejszą hierarchę MQTT.

Obydwa oprogramowania pozwalają na aktualizację Over-the-Air. Po pierwszym wgraniu, kolejne aktualizacje przeprowadzamy po WiFi. Dzięki temu piny RX/TX UARTa można przekonfigurować uzyskując dwa kolejne GPIO.

Tasmota ma obsługę Last Will and Testament w MQTT, co ułatwia sprawdzenie czy moduł jest on-line. Bo przecież do VLANa z włącznikami ma dostęp tylko broker MQTT, nieprawdaż?

Ostatecznie stanęło na ESPEasy. Jednego z pozostałych Sonoffów mam z Tasmotą, może rozwinie się w jakiś sensowny sposób.

Gorąco polecam celebrację lenistwa poprzez usmartawianie swojego domu.

p61107 (a w zasadzie p62056-21) update 2017


Kilka dni temu skończyłem sprzętową część mojego hobbystycznego projektu p61107. Zacząłem raptem pięć lat temu, a nazywać się w zasadzie powinien p62056-21, bo to jest najnowsza wersja standardu IEC. Z tej okazji, przywitajcie moje kilowatogodzinki:

DEBUG - 1.8.0*00(00015605.02) DEBUG - 0.2.2(:::::G11)

Zostało mi tylko sensowne obkodowanie tego. Namierzyłem kilka bibliotek w Pythonie do obsługi protokołu, najsensowniejszą zbackportowałem do starego pythona 3.4 – bo raspbian to przecież Debian, więc staroć. Nie użyłem Fedory, niestety, bo w wersji pignus niedomaga klient FreeIPA.

Z wartych odnotowania spraw: elegancko udało mi się poradzić z zasilaniem. W szachcie przy drzwiach mieści się mój wymiennik ciepła. Do sterowania elektrozaworem wyprowadzone jest z rozdzielni mieszkaniowej 230V. Zza mojego licznika, z własnym bezpiecznikiem i wyłącznikiem. A do skrzynki, w której zamknięte są podłączenia, idealnie zmieściła się stara nokiowa ładowarka z MicroUSB.

Kolejne aktualizacje stanu projektu mam nadzieję pisać częściej, niż co pół dekady.

IPv6 w UPC? Do Bydgoszczy będę jeździł!


Co jakiś czas widuję pytania typu „kiedy UPC będzie dawało IPv6”. I za każdym razem zauważam, że już daje. Co jestem u Teściowej w mieście nad Brdą, to w jej sieci dostarczanej przez UPC w jakimś najtańszym pakiecie bez problemu korzystam z IPv6.

Modem posługuje się taką adresacją:

/dżogstaff/2017.04.15-upc-ipv6-adresacja.png

Adresy legacy IPv4 można sobie zmieniać, v6 nie. Wyjście na świat jest znośne:

$  tcptraceroute6 ftp.task.gda.pl
traceroute to ftp.task.gda.pl (2001:4070:1::fafa) from 2a02:a311:c122:7700:59e:40f7:d772:945b, port 80, from port 40950, 30 hops max, 60 bytes packets
1  2a02:a311:c122:7700:x:x:x:x (2a02:a311:c122:7700:x:x:x:x)  2.890 ms  5.642 ms  5.123 ms
2  * * *
3  2a02:a300:0:8:0:1502:0:1 (2a02:a300:0:8:0:1502:0:1)  11.413 ms  13.263 ms  41.638 ms
4  2001:730:2c00::5474:fe82 (2001:730:2c00::5474:fe82)  23.625 ms  56.263 ms  26.888 ms
5  2001:730:2c00::5474:fe1e (2001:730:2c00::5474:fe1e)  53.984 ms  26.788 ms  25.574 ms
6  2001:730:2c00::5474:fe1d (2001:730:2c00::5474:fe1d)  26.846 ms  27.785 ms  19.525 ms
7  2001:4070:0:f::1 (2001:4070:0:f::1)  27.670 ms  26.323 ms  22.725 ms
8  ftp.task.gda.pl (2001:4070:1::fafa)  22.835 ms [open]  28.463 ms  19.476 ms

W innym miejscu ustawienia sugerują będące w użyciu DS-lite.

/dżogstaff/2017.04.15-upc-ipv6-wersje.png

I faktycznie trasa po v4 wygląda jakoś tak dziwnie:

traceroute to ftp.task.gda.pl (153.19.251.222), 30 hops max, 60 byte packets
1  * * *
2  pl-waw04a-rc1-ae18-0.aorta.net (84.116.253.121)  23.935 ms  23.988 ms  23.984 ms
3  pl-waw26b-rc1-ae4-0.aorta.net (84.116.133.45)  23.969 ms  23.951 ms  26.118 ms
4  * * *
5  * * *
6  ftp.task.gda.pl (153.19.251.222) <syn,ack>  28.595 ms  19.232 ms  27.245 ms

I co tu dużo mówić, po prostu działa, w obie strony. Nie wiem od kiedy – pamiętam tylko, że w grudniu 2013 połączenia szły po fatalnym jakościowo v4. Teraz jest bajerancko.

Antyreklamy radiowe


Z uwagi na kontuzję, ostatnio do pracy nie chodzę ani nie jeżdżę rowerem, a docieram samochodem. W związku z tym słucham radio i jestem narażony na kontakt z głupimi reklamami. Można wręcz napisać antyreklamami, bo osiągają cel przeciwny do zamierzonego. Jedna z nich, sieci sklepów spożywczych, leci mniej więcej tak:

Do tego sklepu ustawiają się kolejki. Dlaczego kolejki? Bo mięso rzucili. Takie smaczne, że sam ustawisz się w kolejce.

Eeeee… jakbym chciał postać w kolejce, to bym poszedł na Pocztę Polską. W przypadku zakupów, jeśli miałbym bezczynnie stać, to zrezygnuję z zostawiania moich dukatów i pójdę gdzieś indziej.

Co osiąga sklep taką reklamaą? Komunikat brzmi: nie potrafimy sprawnie zorganizować sprzedaży, za mało mamy pracowników, u nas stracisz czas. Być może ktoś starej daty operuje skojarzeniem kolejka == coś fajnego, ale sorry, mamy 2017. Ludzie mają lepsze rzeczy do robienia niż marnowanie życia w kolejce.

Podobnie skojarzeń nie przemyślał jeden z deweloperów (takich od blokowisk, nie od kodu), który przez długi czas sponsorował autopilota w radio. Nazwa firmy i inwestycji pojawiała się tuż przed i tuż po informacjach o utrudnieniach na drogach. Zupełnie jakby chcieli w słuchaczach wyrobić skojarzenie nasze osiedle == stanie w korkach.

Niektóre firmy powinny naprawdę przemyśleć jak się promują i z czym chcą się asocjować. To już nawet biedronka wśród deweloperów ma lepsze reklamy.

sd_notify() support in nghttp2


nghttp2 is an implementation of HTTP/2. It comes as a set of libraries and tiny programs using them – a client, WWW server and a proxy. I've started using the last one, nghttpx, as a reverse proxy in few project and I'm quite content with.

Recently I implemented sd_notify() support in it. Explicit main PID tracking and readiness signaling works like a charm with systemd. sd_notify() protocol let us reliably supervise service even during hot-swap. That is, after receiving SIGUSR2, nghttpx executes new binary and tells systemd “this is main process now”. Old binaries can finish serving current requests and exit.

The pull request, after a round of comments and fixes, was merged into trunk after v1.19.0, so it will be in the next release. If you're willing to test, I'd ask you to check USR2 graceful shutdown branch, also. At the moment you need to manually SIGQUIT old processes after hot-swap. This branch is supposed to automate it.

And if you're maintain nghttp2 package in a distribution, please be sure to check changes in the service unit file.

Drutostróż


Od końca zeszłego wieku używam IPSec to zabezpieczania ruchu sieciowego. Zgodnie z dziwactwami opensource, FreeS/WAN morfował się przez Openswan do Libreswan i strongSWAN. Równolegle korzystałem też z racoon. Interesował mnie racoon2 z uwagi na integrację z Kerberosem (KINK), ale ten wygląda na porzucony. Ostatnio zainteresował mnie Wireguard, który do niektórych zastosowań jest całkiem fajny.

Może najpierw zalety. Wireguard oparty jest na współczesnych algorytmach i protokołach kryptograficznych, autor chwali się całkiem niezłą wydajnością i niskimi opóźnieniami. Konfiguracja jest bardzo prosta i działa w zasadzie od strzału. W systemie pojawiają się dodatkowe interfejsy sieciowe, w które można zajrzeć tcpdumpem albo wyroutować w nie ruch do szyfrowania.

Miłym dodatkiem jest że tak powiem moshowatość. Po jednokrotnym nawiązaniu sesji, wymiana zaszyfrowanych pakietów odbywa się nawet jeśli jednej z końcówek zmienia się adres IP (oczywiście jeśli po zmiane odezwie się on do drugiej). Trudno więc wpaść w sytuację, w której sesja jest niby zestawiona, a ruchu trafia w czarną dziurę.

Są też wady. W zestawieniu z IPSec, Wireguard całkowicie ignoruje aspekt zarządzania kluczami. Końcówki mają swoje klucze publiczny z prywatnym, ale administrator pozostawiony jest sam sobie z kwestią ich propagacji. A to często jest najbardziej skomplikowane zagadnienie przy opracowywaniu architektury rozwiązania szyfrującego.

Jak można się domyśleć z obecności dedykowanego interfejsu sieciowego, Wireguard obsługuje tylko tryb tunelowy. Szkoda, bo o wiele częściej korzystam z trybu transportowego. Sieciowo jest bardziej oczywisty. Części scenariuszy nie da się za pomocą WG zrealizować. Można za to inne, jak np. przeniesienie tylko szyfrowanego interfejsu sieciowego do przestrzeni nazw jakiegoś kontenera. Niektórzy tego potrzebują, o czym świadczy chociażby pojawienie się w Linuksie interfejsów ip_vti*.

No i największa wada, WireGuard jeszcze nie jest w jądrze Linuksa. Jason (autor WG) ma plan włączenia gdzieś w drugiej połowie roku. Od tego uzależniona jest szeroka dostępność w dystrybucjach i włączenie obsługi w systemd-networkd. Jak na razie dostępne są repozytoria i samokompilujące się moduły dla różnych dystrybucji.

WireGuard ma jakąś taką trudną do uchwycenia elegancję i czuję, że coś z tego będzie. Może nawet pojawi się wsparcie dla innych niż Linux systemów.

https://video.fosdem.org/2017/Janson/wireguard.vp8.webm

Zaciskanie pasa TLSa


Red Hat zdecydował się na nietypowy krok w swojej dystrybucji Linuksa. W wersji RHEL 6.9 usuną lub ograniczą obsługę przestarzałej kryptografii. Zmiana dotknie SSLv2, MD5, RC4 itp. W aktualizacji stabilnej wersji nie powinno się zmniejszać zakresu obsługi, jednak ten krok wymusiły odkryte problemy z bezpieczeństwem.

Zmiana nie dotknie osób ponadprzeciętnie dbających o bezpieczeństwo, bo Ci admini już dawno wprowadzili zalecenia z Applied Crypto Hardening PDF. I przeprowadzili analizę, do jakiego stanu można podśrubować security, żeby za bardzo nie utrudnić innym. Ja przykładowo na serwerze WWW chciałem ograniczyć TLS tylko do v1.2/1.3. Ale sprawdziłem, i oznaczałoby zablokowanie dostępu osobom z Androidem <5.0. Na takie poświęcenie nie jestem gotów ;-). Nie każdy działający tablet z 4.x można zaktualizować, a jeśli ktoś wchodzi na bloga mobilnie, to zazwyczaj jest w trudnej sytuacji bez dostępu do czegoś lepszego. Zablokowanie mu dostępu w takiej chwili byłoby bezsensowne. A może i okrutne, bo pewnie popsuł sobie dostęp do internetu i szuka sposóbu na naprawę.

Przy okazji, wspomniany dokument w wielu przypadkach specyfikuje wprowadzenie ciągu określającego dozwolone algorytmy w postaci EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+…. Jest to dosyć nieelastyczne, w Fedorze można to zrobić lepiej: wystarczy podać PROFILE=SYSTEM. Wtedy poziom zabezpieczeń dla wszystkich usług na raz ustawimy poprzez manipulacje w /etc/crypto-policies/ i wywołanie polecenia update-crypto-policies.

Adresy .onion w całej sieci lokalnej


Tor ma taką fajną umiejętność tworzenia ukrytych adresów z wykorzystaniem domeny .onion – jak http://sejnfjrq6szgca7v.onion, http://uj3wazyk5u4hnvtk.onion/ czy https://facebookcorewwwi.onion. Ma też drugą fajną umiejętność, dzięki czemu można udostępnić łączność do takich adresów wszystkim urządzeniom w sieci lokalnej, nawet nie znającym Tora.

Sztuczka działa dzięki temu, że Tor potrafi działać jako serwer DNS i syntetyzować rekordy dla domeny .onion. W konfiguracji podajemy z jakiej podsieci mają być zwracane. Trzeba tylko przekierować routing ww. podsieci na klienta tor i voila. Tor odbierając pakiety skierowane na adres X wie, że ten adres zwrócił po zapytaniu o xyz.onion i odpowiednio kieruje połączenia.

Konfiguracja jest prosta. Najpierw wybieramy sobie ta specjalne podsieci:

VirtualAddrNetworkIPv4 10.192.0.0/10
VirtualAddrNetworkIPv6 [fceb:001a::]/32

Dwa, każemy Torowi obsługiwać DNS na naszym wewnętrznym interfejsie. Dobrze się chwile zastanowić, czy nie mamy tu już przypadkiem jakiegoś unbound, deadwood, systemd-resolved czy innego serwera DNS nasłuchującego na tym porcie. Jeśli tak, trzeba go wyłączyć. There can be only one!

DNSPort 203.0.113.2:53
DNSPort [2001:db8:85a3::8a2e:370:7334]:53
AutomapHostsOnResolve 1

Na koniec konfiguracji Tora zostaje kazać mu nasłuchiwać jako transparetne proxy, tak jak umie to Squid:

TransPort 0.0.0.0:9040
TransPort [::]:9040

Zostały jeszcze 2 drobiazgi – przekierowanie ruchu do magicznych podsieci na naszego cichociemnego tora:

iptables -A PREROUTING -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040
ip6tables -A PREROUTING -p tcp -d fceb:001a::/32 -j REDIRECT --to-ports 9040

Oraz poinformowanie naszego głównego DNS, że domenę .onion obsługuje ktoś inny:

  Zone name: onion.
  Zone active: TRUE
  Zone forwarders: 2001:db8:85a3::8a2e:370:7334, 203.0.113.2
  Forward policy: first
----------------------------
Number of entries returned 1
----------------------------

W tym momencie na każdej stacji powinno działać:

$ host facebookcorewwwi.onion
facebookcorewwwi.onion has address 10.207.220.42
facebookcorewwwi.onion has IPv6 address fceb:1a:39ba:123f:1d30:72d1:a46e:1f93

$ wget sejnfjrq6szgca7v.onion
--2016-11-03 13:14:09--  http://sejnfjrq6szgca7v.onion/
Resolving sejnfjrq6szgca7v.onion (sejnfjrq6szgca7v.onion)... 10.221.133.34, fceb:1a:437e:551f:ef67:b2c2:bb64:ece5
Connecting to sejnfjrq6szgca7v.onion (sejnfjrq6szgca7v.onion)|10.221.133.34|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14760 (14K) [text/html]
Saving to: 'index.html'

index.html  100%[======================================================================================>]  14.41K  34.0KB/s    in 0.4s

2016-11-03 13:14:10 (34.0 KB/s) - 'index.html' saved [14760/14760]

Konfigurację dla innych systemów znajdziemy oczywiście na stronie projektu.