nettigo / namf Goto Github PK

Recently built a 0.3.3 STD kit from nettigo.pl, and the SDS has some checksum failures.
Firmware version: NAMF-2020-44rc4
Tried a couple of older firmware versions but the issue persists.

The logs I see from other people show 0% failures.

What are the possible reasons?
Is there anything I can do?

I2C | On I2C bus | 44, 76,
 
HECA | DutyCycle | 0.00 %
HECA | DutyCycleTemp | 0.00 %
HECA | DutyCycleRH | 0.00 %
 
SDS011 | Status | 3
SDS011 | Status change | 7853
SDS011 | Version data | 2021-5-16(6AD9)
SDS011 | Readings failed/total (counter reset with update check) | 2/97
SDS011 | Checksum failures | 16.92% 908/5365
 
WiFi | Time from NTP | Thu Sep 15 07:27:50 2022
WiFi | signal strength | -64 dBm
WiFi | signal quality | 72 %
 
NAM | Number of measurements: | 285
NAM | Uptime | 12h 17m 38s
NAM | Time from last update attempt | 12m 25s
 
NAMF | Sensor slots | 10
NAMF | Free slots | 7
NAMF | Sensors | SPS30 NTW_WTD SHT3x
 
ESP | Reset Reason | Software/System restart
ESP | Max Free Block Size | 23544/23544 B
ESP | Heap Fragmentation | 10/14 %
ESP | Free Cont Stack | 2144/2144 B
ESP | Free Memory | 26096/27456 B
ESP | Flash ID | 1458270
ESP | Flash Vendor ID | 94
ESP | Flash Speed | 40.00 MHz
ESP | Flash Mode | 2
 
ENV | Core version | 2_7_4
ENV | SDK version | 2.2.2-dev(38a443e)
 
DEBUG | Debug options

Home Assistant uses zeroconf to discover a NAM device on the local network and propose a configuration of the integration to the user. The hostname is checked, if it contains NAM- that means this is a NAM device.

If the user changes the network name in the NAM device configuration, the hostname of the device will also change and the HA will not be able to discover the device.

Adding an additional text ID information with the default hostname (NAM-12345678) would solve this problem.

This is an example of mDNS information from Shelly device with ID:

The topic says it all: The current 38rc5 has no option to show SHT3x temperature and humidity on the display. It would be nice to see data of all connected sensors.

When you try to start sensor with SPS30 enabled in config but physically disconnected NAM enters infinite loop and doesn't start. Flashing LED on ESP-12 module suggest that sensor is probing for SPS30 over I2C.

Hi,
I have a pi-hole (local dns resolver) in my network and notice some strange dns quires coming from NAM
It's trying to resolve M-,7M-^??M-0^DM-^??M-\:M-^??D9M-^??te.^J^A^EM-z^D^A.
In pi-hole interface it shows as:

Here is tcpdump collected on my dns resolver for connection from NAM

