replace internal storage float with int

[RobTillaart]

To save some RAM the internal storage in the class can be optimized: int for T & H byte for offset (assuming it is never more than +- 12.7 which is quite a bit.

flloat math will move from the read() function to the getTemp() function. So expect that to be about equal.

[RobTillaart]

Added value is too small

[ilikegitlab]

i would love a full integer version of the lib. Why on earth would one waste so a single byte too much for a horribly inaccurate sensor. Just ask the user of the lib to divide by 10.

There are some alternative libs, but none as feature rich as this one.

[RobTillaart]

Thanks for this question. I understand that a full integer version would same RAM and more importantly it would not need (to include) the floating point library.

Leaving the divide by 10 to the user is one strategy, the other is doing it in the library and

• round T and H to appropriate integers
• return Integer and decimal part separately
• or let user divide.

For sake if usability rounding in the lib seems to fit the integer approach best if one wants to keep the interface as much the same as possible..

Two strategies, a derived class or a stand alone class.with its own repo.

@ilikegitlab How would you name the new integer class?

[RobTillaart]

@ilikegitlab Created a new library - under development - https://github.com/RobTillaart/DHTINT

Build of the examples looks good, so please verify if this works for you.

[RobTillaart]

If problems arise, please open an issue under - https://github.com/RobTillaart/DHTINT

[ilikegitlab]

@RobTillaart thanks! That was fast. I would indeed have called it exactly that!

I wonder though: is it not tedious to maintain a completely different branch for this? I would probably have made DHTnew use ints internally and #ifdeffed float/int as an option. But its your call! and it perfect for my current project.

[RobTillaart]

The library is experimental and it might merge in the future sometime. As I maintain ~150 libraries one more or less isn't such a big deal, especially because DHTNEW is pretty stable.

Using #ifdef is also an option but I prefer a separate class above (user configured) conditional code as it is more explicit for beginners why the behavior / accuracy changes.

Furthermore this allowed me to use an explicit example to see the difference in footprint, if the example still would do

Serial.println(dht.teperature(), 2);

even if the function would return an int the floating point library would still be #included.

Offset

There is one point that caught my attention and which is not resolved in the code. I would still like to set an offset in tenth of degrees (by multiplying by 10 perhaps) to be able to calibrate more accurately. That would also imply that the values, the offset and div 10 should be done later as now. Now I have whole degrees as offset, it won't affect rounding, but I think it is possible to do better. Think I should open an issue for that .

[RobTillaart]

done - https://github.com/RobTillaart/DHTINT/issues/2