Reset 1-wire Bus - DS18B20

[philipBC]

I have a Pi3 application built in NODE JS which samples readings from 4 DS18B20 temperature sensors.

The sensors are connected using all three wires Data, Supply & Ground. I use a single 4.7k resistor to 'pull up' the data line to the 3.3V power line used to power the devices. Initially I used a permanent 3.3V pin on the Pi GPIO header to power the arrangement.

Sometimes I find that the sensors disappear and my application fails to log their temperatures. Restarting my NODEJS app or soft rebooting the Pi does not fix the problem. Only a power off restart of the Pi allows the sensors to the found once again.

So instead, I am now using a GPIO pin (3.3V) as the source of power for the four sensors. When my application detects the sensors have vanished I switch OFF the GPIO pin to power down the sensors for 20 seconds and then switch the GPIO pin back on. The sensors re-appear. A GPIO pin can supply enough current at 3.3V to power my four sensors.

So this mechanism seems to reset the 'hardware' side of the 1-wire bus and allows my sensors to be found once again.

I have not been able to figure out why the sensors vanish, but at least I can now recover gracefully from the problem under the control of my NODEJS app and without requiring a power off reboot of the Pi.

Hope you find this tip useful.

[amatbrewer]

Thanks for the post. I am running into the same problem and find your solution really interesting. Right now I have mine set up to reboot when it detects it can no longer ‘see’ a sensor as a temporary solution. I am considering using your solution, but it will require some mods to my setup (my sensors are soldered to a proto hat) so I want to be sure there are no programming solutions first. Have you received any feedback or learned anything more about this?

FYI my device manages the irrigation and heating of my greenhouse protecting some valuable (at least to me) Bonsai and other plants, so I need this to be as reliable as possible.

[Gangelie]

Hi all,

I know this post is quite old but however I have exactly the same issues and the only "solution" for me is as well switch off the power for the W1 bus to reset and after a couple of seconds the bus is again online and sensors are available till next outtage.

Would be great if the problem could be identified.

[Nitrogen_Widget]

I'm having the same issue with Cayenne IOT.
Randomly my one-wire temp sensors seem to go offline.
Every temp reads 32 degs F.

The only way to get them back is to power down the RPI2.

They worked fine for months so i'm lost on what the issue is.

[soso8465]

I am having the same issue. So it seems like sensors gets out of sync. Because if you look at /sys/bus/w1/devices/ you can still see the exact number of sensors active it's just their ID's are messed and and obviously the data they are sending.

Don't know how to fix. And for me it started to happen like every few minutes... very annoying.

[1wire]

So instead, I am now using a GPIO pin (3.3V) as the source of power for the four sensors. When my application detects the sensors have vanished I switch OFF the GPIO pin to power down the sensors for 20 seconds and then switch the GPIO pin back on. The sensors re-appear.

I am having the same problem, since a bit more than one year,, and after a long search, this is a great solution, or at least a great workaround! (I needed a solution that can be performed remotely.) Thanks a lot!

In my case, the problem arises irregularly, about once every 2 or 3 weeks. I found that whenever it occurred, a power consumer (ice box) hanging close in the same power circuit had turned off very shortly before (e.g., 1 second). Sudo reboot does not (or very rarely) help, but shutdown with repowering the Pi helps. Plugging off the sensors (plug with all three wires) from the Pi and replugging them after a while also seems to help (tried only once so far).
Logfiles tell that "the maximum number of 64 sensors has been reached", and after that, a series of wrong sensor addresses appears in the log, one after the other every few seconds.

To advance this issue, which seems pretty common and barely understood, I would like to ask these questions:

- Where does the error come from? It looks as if quick power fluctuations can provoke it (though not reliably, of course). Does it come via power supply (then a power filter might help), or is it radiation from the power grid into the 1-wire-cable? (Then changing cables might help)

- Where is the error stored, once it hase arisen? If a reboot does not help, but repowering does, then which structures loose their memory only with power off but not with rebooting? Is the error stored in the Pi, or in the sensors?