❯ tcpdump -vvvAs0 host 192.168.0.219 and port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:45:10.577839 IP (tos 0x0, ttl 255, id 59151, offset 0, flags [none], proto UDP (17), length 71)
192.168.0.219.51842 > 192.168.0.44.domain: [udp sum ok] 3383+ A? M-,7M-^??M-0^DM-^??M-:M-^??D9M-^??te.^J^A^EM-z^D^A. (43)
E..G......R>.......,...5.3fP.7............7.?...?.:.?D9.?te.
..........
23:45:10.578384 IP (tos 0x0, ttl 64, id 15073, offset 0, flags [DF], proto UDP (17), length 71)
192.168.0.44.domain > 192.168.0.219.51842: [bad udp cksum 0x829c -> 0xe5cc!] 3383 NXDomain q: A? M-,7M-^??M-0^DM-^??M-:M-^??D9M-^??te.^J^A^EM-z^D^A. 0/0/0 (43)
E..G:.@.@.}m...,.....5...3...7............7.?...?.:.?D9.?te.
..........
23:45:10.590188 IP (tos 0x0, ttl 255, id 59152, offset 0, flags [none], proto UDP (17), length 71)
192.168.0.219.51842 > 192.168.0.44.domain: [udp sum ok] 3383+ A? M-,7M-^??M-0^DM-^??M-:M-^??D9M-^??te.^J^A^EM-z^D^A. (43)
E..G......R=.......,...5.3fP.7............7.?...?.:.?D9.?te.
..........
23:45:10.590626 IP (tos 0x0, ttl 64, id 15074, offset 0, flags [DF], proto UDP (17), length 71)
192.168.0.44.domain > 192.168.0.219.51842: [bad udp cksum 0x829c -> 0xe5cc!] 3383 NXDomain q: A? M-,7M-^??M-0^DM-^??M-:M-^??D9M-^??te.^J^A^EM-z^D^A. 0/0/0 (43)
E..G:.@.@.}l...,.....5...3...7............7.?...?.:.?D9.?te.
..........
23:45:40.629182 IP (tos 0x0, ttl 255, id 59161, offset 0, flags [none], proto UDP (17), length 71)
192.168.0.219.51842 > 192.168.0.44.domain: [udp sum ok] 3385+ A? M-,7M-^??M-0^DM-^??M-:M-^??D9M-^??te.^J^A^EM-z^D^A. (43)
E..G......R4.......,...5.3fN.9............7.?...?.:.?D9.?te.
..........
23:45:40.629669 IP (tos 0x0, ttl 64, id 17256, offset 0, flags [DF], proto UDP (17), length 71)
192.168.0.44.domain > 192.168.0.219.51842: [bad udp cksum 0x829c -> 0xe5ca!] 3385 NXDomain q: A? M-,7M-^??M-0^DM-^??M-:M-^??D9M-^??te.^J^A^EM-z^D^A. 0/0/0 (43)
E..GCh@[email protected]....,.....5...3...9............7.?...?.:.?D9.?te.
..........
23:45:40.632730 IP (tos 0x0, ttl 255, id 59162, offset 0, flags [none], proto UDP (17), length 71)
192.168.0.219.51842 > 192.168.0.44.domain: [udp sum ok] 3385+ A? M-,7M-^??M-0^DM-^??M-:M-^??D9M-^??te.^J^A^EM-z^D^A. (43)
E..G......R3.......,...5.3fN.9............7.?...?.:.?D9.?te.
..........
23:45:40.633098 IP (tos 0x0, ttl 64, id 17257, offset 0, flags [DF], proto UDP (17), length 71)
192.168.0.44.domain > 192.168.0.219.51842: [bad udp cksum 0x829c -> 0xe5ca!] 3385 NXDomain q: A? M-,7M-^??M-0^DM-^??M-:M-^??D9M-^??te.^J^A^EM-z^D^A. 0/0/0 (43)
E..GCi@[email protected]....,.....5...3...9............7.?...?.:.?D9.?te.
..........
23:45:41.550155 IP (tos 0x0, ttl 255, id 59164, offset 0, flags [none], proto UDP (17), length 63)
192.168.0.219.51842 > 192.168.0.44.domain: [udp sum ok] 3384+ A? api-rrd.madavi.de. (35)
E..?......R9.......,...5.+...8...........api-rrd.madavi.de.....
23:45:41.550661 IP (tos 0x0, ttl 64, id 17305, offset 0, flags [DF], proto UDP (17), length 79)
192.168.0.44.domain > 192.168.0.219.51842: [bad udp cksum 0x82a4 -> 0x01ed!] 3384 q: A? api-rrd.madavi.de. 1/0/0 api-rrd.madavi.de. [10h14m53s] A 85.214.202.106 (51)
E..OC.@[email protected]....,.....5...;...8...........api-rrd.madavi.de.................U..j
23:45:42.131313 IP (tos 0x0, ttl 255, id 59179, offset 0, flags [none], proto UDP (17), length 70)
192.168.0.219.51842 > 192.168.0.44.domain: [udp sum ok] 3386+ A? ingress.opensensemap.org. (42)
E..F.+....R#.......,...5.2...:...........ingress.opensensemap.org.....
23:45:42.131710 IP (tos 0x0, ttl 64, id 17333, offset 0, flags [DF], proto UDP (17), length 86)
192.168.0.44.domain > 192.168.0.219.51842: [bad udp cksum 0x82ab -> 0x49f7!] 3386 q: A? ingress.opensensemap.org. 1/0/0 ingress.opensensemap.org. [4m59s] A 128.176.196.25 (58)
E..VC.@[email protected]....,.....5...B...:...........ingress.opensensemap.org..............+......
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Version: NAMF-2020-36

