Optimize sensor readings

[rpanfili]

Lots of checksum errors occur between readings. This is just an example:

[...]
found start char
found second char
Framelen OK
got 40 chars stream
Checksum failure
Sum: 970 - check: 48
[1] skip char 0x1A
[1] skip char 0x49
[1] skip char 0x7
[1] skip char 0x3D
[1] skip char 0x0
[1] skip char 0xF6
[1] skip char 0x0
[1] skip char 0xF
[1] skip char 0x0
[1] skip char 0x2
[1] skip char 0x0
[1] skip char 0x1
[1] skip char 0x0
[1] skip char 0x2
[1] skip char 0x0
[1] skip char 0xD2
[1] skip char 0x2
[1] skip char 0x25
[1] skip char 0x0
[1] skip char 0x0
[1] skip char 0x91
[1] skip char 0x0
[1] skip char 0x4
found start char
found second char
Framelen OK
got 40 chars stream

---------------------------------------
Concentration Units (standard)
PM 1.0: 36              PM 2.5: 48              PM 10: 52
[...]

We need to double check the parsing routine looking for an improvement!

[sirfalo]

Hi If you will need anything from me to test, or even give you like remote connection - we can manage :)

[rpanfili]

@sirfalo I updated the code on the master branch It will publish all the sensor readings with a more robust routine that will avoid checksum errors (aside very rare and legit cases!) Pay attention because, as documented in sensor reference sheet, it will flood looots of data (at lease one message every 2.3s). Using HomeAssistant it's a good idea to switch to a timeseries db (eg Influx) or tune your recorder to avoid SD wearing/too big database!

[sirfalo]

Hi

Thank you very much! I will test this, but first I need to follow your suggestions about Influx or recorder. Thing is that quick readouts will cause much bigger risk of SD card damage (power failuers). I will let you know :)

Thanks again!

[sirfalo]

Hi I had finally time to check it. WORKS! Without single checksum errors :)

Just, it works too fast! :) You are awesome :)

It sends entire string every 1s (even faster). Good I moved DB to Synology NAS so SD card will survive. Still, is this possible to add some delay? I'm not programmer (except something during studies of electronics, but it was long time ago), but this should be super easy to add :)

Maybe grab delay from config.json? Then everyone could define how fast those readouts will go.

[sirfalo]

Ok, fixed :) I asked my friend for help.

Now end loop is changed:

void loop()
{
  ArduinoOTA.handle();

  if (!mqtt_client.connected())
  {
    reconnect();
  }
  mqtt_client.loop();

  if (has_pms_data(&pms_serial))
  {
    print_pms_data(pms_data);
      if(i < 30){
        i++;
      }else{
        publish_data(pms_data);
        i = 0;
      }
  }
}

I can confirm that MQTT recieves result after 30 loops. Ofc, if bigger delay is needed then just increase loop :)

[rpanfili]

Fine! That's good and with your example you are able to avoid data flooding! In my personal opinion a better solution would be limit messages with an internal timer (from last data sent) so you can specify "at most one message every X seconds" and if sensor reading rate changes you will get a more consistent timeframe. You can even buffer your last reading and send it when timer is out if that reading is not too stale but in this context, if everything is running correctly, is a bit over engineered solution :)

Closing this issue! Thank you for your testing!