Thoughts about setting Humidity & Temperature to -999

[RobTillaart]

These thoughts are triggered by issue #11 (burst of failures with DHT22 + ESP32)

Current behavior In case of an error the T&H is set to -999. This value is artificial, out of physical range and chosen to trigger the user reading the sensor went wrong. This is double as the read() provides a return value indicating OK or ERROR.

Proposed behavior Alternative one should not setting this -999 value as the failed read might depending on the cause still have acceptable H&T value in some cases. Depending on return value:

• if OK -> set new values (default, as is)
• if CHECKSUM error -> set new values, as these might be right (user decides if they are acceptable)
• if BIT_SHIFT -> do a 1st order recovery by reversing the shift (user decides if they are acceptable)
• OTHER including SENSOR_NOT_READY -> keep previous values as there are no new values.

Keeping the previous values would give the same values during burst of failures as seen in #11 although a single good read in the burst would be an update of H&T.

A variant keeps previous values in case of any error. Simple, straightforward and less code.

Questions

• Must the library "protect" the users from not checking the return value?
• Should there be a keep last good read flag to suppress the -999 as value? [interesting]

Thoughts

• CHECKSUM errors are seldom seen.
• Reversing BIT_SHIFT errors is not proven, however seems to give acceptable (correct) values. [investigate] Reversing BIT_SHIFT errors will give more updates of H&T that are valid [assumption, to investigate] so it would could be a sort of (best effort ) damage control in the burst of failures seen in burst of failures in #11. Note that ~16% of errors in a burst is BIT_SHIFT so it could reduce the interval between failed readings quite a bit.
• The error value -999 can be replaced by another value that would disrupt graphs less, e.g. -100 would be out of specification and therefor still noticed by the user. The value could also be +125 as that might be even less disruptive. [investigate]

[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?

[RobTillaart]

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