- In this workaround, interrupting 3.3V supply for the sensors helps. But how should this reset the bus master? I rather guess that some memory within the sensors is (helpfully) lost, which solves the problem.

- I think, if actually the bus master would be reset by powering off the sensors, then plugging off (or grounding) the datapin should have the same effect.

I would so much like to understand what is going on, not just work around it.
Thanks.

[jokke_moose]

Hi all,

Very interesting topic. I have been using the DS18B20 on pi zero for a few days. It was immediately recongnised and worked fine, until... no readings any more, and then it seemed the device 28* directory was no longer there. For me the only solution is to unplug-plug the power supply for a few seconds. I will definitely try the solution proposed here as well. I could live with that as a workaround
But I would also like to understand before trying this workaround..
You mention "When my application detects the sensors have vanished", it probably means you are detecting whether or not the directory is still there?

Rgds,
Johan.

[JacekQ]

I think I have found solution.
I had Raspberry Pi Zero W with two thermometers connected to it (sqlite3, apache2 for storing and presenting data) and everything worked fine.
My problems started when I have connected third thermometer. After some search and tests I think that the solution is length of the thermometer cable - third thermometer was connected on 4 meter cable and after shorten cable everything started working fine again.

[jokkemoose]

Hi all,

I tried the solution proposed earlier in this topic and it works great.

Here's a python script that runs constantly in the background. it's executed via cron each time the device reboots.
Rather then connecting the sensor to 3v3, I connected it to GPIO 17.
For people who are not familiar with python, a short explanation:

My sensor = 28-xxxxxxxxxx
If the path of the sensor is not detected, the code will:
- configure the GPIO as output
- force it to 0v for 3 seconds
- make it 3v3 and wait 5 seconds

This process will run forever and hence it will constantly check if the folder is present or not.
I found the sleeps are needed to avoid wrong measurements. (I ran into -63° a few times when not respecting the sleep times. )

Code: Select all

import RPi.GPIO as GPIO
import time
import os

while 1==1:

    if (os.path.isdir("/sys/bus/w1/devices/28-xxxxxxxxxx") == False):
        GPIO.setmode(GPIO.BCM)
        GPIO.setup(17, GPIO.OUT)
        GPIO.output(17, GPIO.LOW)
        time.sleep(3)
        GPIO.output(17, GPIO.HIGH)
        time.sleep(5)

[1wire]

Dear folks,

my recent posting is two months ago. Meanwhile, I have not understood much more about the problem., which I regret. Yet, I have two machines running which now rely on this workaround described above. Either machine had one event so far (within the last 6-8 weeks) with temperature measurement abruptly terminated. Again, I found close temporal relationship of each such error to an offset of another power consumer (ice box, and heating pump) running in the same grid circuit as the respective raspberry. (One is a raspberry pi 3 B, the other a raspbery pi zero w).

The good thing is: The workaround presented above was able to repair the issue fully automatedly (via python) in both cases, and without rebooting the machine! Once again: Great, great workaround, which helped me to maintain these machines at all!

@JacekQ: Maybe the problem is actually influenced by cable length in your case, as you supposed. Yet, let me tell: In the longer history of my DS18B20 errors, I changed so many things for testing purposes. And every time I changed something, it all worked again after the change. Yet, just for a limited time. Particularly, each time I disconnected the sensors from the bus, the problem was reset. However, I did not notice that it was just the fact that I disconnected the sensors which helped. This made it extremely difficult to identify where the problem actually depends on.

@jokkemoose: This is, in principle, similar to my python solution. I set some parameters differently: The LOW phase of the supplying GPIO is set to 30 seconds, and after repowering the sensors I give the machine quite some time to detect all sensors correctly (this is not necessary; you may take temperatures as early as they come in again, but it may help if a new 'measurement error' is not stated earlier than 2 minutes after repowering the sensors). By the way, you might perhaps add a time.sleep(1) in case no error is detected; otherwise, your machine might try to spend 100% of CPU on testing this 'isdir' function millions of times per second..

