Assigning specifc order to oneWire devices.

Imagine I have a box with 8 jacks in the back, into which I connect 8 individual DS18B20 temperature sensors that are sensing temperatures in specifically numbered locations (specifically terrariums). So jack 1 goes to tank 1, jack 2 goes to tank 2, etc.

Is there a way that I can enumerate the sensors so they always end up in particular order? For example, I start with 4 sensors hooked up, and add a 5th to jack 5, and upon bootup the new sensor is detected. How can I make sure that he 'old' sensors stay the same order (index value), so tank 3 stays jack 3? Or I have all 8 sensors hooked up, and one of them fails and gets replaced... is there a way to detect that there is a 'new' sensor replacing the old value?

(Just putting this in words makes me think that I could 'memorize' the existing sensors into EEPROM, make a comparison with the scan, and if there is a change, interactively ask what jack to assign it to. Does it sound like a logical solution?)

THe only way to guarantee that is to give each sensor its own arduino pin.

Take a look in its datasheet.. says something abaout a 48bit uniqe code in each unit. May be interesting I found it here: http://www.datasheetsite.com/datasheet/DS18B20-PAR

robtillaart:
THe only way to guarantee that is to give each sensor its own arduino pin.

Thanks, I’m thinking that also. I am not the worlds best programmer (bottom 10% is more like it! :P) so getting the code working to ensure assignment and uniqueness may be too complicated.

A better option for me might to be use an analog multiplexer and analog sensors, dedicating one pin on the multiplexer to each sensor, and using up just one analog pin on the Arduino. It may be a better choice also because of the long read delay inherent with communicating with the digital sensors, and it may be able to handle longer runs.

Thanks for the suggestion!

The OneWire library allows you to detect and report the unique serial number of each DS18B20 temperature sensor. Later, you can build the detected IDs into your code, so that sensor IDxxx is always sensor #1, etc. You might have to physically label each sensor to keep track of them. See this example: http://www.hacktronics.com/Tutorials/arduino-1-wire-tutorial.html

jremington: The OneWire library allows you to detect and report the unique serial number of each DS18B20 temperature sensor. Later, you can build the detected IDs into your code, so that sensor IDxxx is always sensor #1, etc. You might have to physically label each sensor to keep track of them. See this example: http://www.hacktronics.com/Tutorials/arduino-1-wire-tutorial.html

Thanks. I am working with the 'fixed serial numbers' now, but I would like to make them more dynamic - "just because". That way I can add or replace sensors without having to explicitly alter and reupload the sketch if there are any changes in sensors. So in my mind the sensor ID's should not be built into the code, but the ID's should be added dynamically.

HMMMM.... how about using a digital multiplexer, attaching / assigning one pin to each sensor data line, and polling the mux pins during setup????? That could work!

HMMMM.... how about using a digital multiplexer, attaching / assigning one pin to each sensor data line, and polling the mux pins during setup????? That could work!

That is utter nonsense.

Check here http://www.hacktronics.com/Tutorials/arduino-1-wire-tutorial.html

There are two programmes: one to obtain the addresses of the DS18B20 one at a time, and the other to read the temperatures using them.

Use a sticky label and a pencil to identify them if necessary, or a code with coloured heatshrink on the cables.

In the rare event of theft or failure, run the reader again for the new sensor, and change the address in the setup of your operational code. It really is that simple.

…read on! (datasheet / web ) there is a LOT of practical info to be found abaout this temp-sensor
These measurements will be logged?? Then log ID (i’m sure just on byte of snr is enough) and Temp .
Software is able to detect removel and additions of units on the bus.
–(I did som reading too and understand that my collection of sensors will welcome a new friend…)

Nick_Pyner:

HMMMM… how about using a digital multiplexer, attaching / assigning one pin to each sensor data line, and polling the mux pins during setup??? That could work!

That is utter nonsense.

I guess I could take the lazy way out and hard code everything. For example, each sensor will have a different high and low temperature which when exceeded will ring an alarm, and I could hard code those too. Then when I want to change those limits, I could change the source code and reupload the sketch! :stuck_out_tongue:

That’s not the point of my original question. The question was “Is there a way to assign a specific polling sequence to a oneWire device”? I guess not, hence the hardware to add that functionality. I COULD also build a lookup table by adding them one at a time, and memorizing the individual IDs and logically tying them to the individual port.

There are several issues that polling the hardware round-robin solves, including adding and removing sensors, sensor ID independence (sensors can be switched between ports with only a reset required), higher current capabilities, easy broken sensor replacement.

Edit: In essence I want the software to say " I see a new / different sensor attached. What port do you want me to use it on? Done. Sensor ID memorized and assigned to port XX". Even if they are all connected in parallel (which they effectively are), there has to be an easy 'non-harcoded" method to assign a polling sequence as sensors are added or deleted or rearranged.

edcasati: I guess I could take the lazy way out and hard code everything. For example, each sensor will have a different high and low temperature which when exceeded will ring an alarm, and I could hard code those too. Then when I want to change those limits, I could change the source code and reupload the sketch!