I have this NAM for few months and didn't notice this before.
It doesn’t look normal, what can be wrong? Is there a way to fix it?

Running 38rc6 now, I have never seen HECA duty cycle values other than "0.0". I am sure HECA is active, as HECA T and RH are higher/lower than the other sensor readings. Is HECA data temporary (i.e. only showing a value different from 0 when active) or is it accumulated (how much % activity of sensor uptime)?

Is there any possibility to access builds listed in Versions.md?

Turning off auto updates does not stop firmware from checking and installing updates.

Preferable a CO sensor with gain (4 pin sensor) to increase the resolution.

For example the expensive Alphasense CO-B4 with only 4 ppb (not ppm) noise according to the CO-B4 datasheet.

Some people (including me) may have low Wi-fi signal strength in the place where their NAM device is placed.
In such case it often happens that the reading is not uploaded to the servers. It would be great if the NAM s/w would preserve last N readings and upload them later with the timestamp of occurrence.

Thank you for you work on this project.

We have just built and installed a NAM (NAMF-2020-43) KIT-2106 Nettigo Air Monitor (KIT 0.3.3 STD EN) - smog sensor, DIY Kit.
We have noticed that during a sampling cycle the LED flashes blue on the wifi chip for ~ 145 seconds.
However after the fan stops, the Blue LED stops flashing for ~60 seconds and we can not connect to the NAM via wifi.
The overall cycling time is ~ 305 seconds. The wifi signal when connected is good.
Is this a normal sampling cycle for the device?
We have also noticed that there are gaps in the data recorded and displayed in sensor graphs on Madavi. See attached file.
Any advice would be very welcome please.
Thank you,
Regards.
K.
Please note we also have a couple of sensor community kits and we have not noticed any wifi loss during a sampling cycle.
data-esp8266-5945275-2022-06-04.csv

I noticed that the pressure seems not to be logged when the checkbox that the BMP180/280 is inside the case is checked.
The pressure is still displayed for example on the sensor.community map, but no history is available.

When the checkbox is not selected, the pressure is indeed logged.

Also, I think the menu entry for this sensor is labelled incorrectly. It says "BMP180/280 humidity/temperature sensor" but isn't this family a temperature/pressure sensor instead?

On the /values page, I would expect the "Home" text in the breadcrump line to be linked to the homepage (as is the Nettigo icon). "Home" doesn't contain a link at all.

.
Please link "Home" on /status, /config, /values to the "Homepage".

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1392, room 16
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
@cp:0
ld

NAMF ver: NAMF-a2020-33-2/PL
Chip ID: 2678051
SPIFFS size (kB): 921037
Free sketch space (kB): 1488
CPU freq (MHz): 160
Thu Jan 1 08:00:00 1970: mounting FS...
Thu Jan 1 08:00:00 1970: mounted file system...
Thu Jan 1 08:00:00 1970: reading config file...
Thu Jan 1 08:00:00 1970: opened config file...
Thu Jan 1 08:00:00 1970: Config - JSON object memory used:992
Thu Jan 1 08:00:00 1970: parsed json...
Thu Jan 1 08:00:00 1970: Config parsed and loaded
Thu Jan 1 08:00:00 1970: PowerOnTest
Thu Jan 1 08:00:00 1970: Read SDS...
Thu Jan 1 08:00:01 1970: SDS011 not sending data!
Thu Jan 1 08:00:01 1970: Stopping SDS011...
Thu Jan 1 08:00:01 1970: Read BME280...
Thu Jan 1 08:00:01 1970: Trying BME280 sensor on 76 ... found
Thu Jan 1 08:00:01 1970: Start reading BME280
Thu Jan 1 08:00:01 1970: BME280 couldn't be read
Thu Jan 1 08:00:01 1970: Read HECA (SHT30)...
Thu Jan 1 08:00:01 1970: Trying HECA (SHT30) sensor on 0x44Start reading HECA
Thu Jan 1 08:00:01 1970: Temp: 22.43
Thu Jan 1 08:00:01 1970: Hum: 61.20
Thu Jan 1 08:00:01 1970: Starting Webserver... (IP unset)
Thu Jan 1 08:00:01 1970: output debug text to displays...
Thu Jan 1 08:00:01 1970: SSID: 'LAB'
Thu Jan 1 08:00:01 1970: 6
Thu Jan 1 08:00:01 1970: Connecting to LAB
Thu Jan 1 08:00:02 1970: .......
Thu Jan 1 08:00:05 1970: WiFi connected
IP address: 192.168.10.10
Thu Jan 1 08:00:05 1970: Setting time using SNTP
Thu Jan 1 08:00:05 1970: Thu Jan 1 08:00:05 1970

