Error: nodemcu connected but impossible to connect to IP/doesn't send data

MagTun commented 4 years ago

This morning I noticed that my sensor didn't send data anymore to madavi. I could see it was still connected to the wifi/router but I couldn't connected to its IP.

When I used the serial monitor to read the debug, this is what it printed (every 5 seconds or so):

ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vbc204a9b
~ld

Any idea what it means?

This sensor has been live for several weeks without having such problems. It uses a BME280.

MagTun commented 4 years ago

I re-upload the software with the flashtool but still it's not working. I am still getting the same debug output.

svenkubiak commented 4 years ago

Same here. I have the same problem.

Was there perhaps a new firmware version that was installed via AutoUpdate and bricked the device?

MagTun commented 4 years ago

Good to know I am not the only one! Yes apparently there was an update yesterday ("Jan 7 2020 13:42:11)).

My sensor which run with a DHT22 received it and is running smoothly, but my sensor with a BME280 stopped sending data yesterday at 18h (madavi time).

I have reinstalled the software (BME280 + en) on another nodemcu with the flashtool and since then it's working fine but I would like to get the "bricked device" back on because I don not want my data spread across different ID.

svenkubiak commented 4 years ago

Last data I have is 9 hours ago. Maybe I recieved the update later. However, I also have a BME280.

MagTun commented 4 years ago

I think I was able to fix this.

You need to delete the configuration. I used the second way because the first one didn't work (maybe my arduino IDE version -1.8- isn't compatible, I didn't try with arduino 1.6 as recommended). Actually I find the 2nd way easier so it maybe set as the first way.

Then use the flashtool again to flash latest.bin (don't worry about the language or the bme280, you can set it later in config - it will be in German but you can sort of understand even if you don't know German).

Then enjoy while your sensor is coming back to life!

MagTun commented 4 years ago

My Nodemcu is back to life, but my BME280 is dead. I don't get any data and the humidity line on the config page is missing:

svenkubiak commented 4 years ago

Did you do somerhing or did it just work again?

dirkmueller commented 4 years ago

@MagTun can you please post a full screenshot of the device status page (airrohr-xxxxxx.local/status)

dirkmueller commented 4 years ago

Also, please remove power supply, wait 10s and power it on again. As the i2c devices are connected to the firmware debig pin, they sometimes crash when the firmware had a issue (Don't ask me why the recommended wiring connects i2c to the boot debug pin)

dirkmueller commented 4 years ago

@svenkubiak to wipe the node clean and recover from scratch, you can do this if you have esptool.py available (make sure it is at least version 2.8 by calling esptool.py version)

esptool.py  --chip auto --port $port  erase_flash
esptool.py  --chip auto --port $port --baud 460800 write_flash -fm dio 0x00000 latest_XX.bin

where latest_XX.bin is the file from https://firmware.sensor.community/airrohr/update/ in the locale that you want.

svenkubiak commented 4 years ago

@dirkmueller Don‘t know if I want to start from scratch if I don‘t have to 😄

However, clean install is a/the fix?

MagTun commented 4 years ago

Did you do somerhing or did it just work again?

yes I deleted the configuration (cf my message above the printscreen with the dead bme280)

MagTun commented 4 years ago

@MagTun can you please post a full screenshot of the device status page (airrohr-xxxxxx.local/status)

I don't have the dead bme280 right now online (I replaced it with a new one, which works so far). I will post the printscreen as soon as I can.

dirkmueller commented 4 years ago

@svenkubiak then leave out the erase_flash part. that should be nondestructive.

I don't know what the fix is because I don't know what the issue is that you have :-) if you can connect to the chat.luftdaten.info then lets continue the conversation there in case you want to troubleshoot. I'd really like to understand what is going on..

svenkubiak commented 4 years ago

Yesterday I ended up flashing (latest DE) and reconfigured a replacement NodeMCU with the same hardware (BME280, SDS11). Looks like everything is working - just have to configure the data transfer.

@dirkmueller Haven't looked at the non-functional NodeMCU yet. If you want to get to the bottom of this, feel free to let me know. Otherwise, I'll reflash that too.

dirkmueller commented 4 years ago

@svenkubiak yes absolutely interested in finding out what happened or why. OTAs should not behave like this.

MagTun commented 4 years ago

Also, please remove power supply, wait 10s and power it on again. As the i2c devices are connected to the firmware debig pin, they sometimes crash when the firmware had a issue (Don't ask me why the recommended wiring connects i2c to the boot debug pin)

I did this many times, I also tested the BME280 on another nodemcu (not the bricked one) with the luftdaten latest.bin but I don't have any value. I will take a look at it in more details and let you know.

esptool.py --chip auto --port $port erase_flash esptool.py --chip auto --port $port --baud 460800 write_flash -fm dio 0x00000 latest_XX.bin

Does this also delete the configuration? Or only the "software"?

if you can connect to the chat.luftdaten.info

I tried to connect but I couldn't. Which identification should I use?

airrohr-xxxxxx.local/status

I don't know this page but this is the screenshot of the status page from http://192.168.1.xxx/status. This sensor is the one that was bricked but as I wrote yesterday, I have since deleted the configuration and reflash the lastest.bin so you may have more chance with @svenkubiak

dirkmueller commented 4 years ago

Does this also delete the configuration? Or only the "software"?

the "erase_flash" deletes the complete flash including configuration. if you leave it out, then the 2nd command only replaces the sketch (the "firmware") and keeps configuration in tact.

dirkmueller commented 4 years ago

To summariz the earlier discussion:

Any idea what it means?

this means the esp8266 was booted in eboot serial flash mode, which means it considered GPIO0 to be in "low" state at poweron. disconnecting the cable on D3 / GPIO0 should recover it and boot from flash again.

It looks like this is due to a very unfortunate choice in the sensor setup that we used I2C on a pin that controls boot. It looks like I need to add code to the OTA loader to raise the pin for some time to avoid that a reset pulls a low and stops the node from booting..

dirkmueller commented 4 years ago

see https://www.forward.com.au/pfod/ESP8266/GPIOpins/index.html for details

ricki-z commented 4 years ago

But this seems to have changed over time. I were looking for this at the start of the project. And the pins D1 to D7 weren't used for everything. That was also the reason to not use D0. D3/GPIO0 is used as SDA, so there shouldn't be any 'signal' as we only use I2C slaves (They should wait for commands).

MagTun commented 4 years ago

Any idea what it means?

I forgot to says that this is what I got when I was on baud rate 11520:

ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vbc204a9b
~ld

But when I switched to baud rate 9600 I got this (also printed every 5 secs or so):

[Info] Opened the serial port - COM4

�txW�X6d�H<���airRohr: NRZ-2020-129/DE

mounting FS...

opened config file...

parsed json...

output debug text to displays...

Connecting to RepeaterNodeMCU1

.......

WiFi connected, IP is: 10.24.1.2

Exception (28):

epc1=0x4000bdc8 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

>>>stack>>>

ctx: cont

sp: 3ffffd30 end: 3fffffc0 offset: 01a0

3ffffed0:  3fffff48 00000050 3fffff10 3ffe8937  

3ffffee0:  3ffe8945 3ffe8940 3ffef45c 40217c08  

3ffffef0:  3ffe893c 3ffef518 3ffef45c 4020b10c  

3fffff00:  00000040 00000000 feefeffe feefeffe  

3fffff10:  70747400 2e312e00 80000032 4022276c  

3fffff20:  feefeffe feefeffe feefeffe feefeffe  

3fffff30:  feefeffe feefeffe feefeffe feefeffe  

3fffff40:  feefeffe feefeffe 00706300 0201180a  

3fffff50:  80efeffe feefeffe feefeffe feefeffe  

3fffff60:  feefeffe feefeffe feefeffe feefeffe  

3fffff70:  feefeffe feefeffe feefeffe feefeffe  

3fffff80:  3ffee993 feefeffe feefeffe feefeffe  

3fffff90:  feefeffe feefeffe feefeffe 3ffef674  

3fffffa0:  3fffdad0 00000000 3ffef634 40222b34  

3fffffb0:  feefeffe feefeffe 3ffe8678 40100679  

<<<stack<<<

H!��1��:�airRohr: NRZ-2020-129/DE

mounting FS...

opened config file...

parsed json...

output debug text to displays...

Connecting to RepeaterNodeMCU1

.......

WiFi connected, IP is: 10.24.1.2

Exception (28):

epc1=0x4000bdc8 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

>>>stack>>>

ctx: cont

sp: 3ffffd30 end: 3fffffc0 offset: 01a0

3ffffed0:  3fffff48 00000050 3fffff10 3ffe8937  

3ffffee0:  3ffe8945 3ffe8940 3ffef45c 40217c08  

3ffffef0:  3ffe893c 3ffef518 3ffef45c 4020b10c  

3fffff00:  00000040 00000000 feefeffe feefeffe  

3fffff10:  70747400 2e312e00 80000032 4022276c  

3fffff20:  feefeffe feefeffe feefeffe feefeffe  

3fffff30:  feefeffe feefeffe feefeffe feefeffe  

3fffff40:  feefeffe feefeffe 00706300 0201180a  

3fffff50:  80efeffe feefeffe feefeffe feefeffe  

3fffff60:  feefeffe feefeffe feefeffe feefeffe  

3fffff70:  feefeffe feefeffe feefeffe feefeffe  

3fffff80:  3ffee993 feefeffe feefeffe feefeffe  

3fffff90:  feefeffe feefeffe feefeffe 3ffef674  

3fffffa0:  3fffdad0 00000000 3ffef634 40222b34  

3fffffb0:  feefeffe feefeffe 3ffe8678 40100679  

<<<stack<<<

Also by BME280 is also back to life: I don't understand why except leaving it alone for 24h. I tested it several time the day of the bug, twice leaving it disconnected for 2-3hours. So strange but a good news.

chschmitt commented 4 years ago

I'm also having issues with the BME280 after the update to NRZ-2020-129 (NodeMCU with SDS011, DHT22 and BME280). The update itself was successful and the board kept sending data. Afterwards it was disconnected from power for a few hours (and continued to work normally after powerup). Yesterday it was disconnected again and now I have the following situation:

Everything works until the first measurement
When the countdown is at zero, the board stops responding via HTTP (ping/arping is still possible)

By disconnecting the BME280's VIN or disabling it in the config before the first measurement, the board keeps running and responding.

dirkmueller commented 4 years ago

@chschmitt please open a new issue, this issue is about a crash on boot (looks like MDNS related).yours is likely an endless loop in "takeForcedMeasurement" (which doesn't check whether I2C read was successful and keeps waiting:

  // set to forced mode, i.e. "take next measurement"
  write8(BMX280_REGISTER_CONTROL, _measReg.get());
  // wait until measurement has been completed, otherwise we would read
  // the values from the last measurement
  while (read8(BMX280_REGISTER_STATUS) & 0x08)
    delay(1);
}

there is an abort condition missing here (especially when read8 is returning 0xFF which is "read error")

dirkmueller commented 4 years ago

@MagTun so thats great news (for reproducability!) I checked the documentation a bit more, and the initial output you saw is the bootloader. "~ld" means (all fine, "LoaDing" sketch). so this is good.

unfortunately, I am not able to trace down the crash location that you're getting and I don't have the debug symbols available of that build. is this still happening? can you flash a custom build and capture the crash trace from that one?

The only thing I can determine is that it happens either when calling WiFi.RSSI(), MDNS.begin() or when setting up the WebServer. the only thing that has some usercontrollable parameter is MDNS.begin() and the crash location seems to hint at somewhere inside MDNS.

unfortunately I don't seem to be able to get MDNS.begin() to crash, no matter which garbage I feed into it.

dirkmueller commented 4 years ago

the firmware is https://static.dmllr.de/airrohr/beta/builds-NRZ-2020-130-B2/ (please use the file firmware.bin):

esptool.py  --chip auto --port $port --baud 460800 write_flash -fm dio 0x00000 firmware.bin

if that one crashes as well on start, please paste serial output.

dirkmueller commented 4 years ago

Regarding BME280 coming back to life: the bme280 breakout pcb boards that I have seen are extremely susceptible to high humidity and sometimes even susceptible to light (UV). So a change in environment causes small amounts of condensation and corresponding malfunctioning. After a few hours in a controlled environment they usually recover. I have made good experiences with water proofing by using either paint or a spray. Make sure to cover the sensor breathing hole and surrounding area with a protection before doing this.

MagTun commented 4 years ago

Sorry for the late reply. I couldn't find how to use the esptool command. I went to C:\Users\Me\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.6.3\tools\esptool and open a cmd and then I run this command :

esptool.py --chip auto --port COM4 --baud 460800 write_flash -fm dio 0x00000 C:\Users\Me\Desktop\firmware.bin

But then there is just the help from esptool that is printed so instead I use the esp8266 download tool with this settings:

This is the serial monitor:

�R)�L�}D�`�airRohr: NRZ-2020-130-B2/DE
mounting FS...
failed to mount FS
output debug text to displays...
Connecting to Freifunk-disabled
........................................
output debug text to displays...
Starting WiFiManager
AP ID: airRohr-1518799
Password: 
scan for wifi networks...
AP Password is: 
Starting Webserver... (IP unset)

Then I connect to the webserver to set my wifi password but it's like the nodemcu doesn't remember it and it get the same print than above.

In the webserver, the firmware indicated is: NRZ-2020-130-B2 (Jan 10 2020 16:05:54)

Concerning the BME280, yes that could be the reason, although I have used nailed polish (not paint/spray) to protect it from the condensation.

ricki-z commented 4 years ago

@MagTun are you sure that you have an 2MByte NodeMCU. Normally these modules should have 4MByte (32MBit). In the debug output it looks like a problem with the partitioning (failed to mount FS). So the config can't be written. Anf please try to use the flashing tool mentioned in the build instructions.

dirkmueller commented 4 years ago

@ricki-z I asked earlier to flash the firmware I made for troubleshooting, that's why the flashtool hasn't been used (it doesn't have the ability to flash custom firmwares)

MagTun commented 4 years ago

I have already installed a functionning Luftadent firmware on this nodemcu so I don't think the probelm comes from my nodemcu.

I can retry with the esptool.py. Do you confirm that these are the right way to do it (when my nodemcu is on port COM4):

1) go to C:\Users\Me\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.6.3\tools\esptool and open a cmd from there 2) run this command : esptool.py --chip auto --port COM4 --baud 460800 write_flash -fm dio 0x00000 C:\Users\Me\Desktop\firmware.bin

dirkmueller commented 4 years ago

@MagTun looks very good to me, please try this

MagTun commented 4 years ago

Sorry for the delay, I tried again several times and I don't thing the command in my previous message is working. When I runnin I don't get any confirmation message, jut the help (the firmware is from https://static.dmllr.de/airrohr/beta/builds-NRZ-2020-130-B2/)

C:\Users\Me\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.6.3\tools\esptool>esptool.py --chip auto --port COM4 erase_flash
esptool.py v2.8
usage: esptool [-h] [--chip {auto,esp8266,esp32}] [--port PORT] [--baud BAUD]
               [--before {default_reset,no_reset,no_reset_no_sync}]
               [--after {hard_reset,soft_reset,no_reset}] [--no-stub]
               [--trace] [--override-vddsdio [{1.8V,1.9V,OFF}]]
               {load_ram,dump_mem,read_mem,write_mem,write_flash,run,image_info,make_image,elf2image,read_mac,chip_id,flash_id,read_flash_status,write_flash_status,read_flash,verify_flash,erase_flash,erase_region,version}
               ...

esptool.py v2.8 - ESP8266 ROM Bootloader Utility

positional arguments:
  {load_ram,dump_mem,read_mem,write_mem,write_flash,run,image_info,make_image,elf2image,read_mac,chip_id,flash_id,read_flash_status,write_flash_status,read_flash,verify_flash,erase_flash,erase_region,version}
                        Run esptool {command} -h for additional help
    load_ram            Download an image to RAM and execute
    dump_mem            Dump arbitrary memory to disk
    read_mem            Read arbitrary memory location
    write_mem           Read-modify-write to arbitrary memory location
    write_flash         Write a binary blob to flash
    run                 Run application code in flash
    image_info          Dump headers from an application image
    make_image          Create an application image from binary files
    elf2image           Create an application image from ELF file
    read_mac            Read MAC address from OTP ROM
    chip_id             Read Chip ID from OTP ROM
    flash_id            Read SPI flash manufacturer and device ID
    read_flash_status   Read SPI flash status register
    write_flash_status  Write SPI flash status register
    read_flash          Read SPI flash content
    verify_flash        Verify a binary blob against flash
    erase_flash         Perform Chip Erase on SPI flash
    erase_region        Erase a region of the flash
    version             Print esptool version

optional arguments:
  -h, --help            show this help message and exit
  --chip {auto,esp8266,esp32}, -c {auto,esp8266,esp32}
                        Target chip type
  --port PORT, -p PORT  Serial port device
  --baud BAUD, -b BAUD  Serial port baud rate used when flashing/reading
  --before {default_reset,no_reset,no_reset_no_sync}
                        What to do before connecting to the chip
  --after {hard_reset,soft_reset,no_reset}, -a {hard_reset,soft_reset,no_reset}
                        What to do after esptool.py is finished
  --no-stub             Disable launching the flasher stub, only talk to ROM
                        bootloader. Some features will not be available.
  --trace, -t           Enable trace-level output of esptool.py interactions.
  --override-vddsdio [{1.8V,1.9V,OFF}]
                        Override ESP32 VDDSDIO internal voltage regulator (use
                        with care)

Just to be sure I tried the esptool.py --chip auto --port COM4 erase_flash but my nodemcu is still running the (previous) luftdaten firmware.

I also install other bin files (from https://github.com/martin-ger/esp_wifi_repeater/tree/master/firmware) but with the esp download tool and then tried again the erase command but I am still getting the wifi repeater. So clearly, the esptool.py command doesn't work.

My only solution to download the .bin is to use the esp8266 download tool. After using the same config as the one in my printscreen from my message 6 days ago, I connect to the airRohr access point and set the password of my wifi. Here is the serial monitor:

mounting FS...
failed to mount FS
output debug text to displays...
Connecting to Freifunk-disabled
........................................
output debug text to displays...
Starting WiFiManager
AP ID: airRohr-1518799
Password: 
scan for wifi networks...
AP Password is: 
Starting Webserver... (IP unset)
ws: not found ...
ws: not found ...
ws: not found ...
ws: config page ...
begin webserver_config_body_get ...
ws: not found ...
ws: config page ...
begin webserver_config_body_get ...
ws: not found ...
ws: config page ...
begin webserver_config_body_get ...
ws: not found ...
ws: not found ...
ws: not found ...
ws: config page ...
output debug text to displays...
Saving config...
failed to open config file for writing
Restart.
H!��
�DH)�airRohr: NRZ-2020-130-B2/DE
mounting FS...
failed to mount FS
output debug text to displays...
Connecting to Freifunk-disabled
........................................
output debug text to displays...
Starting WiFiManager
AP ID: airRohr-1518799
Password: 
scan for wifi networks...
AP Password is: 
Starting Webserver... (IP unset)

Apparently there is an error when saving the configuration... And this is the explanation for why I keep seeing ariRohr AP in my wifi scanner. I don't think the configuration error is caused by my nodemcu because I am able to save the config for the wifi repeater (the bin I use above).

So maybe there is something wrong with the firmware from https://static.dmllr.de/airrohr/beta/builds-NRZ-2020-130-B2/

dirkmueller commented 4 years ago

so the command line does look correct. I assume that it can not open the port COM4 (or it is the wrong port identifier). note thaterase_flash is destructive, it will erase all data on the flash. for troubleshooting the connection to the esp8266, it is better to use a command that is harmless, like for example flash_id or chip_id.

are you sure that nothing else is accessing COM4 at that point in time? A serial monitor (like arduino ide or the like) will block esptool from accessing the port. also depending on the flavor of the esp8266, sometimes they require the physical "flash" button to be pressed on the board just before executing the command (for mine it works without).

I will add error handling to not reboot the node when saving of the configuration failed, but I think we better understand why it fails to save the configuration.. or mount the filesystem. Normally it should format the flash and create a new filesystem when mounting fails.

MagTun commented 4 years ago

1) The COM4 is the right one and it's not in use when I do the upload. I try as you recommended to push the Flash button just before executing the command but it's still not working. But I found a way to make it work: instead of using the esptool.py from Arduino15\packages\esp8266, I have install esptool.py via python (python -m pip install esptool) When I exectute this command then I can flash the firmware as expected: python -m esptool --chip auto --port COM4 --baud 460800 write_flash -fm dio 0x00000 C:\Users\Me\Desktop\luftdaten\firmware.bin

After that I connected to the AP, enter my wifi psw and press save/restart and then I open the serial monitor:

WiFi connected, IP is: 192.168.1.79
Starting Webserver... 192.168.1.79

ChipId: 1518799
Read SDS...: 
Stopping SDS011...
Read DHT...
Send to :
sensor.community
Madavi.de
----
Auto-Update active...
SNTP synced: Thu Jan 23 05:54:28 2020

twoStageOTAUpdate
Update md5: f6f8635ad2b0f0efe43f70a14a6ee3f9
Sketch md5: d76992f3767821fde14fe4bfba091757
Success downloading: /airrohr/update/latest_de.bin
Success downloading: /airrohr/update/latest_de.bin.md5
Success downloading: /airrohr/loader-002.bin

Apparently, everything works as expected.

But I see that it auto-updated when it first connected it, so I guess this isn't what you wanted me to test. So I erased everything and reflashed the firmware and disabled auto-update and here again everything works as expected. When I go to the Nodemcu IP, the Firmware is NRZ-2020-130-B2 (Jan 10 2020 16:05:54).

2) I just tried to use another sensor (let's call this one sensor B to not confuse it with the nodemcu I use so far for the testing). I didn't use Sensor B since December 31st 2019 so it yet didn't receive the january 8th update that started this thread. When I connected sensor B for the first time since december, I got the same problem: I can see it that it is connected to my wifi (http://192.168.1.1/wifi) but I can't connect to its IP (http://192.168.1.47/) and there are not data sent. This Nodemcu only has a PM detector and a screen, not dht22 or bme280.

Here is the serial monitor (baud 9600):

WiFi connected
IP address: 192.168.1.47
Setting time using SNTP
Thu Jan 23 13:19:50 2020

.Thu Jan 23 05:19:50 2020

NTP time  ... found
twoStageAutoUpdate
SDS version date : 18-11-12
SDS device ID: 3d22
Success downloading: /airrohr/update/latest_en.bin.md5
NewFW md5: 598a4c371edcc0dc83c92b03d9ebff8b
Sketch md5    : d8cd634f3d419ff7afecf559239e16da
SDS version date : 18-11-12
SDS device ID: 3d22

Then it nothing else happen. I waited more than 12min and still nothing happen. The SDS011 keeps spinning the whole time so I didn't want to wait to long. I haven't reset it (erase_flash) so we can use it for more debugging if needed. I disconnected the D3 pin and press the rst pin but it is still stuck on the update.

dirkmueller commented 4 years ago

Thanks for figuring this out. As you erase_flash the previous sensor A, we lost the config and sdk area and have basically no way to figure out the original crash problem anymore.

For sensor B, this reminds me of an older firmware bug we had. Did you happen to capture the early serial boot message which hopefully contains the firmware version?

It looks like it is still in process of downloading thr main firmware blob. During that window the web services are disabled for safety reasons to not disrupt the process.

Is this a 4mb flash esp8266

MagTun commented 4 years ago

Sensor B firmware version: Airrohr: NRZ-2019-125-B1 It's strange that it's still downloading after 12min, because the update on sensor A with the firmware from January 10th took a minute or so... Even stranger, I just tried and this time I got an Download failed! after about 2-3 minute (cf below). I restarted a second time (by pressing the rst button) and this time it is stuck on this for more than 10min with the sds011 running (well actually it's the fifth or sixth since this morning but let keep it simple):

Success downloading: /airrohr/update/latest_en.bin.md5
NewFW md5: 598a4c371edcc0dc83c92b03d9ebff8b
Sketch md5    : d8cd634f3d419ff7afecf559239e16da
SDS version date : 18-11-12
SDS device ID: 3d22

Both of my esp8266 are the esp8266 NodeMCU Lolin v3. I don't know about the flash size. I looked on some forum to find a way to do this but they all ask to install a script so I haven't done it to keep the sensor B with the buggy firmware.

Sorry for not pasting the whole serial debug. Here it is (from just now with the Download failed!, not from my previous message):

Airrohr: NRZ-2019-125-B1
mounting FS...
opened config file...
parsed json...
output debug text to displays...
6
Connecting to SFR_D7B0
..........
WiFi connected
IP address: 192.168.1.47
Setting time using SNTP
Thu Jan 23 23:56:02 2020

.Thu Jan 23 15:56:02 2020

NTP time  ... found
twoStageAutoUpdate
SDS version date : 18-11-12
SDS device ID: 3d22
Success downloading: /airrohr/update/latest_en.bin.md5
NewFW md5: 598a4c371edcc0dc83c92b03d9ebff8b
Sketch md5    : d8cd634f3d419ff7afecf559239e16da
SDS version date : 18-11-12
SDS device ID: 3d22
Download failed!
Starting Webserver... 192.168.1.47

ChipId: 1492507
Read SDS...
Stopping SDS011...
Send to :
luftdaten.info
Madavi.de
----
Auto-Update active...

opendata-stuttgart / sensors-software

Error: nodemcu connected but impossible to connect to IP/doesn't send data #619