I have been struggling with DS18B20 sensors when employing them at different distances from my UNO for testing. After working on this issue random errors for some time I tried someone else's code for multiple sensors on one bus and come up with the same issue. The distances I’m speaking of are three sensors on individual lines 30-50 ft placed in parallel near the UNO and then two sensors on the test breadboard near the UNO. If I only record the values for three far sensors I get good reading, but when I add in the two close sensors the problem returns. I have tried pull-up resistor values from 2K to 4.7k and resolutions from 9-12. I'm thinking the sensors may need to be on different BUS lines but I'm not convinced yet. Any thoughts on this. The code I'm using is attached:
I was thinking this commented out code :
// sensors.requestTemperatures();
// delay(750);
should be used before the second read of the same sensor but it seems to make no difference if added.
/* Multiple DS18B20 1-Wire digital temperature sensors with Arduino example code. More info: https://www.makerguides.com */
// Include the required Arduino libraries:
#include <OneWire.h>
#include <DallasTemperature.h>
// Define to which pin of the Arduino the 1-Wire bus is connected:
#define ONE_WIRE_BUS 8
// Create a new instance of the oneWire class to communicate with any OneWire device:
OneWire oneWire(ONE_WIRE_BUS);
// Pass the oneWire reference to DallasTemperature library:
DallasTemperature sensors(&oneWire);
int deviceCount = 0;
float tempC;
float tempF;
void setup() {
// Begin serial communication at a baud rate of 9600:
Serial.begin(9600);
// Start up the library:
sensors.begin();
// Locate the devices on the bus:
Serial.println("Locating devices...");
Serial.print("Found ");
deviceCount = sensors.getDeviceCount();
Serial.print(deviceCount);
Serial.println(" devices");
}
void loop() {
// Send the command for all devices on the bus to perform a temperature conversion:
sensors.requestTemperatures();
// Display temperature from each sensor
for (int i = 0; i < deviceCount; i++) {
Serial.print("Sensor ");
Serial.print(i + 1);
Serial.print(" : ");
tempC = sensors.getTempCByIndex(i);
// sensors.requestTemperatures();
// delay(750);
tempF = sensors.getTempFByIndex(i);
Serial.print(tempC);
Serial.print(" \xC2\xB0"); // shows degree symbol
Serial.print("C | ");
Serial.print(tempF);
Serial.print(" \xC2\xB0"); // shows degree symbol
Serial.println("F");
}
Serial.println();
delay(1000);
}
Excellent article but opens up a can of worms. Much to consider. My original house wiring for the system running with LM335 sensors used a Star Topology, the most unreliable. I was reusing those existing lines. So the question now is, might I resolve the issue with new sensors, maybe using R-C filters thinking my system weight is less than 200m, or use multiple one-wire lines, two or even three to multiple Mega Pro ports which would simplify resolving line issues and facilitate isolation. I'm shying towards multiple lines since they can all terminate at the Mega. Food for thought. I'll order some new sensors though to eliminate that potential issue.
Irrelevant. These are not I2C devices. That said, it is easy to incur grief with longer runs. Quality of cable is a first consideration, and just extending an existing with 3m of cheap stuff can be fatal. CAT5 is a common solution.
I have never heard of dud or fake DS18B20 in a weather proof container and would go for those irrespective of the environment.
The critical home automation functions have been hard wired in and reliable for many years. If a sensor were to fail it could cause damage by extremely overheating a zoned area with a hydronic in floor heating system. Lm335 sensors have been used for over 20+ years with no failures or off line conditions. I even have reservations about the new RS485 bus that is being slowly tested and expanded to accommodate Arduino.
That doesn't alter the fact that you have a problem with the hard wiring. Nor does it alter the fact that WiFi can be a lot simpler and cheaper to install than wire - even in a new-build. I'm sure you will find that WiFi monitoring installations have developed fail-safe just as effective as the old stuff. If you are retrofitting, and don't have ducted skirting and cavity walls, you might want to reconsider this....
You can divide lines to 2 or 3 groups and testing them which ones can coexist. Also RC filter may help.
I have an installation in my house with CAT5 for years. The longest stub has about 120m with occasional errors. RC filter helped with this one.
My personal experience is that the length of cable is not so critical so back and fort cable is better the stubs if it is not extremely long. Non-parasitic mode over the parasitic. CAT5. Lower value of pull-up resistor on long line. Small resistor on DATA pin close to each sensor is definitely good idea. Occasional errors treated by SW. Things like switching relays on mains voltage can have influence to the reliability of sensor reading so think about it in SW design, give the time to settle things down.
Good sound info. Interesting about placing the pull-up at sensor. I am believing the R-C network would also be at the sensor. Is this correct in your case?
Two simple terms describe measurements that are critical to 1-Wire network performance: radius and weight.
The radius of a network is the wire distance from the master end to the most distant slave. It is measured in meters.
The weight of a network is the total amount of connected wire in the network. It is also measured in meters.
For example, a star network configuration with three branches of 10m, 20m, and 30m would have a radius of 30m (i.e., the distance from 1-Wire master to the furthest slave) and a weight of 60m (i.e., the total length of wire in the network, 10m + 20m + 30m).
In general, the weight of the network limits the rise time on the cable, while the radius establishes the timing of the slowest signal reflections. "