Thu Jan 1 08:00:05 1970: NTP.org:
Fri Aug 14 12:19:24 2020: .Fri Aug 14 12:19:24 2020

Fri Aug 14 12:19:24 2020:
NTP time received
Check for update with default URLNAMF-a2020-33-2
Fri Aug 14 12:19:24 2020: output debug text to displays...
Fri Aug 14 12:19:24 2020: Update checked:
Fri Aug 14 12:19:24 2020: alfa.fw.nettigo.pl
Fri Aug 14 12:19:24 2020: /NAMF/index.php
NAMF-a2020-33-2 2678051 SDS PL PL

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1392, room 16
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
@cp:0
ld

A configuration change + soft restart didn't improve. After 145 seconds still no particulate matter was read:

[2022-02-16 19:33:08]

{"esp8266id": "1XXXXXX4", "software_version": "NAMF-2020-43", "sensordatavalues":[{"value_type":"SHT3X_temperature","value":"13.02"},{"value_type":"SHT3X_humidity","value":"89.40"},{"value_type":"HECA_temperature","value":"17.88"},{"value_type":"HECA_humidity","value":"64.73"},{"value_type":"HECA_Tdc","value":"0.00"},{"value_type":"HECA_RHdc","value":"100.00"},{"value_type":"HECA_dc","value":"100.00"},{"value_type":"BMP_pressure","value":"99386.40"},{"value_type":"BMP_temperature","value":"12.30"},{"value_type":"samples","value":"112549"},{"value_type":"min_micro","value":"1222"},{"value_type":"max_micro","value":"90517"},{"value_type":"signal","value":"-73"}]}

A cold boot (power cycling) did fix the SDS011 readings:

[2022-02-16 19:38:51]

{"esp8266id": "1XXXXXX4", "software_version": "NAMF-2020-43", "sensordatavalues":[{"value_type":"SDS_P1","value":"1.40"},{"value_type":"SDS_P2","value":"0.80"},{"value_type":"SHT3X_temperature","value":"13.05"},{"value_type":"SHT3X_humidity","value":"89.51"},{"value_type":"HECA_temperature","value":"18.35"},{"value_type":"HECA_humidity","value":"63.53"},{"value_type":"HECA_Tdc","value":"0.00"},{"value_type":"HECA_RHdc","value":"100.00"},{"value_type":"HECA_dc","value":"100.00"},{"value_type":"BMP_pressure","value":"99381.00"},{"value_type":"BMP_temperature","value":"12.30"},{"value_type":"samples","value":"104553"},{"value_type":"min_micro","value":"1305"},{"value_type":"max_micro","value":"546981"},{"value_type":"signal","value":"-72"}]}

Github forked lib deps definitions are not compatibile with Platformio 5.0.
Build fails for fresh projects or with removed .pio folder.
See https://docs.platformio.org/en/latest/core/migration.html

Adding the uptime value to the data.json file will allow to create an uptime sensor in Home Assistant.

After upgrading to NAMF-2020-38 PMS5003 stopped working.

After connecting via serial no error can be seen in console, however PMSx003 reading are not providing any results. Tested on two devices, same result on both.

Today and yesterday I ran into a problem with the ESP not being able to connect to the (in the meantime unchanged) wifi network that it used to connect to before.
This has happened two times after I disconnected it from power for a short time to redo my wiring.

Yesterday I managed to get the connection back up by entering the credentials, waiting for the reboot and then disconnecting the power for a minute or so. Today this did not help at all; I finally got it working by changing the PHY mode from "n" to "g".
This seems to have caused the configuration to update.

Maybe this is related to an issue I ran into, as well, where the /configSave.json would not save the config. E.g. if I change the debug level on /configSave.json and hit "save and reboot", after the reboot /config.json will still be on the old debug level.
So maybe the wifi credentials are lost when power is disconnected and then it is unable to save them again unless some other setting on the config change is altered, as well?

Also: is there a way to perform a full reset, i.e. wipe all configuration and start again like /ResetConfig? That would be good to have in case you mess up the config somehow.

