Nasze czujniki Nettigo Air Monitor do tej chwili korzystały z oprogramowania, które wprost pochodziło z projektu Luftdaten. Dzięki temu było możliwe stworzenie tego produktu. Korzystanie z rozwiązań open source pozwala przyspieszyć rozwój. Dzięki temu nasz w sumie niewielki zespół był w stanie stworzyć NAMa.
Jednak szybko okazało się że oprogramowanie Luftdaten ma istotne wady (z naszego punktu widzenia), które utrudniają rozwój. Mogliśmy pozostać “wierni” oprogramowaniu Luftdaten, lub zdecydować się na zrobienie czegoś więcej niż zwykłego forku na githubie. Oznacza to znacznie więcej pracy, ale pozwala znaczenie lepiej dopasować oprogramowanie do naszych potrzeb.
Jakie wady dla nas ma Luftdaten?
Jest ich kilka, pierwszą jest część sprzętu, którego w naszym projekcie nie mamy zamiaru obsługiwać, więc pozbycie się go oznacza zmniejszenie ilości kodu do utrzymania.
Drugą jest forma oprogramowania – główny plik mający kilka tysięcy linii kodu… Jakie ma to znaczenie? Takie, że każdy kto chce coś zmienić/dodać musi wykonać gigantyczną prace by zrozumieć co się w tym sofcie dzieje. Nie jest problemem sama liczba linii (ale stanowi pewną barierę) ale ścisłe powiązania między poszczególnymi częściami kodu. Modyfikacja w jednym miejscu ma często skutki w innym. Jednym z założeń dotyczących NAMów jest to by zapraszały do modyfikowania, tinkerowania w duchu DIY. Jasne i czytelne oprogramowanie jest do tego niezbędne.
Trzecim powodem do zmiany jest nasze przekonanie, że to w jaki sposób napisane jest oprogramowanie można poprawić, ale dopóki forma jego nie zostanie uproszczona trudno będzie to zrobić.
NAMF wersja 2020 🙂
Dlatego powstało nowe repozytorium NAMF w którym prowadzimy prace. Jeśli ktoś chce testować, to oprogramowanie jest już w stadium beta i można próbować go używać. Najprościej – wgrać binarkę na sensor, z tego linka http://beta.fw.nettigo.pl/NAMF/data/latest_pl.bin
Pierwsza istotna zmiana – zamiast podziału pamięci flash z 1 MB na kod, 3 MB na system plików nowy firmware pracuje na podziale 2/2. Znaczy to, że po wgraniu nowego firmware na stary sensor, nie zostanie zachowana konfiguracja. Jest procedura migracji, ale na razie zbyt (naszym zdaniem) skomplikowana, popracujemy nad jej uproszczeniem. Na razie – chcesz przetestować, to skonfiguruj sensor na nowo.
Czemu zmiana podziału pamięci? ESP8266 i tak ma maksymalny rozmiar pliku wykonywalnego 1MB. Z 2MB na kod, jest prosta procedura uaktualnienia, można przez OTA wgrać cały kod w jednym kroku, bez pośredniego firmware. Na dodatek mamy górną granicę rozmiaru fw 1 MB a nie 700-800 kB jak w Luftdaten.
Co się jeszcze zmieniło?
Uproszczenie nieco już struktury plików pozwoliło na zmiany:
- Podczas startu jest wykony test podpiętych sensorów, a wyniki zapisywane tak, że wchodząc na stronę /values od razu widzimy odczyty, nie trzeba czekać aż sensor wyśle pierwsze dane. Nie zawsze uda się odczytać dane z SDS011,
- LCD znakowe są obsługiwane przez jedną zmienną – zużywa to mniej pamięci, ale jednocześnie może być obsługiwany tylko jeden. Mieliście dwa LCD podpięte jednocześnie?
- Na stronie /values podane są też dane diagnostyczne dotyczące wersji oprogramowania i zużycia pamięci
- Gdy sensor konfigurowany jest po raz pierwszy (czyli jest w trybie access pointa) wpisywane hasło do WiFi jest widoczne – zmniejsza to szansę pomyłki, zwłaszcza jeśli robicie to ze smartfona
- Dostępna jest opcja aktualizacji z dowolnego URL (/forceUpdate) ale to zapewne zostanie usunięte w przyszłych wersjach
W skrócie to najistotniejsze zmiany. Ten wpis na naszym blogu rozpoczyna nową serię, wszystkie będą otagowane NAMF, będziemy tutaj raportować postęp prac nad firmware. Bo plan zmian jest dość obszerny 🙂 ale co dokładnie to sami zobaczycie 🙂