SDS011 seems to only generate one reading and then returns 0 for all following readings about esp32-paxcounter HOT 18 CLOSED

The sds011 code was from @AugustQu as i remember, maybe he is still reading here?

from esp32-paxcounter.

Try setting sleep cycle off by setting sleep cycle to 0 in paxcounter.conf. Remember to clear NVRAM before reflashing, otherwise old value will persist. Alternatively, set sleep cycle by rcommand, this takes place immeditaley.

SDS011 needs ~30 seconds warm up time. You must adapt your run/sleep cycle accordingly, by adjusting values for send cycle (time when values are sent), sleep cycle (time while module and SDS011 will sleep) and home cycle (frequency which with values are read from SDS011).

A good starting point to check is SDS011 is working is to switch off sleep mode, as suggested above.

from esp32-paxcounter.

Thanks, I'll give that a go shortly.

Out of interest, is there any documentation on setting up your own OTA server?

I see references to PaxExpress in a few places, and I know that OTA is supported, but the TLS cert for pax.express expired 255 days ago and I'm not sure if Pax.express actually provides OTA or whether it just displays the data?

It would be a lot easier for me to be able to update these devices via OTA rather than serial!

from esp32-paxcounter.

I don't maintain PaxExpress, thus can't answer questions related to this.

The original OTA function was based on Jfrog Bintray, but Jfrog cancelled Bintray as SaaS. PaxExpress took over this role for paxcounter boards, what means it provides an OTA update server which is compatible to Bintray and works with paxcounter code.

from esp32-paxcounter.

Ok, thanks, I'll look into that.

I tried setting sleep to 0 and clearing the NVRAM but I'm still getting the same results so I'll keep playing with the settings and see what I can gt back from them.

The first reading on boot is always reliable though, so at least I know 99.99% of my device is now working as it should!

from esp32-paxcounter.

please give me one day or two, I will look for it.

from esp32-paxcounter.

Amazing, thank you.

Let me know if I can provide any further data to help.

from esp32-paxcounter.

I checked this today, and found a working configuration with these settings:

Board LILYGO® Paxcounter LoRa V2.1_1.6.1

// SDS011 dust sensor settings
#define HAS_SDS011 1 // use SDS011
// used pins on the ESP-side:
#define SDS_TX (12)     // connect to RX on the SDS011
#define SDS_RX (14)     // connect to TX on the SDS011

Note: Disable SD-Card when using GPIO 12/14 for SDS!

Keeping the default settings in paxcounter.conf:

// Payload send cycle and encoding
#define SENDCYCLE                       30      // payload send cycle [seconds/2], 0 .. 255
#define SLEEPCYCLE                      0       // sleep time after a send cycle [seconds/10], 0 .. 65535; 0 means no sleep [default = 0]
#define PAYLOAD_ENCODER                 2       // payload encoder: 1=Plain, 2=Packed, 3=Cayenne LPP dynamic, 4=Cayenne LPP packed
#define COUNTERMODE                     0       // 0=cyclic, 1=cumulative, 2=cyclic confirmed
#define SYNCWAKEUP                      300     // shifts sleep wakeup to top-of-hour, when +/- X seconds off [0=off]
...
#define HOMECYCLE                       30      // house keeping cycle in seconds [default = 30 secs]

This setup results to PM10/PM25 values sent every minute, while SDS011 is falling asleep between two send cycles:

12:23:25.505 > I (224018) src/sds011read.cpp: SDS011: pm25: 1.20, pm10: 4.00
12:23:25.505 > D (224018) src/sds011read.cpp: SDS011: go to sleep

from esp32-paxcounter.

Your cycle configuration is as follows:

• board is taking SDS011 probe every 30 seconds (HOMECYCLE)
• After 5 minutes (SENDCYCLE) the value oft last probe is sent
• Board then sleeps for 100 secs (SLEEPCYCLE)
  It does what you've configured. Not a software issue. Yes, the documentation on SDS is missing / bad.

from esp32-paxcounter.

OK, thanks, so if I wanted to take a measurement every 5 minutes and then go back to sleep in order to save battery, then would the following make sense?

// Payload send cycle and encoding
#define SENDCYCLE                       30      // payload send cycle [seconds/2], 0 .. 255
#define SLEEPCYCLE                      30       // sleep time after a send cycle [seconds/10], 0 .. 65535; 0 means no sleep [default = 0]
#define PAYLOAD_ENCODER                 2       // payload encoder: 1=Plain, 2=Packed, 3=Cayenne LPP dynamic, 4=Cayenne LPP packed
#define COUNTERMODE                     0       // 0=cyclic, 1=cumulative, 2=cyclic confirmed
#define SYNCWAKEUP                      300     // shifts sleep wakeup to top-of-hour, when +/- X seconds off [0=off]
...
#define HOMECYCLE                       30      // house keeping cycle in seconds [default = 30 secs]

If I've understood you properly, then it would read the sensor every 30 seconds whilst it's awake, send the message after 60 seconds (30 = 60/2), and then sleep for 5 minutes (30 = 300/10)?

Apologies if this is a basic misunderstanding on my part - I'm happy to try and update the docs once I've got my head around this!

from esp32-paxcounter.

sorry. I didn't look into this project for about 3 years so I had to make PIO working again. Then I had to copy the code and start the project. So I still have no working copy here. I'm working on this.