EDIT:
I just realized that there are also some gaps in the data in the middle of the night – could be related, but could also be the router doing updates or so, see https://api-rrd.madavi.de/grafana/d/GUaL5aZMz/pm-sensors?var-chipID=esp8266-15378168&orgId=1&from=1642718246985&to=1642746550071

Details:

config

{"current_lang":"EN","SOFTWARE_VERSION":"NAMF-2020-43","wlanssid":"***",
    "wlanpwd":"***","www_username":"admin","www_password":"admin",
    "fs_ssid":"NAM-15378168","fs_pwd":"","www_basicauth_enabled":"false",
    "dht_read":"false","pms_read":"false","ds18b20_read":"false",
    "gps_read":"false","send2dusti":"true","ssl_dusti":"false",
    "send2madavi":"true","ssl_madavi":"false","send2sensemap":"false",
    "send2fsapp":"true","send2lora":"false","send2csv":"false",
    "auto_update":"true","update_channel":"2","has_display":"false",
    "has_lcd1602":"false","has_lcd1602_27":"false","has_lcd2004_27":"false",
    "has_lcd2004_3f":"false","show_wifi_info":"false","has_ledbar_32":"false",
    "debug":"0","send_diag":"false","sending_intervall_ms":"145000",
    "time_for_wifi_config":"1200000","outputPower":"20.50","phyMode":"2",
    "senseboxid":"","send2custom":"false","host_custom":"","url_custom":"/data","port_custom":"0","user_custom":"","pwd_custom":"",
    "send2influx":"false","host_influx":"influx.server","url_influx":"/write?db=luftdaten","UUID":"d2542303-262d-4bcd-a92f-01489213b030",
    "port_influx":"8086","user_influx":"","pwd_influx":"","sensors":{"SPS30":{"e":0,"refresh":"10"},"NTW_WTD":{"e":0,"ip":"(IP unset)"},"SHT3x":{"e":1,"d":1},"MHZ14A":{"e":0},"SDS011":{"e":1,"d":1},"HECA":{"e":1,"d":1},"BMPx80":{"e":1},"BME280":{"e":0}}}

Is it possible to add the MAC address of the device to the config.json?

This would be helpful for Home Assistant integration. Currently, the backend library gets the MAC address of the device from the values endpoint (via regex). If the MAC address is available in config.json the library will make one less request (config.json is fetched on init to check if auth is required).

Greetings.

I noticed that after the NAMF-2020-42rc6 update (2021-12-07 rev) my WINSEN MHZ14A - CO2 sensor no longer returns the values and from the LEDs you can see that it no longer takes CO2 readings.
Why is this sensor disabled when doing beta software updates?
Can you check and reactivate it? Thanks.

There seems to be a stability issue after automatic upgrade to NAMF-2020-37.
The screenshot from madavi shows some random blanks in 7-day data that start on April 28.

PM2.5 data for April 27:

And PM2.5 data for April 28:

This seems to correlate with NAMF-2020-37 release date...
I have been monitoring uptime for the last hour, and it seems that watchdog reboots are rather frequent, I haven't seen an uptime longer than 30 minutes.

What debug data can I provide?

The sensor reading is currently only online on the http://aqi.eco portal. It would be interesting to present the data directly in the LCD display.

Heating element (HECA) seems to have a hysteresis of almost 5ºC:

and 18-19% variation for relative humidity:

It would be nice of these wavy lines for temperature and RH become smoother. Not by changing the graph but instead by changing the operation of the Heating Element Control Assembly (HECA).

If you will try to put any path (ex. your own .bin file) in /forceUpdate
the device still use hardcoded path from firmware:

#define UPDATE_HOST F("beta.fw.nettigo.pl")
#define UPDATE_URL F("/NAMF/index.php")
#define UPDATE_PORT 80

I have about 10 SDS011 sensors lying around. One of them reads PM 2.5 values very close to the next official measurement station. 50% of the remaining samples reads consistently 50% lower than that. The rest reads 30% lower. I am tired of spending more money to find another accurate sample.

Would it be possible to add a scaling factor in the firmware, which allows the user to match the PM measurements to a reference?

Hello.

I encountered a problem after the 38rc1 upgrade.
After the update the LCD 2004 no longer displays the SDS011 sensor data page.
Can you check?

