Od 8.01 wznawiamy wysyłkę zamówień, do końca tego tygodnia powinny zostać nadrobione wszystkie zaległości.
Styczeń, pogoda jest jaka jest i niestety trafiło się nam ciężkie przeziębienie. A że nas niewielu, to i pojawił się problem z realizacją zamówień. Dziś, (wtorek 7.01) na pewno nikt nie będzie w stanie przygotować zamówień do wysyłki. Mam nadzieję, że jutro przynajmniej część się uda wysłać, a po przedłużonym weekendzie jest sporo zamówień.
Za kłopot przepraszam, ale niestety to jest druga strona medalu o nazwie mała firma – jesteśmy dzięki temu elastyczni i możemy się do naszych klientów łatwo dopasowywać, ale w takim przypadku trudno jest utrzymać działalność bez zakłóceń.
Kurujemy się i mamy nadzieję, że lada dzień wróci wszystko do normy.
W wigilię świąt Bożego Narodzenia dla wszystkich naszych klientów i przyjaciół życzenia wszystkiego najlepszego – niech czas świąt będzie dla nas okazją byśmy stawali się lepszymi ludźmi!
Te szczególne dni w tym roku już tuż, tuż. Tym razem tak się u nas przedstawia harmonogram.
20 grudnia (piątek) ostatni “normalny” dzień pracy – wszystkie opłacone zamówienia powinny zostać wysłane
21-22 grudnia ( sobota-niedziela) – nie pracujemy
23 grudnia – pracujemy w zasadzie normalnie, ale z praktyki wiemy, że mogą być perturbacje z wysyłaniem zamówień, nie zawsze w taki dzień kurierzy odbiorą przesyłkę więc nie gwarantujemy wysyłki
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.
Uaktualniliśmy zdjęcia produktowe modułów Olimex ESP32-POE. Zarówno wersja z ESP32 z anteną PCB jak i ESP32 z zewnętrzną anteną, od pewnego już czasu jest sprzedawana w rewizji PCB co najmniej L lub późniejszej L1. Oznacza to, że moduł ma nieco większe rozmiary oraz dodatkowo dwa otwory montażowe.
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.
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.
