Thoughts about setting Humidity & Temperature to -999

[robtillaart]

Thoughts about setting Humidity & Temperature to -999

[RobTillaart]

You need to set it just before the #include statement.

[Mr-HaleYa]

Ds18b20 uses -127 as an error reading. I don't think you should worry about making the number pleasing for graphs, if a user doesn't want it on their graph they can set a filter very easily to not add it.

What are some numbers for the error occurrences?
how many bit_shifts happen in a row on average and how many checksome errors happen in a row on average?

Potential question to investigate
There are other libraries for dht22 sensors. Specifically one in mind is the adafruit library. What do they do that is different that does not cause these errors? Do they use a user protection as you are suggesting or do they have some other measure and place that corrects the errors?

Thoughts
Since you say check sums don't happen often I I would ignore those and instead since bit shifts are more common I think there should be a flag that is called attempt bit shift correction and when set to true it will attempt to correct bit shift errors. It should not give the okay output though instead it should give an output like bitshift corrected

[RobTillaart]

-127 had crossed my mind but one only needs to be distinct, out of range.

CHECKSUM error - seldom, maybe 10 in all those years I use the sensor.
TIMEOUT error - seldom seen, only in breadboards when appropriate pull ups were missing.
SENSOR_NOT_READY error, only defined recently in tests, so no long term data. So far only seen in conjunction with ESP32 in the test case you brought up.
BIT_SHIFT error, only defined recently, so no long term data. Approx 6 x less often than SENSOR_NOT_READY, but most of the time together with SENSOR_NOT_READY.

The latter two are under investigation in #11
Unless the root cause is found I will not fix it or provide a workaround.

What do they do that is different that does not cause these errors?
Have you verified that these libraries do not have the same error after 10 hrs and 12:25 hrs?

I know different libraries handle the low level bit reading / timing differently.
I will look at how Adafruit handles the wake up part as there seems to be the problem.

A flag to attempt bitshift correction sounds like a good idea.

[RobTillaart]

Errors (bitshift, timeout, CRC, not ready - do not occur after the 3.0 release, so no more effort will be put in them.

Should there be a keep last good read flag to suppress the -999 as value? [interesting]

This is stil interesting, as the errors are in the return value of read(). There are multiple options:

• never use -999 again as users should check the return value of read()
  breaking change in behavior (but no one might notice)
• set a flag suppressErrorValues(), in case of an error temperature and humidity will not change, keep their last valid value.
• calculate the new T and H and if they differ less than 1.0 from the existing value use them.
  Threshold of 1.0 is arbitrary so people want to set it (complexity). Furthermore around zero it can be crucial, freezing or not.

The second option is the most explicit in its behavior so I'm gonna explore it.

[Mr-HaleYa]

@RobTillaart
This is great 👍 I was wanting a way of changing the default error value to something a little less Ummm visually damaging to my graphs lol.
I was just doing if(lastRead=-999) lastRead=-1; but now i just have to set #define DHTLIB_INVALID_VALUE -1 at the top section of my sketch right?