Need for calibrateReadDelay()

[RobTillaart]

During the investigations of issue #11 it became clear that the READ_DELAY of 2250 or 2000 datasheet is way higher than needed. It is a good default but power users might want to read the sensor more often. The library blocks this if the last read is less than READ_DELAY ago. This should stay for the normal usage.

For the power users a function uint16_t optimizeReadDelay() (name?) could find the optimal timing of an individual sensor and adjust READ_DELAY (including a safety margin of e.g. 100 ms of course). The adaptive delay example gives some ideas how to do this. The function should return the value found.

Also a resetReadDelay() should be available?

[RobTillaart]

interface thought

uint16_t setReadDelay(uint16_t rd)

• value of 0 means auto detect
• any other value means setting hard value
• returns readDelay value

uint16_t resetReadDelay()

• returns readDelay value set, depending on DHT11 / 22

[RobTillaart]

Tests discussed in #11 showed that DHT22 + ESP32 works with a readDelay interval as low as 400. However the same DHT22 + UNO needs more time.

For this issue it means that setting that interval (by user) is a valid enhancement. The interface will be reduced to simple get/set to minimize footprint.

TODO: example sketch that finds working minimum. void setReadDelay(uint16_t rd)

• value of 0 means datasheet values will be set with next read
• any other value means setting that value

uint16_t getReadDelay()

• returns readDelay value set

Note: A optimizeReadDelay() function can be added in the future.

[RobTillaart]

TODO: example sketch that finds working minimum.

Example sketch written, test with library 0.3.0 asap

[RobTillaart]

Fixed, get/setReadDelay added in version 0.3.0 An example sketch dhtnew_setReadDelay.ino is written to determine a near optimal readDelay.