-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add hotfixed DHT.h that disables interrupts on ESP32 #24
Conversation
TestAs a quick test I checked startup of the DHT22 20 times with waterelf32 code without commit 4d27eac having been applied, and 20 times with commit 4d27eac being applied. For the test I plugged in the DHT22, HR-SR04, TSL-2591, RF LINK TX, and DS18B20. ResultsSee table below for percentage of 20 times that DHT22 was detected in
ConclusionFor the ESP32 this change is necessary for the DHT22 to start up consistently (and perhaps at all). |
Great stuff! tiny point - if you kept the same library order in waterelf32 then wouldn't the change from <DHT.h> to "DHT.h" would be more obvious as a single line on the diff? |
Yes, I just sorted the includes out of habit - I'll change them back to make the changes more clear! I'll also add in some comments to explain the changes. With regards to adafruit/DHT-sensor-library#48 (comment), the problems in the thread seem to be centered around sensor inaccuracy. As #15 concerns detection it may be better to open a new issue to check that the DHT is reading accurately and have a seperate pr if necessary. |
- Custom DHT.h correctly disables interrupts on ESP32, allowing for conistent startup of sensor - Closes hamishcunningham#15
Seems to me most folks are having approx 5% occasional NaNs and read failures in the adafruit bug thread, detection is just starting the sensor and taking a reading of both humidity and temperature. |
100 non-NaN readings :)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
Closes #15
Thanks to @Eroc33 for pointing out that the issue was centered around the disabling of the esp32's interrupts!