NAMF-2020-46rc7

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.

ESP32-CAM

W końcu pewna zaległość została nadgoniona. W sklepie pojawił się ESP32-CAM. Prosty, niewielki zestaw który pozwala na dostęp do obrazu przez sieć. Ale po co? Przecież kamerki internetowej na tym nie zrobimy. Albo inaczej – specjalizowane kamery dają dużo lepszy obraz.

Natomiast, dla mnie ten moduł to jest próba zmierzenia się z projektem, który widziałem już dawno. Nadszedł czas by spróbować:

Chodzi o AI on edge device to projekt, który ma na celu ułatwienie digitalizacji starych, analogowych liczników. Zbudowany jest w oparciu właśnie o ESP32-CAM i wiem (bo sam tak mam), że jak zacznie się zbierać dane o własnym domu, to ciągle się chce kolejne.

Spodziewajcie się jakiejś relacji, ale to raczej w formie instruktażu na Starter Kit.

ZE25a-O3 – pierwszy rzut oka na ozon.

Od niedawna w naszej ofercie jest nowy sensor Winsena – ZE25a-O3. Jest to sensor O3, czyli ozonu. Jak w opisie produktu wspomniałem, jakiś rok temu testowaliśmy ZE27-O3. Jednak tamten mający rozdzielczość 10 ppb (o ile dobrze pamiętam) to nie było to na co czekałem.

ZE25a-03 ma tą zaletę, że jego protokół UART jest wspólny z ZE27, więc mogłem skorzystać ze kodu napisanego rok temu podczas testów ZE27. Wystarczyło skorzystać z rozebranego NAMa jako platformy testowej, trochę gorącego kleju, ucięcie kabla dołączonego do sensora i proszę:

Po kilku godzinach działania (wartości w ppb):

W najbliższych planach – wsadzić dla porównania ZE27 obok i zobaczyć jak wyglądają odczyty. Drugi test – to wziąć kolejny sensor ZE27 i wystawić w pobliżu ruchliwej drogi. W tej chwili, sensor jest wystawiony w miejscu gdzie źródeł ozonu specjalnie nie ma. Ogród, z dala od ruchu samochodowego.

Dziś tego nie zdążyłem zrobić, ale na ile rozumiem specyfikę pomiaru trzeba dodać czujnik temperatury i ciśnienia, bo te dwie wartość wprost wpływają na przeliczenie wartości ppb na µg/m³.

Nikt pytania na razie nie zadaje, ale… skoro na płycie NAMa jest test, to czy planuję umieszczenie wsparcia w NAMF?

Nie powiem, jest to interesujący parametr. O3 w naszym otoczeniu to głównie wynik rozpadu tlenków azotu (NOx) ze spalin pod wpływem światła słonecznego. Nie trzeba mówić, że latem może to być problem w terenie gdzie występuje ruch samochodowy.

Temat chyba jest warty zbadania, bo jeśli dobrze liczę to wskazania na poziomie 105 ppb przy obecnym ciśnieniu i temperaturze to ok 200 µg/m³. Sporo.

Bazarek…

Chyba już o tym kiedyś wspominałem, ale w końcu powoli rusza Bazarek Nettigo – miejsce gdzie będzie można kupić produkty/podzespoły których przez kilkanaście lat działania się nazbierało, a szkoda je wyrzucić. Postawiłem go na Presta Shop, dziwaczne to zwierzę 🙂 ale wygląda na to, że działa.

Na razie niewiele, ale wkrótce pojawi się tam więcej pozycji. Ma wg was to sens?

Odświeżenie sklepu

Dziś, zmienił się nieco wygląd naszego sklepu. Nie jest to rewolucja, raczej ewolucja. Prace nie są jeszcze skończone, na pewno jeszcze sporo rzeczy jest do poprawy, ale pracuję nad tym.

Niezależnie od tego jak oceniacie odświeżony wygląd, to podczas prac usunęliśmy sporo błędów i pewnych nieścisłości, zwłaszcza w procesie finalizacji koszyka. Zwłaszcza na komórkach i wąskich ekranach będzie to teraz lepiej wyglądało.

Na pewno w najbliższych dniach jeszcze będziemy nad tym intensywnie pracować. Ale, tak jak wspominałem w newsletterze (jeśli nie jesteś zapisany to zachęcam, góra raz, dwa razy w miesiącu i bez spamu i natręctwa sprzedażowego) teraz, gdy zbliżamy się do finiszu tego zadania, powinny zacząć się dziać inne ciekawe rzeczy, już bardziej związane z naszą ofertą.

Piątek po Bożym Ciele – pracujemy

W najbliższy piątek (31 maja) pracujemy normalnie. Jednak z doświadczenia wiemy, że często w takie dni występują problemy z odbiorem przesyłek przez kurierów. Odbywają się dużo wcześniej niż zwykle lub zdarza się, że kurier na zastępstwie mając dużo większy teren nie odbierze przesyłek. Dlatego może się zdarzyć, że zamówienia, choć spakowane w piątek, wysłane zostaną dopiero w poniedziałek.

Krótka przerwa 22-go maja

Z powodu spiętrzenia się zdarzeń losowych, w najbliższą środę, tj. 22-go maja, Nettigo przez jeden dzień będzie zamknięte. Nie będziemy wysyłać zamówień ani odbierać telefonów czy odpisywać na emaile. W czwartek wracamy do pracy i wyślemy wszystkie zamówienia.

BH1750 czyli o świetle i NAMie

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?

Dzień słoneczny (31.03.2024)
Dzień pochmurny (3.04.2024)

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!

Wygrali w Polsce, pomóż wystartować za wielką wodą!

omeGANG to drużna z białostockiego I LO, która jakiś czas temu zwróciła się do Nettigo z prośbą o pomoc w przygotowaniu do polskiego finału Destination Imagination. I, gratulujemy sukcesu drużynie, która zakwalifikowała się do finału w USA!

W ramach polskiego finału, sprzęt uzyskany od nas, omeGANG wykorzystał do realizacji otrzymanego zadania, czyli budowy flippera. Zadanie dokładniej polegało na zbudowaniu:

Flippera, który będzie poruszał piłką przez jak najdłuższy czas oraz stworzenie historii powiązanej z jego działaniem. Flipper musiał się składać z 3 modułów różniących się od siebie metodami technicznymi wykorzystanymi do ich działania. Państwa części okazały się niezbędne do tych modułów, które choć trochę opierały się na elektronice. Ostatecznie nasz Flipper został bardzo wysoko oceniony, zarówno za czas poruszania piłki, jak i różnorodność metod technicznych.

Jednak to nie koniec historii. Otóż, wygrana w polskim finale daje prawo udziału w finale globalnym, który odbędzie się pod koniec maja tego roku, w USA. Związane jest to z dużymi kosztami. Nettigo zwykle może pomóc zespołom takim jak omeGANG poprzez darowiznę nieco sprzętu, którym handlujemy. Jesteśmy jednak niewielką firmą i nie bardzo mamy możliwość większego wsparcia finansowego na tym etapie.

Jednak, wierzymy w nettigową społeczność! omeGANG założył zbiórkę na organizację wyjazdu do USA, a my mamy swoją skarbonkę na zrzutka.pl!

Zapraszam i zachęcam wszystkich do wsparcia młodzieży! Nasza skarbonka: https://zrzutka.pl/95jhvx/s/nettigo

NAMF-2020-46rc5

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.