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.