Closed RobTillaart closed 4 years ago
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
-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.
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:
The second option is the most explicit in its behavior so I'm gonna explore it.
@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?
You need to set it just before the #include statement.
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:
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
Thoughts