Thanks for your quick and detailed response — I really appreciate discussions like this in a forum! :)
1) “Why even use DS18B20 in blocking mode?”
– You are correct that in many applications, non-blocking is essential when the processor has other tasks to handle. In my example, the blocking call was used intentionally to make the conversion and any additional recovery time directly observable via the LED. This is particularly helpful for beginners who are trying to understand what the sensor is actually doing during its measurement cycle.
2) Inefficiency of the “get by index” functions
– Yes, technically you are right: using sensor addresses directly is optimal for speed and avoids the double OneWire transaction. My focus here, however, is flexibility for practical scenarios: that's most important because I can even ask someone to get a new sensor from the shelf and swap it without needing to touch the code.
– To clarify: if there is only one sensor per bus, the “get by index” concern about changing indices does not apply. In multi-sensor setups it’s indeed something to be aware of.
3) Timing with currentTime - timer >= waitTime
– I understand your point about waiting for the conversion and potential issues in multi-sensor setups. In my setup, again with one sensor per bus, the global conversion command starts all sensors simultaneously. The library’s sensor.getResolution() returns the maximum wait time, which is sufficient to guarantee that the conversion is done.
– Explicitly checking “whether the conversion has actually completed” would require another OneWire transaction, which can be slow and wasteful. For a single sensor, or in cases where the exact timing is known from the datasheet, using the calculated wait time is reliable and keeps the processor free for other tasks.
Yes, your statement is 100% correct. And maybe you cannot call it a bus OK.
The one device per bus solves (1) a replacement issue and (2) if a device gets broken there is a serious chance that none of the devices on the bus are accessible. With one device per pin/bus this special (rare?) case will not happen.
So with one device per pin you can create a fail over system as you can put the sensors in pairs and they must give the same Temp. If one is broke, you always have the 2nd one to measure until replacement. (Yes, you need async com to have this running smoothly).
Drawback, you need a lot more pins, so it is a design choice.
Thanks for pointing that out — that reflects my experience quite well.
The reason I eventually switched to the one sensor per bus approach was actually a real-world issue. I had a sensor that was repeatedly exposed to temperatures up to about 116 °C, and over time it started to behave erratically and eventually caused chaos on the whole bus. In that situation, all sensors on that bus became unreliable until the faulty one was identified and replaced.
After running into that problem, I moved to one sensor per pin / bus, mainly for robustness and easier maintenance. It also fits well with the “swap-it” idea: if a sensor fails, it can simply be replaced without worrying about bus enumeration or affecting other sensors.
And in practice the pin usage is often less of an issue than it might seem at first. Even an Arduino Uno frequently has enough pins available for several sensors. Things like displays or other peripherals can easily be moved to I²C, which keeps the digital pins free for dedicated sensor buses.
Of course it’s a design choice, but in my setups the single-sensor-per-bus approach has proven to be very reliable.
Interesting take and I see the advantages. However, even in a one device per bus architecture, I would get and store the OneWire address of that device in the setup() function. Then use it for all subsequent device transactions rather than use the "get by index" family of functions. The latter require scanning through the valid address range from lowest to highest until a sensor responds and then using that address to do what you wanted in the first place. Doing that for every temperature reading going forward is, IMO, that's offensively inefficient.
Too many words in Ai style. Didn't read.
All I saw was "DS18B20", no display and "heartbeat LED"
I had a similar problem with a display in my bathroom, where I flashed a LED, not just as a heartbeat, but displaying the temperature in pulses.
First the tens as 20ms pulses with 400ms in between, then a 600ms pause, and then the units with the same pulse/pase duration. Then a longer separation between the next temp sequence.
Leo..
Practically, there is no benefit in reading the sensor more often that once every five seconds or so. sensor body and copper of the wiring or circuit board takes time to equalise.
Leo..
