DallasTemperature implementation as a separate class/library

[mairas]

This goes solidly into the wishlist territory: you currently have a DallasTemperature implementation using the new OneWireNg interface as an example. It would be great to have it as a proper class or a library of its own instead of having to go through the wrapper.

I'd rather use your implementation directly because your example implementation already supports more devices (DS28EA00, in particular) and your code in general already has better documentation and comments (and appears to be supported, whereas the PaulStoffregen one has a number of important open PRs dating back already several years).

This is of course something I could easily do myself but I only have DS18B20s at my disposal, so testing during the development would be problematic. :-)

[pstolarz]

The question is what exactly do you mean by this new lib. Writing a new DallasTemperature lib with similar functionality just to work with OneWireNg and supporting few more sensors is a waste effort in my opinion. It's just better to provide the upstream lib with proper PRs or provide own fork in case of more earth-breaking changes.

But since you are a subsequent person asking me about such service maybe it'd be good to provide more reusable and user oriented class with simple yet not primitive Dallas thermometers service API. I'll consider this. Let me know what type of functionality would you like to have via such service (I'd like to confine the functionality to bare minimum but allowing to reach for the full power of the Dallas therms if required, so I'm considering more "plumbing" rather than "porcelain" methods in therms of git-nomenclature).

This is of course something I could easily do myself but I only have DS18B20s at my disposal, so testing during the development would be problematic. :-)

Maybe I'd surprise you but so do I ;) That's why I stated I'm inviting all developers, eager to help me with porting and testing the library for new platforms in the README. More people eager to help and test, more stable and mature code at the end.

[pstolarz]

@mairas I've prepared Dallas thermometers driver intended as a general purpose service for everyone who wants to use OneWireNg lib w/o reaching for DallasTemperature with OneWire wrapper substitution.
Some notes:

• Current implementation is on branch DSTherm. This new feature is planned with the next OneWireNg version 0.8.
• Driver interface is provided by DSTherm class. API documented directly in the sources.
• Good staring point is DallasTemperature.ino sketch which was accordingly rewritten to use the new service.
• The driver was thoroughly tested on my setups + I wrote some unit tests for most crucial parts of code like temperature conversion.
• Final version occured more advanced and feature rich than I preliminary planned, but I believe it didn't get complicated too much. Basically the API directly reflects DS therms command like "Convert Temp" or "Read Scratchpad" and everyone familiar with these types of sensors should get familiar with the API very quickly.

Feel free to test the new service on your setups and share your opinion/comments.

[everslick]

Sorry for asking such a mundane question... If I switch from OneWire + DallasTemerature to OneWire + DSTherm on ArduinoESP32. Will my flash usage go up or down? (in your humble opinion)?

best regards & thanks for your work. from browsing the repository your code looks really clean and consistent! kudos

[pstolarz]

The footprint will be lower, for sure. How much? It all depends how you configure the library. For example for AVR's ATtiny 1614 platform, the DallasTemperature.ino example (which uses DSThrem driver under the hood) configured with similar functionality as OneWire lib (search filtering disabled, CRC tables located in flash) has similar footprint as pure OneWire's DS18x20_Temperature.ino example (not saying additional footprint provided by DallasTemperature library):

ATtiny 1614/OneWireNg with DallasTemperature.ino example

Sketch uses 4126 bytes (25%) of program storage space. Maximum is 16384 bytes.
Global variables use 186 bytes (9%) of dynamic memory, leaving 1862 bytes for local variables. Maximum is 2048 bytes.

ATtiny 1614/OneWire with DS18x20_Temperature.ino example

Sketch uses 5273 bytes (32%) of program storage space. Maximum is 16384 bytes.
Global variables use 173 bytes (8%) of dynamic memory, leaving 1875 bytes for local variables. Maximum is 2048 bytes.

[everslick]

thank you very much. so I will give it a run and report my findings! ;-)

[uzi18]

@everslick in fact on ESP32 this aspect is not a big deal.

[everslick]

@uzi18 I guess you meant to tag me, and you're referring to the flash footprint. In my case it IS a big deal, because I have 1000 devices in the field I cannot re-partition and they have 2KB flash left free. ;-)

[pstolarz]

To reduce flash usage try with these settings in OneWireNg_Config.h:

• CONFIG_MAX_SRCH_FILTERS set to 0 (search filtering disabled),
• CONFIG_FLASH_CRC_TAB disabled (CRC tab in RAM; default setting)
• If you use only single sensor on a bus you may disable 1-wire search activity by commenting out CONFIG_SEARCH_ENABLED. This is a configuration I added recently (not yet released).