Nie mogłem się powstrzymać przed clickbaitowym tytułem. Tym razem nie będzie o państwowych dotacjach na dzieci, tylko podsumowanie sezonu rowerowego.
W maju zapowiadałem, że biorę udział w wyzwaniu Kręć kilometry. Właśnie sobie uświadomiłem, że dziś jest ostatni dzień września, a wyzwanie zostało zaliczone już jakiś czas temu. Znaczy mam taką nadzieję, bo pisze, że 100%, ale czy kilkuset metrów nie brakuje – nie mam pojęcia. W każdym razie za ostatni rok pokazuje mi 512 km. A było przecież parę km przejechanych bez rejestracji, stąd plus w tytule.
Wyzwanie okazało się prostsze, niż myślałem. We wrześniu już prawie nie jeździłem – przejechane raptem 27 km. Przeważyły względy logistyczne – nie mogłem brać swojego roweru, a Nextbike to jednak nie to samo.
Nie ukrywam też, że mam problem z pogodą i była głównym czynnikiem powodującym, że jeździłem mniej, niż bym mógł. Nie lubię jeździć ani jak jest bardzo gorąco, ani jak jest zimno. Dlatego odpuszczałem rower w największe upały, wybierając śmierdzące wówczas tramwaje. Smutne, ale niektórzy mają problem z higieną, a w upały się to potęguje. Z kolei wrzesień to już chłody. Ręce jeszcze nie kostnieją, ale w uszy zimno. Być może rozwiązaniem są nauszniki, jakoś nie sprawdziłem.
Natomiast największym sprzymierzeńcem był nawyk. Do pracy jeździ się całkiem miło i poza częścią urlopową i paroma dniami deszczowymi mógłbym wybierać rower niemal codziennie. Co oznacza, że teoretycznie mógłbym celować nawet w dystans dwukrotnie dłuższy…
Skutek uboczny: zacząłem trochę biegać. Weekendowe bieganie dobrze się łączy z dojazdami do pracy rowerem w tygodniu. Taka powiedzmy synergia.
Dawno temu NAS został wyłączony, ale zmierzam do jego reaktywacji. Po głowie chodziło mi zamknięcie wszystkiego (zasilacz, dysk, Banana Pi) w zgrabnej, tym razem dedykowanej do elektroniki, obudowie.
Trochę z myślą o programie do przełączania łącza internetowego, a trochę o pomiarze temperatury przy pomocy komputera, przyszedł mi pomysł, by sygnalizować stan różnych rzeczy w sposób nie wymagający łączności sieciowej, czyli najdoskonalszy, analogowy: migając diodą. Oczywiście szybko doszedłem do wniosku, że jedna dioda nie wystarczy. Wbudowane diody to trochę mało, ale przecież w Raspbery Pi i analogach mamy GPIO, możemy tych LEDów podłączyć kilka…
Nie wiem jak dokładnie doszło do tego, ale podczas poszukiwań szybko wpadłem na ekrany LCD z serii 1602, które również można podłączyć przez GPIO. Skoro tak, to pomyślałem, że nie ma się co ograniczać. Zamiast prostej sygnalizacji stanu i konieczności pamiętania która kombinacja co oznacza można po prostu wyświetlać dowolny tekst. Niezbyt długi, ale nadal jest to znacznie większa ilość informacji, niż z kilku czy nawet kilkunastu LEDów. W dodatku cena takiego jest bardzo przystępna, czego o różnych ekranach dotykowych czy e-ink powiedzieć nie można.
Pierwotnie chciałem podłączyć LCD do Orange Pi zero, ale niestety, nie ma on pinów GPIO. Są wyprowadzenia, ale trzeba by lutować, co pewnie docelowo zrobię, ale bardziej chodziło mi o sprawdzenie sterowania. Zatem użyłem będącego pod ręką Banana Pi. Gdy szukałem schematu jak podłączyć ekran do Banana Pi, natknąłem się na coś znacznie ciekawszego. Wersję ekranu LCD ze sterownikiem podłączanym przez interfejs i2c. Dzięki podłączenie temu jest bardzo proste. Wystarczą raptem cztery przewody, nawet nie trzeba lutować, o ile używa się gotowych przewodów z końcówkami. Dodatkowo – i to najlepsza część – całością daje się w elegancki sposób sterować za pomocą Pythona.
Efekt końcowy wygląda tak:
LCD 1602 Źródło: fot. własna
Zdjęcie zrobione telefonem, po ciemku. Z tyłu płytki jest potencjometr pozwalający na regulację kontrastu. Poziom podświetlenia jest stały, można tylko włączyć i wyłączyć LED, zarówno hardware’owo (zworka), jak i programowo. Ekran LCD bierze bardzo mało prądu – przy pomocy watomierza nie udało mi się zarejestrować różnicy, czyli całość zużywa poniżej 0,1 W.
Jak to zrobić? Powtórzę instrukcje, z których korzystałem. Instalujemy dodatkowe pakiety:
apt-get install i2c-tool python-smbus
Następnie podłączamy ekran i sprawdzamy adres przy pomocy polecenia:
i2cdetect -y 1
Otrzymaną wartość należy wpisać w skrypcie (stała ADDRESS, linia 29 w przytoczonym przykładzie).
Następnie możemy sterować ekranem z poziomu języka Python. Na przykład wywołanie efektu widocznego na ekranie można zrobić przy pomocy polecenia:
Biblioteka pozwala na dużo więcej, między innymi na własne znaki, ale tym się póki co nie bawiłem. Wyświetlony tekst pozostaje na ekranie po zakończeniu programu do momentu wpisania nowego lub skasowania poprzedniego. Jeśli do ekranu będzie dostarczone napięcie, to wyłączenie Banana Pi nie wpływa na wyświetlany tekst. Dlatego jeśli chcemy monitorować, czy nasz komputer się nie zawiesił, musimy zmieniać okresowo tekst. W innym wypadku zawartość LCD nie świadczy o niezawieszeniu się komputera.
Sterowanie włączaniem i wyłączaniem podświetlania to:
Wyświetlać przy pomocy Banana Pi na ekran LCD można cokolwiek – temperaturę, zajętość dysku, opóźnienia/straty na sieci, kurs BTC (pozdro dla L.!), adres IP (po starcie!), informacje o nowych mailach…
Pozostało mi wymyślenie, w jaki sposób zrobić sensowne sterowanie. Po głowie chodzi mi demon, który będzie pobierał informacje do wyświetlenia z jakiejś kolejki, w zależności od ich priorytetu, czasu ostatniego wyświetlenia i pory dnia sterował oświetleniem i wyświetlał informacje. A może już jest coś takiego?
I garść linków pomocnych przy tworzeniu ww. rozwiązania AKA źródła:
UPDATE Dla zainteresowanych kupnem – ekran z modułem do komunikacji i2c kosztuje ok. 12 zł na Allegro. Na zdjęciu jest wersja zielona, ale istnieją też wersje niebieskie, gdzie tło jest ciemne, a napisy jasne.
Jakiś czas temu zauważyłem, że polecenie su w moim Debianie unstable na domowym desktopie zmieniło zachowanie. Na koncie root przestał działać skrypt do aktualizacji systemu i usypianie.
Szybko sprawdziłem i oczywiście chodziło o PATH. Dopisałem pełne ścieżki do poleceń i prawie zapomniałem o sprawie, przypuszczając, że chodzi o jakiś chwilowy błąd w którymś z pakietów.
Jednak problem nie zniknął, więc postanowiłem sprawdzić dokładnie, co się wydarzyło. Na pierwszy ogień poszło sprawdzenie /etc/profile, w którym znalazłem spodziewane:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
Również w /etc/login.defs wszystko wyglądało poprawnie:
# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Skończyły mi się pomysły, więc udałem się na kanał #debian-next z pytaniem, czy to błąd, czy może były ostatnio jakieś zmiany. I okazuje się, że zmiany były, grubsze, dotyczące polecenia su.
Uprzednio, wydanie „gołego” polecenia su zmieniało użytkownika na rootoraz ustawiało należną mu ścieżkę. Obecnie należy podawać su – (forma niezalecana) lub, lepiej, su -l, aby osiągnąć ten efekt.
I jeszcze co ciekawsze fragmenty dokumentacji (man su). Było:
The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.
[...]
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.
Aktualnie jest:
For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME
if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing envi-
ronments.
[...]
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make the shell a login shell
Więc gdyby komuś w jakiejś debianopodobnej dystrybucji niebawem polecenie su przestało ustawiać PATH, to najprawdopodobniej chodzi o tę zmianę.