from esp32-paxcounter.

if I remember it correctly:

please check the file SDS011.cpp. It contains a piece of code like this one:
void SDS011::wakeup() {
sds_data->write(0x01);
sds_data->flush();
}

This code works for some devices but not for all (it's too tricky).

So please check your code and let me know.

from esp32-paxcounter.

Thanks @AugustQu I'll do that shortly

from esp32-paxcounter.

@AugustQu - apologies for the delay in replying.

That file does not exist in the version I am currently running (git latest), I only have https://github.com/cyberman54/ESP32-Paxcounter/blob/master/src/sds011read.cpp and the code you mention is not in there.

from esp32-paxcounter.

If it helps, this is the serial output:

16:14:55.132 > I (11419) src/lorawan.cpp: LORA send queue created, size 530 Bytes
16:14:55.145 > I (11441) src/lorawan.cpp: Starting LMIC...
16:14:55.145 > I (11442) src/main.cpp: init fine-dust-sensor
16:14:56.162 > I (11957) src/sds011read.cpp: SDS011: Firmware version [year.month.day]: 18.11.16
16:14:56.664 > I (12958) src/main.cpp: Starting Interrupt Handler...
16:14:56.664 > I (12959) src/main.cpp: Starting Timers...
16:14:56.698 > I (12990) src/timekeeper.cpp: Starting time pulse...
16:14:56.698 > I (12990) src/timekeeper.cpp: Timepulse: internal (ESP32 hardware timer)
16:14:57.695 > I (13991) src/main.cpp: Features: DISP LED BATT LORA SDS PACKED TIME
16:14:57.724 > I (14019) src/timesync.cpp: [14.030] Timeserver sync request started, seqNo#47
16:15:02.772 > I (19061) src/lorawan.cpp: DEVaddr: 0x260B1639 | Network ID: 0x000013 | Network Type: 0
16:15:02.772 > I (19062) src/lorawan.cpp: RSSI: 0 | SNR: 7
16:15:02.779 > I (19063) src/lorawan.cpp: Radio parameters: SF7 | BW125 | CR 4/5
16:15:10.051 > I (26336) src/timekeeper.cpp: [26.347] UTC time: 1711728910.000 sec
16:15:10.051 > I (26338) src/lorawan.cpp: 1 byte(s) sent to LORA
16:15:27.738 > I (44022) src/sds011read.cpp: SDS011 Reading
16:15:28.242 > I (44525) src/sds011read.cpp: SDS011: pm25: 141.10, pm10: 1999.90
16:15:54.153 > I (70434) src/lorawan.cpp: 8 byte(s) sent to LORA
16:16:27.738 > I (104022) src/sds011read.cpp: SDS011 Reading
16:16:28.241 > I (104523) src/sds011read.cpp: SDS011: pm25: 0.00, pm10: 0.00
16:16:54.157 > I (130434) src/lorawan.cpp: 8 byte(s) sent to LORA
16:17:27.754 > I (164022) src/sds011read.cpp: SDS011 Reading
16:17:28.257 > I (164523) src/sds011read.cpp: SDS011: pm25: 0.00, pm10: 0.00
16:17:54.174 > I (190434) src/lorawan.cpp: 8 byte(s) sent to LORA
16:18:27.750 > I (224021) src/sds011read.cpp: SDS011 Reading
16:18:28.253 > I (224522) src/sds011read.cpp: SDS011: pm25: 0.00, pm10: 0.00
16:18:54.161 > I (250433) src/lorawan.cpp: 8 byte(s) sent to LORA
16:19:27.751 > I (284022) src/sds011read.cpp: SDS011 Reading
16:19:28.254 > I (284523) src/sds011read.cpp: SDS011: pm25: 0.00, pm10: 0.00

from esp32-paxcounter.

For anyone else who comes across this, the answer is to replace your SDS011 sensor with a new one.

Doing this solved all these probloems.

Best way to confirm that your SDS011 is working is to plug it in to a USB port with the provided adaptor (I'd lost mine so couldn't do this originally!) and then run something like https://github.com/vvidovic/aqi on your laptop to check the values.

A working sensor will return values every few seconds, a broken sensor will not.

from esp32-paxcounter.

Thanks for your note. To me this looks like a firmware issue on SDS011, not a damaged SDS011. Can you read the firmware version and post here? Thanks.

If connected to paxcounter, the SDS011 firmware version is shown in debug log during initialization.

Edit: it's 18.11.16, you showed this in your log above already.

Please check and compare version on your new sensor. Thanks.

from esp32-paxcounter.

Thanks for your note. To me this looks like a firmware issue on SDS011, not a damaged SDS011. Can you read the firmware version and post here? Thanks.

If connected to paxcounter, the SDS011 firmware version is shown in debug log during initialization.

Edit: it's 18.11.16, you showed this in your log above already.

Please check and compare version on your new sensor. Thanks.

New version is running firmware from 2023:

08:04:22.032 > I (11887) src/sds011read.cpp: SDS011: Firmware version [year.month.day]: 23.6.26

I've had a search but can't see a way to update the firmware on the sensors. If that is indeed the issue, then that would mean I can reuse the existing sensors that I have, although the "old" sensors don't work with the python code I posted above whereas the new one does.

from esp32-paxcounter.