SDS011 gets only first measurement after boot, then same value is constantly displayed on values page and uploaded to server. Other sensors (BME280, HECA) are refreshing as configured.

SDS011 works properly again after downgrade to 2020-37.

After updating firmware to NAMF-2020-37, the device doesn't send any mDNS information.

Is it possible to add support for InfluxDB 2.x? I've tried to use api token as password but unfortunately that didn't work.

Thanks in advance!

My custom API (.NET Core) returns 411 HTTP Error.

I found that the Content-Length is not filled in request headers.

Current BETA NAMF-2020-23

Stable version - NAMF-2019-020:

Additionaly I found that used Library probably want to fill Content-Length:
https://github.com/esp8266/Arduino/blob/372a3ec297dfe8501bed1ec4552244695b5e8ced/libraries/ESP8266HTTPClient/src/ESP8266HTTPClient.cpp#L673

But, not only I have this issue with this library:
esp8266/Arduino#2678

Would you mind sharing instructions how to build/config depending on NAM version?

I haven't found anything yet and I would like to be sure I am doing everything correctly.

More specifically I would like to build the firmware uploaded into NAM 0.3.3 STD with some modifications and possibly upload some PR.

If I am not mistaken the platform should be espressif8266 and the board is d1_mini?

Would be great to have the possibility on the web interface to turn off the LED on the Wemos D1 mini.

As an extra, the switch could be presented on the Home Assistant integration as well.

NAMF-2020-41rc4 introduced opt out for sending diagnostic data to Nettigo.

Using NAMF-2020-41: Removing the checkmark for "Sent diagnostic data to Nettigo" and choosing "Save and restart"

results in "checkmark" enabled after the page loads again.

Expected is the checkmark to be gone/stay disabled.

Hardware: KIT 0.3.3
Software: Autoupdated to NAMF-2020-44

Since the auto update from the previous Version my AirMonitor needs regular reboots and it stops reporting and is not reachable via Network.

I'm not able to debug that device as I do not know what I need to make to get a new (old) firmware on that device when it is not working via Network. Maybe some english instructions how I can debug that situation as I can't get the logs from the device when it is not working. I still see a light flashing when it is not reachable but there is no way for me to get on that device.

If this is not the right place to look for that kind of help, please let me know where I can go.

versus:

First thought on the NAMF is, wow this firmware is as old as the Luftdaten firmware. Clicking on the hyperlink will show that NAM firmware 2020-41 is dated 2021-11-08.

I wish to see that date information directly right from the firmware identifier.

Nettigo Pro hardware with a BMP180 turns out to be having too high pressure readings.

Another BMP280 at 0.1 kilometer distance is: 1019.6
The Nettigo Pro hardware met BMP180 is at: 1061.2
Other pressure sensors nearby on maps.sensor.community show: 1019.6, 1019.3, 1019.3, 1018.0

SDS011 does not show PM2.5 and PM10 values after update to firmware version: NAMF-2020-34

@netmaniac Currently NAMF tries to fetch NTP server from DHCP server from WiFi, but not every DHCP server on home router has this set.

Can we have separate text field in NAMF, where we could enter our own desired NTP server? This could work like this:

• if NTP server field is empty then try to set time through DHCP fetched NTP server
• if NTP text field is populated with hostname then try to fetch time from this server

Sometimes you may suspect that the last reading was disturbed by some random event (e.g. it it much higher or lower than previous one).
In such case it would be great to have an opportunity to refresh the reading without waiting for the next one e.g. after entering the /refreshReadings sub-page.

The main questions are: is this something doable, will it get accepted as a PR, does it make sense?

If so, could you please provide some hints how to achieve this?

Next things that would be nice to have:

1. An option to have configurable physical button that would act as a trigger. (e.g. the used pin could be configurable)
2. Even more configuration that allows other actions to be performed by the trigger e.g.:
   • readings would be displayed on the LCD only after the trigger

Please let me know what you think!

I would also like to notify you of a data problem with the API of https://luftdaten.info/.
On my https://devices.sensor.community/ account I added the SPS30 sensor, but I can only see the data from the BME280.
Both sending to Luftdaten and Madavi are enabled in the NAM configuration.
Can you check if it's a firmware problem?
Thanks.

Originally posted by @icnmfabro in #21 (comment)

It would be nice to have support for airmonitor.pl data sending next to other services.

I will try to implement it unless author has something against it.

