SDS011 sensor does not return data after a few days

eku commented 3 years ago

PROBLEM DESCRIPTION

I'm using a self compiled version of Tasmota (current HEAD), which includes only the sensors SDS011, DHT22, BMP280 and BH1750. After the cold start of Tasmota all sensors deliver values. After about 6 days the SDS011 does not deliver any data anymore. Only a powercycle brings the SDS011 back to life.

As hardware I use a Wemos D1 Mini, which is powered by a USB power supply. The SDS011 is directly connected to the 5V from the power supply.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

[ ] Read the Contributing Guide and Policy and the Code of Conduct
[x] Searched the problem in issues
[x] Searched the problem in the docs
[ ] Searched the problem in the forum
[ ] Searched the problem in the chat
[x] Device used (e.g., Sonoff Basic): Wemos D1 Mini
[ ] Tasmota binary firmware version number used: HEAD
- [ ] Pre-compiled
- [x] Self-compiled
- [x] IDE / Compiler used: Platform-IO
[ ] Flashing tools used: _____

[ ] Provide the output of command: Backlog Template; Module; GPIO 255:


Configuration output here:
17:31:16 MQT: stat/esp24/RESULT = {"NAME":"Wemos D1 Mini","GPIO":[1,1,320,1,1,1,0,0,1,1,1,1,1,1],"FLAG":0,"BASE":18}
17:31:17 MQT: stat/esp24/RESULT = {"Module":{"0":"Wemos D1 Mini"}}
17:31:17 MQT: stat/esp24/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"1728":"SDS0X1 Tx"},"GPIO2":{"320":"Led_i1"},"GPIO3":{"1760":"SDS0X1 Rx"},"GPIO4":{"640":"I2C SDA"},"GPIO5":{"608":"I2C SCL"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"0":"None"},"GPIO13":{"1216":"AM2301"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"},"GPIO17":{"0":"None"}}

- [ ] If using rules, provide the output of this command: `Backlog Rule1; Rule2; Rule3`:

Rules output here:

- [ ] Provide the output of this command: `Status 0`:

STATUS 0 output here: 17:32:27 MQT: stat/esp24/STATUS = {"Status":{"Module":0,"DeviceName":"esp24","FriendlyName":["esp24"],"Topic":"esp24","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}} 17:32:27 MQT: stat/esp24/STATUS1 = {"StatusPRM":{"Baudrate":9600,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota-DE.bin","RestartReason":"External System","Uptime":"7T01:27:28","StartupUTC":"2020-10-29T15:04:59","Sleep":200,"CfgHolder":4617,"BootCount":16,"BCResetTime":"2020-03-23T15:46:52","SaveCount":41,"SaveAddress":"3F7000"}} 17:32:27 MQT: stat/esp24/STATUS2 = {"StatusFWR":{"Version":"9.0.0.2(eku-sensor)","BuildDateTime":"2020.10.19 15:39:14","Boot":31,"Core":"2_7_43","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"418/699"}} 17:32:27 MQT: stat/esp24/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"MqttLog":0,"SysLog":1,"LogHost":"+++deleted","LogPort":514,"SSId":["+++deleted+++],"TelePeriod":300,"Resolution":"518180C0","SetOption":["00008009","2805C8000100060000005A00000000000000","00000000","00006000","00000000"]}} 17:32:27 MQT: stat/esp24/STATUS4 = {"StatusMEM":{"ProgramSize":417,"Free":2652,"Heap":26,"ProgramFlashSize":4096,"FlashSize":4096,"FlashChipId":"1640C8","FlashFrequency":40,"FlashMode":3,"Features":["00000407","00000484","04000001","00801482","00000000","00000000","00400000","00000000"],"Drivers":"1,2","Sensors":"2,6,9,10,20,76"}} 17:32:27 MQT: stat/esp24/STATUS5 = { +++deleted+++} 17:32:27 MQT: stat/esp24/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.22.1","MqttPort":1883,"MqttClientMask":"DVES%06X","MqttClient":"DVES_22B2EF","MqttUser":"DVES_USER","MqttCount":89,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30}} 17:32:27 MQT: stat/esp24/STATUS7 = {"StatusTIM":{"UTC":"2020-11-05T16:32:27","Local":"2020-11-05T17:32:27","StartDST":"2020-03-29T02:00:00","EndDST":"2020-10-25T03:00:00","Timezone":99}} 17:32:27 MQT: stat/esp24/STATUS10 = {"StatusSNS":{"Time":"2020-11-05T17:32:27","AM2301":{"Temperature":9.2,"Humidity":79.2,"DewPoint":5.8},"BMP280":{"Temperature":11.8,"Pressure":970,"SeaPressure":1034},"BH1750":{"Illuminance":0},"SDS0X1":{"PM2.5":6.8,"PM10":20.2},"PressureUnit":"hPa","TempUnit":"C"}} 17:32:27 MQT: stat/esp24/STATUS11 = {"StatusSTS":

- [ ] Provide the output of the Console log output when you experience your issue; if applicable:
  _(Please use_ `weblog 4` _for more debug information)_

