Did not test it, just a quick look at the code and looks good to me.
A number of remarks:
One call I do not know and that is pullup() ? Is this ESP specific?
Missing example codes (incl the one that generated the data for your test)
You have all kind of functions that calculate e.g. dewpoint. imho these are not DHT related and could be used with another sensor(s) as well. From design point of view I would keep them as separate static functions OR integrate them in such a way that I do not need to provide the parameters. Just use the actual or last read() ones. Would reduce the size of code quite a bit.
Similar remark to have both C and F interfaces, The sensor is C so the user of the lib could convert it if needed. This results in semi-duplicate code.
I like the Comfort concept.
Did you keep the interface compatible with ADAfruit's one?
seems that pullup was ESP specific. I replaced it with a PULLUP macro depending on the Ardino version it either does pinMode(INPUT_PULLUP) or pinMode(INPUT);digitalWrite(HIGH);
-I have included an example sketch in the /example folder - unfortunately I do not have an arduino setup&hardware to compile & run it
-A very good point. For now, I have defaulted the parameters so if you call it with no params it will attempt to read() and work with the internal cache - the read() can be excluded with a compile switch
-Regarding F and C. There is now a way to either always output Celsius via compile swith which results in smallest code size, always output F slightly higher code size and also the option to decide on runtime via function params which is most flexible and also does not break compatibility with Adafruit's lib.
-Thanks, I have now separated things a bit and defined the comfort profile. In the end the user should be able to apply learned profiles etc.
-Yes the interface is compatible with Ada's there is a separate function for readH readT(with farenheit option via param)
Let me know if you decide to give it a spin:)
Best,
Andrei
You have all kind of functions that calculate e.g. dewpoint. imho these are not DHT related and could be used with another sensor(s) as well. From design point of view I would keep them as separate static functions OR integrate them in such a way that I do not need to provide the parameters. Just use the actual or last read() ones. Would reduce the size of code quite a bit.
Rob, I'll take your advice and begin working on a thermodynamics library with all sorts of algorithms that will use pressure, temp and rel. humidity.
for me the least restrictive license - creative commons I think, everyone can share but give credit and reference to source or so. Most algorithms are just a rewrite in C++ from Fortran.
Think the "core" codes should all work with Celsius as most sensors return Celsius temperatures.
Do you agree?
Yes just my thinking, I'll maybe add a #define to switch it all to Fahrenheit for convenience..
I'll also integrate the various comfort and comfort-profiles so the DHT lib will be less cluttered
