Przepisanie firmware do czujników smogu

#1

Czołem Załogo!

Od pewnego czasu nosimy się z zamiarem przepisania firmware czujników. Mamy już do tego zadania oddelegowanego programistę z wieloletnim stażem w dziedzinie mikrokontrolerów. Więc o poziom kodu i wzorce projektowe się nie martwię.

Naszym celem jest uporządkowanie kodu źródłowego, zmodularyzowanie go i stworzenie przejrzystej dokumentacji. Chodzi o to aby łatwiej się nad nim pracowało w grupie. Żeby praca nad jednym czujnikiem nie powstrzymywała pracy nad innymi. Bo w tej chwili mamy jeden plik z 4000 lini kodu, a to lekkie przegięcie. Śledzenie zmian i debugowanie co właściwie poszło nie tak, jest nieco upierdliwe.

Jest to też dobry moment aby zastanowić się nad tym jakiej funkcjonalności brakuje nam w firmware, co byśmy chcieli zmienić, co dodać, a co wyrzucić.

Firmware będzie obsługiwał ESP8266 i ESP32. Pozostanie oczywiście OpenSource.

Do tej pory w tym wątku zebraliśmy:

Integracje:

  • obsługa ThingSpeak
  • obsługa MQTT

Zarządzanie:

  • Log dostępny z poziomu www
  • Konfiguracja IP: statyczny / DHCP
  • Możliwość ustawienia dowolnego portu panelu zarządzania
  • Ustawianie interwału restartu

Obsługa czujników:

  • Możliwość ustawienia offsetu korekcyjnego dla czujników
  • Możliwość restartu i diagnozy czujników bez potrzeby ponownego uruchomienia
4 Likes
#2

Super. To czego mi brakuje:

  • log do pliku aby można było podejrzeć przez www (np. ostatnie 100 linii loga)
  • możliwość kalibracji czujnika temperatury (np. + - 0.4) zauważam lekko zawyżoną temperaturę, pewnie obudowa
  • obsługa dodatkowego serwera danych ThingSpeak
    :slight_smile:
#3

Witam, ze swojej strony proponuje:

  • obsługe MQTT
  • wysyłanie na ThingSpeak
#4
  • Zmiana ustawienia IP statyczny/DHCP
  • Zmiana domyślnego portu zarządzania (80) na inny
#5

Auto restart

1 Like
#6

Wspaniała inicjatywa, należą się brawa. To czego mi brakuje to możliwość zmiany nastawy granicznej wilgotności przy której włącza się grzałka w NAM.

#7

Tak. To akurat pójdzie w pierwszej kolejności.

Tworzę właśnie dokumentację wymagań, którą dostanie kierownik zespołu. Warstwę sprzętową już opisałem i zaczyna mnie to powoli przerażać.

Kawałek spisu treści:

  1. Sprzęt
    1.1. Mikrokontroler główny
    1.1.1. ESP8266
    1.1.2. ESP32
    1.2. Łączność
    1.2.1. Wi-Fi wbudowana w ESP8266 / ESP32
    1.2.2. Ethernet wbudowany w ESP32
    1.2.3. LoRaWAN
    1.2.4. GSM 2G GPRS (SIM800L)
    1.3. Czujniki do dodania na start (MVP)
    1.3.1. Czujnik [PM] NovaFitness SDS011 (UART)
    1.3.2. Czujnik [PM] Plantower PMS5003 / PMS7003 (UART)
    1.3.3. Czujnik [PM] Nettigo NPMS-5 (UART/I2C)
    1.3.4. Czujnik [T/P] Bosch BMP280 (I2C)
    1.3.5. Czujnik [T/H/P] Bosch BME280 (I2C)
    1.3.6. Czujnik [T/H] Sensirion SHT3x (30/31/35) + HECA (I2C)
    1.3.7. Czujnik [T/H] DHT22 AM2302 (chińskie “OneWire”)
    1.3.8. Czujnik [T] DS18B20 (OneWire)
    1.3.9. Odbiornik GPS (UART)
    1.4. Czujniki do dodania później
    1.4.1. Czujnik [T/H] AM2302 (I2C)
    1.4.2. Czujnik [T/P] Bosch BMP388 (I2C)
    1.4.3. Czujnik [G] CCS811 (I2C)
    1.4.4. Czujnik napięcia / ADC (I2C)
    1.4.5. Czujnik promieniowania jonizującego (I2C)
    1.5. Czujniki do rozważenia
    1.5.1. Czujnik [T/H] AM2302 (I2C)
    1.5.2. Czujnik [PM] Sensirion SPS30 (UART, I2C)
    1.6. Wyświetlacze
    1.6.1. LCD 1602 (I2C)
    1.6.2. LCD 2004 (I2C)
    1.6.3. SSD1306 (I2C)