Edit: I believe that the error, once it occurs, is stored in the sensors, or in one of the sensors, not in the raspberry. This is, in my understanding, the only explanation why dispowering the sensors helps, while rebooting (without repowering) the machine does not. I wonder whether the manufacturer of DS18B20, MAXIM, might be able to contribute to identify the source of this problem. Given that the combination of this sensor type and computer type is quite frequent, MAXIM might like to clarify.

[Warnerduh]

Ive got a JNC Navig8 GPS-578, after some fiddling its gotten stuck on the launch screen, does anyone know if there is a way to hard reset the device?

[wrypi]

Problem:
I need to attach many DS18B20 to a raspberry pi, but I am having the problem where the device disappears from the bus. Currently using external power.

Assumptions (correct me if I'm wrong):
On the 3v rail
Max of 16mA per pin
Max of 50mA per pi

On the DS18B20
Max draw is Sink Current of 4mA

Question:
Given the above assumptions, would I be able to put 12 DS18B20 (12 x 4mA = 48mA <= 50mA) on one board if I distribute them among 3 (48mA / 3 = 16mA <= 16mA) pins?

I'm a novice and I don't know much about current and voltage. I took the the highest current demand from the below data. Is Sink Current the right value to consider? or should I be restrained by active current which would bump me up to 10 sensors per GPIO pin?

From the DataSheet:
Sink Current | 4.0 mA
Standby Current | 1000 nA
Active Current | 1.5 mA
DQ Input Current | 5 µA


https://datasheets.maximintegrated.com/ ... S18B20.pdf

[ottsm]

Using a pull-up resistor will work for an experiment or for one sensor directly on the gpio. To start using long cable lengths and multiple sensors you need to use the DS2482-100 with a strong pull-up circuit. Also use a level shifter and get to 5VDC.

[rpdom]

Using a pull-up resistor will work for an experiment or for one sensor directly on the gpio.

It works fine for several sensors, as long as the wire length is not excessive.

[Greg Erskine]

I am currently testing 5 DS18B20 in parallel (in close proximity) and the have been running a script to record temperature since January 8th.

Looking through a month's data I occasionally get a "missed" reading, and there is a corresponding error message in dmesg.

When I initially setup the DS18B20's I had 2 devices that would start working then stop for no apparent reason. One would stop after a minute or 2 and the other would work for 10 minutes before failing. I thought at the time how lucky I was that the first 4 devices worked reliably because if I had started with the faulty ones it would have been very difficult to determine if my code was functioning correctly.

I am not sure if the faulty devices where faulty on delivery or I killed them mishandling them. I have been hot swapping them. Naughty I know

[1wire]

An update, which primarily refers to the "reset" topic.
- Machine 1 (a Raspberry Pi 3B) runs the built-in 1-wire protocol and bus master with 3 sensors (DS18B20, star-topology with 3 x 5 meters unshielded three-wire cable). As described above, the +3.3V supply for the sensors is provided by a GPIO output, which can be switched off and on in order to reset the bus. Pullup is 3k3. Within the last 4 months, six automated resets of the bus were performed (after complete measurement failures), each of them effectively repairing the problem.
- Machine 2 (a Raspberry Pi Zero W) runs the built-in 1-wire-protocol and bus master with 6 sensors (DS18B20, two branches with 4 and 2 sensors, total cable length about 12 meters, partly shielded cables). Power supply for the bus as above. The pullup was initially 3k3, but I reduced it to 1k5 after I had observed single sensors repeatedly disappearing from the bus. With 1k5, no such disappearance any more. In cases of high otherwise CPU load, the rate of false readings (indicated by "no such file or directory", or by a CRC mismatch), increases considerably, but otherwise, it works.
- Generally, despite some recommendations, I am reluctant with reducing the pullup resistor further and further, because in this particular "workaround" combination with supplying power via a GPIO output, this one GPIO output has to maintain +3.3 Volt even when the "data" wire is in low state. With e.g. 820 Ohm, this would draw 4 mA. I do not know the precise output impedance, but a significant voltage drop of the bus supply should be avoided. Or am I wrong here?
- Machine 3 (also a Raspberry Pi Zero W) is running for test and experimental purposes. I connected a DS2482-100 module (bought from Artekit, used "as is") as bus master for 1-wire via I2C. - Not so long experience yet, but there were no false readings so far. This module has been claimed much more reliable than the built-in 1-wire master (https://raspberryblog.de/?p=2293). Yet, I have a bit more than 1 per cent missing readings ("no such file or directory" errors), which is worse than with the built-in bus, and which I do not like to accept. I use a 4k resistor as pullup (although not required with this module). Ideas for improvement are welcome.

[rpdom]

Star topology is not recommended for 1-wire. Neither are branches. Just a single run of cable with sensors in parallel.

The code I run to measure my sensors does check for anomalous readings, particularly the 85°C which indicates a failure, and tries again. After that I have had very few bad readings in the years I've been running them.

I did have a few bad readings in the early days, but that was due to poor connections.

[1wire]

It seems I got a bit further.
With one Raspberry Zero W ("machine 2", above), I had observed that sometimes one particular sensor, and sometimes the entire bus, disappeared from the system. The workaround described in this thread did well every time!

As mentioned earlier, each of the errors (except the very few single-reading errors) occurred exactly when another load had been switched off from the power grid. This load, neighbouring the power supply of the raspberry in the grid, was in one constellation the aquarium heater, in another constellation the icebox compressor, in a third constellation the gas boiler.
Now I observed additionally that with switching the gas boiler off, sometimes (frequently but not every time) one GPIO relay switched "uncleanly", with a hearable sort of double-click. I went further into that, and the reason turned out to be a large, but extremely short (few microseconds) voltage peak measurable everywhere in the system consisting of the raspberry and its peripheral electronics. I have to say that my measurement was not well shielded, so that quantification and localization failed. The reason for this voltage peak was (most likely) that the gas boiler has a transformer inside, which is a considerable inductive load switched off each time together with the gas boiler (also, the pump is an inductive load, but the gas boiler was never switched off with the pump running).
I did not find out whether the voltage peaks came over to the raspberry system via power grid or via electromagnetic radiation. I did no tests to differentiate that.

The solution was to put an R-C combination ("snubber") in parallel to the switched load (not across the swich, not across the unswitched grid supplying the Zero, but after the switch in parallel to the switched load). I used 47 nF and 47 Ohm in series, with an additional 1M5 resistor in parallel to the capacitor.

Since that, all relays switch as they are supposed to. Moreover, most striking, the problem of disappearing sensors, or the entire bus disappearing, has vanished completely (if this can be said after only 3 weeks).

Of course, this is a solution working in my particular constellation. Yet, switched inductive loads are ubiquituous, and the may be one reason for the unreliable 1-wire bus of the pi. If so, a causal solution by a protective circuit, as described here in its simplest form, should be possible in some cases.

[johnny2678]

Just created an account to say thank you to @jokkemoose and other for this thread. This issue has been plaguing me for over a year. Switched from the 3.3v pin to a GPIO pin and resetting the pin every time a sensor disappears seems to be working.

Cheers all.

[SkullKill]

wrote something up with a bit more error handling and to be a bit more reliable.

https://github.com/SkullKill/onewireMonitor

[mwh]

I have been having the same issues, and with all the threads concerning this issue, it's really hard to find some useful information.

I haven't tried powering the sensor via a GPIO pin, but toggling 1-wire in raspi-config made a "bad" sensor work for me again (based off information the following thread: viewtopic.php?t=25154).

Clearly there must be a way of avoiding this problem from happening.

[RDPUser]

I had the same problem, but only with DS18B20 sensors from China. Most DS18B20 sensors are counterfeit, please check https://github.com/cpetrich/counterfeit_DS18B20 to identify fake sensors. You need an arduino. Didn't mangage to run the code directly on RPI. In fact even a lot of big sellers sell non original DS18B20.
So probably problem arises because of fake sensors. Please report back.