*ByIndex() functions hazard if >1 sensor is applied

[jirkaptr]

The functions *ByIndex() work correctly only when all expected sensors work correctly. If one of sensors becomes faulty (not connected), the resulting gap is filled by the next available sensor. Indexation crashes. The temperature sensors (and data) are mismatched. The last sensor(s) in the chain is falsely presented as faulty. This behavior could cause fatal problem in HVAC, engine control etc. (e.g. Inlet/Outlet Water/Oil/Air Temp …)

The root of the problem I see in the usage of getAddress() function. This function looks for sensors available ad hoc instead of the sensors really installed and defined in technology and assigned by a table.
The problem begins by begin() function which detects available sensors ad hoc. The application can compare the detected number of sensors with expected number only. And probably without *ByAddress() there is no chance to detect which of sensors disappeared.
The replacing of a faulty sensor can bring next difficult problem because the order of reading (indexation) may be different in comparison with the previous state. (I do not know rules for the order of sensor detection/reading).

For above mentioned reasons the use of actual getAddress() and *ByIndex() is very hazardous. The best solution would be to avoid the use of *ByIndex() functions (even to exclude them from the library). Apart from the fact that *ByIndex() are redundant to *ByAddress() functions.
Note: Sensors will be usually placed into a common table which assigns sensors to controlled technology. Position in the table is equal to the index. This indexation is likely “external” controlled by programmer instead of “internal”.
I imagine only one reliable solution:

1. Use *ByAddress() functions only (with respecting the Note above).
2. The DeviceList (i.e. identification) of expected sensors must be defined in application. The best solution would be to store the DeviceList in PROGMEM for practical reasons (Minimum space of RAM occupied by DeviceList)
3. The function begin() should compare identifiers of sensors listed in DeviceList with really existing sensors instead of getting count_dev value.
4. Mentioned DeviceList data should be obtained using simple example detecting the sensor identification code. The actual version of getAddress() is good enough to get sensors addresses one after another (but for nothing else).

I guess the price for reliability of sensors identification is acceptable.
I am unexperienced newbie in this forum. Perhaps Miles or Rob could implement presented idea..?

[RobTillaart]

Good observation, this problem is known and discussed on the Arduino forum a few times. (I do not have links sorry). From my head I recall some solutions to make robust temperature readings with detection of which one failed.

The first is to create a single bus for every individual temperature sensor. You will always know exactly which sensor you read, even after replacing a sensor, it will always have index[0] for that bus. Implication is you need a lot of pins and (a lot of) additional wire.

The second solution is a variation that uses an array of bidirectional switches (e.g. CD4066) or a pin multiplexer. This additional hardware takes care that you have only one sensor to talk to. It uses typically less pins than solution 1 but still uses a lot of wire.

Third solution is not always usable but works quite well. In fact I added it to the library a few years ago.
The scratchpad of the sensors have two registers for HIGH ALARM and LOW ALARM and if those are not used, the programmer can put his/her own 16 bit value in every sensor - check setUserData() and getUserData() - . This allows to put a program specific ID in every sensor. These ALARM registers are non-volatile (stored in EEPROM), so they will retain data after the device goes through a power down/up cycle. One can even prepare replacement sensors by placing the right ID in the sensor. At startup one can read all addresses on the bus and put them in an array with the user-provided-ID's as index.

wrt your solution:

1. Agree, - using byIndex() is indeed more dangerous than using byAddress()
2. Agree partially, - by having a fixed table in PROGMEM one cannot replace broken sensors easily. Imho it is better to store the addresses in EEPROM so they can be updated by the application. If the sensors break one at the time the application could in theory "repair/update" the table after replacement.
3. Agree, better check as much detail as possible is good
4. Agree

That said, working with your own ID in the sensors would allow a program to fetch all addresses and put them in an array with the ID as index. If an ID is missing there is one or more broken sensors (or wiring). The application can address all (remaining) sensors correctly even if one fails (using ByAddress() of course) as the user provided ID is mapped upon e.g. the kitchen, bathroom, living room etc.
Replacing a sensor can be done without adjusting the application, you only need to prepare the right user-ID in it. Note that an application can also detect if two sensors with same user-ID are on one bus.
The application should provide an error message like "failing sensor " or so.

Hope this helps.

[milesburton]

I'd agree the byIndex calls are dangerous, and shouldn't be used in this scenario.

Ideally this should be an FAQ