Jeżeli macie jakieś wnioski o obsługę sprzętu to jestem otwarty.

1 Like
#8

Ja poproszę o czujnik BME 680 albo podobny który wykrywa benzopireny i inne organiczne substancje rakotwórcze…

#9

A z BME680 da się korzystać, żeby wyliczyć IAQ? Czyli Internal Air Quality. Bo z tego co pamiętam, to Bosch nie dawał źródła, tylko binarkę do liczenia tego.

1 Like
#10

Nie przepadam za BME680. Jest tak jak Rafał pisze - jeżeli chcesz skorzystać z jego pełnego potencjału to musisz dołączyć do swojego projektu binarny zamknięto-źródłowy BLOB od Boscha. To nie wchodzi w grę, żebyśmy dołączali coś z zamkniętymi źródłami. Myślę nad czujnikami elektrochemicznymi od Winsena. Ale zobaczymy gdzie wylądujemy.

#11

Dorzucam do specyfikacji obsługę DS1307 jako zegar czasu rzeczywistego z obsługą budzika.
Budzik w zamierzeniu ma robić za Watchdog. Ustawiony będzie na 2-3 minuty do przodu, i co minutę będzie przestawiany. W razie zawieszenia się mikrokontrolera powinien sygnałem SQ zrestartować urządzenie.

Powinno pomóc w instalacjach z sygnałem wifi poniżej 30%. ESP8266 ma błąd, który powoduje że przy zwiększonym poborze prądu przez radio układ czasami się zawiesza.

Teoretycznie ESP8266 ma wbudowany watchdog… Ale zewnętrzny to zawsze jakieś dodatkowe zabezpieczenie.

1 Like
#12

I wyjaśnione zwiechy niektórych czujników.

#13

Jest na to sposób softwarowy. Można ograniczyć moc nadawczą. Eksperymenty trwają :slight_smile:

2 Likes
#14

A nie prościej na szybko dorzucić reboot co wyznaczony interwał?

#15

Jak masz dużo sieci wifi w okolicy to taki reboot nic Ci nie da. Może przejście na nowsze SDK od espressiff pomoże. A może wręcz przeciwnie.

#16

Eee… a co zmienia dużo innych sieci dookoła?

#17

Jak masz na tym samym kanale dużo ruchu to RSSI spada i radio musi się bardziej pocić żeby dorzucić pakiety.

#18

Oj nie :slight_smile: Odbierany sygnał spada tylko wtedy, gdy spada faktycznie. Inna sieć na tym samym kanale nie powoduje spadku sygnału. Powoduje, owszem, spadek przepustowości i liczne retransmisje, ale nie spadek poziomu sygnału.

Zatem, tak, zgadzam się, że ESP bierze więcej mocy, bo musi retransmitować dane.

#19

Poszperałem, poczytałem i w teorii możemy dodać obsługę BME680

Znalazłem dzisiaj takie coś:

W teorii bo David Bird to kawał wuja dbającego tylko o swoje interesy. Okopirajtował wszystko tak, że szkoda gadać. Więc jego implementacji nie wykorzystamy. Ale pomysł jest niezły. Zaczerpniemy z tego ogólną ideę na liczenie IAQ, a bibliotekę napiszemy sami. Trzeba to jeszcze skonfrontować z tym co podaje własnościowy blob Boscha i tyle. Powinno się udać - gorzej z czasem.

Trochę użytecznych informacji mamy tutaj:

Zasadniczo trzeba wyłapać kilka rzeczy:

  • udział % rezystancji gazu, wilgotności i temperatury w liczeniu IAQ
  • progi i rozkład (czy liniowy, czy może jakiś inny)

Można to zrobić rejestrując dużą ilość danych z czujników i konfrontując to ze sztuczną inteligencją.

1 Like
#20

A to nie jest jak w opisie
https://armaag.gda.pl/indeks_jakosci_powietrza/liczenie_indeksu.htm