You could, but it's also irrelevant. If you want to change an alarm, you can send that as data.,

That's not the point of my original question. The question was "Is there a way to assign a specific polling sequence to a oneWire device"? I guess not, hence the hardware to add that functionality. I COULD also build a lookup table by adding them one at a time, and memorizing the individual IDs and logically tying them to the individual port.

You can incorporate the address seaching in the operational programmne's loop. That may answer your problem as it apparently allows hot-swapping a sensor.. I don't know much about it and can't see the need. It just seems like redundant programming to me but, I guess that's not necessarily a problem

There are several issues that polling the hardware round-robin solves, including adding and removing sensors, sensor ID independence (sensors can be switched between ports with only a reset required), higher current capabilities, easy broken sensor replacement.

If you paranoia is getting the better of you, salvation lies here

http://sheepdogguides.com/arduino/ar3ne1tt.htm

All you need is enough pins

The original "one wire" protocol imagined a bunch of devices, all individually addressable, on one data wire and thus, one port pin. That obviously has its complications in that you need to know the unique ID for every device and address each device individually.

On the other hand, if you assign a separate pin to each sensor, then you do not need to know or pay attention to the individual IDs and each device is treated exactly the same way by the program (except the program must keep track of the pin).

I've always gone the latter route, but I've read that some people have worked with a dozen or more sensors on one wire.

If you want to use a single bus for these devices, you can, as you suggested originally, enumerate the devices attached and have some interface that allows you to designate a virtual port for each one. That port number can be defined to correspond to the jacks on the box so that you know which jack to plug each sensor into, even though they're all actually connected to a single bus pin. The only point to this is to be able to label the jacks and the probes for when you tear the thing down & reconnect it.

When a new sensor is detected, the interface will ask you to designate a port before it can be used. The port/device address mapping can reside in EEPROM. Presumably, your interface will also need to allow you to set the alarm temps associated with each sensor too. EEPROM again for these.

There's quite a lot of coding effort needed to build this interface - it might be easier to do it on a PC and send the config data to the arduino via serial. Given the effort required, unless you foresee a lot of changes to the sensors, I'd really be more inclined to hard code the addresses and alarm limits and live with the fact that I'd need to update the sketch to change them.

wildbill: There's quite a lot of coding effort needed to build this interface - it might be easier to do it on a PC and send the config data to the arduino via serial. Given the effort required, unless you foresee a lot of changes to the sensors, I'd really be more inclined to hard code the addresses and alarm limits and live with the fact that I'd need to update the sketch to change them.

So here is what I have decided to do. I definitely want adding or replacing probes to be 'transparent', so I don't have to reload code. 8 jacks, each one with one probe. The answer is actually pretty simple. Just use an MCP23017 I2C I/O multiplexer (about $1.50), hook up a sensor to each of the 8 I/O pins (the chip can handle 16 individual devices), and check them round-robin with a broadcast on the individual pin, so the individual serial number of the temperature probe becomes irrelevant.

edcasati:
The answer is actually pretty simple. Just use an MCP23017 I2C I/O multiplexer (about $1.50), hook up a sensor to each of the 8 I/O pins (the chip can handle 16 individual devices), and check them round-robin with a broadcast on the individual pin, so the individual serial number of the temperature probe becomes irrelevant.

This will not work as it is impossible to implement the 1-wire protocol over this device. It is just to slow. The protocol requires 10 us level pulses. The device could be used for (parasite) power control.

There are several solutions to the problem with 8 ports and 8 DS18B20s on individual wires. Below are a few examples:

  1. Use 8 pins on the Arduino. One 1-wire controller per pin.
  2. Use a demultiplexer (74HC238) and use power control and 4(5) pins.
  3. Program a learning phase where the DS18B20 are plugged in one at a time.

The 1-wire protocol allows omitting the device identity number. This works fine for commands with no reply (broadcast) or when there is a single device on the wire. This ability may be used to broadcast a DS18B20 CONVERT T command and then use the general 1-Wire ALARM SEARCH command to poll which devices have exceeded their temperature thresholds. This is one of the intended usage pattern and very fast as all the temperature conversions and alarm checks are done in parallel. Only the devices with an alarm state will answer the ALARM SEARCH command.

All the above is support by the Cosa OWI and DS18B20 driver.
Examples: https://github.com/mikaelpatel/Cosa/tree/master/examples/OWI

The solution (3) above could be used with a single wire and multi-drop. There is a lot of info about the DS18B20 on open-source home automation web-sites.

Cheers!

kowalski:
This will not work as it is impossible to implement the 1-wire protocol over this device. It is just to slow. The protocol requires 10 us level pulses. The device could be used for (parasite) power control.

You are correct about the I2C not working. Once I started digging in, I realized that I neither knew or understood the issue completely.
But I did get it finally working, multiplexing through a 4051. Basically it is select the pin, and send a “sensors.getTempCByIndex(0)” instruction. Since there is only one sensor on the selected line, it answers without an address, and it seems VERY quick.

Thanks for the advice. It really is appreciated.