Closed budulinek closed 3 years ago
Looks good and useful, Can you add the example (2) in the lib/examples folder ? e.g dhtnew_waitForRead_2.ino
Sure, here is an example, put together from your existing examples.
Corrected. I am still relatively new to github...
As you can see, I have also tried to fix dhtnew_setReadDelay.ino
Now the calculation of readDelay works. I think that it is an interesting idea. What about adding calculateReadDelay() function to the library, as a complement to setReadDelay() ??
Corrected. I am still relatively new to github...
Definitely not bad at all, in fact looks good to me, thanks for the updates.
I will check the code tomorrow again as now it is quite late. Tomorrow I have a pair of fresh eyes :)
BTW, dhtnew_setReadDelay.ino calculated readDelay 434 ms for my DHT22. Quite interesting, if you compare it to default 2000 ms.
OK, good night.
At the moment, read() function returns DHTLIB_OK, without distinguishing between two situations:
1) Read successful 2) Waiting for read. Type is known from some previous readings (or from setType() function), but we actually do not know whether the sensor is connected or not.
Example:
Gives me the following output with sensor not connected:
setWaitForReading(true) is not an option, I need non-blocking sketch.
I propose a simple solution: differentiate between DHTLIB_OK and DHTLIB_WAITING_FOR_READ
It will also allow us to implement non-blocking wait for read, for example: