Thank you very much. Yes, the code is pretty different, but full of gems! I’m working on adapting it now. Thanks again.
Thank you so much for the great work here. I have struggled with the onewire lib for years. Add one more verification this fix works 100% on the Photon. Using 2 probes my error rates dropped from ~10% to 0.
Okay, well-meaning idiot here. 
How do I update the OneWire library with the code earlier in this thread? I see it’s called by the DS18B20 library, but that library is called directly from Particle resources and is not in my firmware code. I’m using the Web IDE.
Any pointers in the right direction greatly appreciated.
Thanks!
Since 2.0.3 is the latest OneWire version in the cloud the DS18B20 library can't really pull a newer version in. I'd reupload the DS18B20 lib if there was a newer public OneWire version.
Having said that, you can add new files to a Web IDE project via the (+) icon top right.
Then name the added files according to the library files you'd need to modify and copy paste the library codes into the respective file tabs.
It's not comfortable but at least that way you can tweak the libraries to your needs.
@bsatrom, can the above fix be included in the official OneWire library and a new version made public?
BTW, the GitHub link is missing in 2.0.3 - having that available would make it easier to file issues and PRs on the library 
Please also enable the Issues tab on the repo (as already mentioned half a year ago)
IMHO, official libraries should set an example in best practices on the meta-data side too
2 Likes
Thanks for flagging @ScruffR, I’ll get the library fixed this week. In the meantime, I’ve just enabled Issues for the repo.
1 Like
Thanks, @ScruffR. That did it.
I “removed” the integrated DS18B20 library from my build in the IDE, and text copied and pasted the .h and .cpp files for DS18B20, OneWire, and DS18 as new library file tabs.
As others have noted, my DS18B20 temp sensors now seem super-robust and reliable in their readings.
Thanks also to all above (@Jonpcar and others) who took the time and effort to figure this thing out and make things a bit better for all of us.
My electron would have good readings when using AUTOMATIC mode. However, when doing SEMI_AUTOMATIC it wouldn’t be reliable, after following the instructions on this post to modify the code it’s now running great in whatever mode I run it.
Thanks a lot for that, you saved a bunch of people’s headaches!
1 Like
Hey folks, just wanted to let you all know that the OneWire library has been updated with this fix, and published: https://build.particle.io/libs/OneWire/2.0.4/tab/DS18.cpp.
Thanks @ScruffR for the callout and @Jonpcar for the original fix!
5 Likes
@bsatrom…thanks for the update to the library! I’ve been travelling and have only recently started working on my pool project again, which was the impetus for debugging this particular OneWire problem last year.
I have to say…my cheap (5 for $17) OneWire DS18B20 devices have worked like a dream since that point. I have all connected to one Photon pin and take samples from all five each second (and if my memory is correct requires less than 10ms of overhead to start & read all those conversions)…its overkill but what the heck. And they are very, very accurate…at first I had a multiple sampling routine in place to average multiple conversions before using the values…it was NOT needed.
For others thinking of using the DS18B20 devices, if there are any kinds of performance concerns for your app, I would highly recommend NOT using the library read functions for these sensors. The library read functions rely on a Delay() function that essentially requires almost one second of dedicated processor waiting for each device to complete its calculation (for 10 bit precision). In my case it would have taken almost five seconds to read all 5 sensors with nothing else getting done in the meantime. Also, I remember that at least one of the libraries had a bug in its routine to change the precision of the temperature calculations. It’s been awhile since I worked on this.
So…although this particular library change fixes one issue with using the OneWire bus for DS18B20 devices, there are still some things to watch out for.
1 Like
I may have missed something in the conversation, but do you have a proposed alternative to the use of delay() in the library? With the default 12 bit precision the specs from Maxim state a 750ms conversion time is needed. The conversion time goes down as you lower the precision, but the library currently does not offer the ability to change precision.
Hey Picsil, those are the same limitations I recall when I looked at using one of the DS18B20 libraries and therefore didn’t. Someone smarter than me could probably make the library change necessary to get rid of those limitations (especially adding a change resolution command which should be simple)
Instead my usage model includes only the OneWire.h file and not the DS18B20 library. I created the three functions I needed for DS18B20 operation directly in my code, and they are pretty simple: (1) set the resolution for ALL devices on a particular OneWire bus (2) start a temperature conversion for ALL devices on a particular OneWire bus (3) read the temp conversion from a PARTICULAR device
But the code (1) that starts a temperature conversion does NOT wait (DELAY) for it to finish…it allows execution to continues through the main code loop. Next time through the loop, code uses the standard method to “check if the conversions are finished” before doing the reads of the conversion results from the individual DS18B20s:
if (currentMillis - prior_DS18B20_conversion_start) >= DS18B20_CONVERSION_TIME) { do the device reads here
}
In summary, the code I use starts all five 12-bit temperature conversions simultaneous/in-parallel which take 750ms. About a second later, the temperatures are read from the DS18B20s. So the end result is five 12-bit temperature conversions every second (from my 5 probes) which require about 10ms total overhead (this number is from ?memory? when I did some rough calculations…it is primarily because of the serial bit reads/writes of the DS18B20 devices over the relatively slow OneWire bus.
I seem to remember that your system is slightly different in that you have multiple OneWire busses (1 per device), but if you are hurting for execution performance, it could be an option for you…
1 Like
That makes a lot of sense. I do have multiple (3) OneWire busses, soon to be 4. I plan to support multiple OneWire families, and am also building a custom sensor that emulates a OneWire device. Each of the device types will have varying delays, so I’ll have to think through whether your method or my current blocking reads make more sense in my application. Good information to consider.