NAMF 2020-26 (2020-03-17) mentions: added I2C RGB LED Bar support.

Searching nettigo.eu for the term "LED bar" results in 8 product. None of the results seem to be a NAM compatible module.

NAM compatible modules lists LCD's and OLED but no LED module.

I'm still puzzling which exact hardware item is supported with "I2C RGB LED Bar". Please improve the documention.

NAMF-2020-26 firmware.
Incorrect data.json structure.
The closing quotation mark after "age" is missing.

{"software_version": "NAMF-2020-26", "age":"0, "measurements":"3452", "sensordatavalues":[{"value_type":"SDS_P1","value":"5.30"},{"value_type":"SDS_P2","value":"2.40"},{"value_type":"BME280_temperature","value":"23.19"},{"value_type":"BME280_humidity","value":"15.99"},{"value_type":"BME280_pressure","value":"101141.87"},{"value_type":"HECA_temperature","value":"22.18"},{"value_type":"HECA_humidity","value":"18.34"},{"value_type":"samples","value":"195472"},{"value_type":"min_micro","value":"1185"},{"value_type":"max_micro","value":"165036"},{"value_type":"signal","value":"-89"}]}

It would be convenient to have information about pull request workflow in this project. Should they be requested to master or to beta branch? Should bugfixes and new features be submitted in the same way?

I'm implementing support for mqtt as api and for pir sensor for turning on and off lcd backlight, and I'll be happy to contribute them to main project in the most welcome way.

Currently readings from SPS30 particle matters sensor are only sent to cloud and available on sensor page and JSON. NAM should display info on LCD, when enabled.

Hello
How do I display debug information using NAMF-2020-43 please?

Thank you
Regards
K

I read the release notes of rc16 but do not fully understand. Does that mean that support of BME280 will be removed from the firmware? The data is still showing up on the LCD and the website, but what is sent to api-rrd.madavi is obviously broken (maps.sensor.community seems to be fine).

Please keep support for the BME280.

With the 41rc1 update, the Winsen MHZ14A - CO2 sensor always gives 0ppm as a result. is it possible to check the code if there is a bug on the new beta release?

Endpoint /config.json returns json data but the content type of the answer is text/plain, not application/json.
Firmware: NAMF-2020-40

$ curl -v http://user:[email protected]/config.json
*   Trying 192.168.1.99:80...
* Connected to 192.168.1.99 (192.168.1.99) port 80 (#0)
* Server auth using Basic with user 'user'
> GET /config.json HTTP/1.1
> Host: 192.168.1.99
> Authorization: Basic kDFjaBNrOmghYXRhLTk8lw==
> User-Agent: curl/7.74.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/plain     <-------------------------------------------------
< Content-Length: 1236
< Connection: close
< 
{"current_lang":"PL","SOFTWARE_VERSION":"NAMF-2020-40","wlanssid":"SSID","wlanpwd":"***","www_username":"user","www_password":"pass","fs_ssid":"NAM-16066574","fs_pwd":"","www_basicauth_enabled":"true","dht_read":"false","pms_read":"false","ds18b20_read":"false","gps_read":"false","send2dusti":"false","ssl_dusti":"false","send2madavi":"false","ssl_madavi":"false","send2sensemap":"false","send2fsapp":"false","send2lora":"false","send2csv":"false","auto_update":"false","update_channel":"2","has_display":"false","has_lcd1602":"false","has_lcd1602_27":"false","has_lcd2004_27":"false","has_lcd2004_3f":"false","show_wifi_info":"false","has_ledbar_32":"false","debug":"3","sending_intervall_ms":"145000","time_for_wifi_config":"600000","outputPower":"20.50","phyMode":"3","senseboxid":"6075a03aa81682001b533a6f","send2custom":"false","host_custom":"","url_custom":"","port_custom":"443","user_custom":"","pwd_custom":"","send2influx":"false","host_influx":"","url_influx":"","port_influx":"8086","user_influx":"","p* Closing connection 0
wd_influx":"","sensors":{"SPS30":{"e":0,"refresh":"10"},"NTW_WTD":{"e":1,"ip":"192.168.2.15"},"SHT3x":{"e":0,"d":0},"MHZ14A":{"e":0},"SDS011":{"e":1,"d":1},"HECA":{"e":1,"d":1},"BMPx80":{"e":0},"BME280":{"e":1}}}