Let's Control It

For years have used the SDS011 Dust-sensor in the 'official' Luftdaten-configuration, in combination with BME280/DHT22.
However, some months ago the setup broke-down, and no revival if reflashing & restarting.
Now question: which part is at fault?
'No reflash possible' seems to hint that the NMCU has 'gone':
that leaves SDS011 and BME280/DHT22 as elements for check & recycling.

Using ESPEasy MEGA_2020310 in various of my ESP8266s, I see Dust - SDS011/018/198 in the menu for devices.
In the forum also found a message_with_description for setup.

Simple question:
is that message_with_description the latest & greatest for a Dust-setup with SDS011?

Heating-modification
Would like to insert a 'twist' in the setup described:
for controlled heating the programmable PWM-output from the ESP8266 might be used instead of a relais.
Have applied such PWM-signal as feed for humidity-measurement, but not yet with heating:
any forum-member with experience on such heating-setup?

For heating using "PWM" I would look for a solid state relais. (SSR)
On the ESP side, it is just like a LED.
On the AC side (important to use AC as not all SSRs will work on DC) it is a triac with zero-crossing detection.
This zero-crossing is important as it will only turn on when the voltage is at (or very close to) 0 V.
This is also the reason why it will not work on DC and only on AC.

Since a heater is quite slow, I don't think you should use "PWM" at a frequency higher than 0.1 Hz.
So you could use the longpulse_ms command. In the latest builds there is another parameter to keep it looping until you change it.
This way you can define your own high low durations and thus create something similar to PWM.

About the parts which may be broken.
The DHT series are for sure a good candidate for replacement, but that's because they always are a good candidate for replacement.
Especially the DHT11 is utter garbage. The DHT22 is already infinitely better compared to the DHT11, but still garbage.

The SDS011 does have a laser internally.
Such a laser has a life time of roughly 8000 hours, which is about 1 year when running continuously.
For this reason, I added the option to configure the SDS011 to turn it off for like 5 minutes, take a sample and turn it off again.
In this example of 5 minutes sleep, 30 sec running can reduce the "running time" of the laser by a factor of 10.
It is a bit unlikely the fan will last 10 years, but the laser probably will


The NodeMCU... If you're running a really old version of ESPEasy, or some other firmware, it is possible the WiFi config was saved over and over again when the node reconnected to WiFi. Then the same sector on the flash has worn out.
You could try to flash a build for 2M flash on it to see if that will work. If so, then this sector was worn out.

It is also possible that whatever you used as a power supply now has broken down.
So you can try another power supply unit to test it. Do not (!!!) test the old adapter on good hardware. Worst case scenario, it will output spikes of much more than the rated 5V.

@TDer

Thanks for the elaborate response.

Low power PWM-heating based on idea that PWM can easily have variable duty-cycle:
if such PWM-signal controls a switching transistor, the rectified output is a DC-signal with variable level.
All solid-state and can be realised with 'left-over', antique components.

DHT-sensor indeed the weakest part of the sensor-chain:
in this setup only used for general temp-sensing in the top of the housing, not by NMCU anymore but by separate ESP8266, planned as secondary control for heating.
BME280 much better and in the main loop.

Driver-software for CH340Ser installed in Windows10, but airrohr-flasher 0.3.2 on PC reporting 'No boards found',
have to fear that something different than bad power supply. And your suggestion to load small file cannot be realised.
If not corrupted flash-memory of NMCU (or similar), probably to look more in direction of corrupt-driver-software in Windows,
but don't see how to check&correct that aspect.

