Uwa偶ni obserwatorzy (wiem 偶e tacy s膮 馃檪 ) zauwa偶yli pewnie to pojawienie si臋 literki a przy numerze wersji. Zosta艂 poprawiony jeden drobny b艂膮d – format danych Prometheus. Od d艂u偶szego czasu wkrad艂 si臋 tam jeden nadmiarowy znak, psuj膮cy wszystko.
Format Prometheus jest odziedziczony po kodzie Sensor Community i chyba nie jest u nas intensywnie wykorzystywany (dlatego dopiero po d艂ugim czasie ten nadmiarowy nawiasik wyszed艂 na jaw), ale przy tej okazji sprawdzi艂em dok艂adniej czym jest Prometheus.
I musz臋 powiedzie膰 jako zwolennik rozwi膮za艅 open source, 偶e spodoba艂 mi si臋 馃檪 Jest to system zbierania danych nieco podobny do InfluxDB. Mo偶na poczyta膰 wi臋cej na stronach Prometheusa.
Po pewnym po艣lizgu, kilka dni temu na serwerze pojawi艂a si臋 w ko艅cu nowa wersja NAMF. W skr贸cie, co si臋 zmieni艂o:
jest procedura resetu do ustawie艅 fabrycznych – 3krotne naci艣ni臋cie reset w kr贸tkich odst臋pach czasu (ok 5-10 sekund) spowoduje wymazanie ca艂ej konfiguracji
je艣li masz w swoim NAM LCD mo偶esz skonfigurowa膰 wygaszanie pod艣wietlenie w okre艣lonych godzinach. Gdy LCD 艣wieci ci w okno mo偶esz go np od p贸艂nocy do 6 rano wy艂膮czy膰 (pod艣wietlenie)
BH1750 – sensor nat臋偶enia 艣wiat艂a otoczenia jest obs艂ugiwany
LoRaWAN – tu troch臋 si臋 chwal臋, bo jeszcze wersja p艂ytki/sensora wsp贸艂pracuj膮ca z LoRaWAN nie jest publicznie dost臋pna, ale wersja NAMF-2020-46 przynios艂a wiele potrzebnych zmian by wreszcie j膮 upubliczni膰. Plan jest by by艂a dost臋pna (wersja LoRaWAN) jeszcze w tym roku.
Dzi艣 rano trafi艂y na serwer nowe binaria, z wersj膮 NAMF-2020-46. Niestety po kilku godzinach z analizy log贸w wynikn臋艂o, 偶e jaka艣 niewielka cz臋艣膰 NAM贸w, kt贸ra dokona艂a aktualizacji wpad艂a w p臋tl臋 restart贸w.
Przywr贸cona zosta艂a poprzednia wersja i problem usta艂. B臋dziemy analizowa膰 przyczyny, by postara膰 si臋 ustali膰 czy to problem by艂 powszechny czy dotyczy艂 tylko niewielkiej grupy. Jednak偶e ze wzgl臋du na okres urlopowy u nas – kolejnego podej艣cia do wypuszczenia wersji NAMF-2020-46 mo偶na spodziewa膰 si臋 dopiero na koniec wrze艣nia.
Poniewa偶 zmieni艂 si臋 spos贸b zapisu konfiguracji LCD – je艣li tw贸j sensor nie wy艣wietla nic na LCD – mo偶e zdarzy艂 sie zaktualizowa膰 i po powrocie do wersji -45a “zgubi艂” ustawienia. Po prostu skonfiguruj LCD ponownie.
Powinna ju偶 by膰 wersja stabilna NAMF-2020-46, jednak zamiast tego pojawi si臋 jeszcze kilka wersji 46rcX. Dlaczego? Przyznam si臋, nie 艣ledzi艂em tego parametru dok艂adnie, dopiero przed wypuszczeniem NAMF-2020-46 sprawdzi艂em statystyki. Od wersji NAMF-2020-46rc6 znacznie wzros艂a liczba b艂ed贸w sum kontrolnych w komunikacji z SDS011.
Eksperymentowa艂em z ustawieniami kt贸re mog艂y na to wp艂yn膮膰 na sensorach w naszym labie, ale… mimo 偶e jest ich niemal 10 szt to dane zebrane s膮 do艣膰 niejednoznaczne. By przyspieszy膰 zbieranie danych zdecydowa艂em si臋 wypu艣ci膰 par臋 wariant贸w na lini臋 beta by zebra膰 wi臋cej danych w kr贸tkim czasie.
Dlatego w tym tygodniu mo偶na si臋 spodziewa膰 kilku wersji beta, oraz mo偶liwe 偶e nawet pewne cofni臋cie. W tej chwili jest rc10, je艣li poprawa nie b臋dzie zadowalaj膮ca – jutro b臋dzie jeszcze rc11 i mo偶e rc12 pod koniec tygodnia. Mo偶e si臋 zdarzy膰 powr贸t do wcze艣niejszej wersji by zebra膰 kolejne dane.
Dlatego, do os贸b kt贸re maj膮 wersje beta w艂膮czone – je艣li zaniepokoi was cz臋sta zmiana wersji, to mam nadziej臋, 偶e ten wpis wam to wyt艂umaczy.
Gdy znajd臋 przyczyn臋 tego wzrostu i uda si臋 zbi膰 poziom b艂臋d贸w – pojawi si臋 wersja stabilna.
Zmiana drobna, ale przydatna. Od teraz pojawia膰 si臋 b臋d膮 linki do pomocy w konfiguracji NAM. W tej chwili jest to symbol kompasu, kt贸ry wiedzie do stron z kr贸tkim opisem. Np jak ten.
Czemu kompas? Bo ikonki u偶yte przez NAMF oparte s膮 o symbole dost臋pne w Unicode. I jako艣 nie znalaz艂em lepszego. Jest 艂adny znak zapytania, ale bia艂y na bia艂y to tak s艂abo, a czerwony – nie bardzo pasuje.
Opiera si臋 to o system stron kt贸re s膮 generowane razem z kodem na GitHubie. Zalet膮 jest prostota ca艂o艣ci, a struktura pozwala na utrzymywanie r贸偶nych wersji j臋zykowych. Na razie jest tylko struktura, nad t艂umaczeniami (oraz rozszerzeniem listy temat贸w) to jeszcze musz臋 popracowa膰 馃檪
Wad膮 jest to, 偶e skoro pliki pomocy s膮 na GitHubie to niezb臋dny jest dost臋p do internetu. W momencie gdy konfiguruje si臋 pierwszy raz NAMa i ma si臋 po艂膮czenie z AP w NAM, zwykle nie ma dost臋pu do sieci, ale to ju偶 zale偶y od ustawie艅 telefonu.
I tak, zaraz b臋dzie jeszcze wersje rc8, bo by艂em przekonany, 偶e wersja rc7 obejmuje wszystkie niezb臋dne t艂umaczenia/napisy je艣li chodzi o j臋zyki, a jednak nie, wi臋c lada moment b臋dzie rc8. I na podstawie tego b臋dzie pewnie ju偶 wersja stabilna.
Z innych zmian – doko艅czona zosta艂a implementacja czujnika 艣wiat艂a BH1750.
Co dalej?
Nast臋pne wersje b臋d膮 mia艂 zmienion膮 nieco numeracj臋. Skoro jest i tak obecnie jedna linia oprogramowania, z numeru wersji “wyleci” 2020, czyli po NAMF-2020-46 nast臋pna wersja to b臋dzie NAMF-47.
W wersja 47 to b臋dzie przede wszystkim – doko艅czenie wersji ESP32 z LoRa (i mo偶e Ethernet, ale to nie jest g艂贸wny cel). Z sensor贸w – pierwsze testy Winsen ZE25A s膮 bardzo ciekawe, wi臋c mam zamiar doda膰 obs艂ug臋 tego sensora O3 do NAM.
Jak pisa艂em przy okazji NAMF-2020-46rc5 doda艂em wst臋pn膮 obs艂ug臋 czujnika nat臋偶enia 艣wiat艂a otoczenia – BH1750FVI, kt贸ry w formie modu艂u jest dost臋pny na Nettigo. Pod艂膮czenie jest do艣膰 proste, bo sensor pracuje na szynie I2C, nie ma kolizji adres贸w, g艂adko. Ale pod艂膮czenie to jedno, a wystawienie go na 艣wiat艂o to druga sprawa.
Najpro艣ciej (kwestia utrzymania wzgl臋dnej szczelno艣ci obudowy NAM, zw艂aszcza od g贸ry) by艂oby zostawi膰 sensor w 艣rodku. Ale czy jego wskazania b臋d膮 mia艂y jaki艣 sens? Zw艂aszcza, 偶e od d艂ugiego ju偶 czasu do ka偶dego NAMa dodawana jest ochronna naklejka.
Dlatego, wyniki kilkudniowych test贸w! Jeden sensor zosta艂 pozbawiony kopu艂ki rozpraszaj膮cej 艣wiat艂o i umieszczony pod pokrywk膮, na kt贸rej jest standardowa naklejka. Drugi, przez rozszczelniona obudow臋 zosta艂 wystawiony nad NAMem. M贸wimy o dw贸ch r贸偶nych NAMach, wisz膮cych jeden obok drugiego.
Oba NAMy znajduj膮 si臋 na wschodniej 艣cianie budynku, pod dachem, wi臋c rozszczelnienie obudowy jednego nie stwarza problemu. Jaki rezultat?
OK. Pierwsze wyniki – stosunek odczytu warto艣ci tego z BH1750 na zewn膮trz do tego “pod” naklejk膮 jest mniej wi臋cej sta艂y, mi臋dzy 8.1 a 8.8. Czyli np jak ten wewn膮trz pokazuje 138 to ten na zewn膮trz 1167 lux贸w. I zar贸wno w dzie艅 s艂oneczny jak i pochmurny ten stosunek jest zachowany.
Wst臋pny wniosek? Spokojnie mo偶na wsadzi膰 BH1750 do 艣rodka obudowy i nie przejmowa膰 si臋 k艂opotami z wyprowadzeniem sensora na zewn膮trz. Bo uszczelni膰 nie tylko obudow臋 NAM trzeba jak i kopu艂k臋 BH1750 – kt贸ra jest na艂o偶ona na wcisk i to taki niezbyt silny…. Wygl膮da na to, 偶e rule of the thumb b臋dzie – pomno偶y膰 odczyt przez 8.5 je艣li sensor jest wewn膮trz obudowy z naklejk膮. Musz臋 to przemy艣le膰, bo dot膮d nie by艂o takiej opcji “modyfikowania” odczytu.
Jeszcze troch臋 poobserwuj臋 zachowania sensor贸w – raz, w s艂oneczny dzie艅 dzielnik spad艂 do 7.5, ale wydaje mi si臋, 偶e to by艂o w momencie gdy s艂o艅ce przesta艂o ju偶 艣wieci膰 bezpo艣rednio na “zewn臋trznego” BH a ten schowany w obudowie by艂 jeszcze w s艂o艅cu. To z oczywistych wzgl臋d贸w zaburzy艂o stosunek warto艣ci odczyt贸w z obu sensor贸w.
W kwestii czujnik贸w nat臋偶enia 艣wiat艂a – dobra wiadomo艣膰 jest te偶 ju偶 taka, 偶e niezawodne aqi.eco ju偶 wspiera odczyty nat臋偶enia 艣wiat艂a! Dzi臋kujemy!
Dzi艣 na serwerze z aktualizacjami umie艣ci艂em nowa wersj臋 firmware. 46rc5 przynosi dwie istotne zmiany.
Czujnik BH1850FVI mierzy nat臋偶enie 艣wiat艂a, by艂o sporo pyta艅 kiedy oficjalnie pojawi si臋 dla niego wsparcie. No to ju偶 prawie oficjalnie, bo na razie tylko na kanale beta. Czujnik trzeba pod艂膮czy膰 do zasilania, I2C, 偶贸艂ty kabel mo偶e zosta膰 luzem, b臋dzie na domy艣lnym adresie 0x23.
Nie trzeba ustawia膰 adresu I2C, NAMF sam pr贸buje najpierw 0x23 a je艣li nie uda sie inicjalizacja to pr贸buje drugi adres, 0x5C.
Dane s膮 zbierane i wysy艂ane do wi臋kszo艣ci API (poza Sensor Community, bo ono nie obs艂uguje na razie takiej wielko艣ci fizycznej). Pozosta艂e API nie korzystaj膮 jeszcze z tej wielko艣ci. InfluxDB oczywi艣cie przyjmie dane i je艣li masz np Grafan臋, to zrobisz wykres.
Skoro wi臋kszo艣膰 API tego nie obs艂uguje, pojawia si臋 pytanie po co? Dane s膮 dost臋pne lokalnie (w /data.json), tak偶e 艣wietnie si臋 nadaje to do integrowania z Home Assistant czy Domoticz.
Druga zmiana jest dla wszystkich kt贸rzy lubi膮 “wi臋cej danych”. Od teraz NAMF mierzy czas potrzebny do wys艂ania danych dla ka偶dego API – poza Sensor Community API. To ostatnie jeszcze nie jest mierzone, bo w odr贸偶nieniu od pozosta艂ych wysy艂anie danych do SC jest bardziej rozrzucone po kodzie NAMF oraz wymaga oddzielnego wywo艂ania dla ka偶dej raportowanej wielko艣ci fizycznej. Pomy艣l臋 te偶 nad tym, ale na razie, dla pozosta艂ych API podawany jest kod HTTP zwr贸cony przez API i czas ile ca艂o艣膰 zaj臋艂a (tylko dla ostatniego wywo艂ania). Dane s膮 dost臋pne tylko w interfejsie HTML, na stronie /status.
Od pewnego czasu na biurku obok mnie le偶y sobie taki fioletowy go艣膰.
Niby dobrze znajomy widok, a jednak nie tylko kolor si臋 nie zgadza. Ten Wemos jaki艣 dziwny… Ano, bo to jest Wemos ESP32 D1 mini. Jak sama nazwa wskazuje, zamiast ESP8266 na pok艂adzie jest ESP32. Podstawowy uk艂ad pin贸w jest zachowany, ale sama p艂ytka jest wi臋ksza i ma dodatkowe piny. Je艣li miejsce pozwala (bo p艂ytka ma wi臋ksze rozmiary, aby zmie艣ci艂y si臋 dodatkowe piny) to mo偶na u偶y膰 go tam gdzie Wemosa z ESP8266 dostaj膮c nowe mo偶lwo艣ci.
A jakich to mo偶liwo艣ci szukamy? No c贸偶, zmienia膰 procesor na ESP32 dla samego zmieniania nie ma specjalnego sensu. Taki NAM nie r贸偶ni艂by si臋 istotnie od zwyk艂ego, no mo偶na by doda膰 Bluetooth, ale to troch臋 na si艂臋.
Ten NAM z ESP32 D1 mini powsta艂 by przetestowa膰 czy uda sie uruchomi膰 NAMF na platformie ESP32. No i posz艂o do艣膰 szybko, wersja bardzo beta okrojona z kilku w艂a艣ciwo艣ci dzia艂a od kilku dni. Teraz maj膮c wersj臋 firmware na ESP32 mo偶na przeprowadzi膰 w艂a艣ciwe testy.
A testy te, oznaczaj膮 u偶ycie gotowych modu艂贸w opartych o ESP32. Konkretnie Wireless Stick Lite od Helteca oraz ESP32 PoE z Olimexu. Maj膮 one doprowadzi膰 nas do NAM w wersji 0.4, kt贸ra b臋dzie korzysta艂a z tych modu艂贸w jako bazowych (zamiast Wemosa). I tak, z Wireless Stick Lite b臋dziemy mieli radio LoRa a z ESP32 PoE – port Ethernet z zasilaniem PoE.
Te dwa warianty chyba by艂y najcz臋艣ciej postulowane przez wielu u偶ytkownik贸w. Pr贸by kt贸re prowadzili艣my z ESP8266 by doda膰 do niego radio LoRa lub Ethernet doprowadzi艂y nas do wniosku, 偶e lepsze b臋dzie oparcie si臋 o gotowe, sprawdzone platformy. A takie s膮 na ESP32.
G艂贸wne za艂o偶enia dla serii NAM 0.4 s膮 nast臋puj膮ce:
tak zwany “form factor” zostaje bez zmian – obudowa Kradexa Z59JpH
podstawowe czujniki te偶 zostaj膮 – czyli SDS011/HECA/BME280
prawdopodobnie nie uda si臋 zmie艣ci膰 LCD znakowego, ale mamy pewne pomys艂y czym go zast膮pi膰
poza standardowym WiFi w zale偶no艣ci od wariantu b臋dzie mo偶liwo艣膰 skorzystania z LoRaWAN lub Ethernet z PoE
Po wypuszczeniu wersji NAMF-2020-45 wczoraj r贸wnie偶 rozpocz臋li艣my migracj臋 starszych sensor贸w NAM, kt贸re dzia艂a艂y na oprogramowaniu wprost odziedziczonym po Luftdaten. Wersje NAMF-2019-x dzi艣, do ko艅ca dnia powinny zaktualizowa膰 si臋 do NAMF-2020-45.
Wczoraj zosta艂a opublikowana nowa wersja NAMF-2020-45. Istotn膮 zmian膮 (na kt贸ra liczymy) powinno by膰 obni偶enie poziomu b艂臋d贸w w odczycie danych z SDS011. W wersji -44 by艂a ona zdecydowanie za wysoka. Z test贸w na sensorach dzia艂aj膮cych na wersjach beta -45 poprawa powinna by膰 wyra藕na.
Z mniejszych zmian to w konfiguracji sensora wprowadzony zosta艂 wyr贸偶nik opcji zaawansowanych. Takimi by艂y np czas pomiar贸w i rozgrzewki SDS011. Takie ustawienia s膮 teraz domy艣lnie ukryte, trzeba klikn膮膰 w przycisk by je zobaczy膰. W ten spos贸b podkre艣lamy, 偶e nie ma potrzeby w podstawowej konfiguracji ustawiania tych warto艣ci.
Zaawansowane opcje pojawi艂y si臋 te偶 dla HECA – pozwalaj膮 na ustawienie prog贸w wilgotno艣ci dla kt贸rych w艂膮cza i wy艂膮cza si臋 grza艂ka. Znowu – sugerujemy nie zmienia膰 tych warto艣ci, je艣li nie macie istotnej potrzeby (dlatego pola te te偶 s膮 domy艣lnie ukryte).
Pojawi艂a si臋 opcja przywr贸cenia starszej wersji oprogramowania. Dost臋pna jest przez stron臋 /rollback .
Te NAMy, kt贸re maj膮 LCD mog膮 teraz wy艂膮czy膰 r贸wnie偶 wy艣wietlanie informacji o urz膮dzeniu czyli – mo偶na wy艣wietla膰 tylko dane z sensor贸w. Je艣li w艂膮czy si臋 wy艣wietlanie tylko dla jednego (np SDS011) w贸wczas na wy艣wietlaczu b臋d膮 prezentowane tylko te dane.