Console output here:

17:37:03 MQT: tele/esp24/SENSOR = {"Time":"2020-11-05T17:37:03","AM2301":{"Temperature":9.1,"Humidity":79.9,"DewPoint":5.8},"BMP280":{"Temperature":11.7,"Pressure":971,"SeaPressure":1034},"BH1750":{"Illuminance":0},"SDS0X1":{"PM2.5":6.8,"PM10":20.2},"PressureUnit":"hPa","TempUnit":"C"}



### TO REPRODUCE
Just run the system for several days.

### EXPECTED BEHAVIOUR
Always receive data for the SDS011.

### SCREENSHOTS
none

### ADDITIONAL CONTEXT
none
![Bildschirmfoto vom 2020-11-06 16-10-20](https://user-images.githubusercontent.com/418685/98381757-9f775a00-204a-11eb-84f0-e432c7ce929b.png)
![Bildschirmfoto vom 2020-11-05 17-37-29](https://user-images.githubusercontent.com/418685/98269089-a12f1800-1f8d-11eb-84a3-58710222139c.png)

**(Please, remember to close the issue when the problem has been addressed)**

eku commented 3 years ago

Could it be that the cause is the same as with the "DHT gives only NULL", i.e. that the communication with the sensor is interrupted by an interrupt and afterwards the sensor is in a state from which it can only get out by power cycle?

curzon01 commented 3 years ago

(aah, another FHEM user :wink:) Can not confirm, I'm using SDS011 with same config (wemos d1 mini, 5V from USB) for months now without issue with v8.x (last using v8.4.0 since summer, no reboot). I've installed 9.1.0 since yesterday, will let you know if it stop working in a few days.

Anyway - to avoid side effects in such casses of self-compiled versions I always use an official version first for test - tasmota-sensors includes the SDS011. Try this first and check if it's also failing

eku commented 3 years ago

@curzon01 Yes, with a version of 8.x the sensor also worked for me without failure.

ascillato2 commented 3 years ago

@eku

Hi, any news on this? Were you able to perform the test proposed by @curzon01 ? Thanks.

eku commented 3 years ago

@ascillato2 Which test do you mean? The self-compiled version does not differ in the relevant functions from the pre-compiled firmware images. The only reasonable test in my opinion would be a downgrade to an 8.x version that did not have these problems. But would that help us with troubleshooting?

curzon01 commented 3 years ago

The question was the other way around: Does the issue also occur with your equipment with the pre-compiled release v9.1.0 (with exactly this version and not with any developer version 9.0.0.x, in your issue you used some dev commit v9.0.0.2)? my wemos now running with the pre-compiled release v9.1.0 from the link above since 2T23:17:42, data stable, no SDS011 outage

eku commented 3 years ago

@curzon01 I updated to 9.1.0.1 yesterday. I can't flash an official version because I use a different flash layout (4M vs 1M). Furthermore, the serial interface is not accessible. Flashing with different flash partitioning via OTA does not work.

Since the sensor data is missing after almost a week, your 2 days are no proof that the error does not still occur.

curzon01 commented 3 years ago

TO REPRODUCE

Just run the system for several days.

what do you mean for "several" when 3 days (2T23:17:42) are not enough? Do you observed a minimum (lets say 6 days or whatever)

[x] Device used (e.g., Sonoff Basic): Wemos D1 Mini

why needing another flash layout?

Unfortunately you can't test the official binary, this doesn't sound conformtable 'cause we may be looking for a issue based on your self-compiled version.

ascillato commented 3 years ago

In order to know if that is a problem with Tasmota or with your custom version, please, erase your flash and flash by serial the latest version of the precompiled bin. Thanks.

The 4MB version for memory map is not supported. The support is for the precompiled bins.

curzon01 commented 3 years ago

Interim status after 8 days 4h: stable as before using v8.4.0. I assume issue reason based on FW 4M layout, self-compiled settings and/or cabling.

I'm using a 3 m USB cable between Wemos and SDS, 4-wire (TX/RX/vcc/Gnd), cable-shield on GND too, SDS011 power supplied from D1 Wemos mini, same GPIOs (GPIO1=SDS0X1 Tx, GPIO3=SDS0X1 Rx)

eku commented 3 years ago

assume issue reason based on FW 4M layout, self-compiled settings

This is a thesis for which you have no proof. Why does everyone here think that compiling by yourself alone causes problems? According to that, the building process should be so fragile, which I just don't believe.

As I wrote above I had no problems with 8.x either, only with 9.x.

curzon01 commented 3 years ago

ok I'm out

ascillato2 commented 3 years ago

In order to know if that is a problem with Tasmota or with your custom version, please, erase your flash and flash by serial the latest version of the precompiled bin. Thanks.

The 4MB version for memory map is not supported. The support is for the precompiled bins.

eku commented 3 years ago

The default image does not contain any debug output in the SDS driver, so I am forced to enhance the driver with debug output and compile it myself. And here's the output when the sensor stops providing data after about 6 days.

15:11:48 SDS: Send AA B4 06 01 01 00 00 00 00 00 00 00 00 00 00 FF FF 06 AB
15:11:48 SDS: timeout
15:12:03 SDS: Send AA B4 04 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 02 AB
15:12:03 SDS: timeout
15:12:04 SDS: Send AA B4 08 01 00 00 00 00 00 00 00 00 00 00 00 FF FF 07 AB
15:12:04 SDS: timeout
15:12:04 SDS: Send AA B4 02 01 01 00 00 00 00 00 00 00 00 00 00 FF FF 02 AB
15:12:05 SDS: timeout
15:12:05 SDS: Send AA B4 04 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 02 AB
15:12:05 SDS: timeout

This clearly looks to me like the sensor is in a state where it does not respond to any commands. But this reminds me a lot of the behaviour with the DHT sensor and there was the reason that the communication with the sensor was disrupted by an interrupt.

strokovnjaka commented 3 years ago

Had the same issue. Sensor worked more than 30 days without a problem. Then it stopped any communication. Tried:

reboot, did not work
upgrade tasmota from 9.1 to 9.2, did not work
power cycle: now it works again Seems like a sensor issue.

eku commented 3 years ago

@ascillato2 @strokovnjaka I changed NOVA_SDS_RECDATA_TIMEOUT from 150 to 250. The result is promising. No problems with the sensor so far.

eku commented 3 years ago

@ascillato2

The 4MB version for memory map is not supported. The support is for the precompiled bins.

With respect, however, the statement is purely arbitrary. The file platformio_override_sample.ini contains a 4MB layout for the Wemos D1. See also e7c96fbb7897ffd8b11d7213e8793eabef91b0e5 Support for 2M and 4MB builds.

strokovnjaka commented 3 years ago

@eku Great, will try that. But I'm not sure how timeout would help in my case: I only had 2 breakdowns so far, first was after > 30days (on 9.1), second after the next 7 days (on 9.2), after that it works > 14days (on 9.2). As I mentioned, rebooting or upgrading did not work, powercycling did.

I should test if I powercycling just SDS011 would work. But, I cannot reproduce the breakdown.

strokovnjaka commented 3 years ago

Increasing timeout to 250ms does not seem to do the trick, as timeouts still happen and are recoverable.

14:50:13 SDS: Send AA B4 04 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 02 AB
14:50:14 SDS: timeout
14:50:14 SDS: communication problem, reinit
14:50:14 SDS: Send AA B4 08 01 00 00 00 00 00 00 00 00 00 00 00 FF FF 07 AB
14:50:14 SDS: timeout
14:50:14 SDS: Send AA B4 02 01 01 00 00 00 00 00 00 00 00 00 00 FF FF 02 AB
14:50:14 SDS: timeout
14:50:14 SDS: Send AA B4 06 01 00 00 00 00 00 00 00 00 00 00 00 FF FF 05 AB
14:50:15 SDS: timeout
14:50:45 SDS: Send AA B4 06 01 01 00 00 00 00 00 00 00 00 00 00 FF FF 06 AB
14:50:45 DMP: AA C5 06 01 01 00 6F 98 0F AB

eku commented 3 years ago

@strokovnjaka

Increasing timeout to 250ms does not seem to do the trick, as timeouts still happen and are recoverable. 14:50:14 SDS: communication problem, reinit

Did you add this logging to the driver code? For me, the sensor never recovers from timeouts.

strokovnjaka commented 3 years ago

@eku yes, added just below l.150 in tasmota/xsns_20_novasds.ino, where the same comment is. I did not change anything else besides 150ms -> 250ms timeout and added logging.

Timeouts happen quite frequently and are recoverable.

It seems to me that if timeout would be a problem then rebooting would help; it does not.

easyyu commented 1 year ago

Hi, I am a user of Tasmota with Nova Fitness SDS011 dust sensor for more than 2 years. From version v9.x I tried every major release at this moment latest (12.2.0) release, but without success. After approx 7 days the sensor stuck :( I always used the official releases. It is really frustrating that there is no fix for this, just a power off/on can solve this issue. If anyone knows some trick, I will appreciate it.

strokovnjaka commented 1 year ago

Mine gets stuck more in winter then in summer... I added a mosfet to power down the sensor when the count of retries for connect reaches some threshold (e.g. 20). Works like a charm.

easyyu commented 1 year ago

Thank you for your quick respond. Would you be so kind and share with us more details of your fix?

strokovnjaka commented 1 year ago

I bought a mosfet https://a.aliexpress.com/_mKMwyLI connected it to power the sensor (many recipes on the net).

Then I changed tasmota a bit to give 'sensor age' over mqtt (the age being number of unsuccesful connection tries). As I'm using HomeAssistant, I made an automation there to switch off the power supply to the sensor for cca half a second. The sensor is thus power cycled. The same can probably be done in tasmota itself.

easyyu commented 1 year ago

OK, I understood the idea. Thank you for sharing.

arendst / Tasmota

SDS011 sensor does not return data after a few days #9747

PROBLEM DESCRIPTION

REQUESTED INFORMATION

TO REPRODUCE