DS18B20 Device Address VS getTempCByIndex()

I've looked around and can't find any discussion on this.

What are the pro's and con's of the following two methods for the DS18B20 temp probes? Just wondering because the second one seems simpler. If it matters, my application would not be a permanent installation. Probes would be connected before use in process and disconnected after process is complete.

Specific lines pulled from a sketch I'm currently working on: DeviceAddress HLTTMP = { 0x28, 0xFF, 0x2C, 0xB3, 0x64, 0x15, 0x01, 0xFE }; //HLT probe (#1) sensors.requestTemperatures(); probe1 = sensors.getTempC(HLTTMP); probe2 = sensors.getTempC(MLTTMP); hlttmp = (DallasTemperature::toFahrenheit(probe1)); mlttmp = (DallasTemperature::toFahrenheit(probe2));

An alternate method found in a couple examples on the web: sensors.requestTemperatures(); SensorTemp=sensors.getTempFByIndex(0);


Somehow you need to define two addresses. Somehow, you need to define which sensor to read.

The two approaches produce exactly the same result, IF you know which physical sensor corresponds to which address.

The first approach does not assume that you know the order of the addresses in a list. The second one does.

If you can tell, based on the results, which array index corresponds to which physical sensor, then the second approach is easier. That would be easy if one sensor is in your steaming hot tub and the other is in a snow bank.

If one is in your living room and the other is in your bedroom, telling which temperature is which might be a bit more difficult.

Thanks for the info Paul.

I kind of assumed a lot of that. Luckily, with my process, the probes are hung in the vessel so I can see which one reacts and move them to the appropriate vessel.

I have the arduino mounted in a control box along with quick connectors for the probes. Just for giggles, after I determined which probe was which on the display, I swapped the probes to the opposite connector. I expected the probes to move and start reading on the other display but they actually stayed connected to the original assignment.

I haven't tested what happens if I power down and move them but I expect still what you indicated, that they could change their assignment. I know with the first method that the assignment is static and set in the code.

Just because of easier coding, I may just give the second method a shot.

I have never been able to get my head around this. One DS18B20 looks very much like another, and the only way to be sure which is which, hence which one you are reading, is to read their addresses. Once you have done that, you might as well use the addresses in the code.

As things are, I still feel the need to identify every sensor with a sticky label which has the address and the position written on it with a pen. This sounds very 1950s but is quite reliable.

I recognise that using "by index" does give a set of readings, but I have never understood why anybody would see any advantage in using that method. I also recognise that this may be because I used "by addresses" first and have rigorously stuck with it. But if you use

quick connectors for the probes. Just for giggles, after I determined which probe was which on the display, I swapped the probes to the opposite connector.

and "by index", I don't think you will be giggling for long. Indeed, it rather sounds like that might be about to stop very soon.

answer probably no use to op but persons like me searching for the answer. I have historicaly used "by addresses" and used same design in a number of installations, more grief setting up would have been easier one sketch "by index". What happens with a dodgy connection/ device? "by addresses" each physical location will maintain its position and the value front cylindar will always refer to the same physical position and given the error 85 you can work out where the problem is. "by index" and you dont know which 1 of x has gone down, unless you expect distinctly different results. (I have experianced this issue using mechanical rather than soldered connections) if its not connected you wont find it by index but asking a specific address will give an error. Are there any other differences eg which is slower/ a more reliable method, I dont know.

the1andonly: What happens with a dodgy connection/ device?

Indeed. The way I understand it is this:

whichever way you do it, you have to know which address is where. When using "by index" Arduino has to check the addresses of each sensor and report the readings in order, which I assume this takes time. The time may not be a problem, but why would you endure the potential complication? I assume that, if a sensor is not connected, Arduino doesn't know it should be there, whereas, with stated addresses, it should be suss about a missing one. Therefore, in the event of a dodgy connection, I believe a table of results could be

sensor address 1 dead sensor address 2 found first so read as address 1 sensor address 3 found second so read as address 2 dadedah...

A diligent user will know a connection is dodgy but there is no indication as to which one. Why on earth would anybody do that? Even if my premise is wrong, I still fail to see why you would use "by index".

I don't think the 85 is a problem, you might have meant 127

It was 6 years ago when i first had the 85 problem a quick search here and it does exist. cant remember precice reason but may be timing related. Of 5 sensors the same 3 ocasionally gave the error, util i striped the mechanical connections made new solder joints and problems vibration related went. (automotive application). Ive not used "by index" until recently. The only reason I can see to use it is for other people to use the code as written without the ability to run an address program modify the intended code. ( if i had done this in the past it would have saved a month elapsed and 2 x 200 miles). Is there any saving in memory by either method?

the1andonly: The only reason I can see to use it is for other people to use the code as written

At last, an understandable explanation.... So, you inflict dopey code upon yourself, just so others can get the benefit of dopey code. And it does not absolve those unknown others from determining the address of their own sensors.

Using "by address" does mean that the addresses must be stored in memory. This may be significant if you have a great swag of sensors, but I don't suppose it would be significant enough to justify using "by index".

The 85 is indeed a matter of timing. You see it when the sensor has not had sufficient time to to its job. The most common instance of it is the first reading when it is called upon within 750ms of turning on.