To check other elements of the chain thinking about hooking SDS011 to ESPEasy on available ESP8266:
for alternative check that SDS011 still usable, and
therefore confirmation requested in previous message whether the described setup still uptodate, according to actual experience (such as your hint for 5min-interval.
Temporary setup with ESP8266 seems more economic apporach than ordering new NMCU and then perhaps detecting that also SDS011 'deceased/end-of-life';
and if that setup working, could be easy life-extension for SDS011+BME280 as secondary, local dust-sensor.
Anyway if NMCU 'deceased', then the identification at SensorCommunity has become invalid and useless.

One way to test whether it is something USB->UART related is to use a different USB cable and/or USB port on your PC.

Windows stores in the registry what driver to use for what USB device, also using the serial nr of the chip, which is kinda important to have it unique. Not all chips have unique serial nrs.
But it also uses the "path" or "route" to the device for this.
So if you put it into a different USB port, Windows may try to install a (new) driver for it.

Using a different cable may be useful when for whatever reason the one you're using doesn't make perfect contact (can also be caused by oxidation in the USB port on the NodeMCU).
Bad contact may cause a voltage drop when the current draw changes. This may cause the ESP to reboot or act undefined.

@TDer

'Loose connection' was in my mind as source for malfunction and hence have been fiddling with the connectors to 'correct' any corrosion on the NMCU-interface,
but indeed also further along the cable deterioration might have occurred.
Clean-up of driver-software in the PC also in mind as remedy for possible fault, but not sure how to 100% remove the present driver-software, for subsequent really clean reinstall:
I have some bad experience with just new install over the old install, with the new install being ignored, because subject software already present (but corrupt).

Plugging the same USB device in another USB port will install a driver on that port/USB-ID/serial combination.
Thus it leaves the installed driver for the old port/USB-ID/serial combination.

Your hint to the cable made me completely change the usb-cable.
Now checked OK that interface to NMCU still lives,
because in the PC-flasher a virtual COM-port pops up,
although report after 'Upload' is

Maybe holding down (and keep it pressed) the "flash" button (the one connected to GPIO-0) when plugging in the USB cable can help here?
Just keep it pressed until after you flashed the device, then power cycle it with the button no longer pressed.

With suggested procedure see the blue LED on the Lolin_V3_board flashing in some slow rythm, until it again reports the failure to connect.
SDS011 connected or not makes no difference.
Command 'Erase flash' gets same reaction.
Pressing RST sometimes helps, but in this case just a time-out with another failure report Conclusion: signs of some life on the interface and in the NMCU, but how to make good use of that, that is the question .....
Parking this project for later in december.

Without much hope, did a last test with 'naked' NMCU (= all sensors disconnected) and with 'undoubted' USB-cable:
NMCU loads firmware without problems.
Reconnected SDS011: no problem reloading the firmware .....
Reconnected BME280: loading problem
Conclusion: BME280 at fault

Should have done that 'naked' test as 1st defaulting step .......
In hindsight being fooled by the situation till last moment before breakdown, with BME280 100% OK.
And not expecting that NMCU would completely block when BME280 fails
[although should have remembered from experience with DHT22 how the firmware reacts to a faulty sensor].

Not only NMCU having memory-problems ......

Some corrosion on the BME board?
Or maybe the I2C bus hanging?

The BME280 is on purpose in the 'front chamber' of the setup, where it is fully exposed to incoming air, and upcoming corrosion ensured.
Have replacement-BME280 already in house (as well as SHT31):
therefore rather easy to check who is at fault: either BME280 itself, or I2C-interface.

Pity, but reanimation of Luftdaten-setup is least effort,
when comparing with rebuild with ESP8266/ESPEasy or build a LoranWAN-setup using SDS011&Marvin.

Older setup with LoraWAN_TTN probably is for TTN_v2 and needs update towards present TTN_v3:
somebody with a hint how_to_mod for TTN_v3?

Addition 15Dec2022:
BME280 was the culprit

TD-er wrote: ↑12 Dec 2022, 22:30
About the parts which may be broken.
The DHT series are for sure a good candidate for replacement, but that's because they always are a good candidate for replacement.
Especially the DHT11 is utter garbage. The DHT22 is already infinitely better compared to the DHT11, but still garbage.

So in your opinion, what are the better temperature and humidity sensors? The BME280 from China are not really the solution either, also give many problems.

The T&H-sensors of Sensirion type SHT3x are good choice (also considering trade-off performance vs. cost), and often used in the 'better' Meteo-systems.
SHT4x is the even better variant.
SHT3x can be purchased enclosed within protective capsule, which should enable them to survive longer, especially in outdoor environment:
as illustration shown below for SHT15, but comparable layout might be applicable for SHT3x
In outdoor application it is prudent to additionally install them in 'weather hut' like from TFA, Davis or Barani, to shield against direct rain and direct sun.
. .
In fact the demise of 'my' BME280 probably also caused because it was 'naked' to the outdoor environment although inside a housing.
In that perspective to be expected that within a few years the replacing BME280 will break down,
although now probably earlier end-of-life for the SDS011 (because in use since 2018).

Ton_vN wrote: ↑15 Dec 2022, 19:21 The T&H-sensors of Sensirion type SHT3x are good choice (also considering trade-off performance vs. cost), and often used in the 'better' Meteo-systems.
SHT4x is the even better variant.
SHT3x can be purchased enclosed within protective capsule, which should enable them to survive longer, especially in outdoor environment:
as illustration shown below for SHT15, but comparable layout might be applicable for SHT3x
In outdoor application it is prudent to additionally install them in 'weather hut' like from TFA, Davis or Barani, to shield against direct rain and direct sun.
.
SHT15_Cap [640x480].jpg
.
In fact the demise of 'my' BME280 probably also caused because it was 'naked' to the outdoor environment although inside a housing.
In that perspective to be expected that within a few years the replacing BME280 will break down,
although now probably earlier end-of-life for the SDS011 (because in use since 2018).

Thanks for the info Ton.