New: the AI firewall watches the whole platform and explains each incident in plain words. See how it works

Twenty DS18B20 probes on one Pi: dropouts past eight sensors and how to name the keys

Twenty DS18B20 probes on one Pi: dropouts past eight sensors and how to name the keys

Solved 7 6

ok so this is probably two questions in one, sorry.

I’m monitoring a small cellar where I keep cheese and some homebrew. Raspberry Pi 4, Raspberry Pi OS Bookworm, 1-wire on GPIO4 with dtoverlay=w1-gpio. I want 20 DS18B20 probes (rack top/middle/bottom etc). With up to 8 it is fine. Past that some sensors vanish from /sys/bus/w1/devices and come back, and a few read exactly 85.0 now and then.

Second thing: I send them to Hermetry with paho-mqtt, one publish per sensor, key = the ROM id like 28-0316a2794bff. Is that a bad idea? My dashboard looks like a phone book.

Wiring: 4.7k pull-up at the Pi, cat5 run out to the racks, then short legs to each probe, about 15 m total.

Ask me about 4–20 mA.
♥ 2

Are the probes on 3 wires or parasite power? And when you say short legs, how short?

Timestamps in UTC or it didn't happen.
♥ 2

3 wires, 3.3V from the Pi. Legs are 30 cm to 1 m, it’s more of a star than a line I guess.

Ask me about 4–20 mA.
♥ 0

The star is your dropout problem. 1-wire hates stubs, every leg reflects. Either run one line past every probe with tiny stubs, or split it: you can load the overlay twice on two pins and have two shorter buses. I’d also try 2.2k instead of 4.7k with that much cable.

Ground loops are my cardio.
♥ 0

Would it be easier to just put a cheap ESP32 on each rack? That’s what I’d do but I’m not a hardware guy.

Still waiting for the gateway to reconnect.
♥ 0

James has the wiring right. Two buses, 2.2k each, and you’ll be fine. We run 14 probes per bus in a pump house that way.

85.0 is the power-on value of the DS18B20, it means the read happened before a conversion finished, usually a brown-out on the bus. Drop it in code, never send it.

On the keys, change it now before you have history. Keys count as distinct names across the whole organisation (Starter caps you at 250), so ROM ids per sensor will eat that fast once you build a second cellar. Name them by position, keep a map from ROM id to position in a file on the Pi, and send all 20 in one message. One message with 20 points costs the same quota as one with one.

import glob, json, paho.mqtt.client as mqtt
MAP = {"28-0316a2794bff": "rack1.top", "28-0316a27a11ff": "rack1.mid"}  # etc
vals = {}
for p in glob.glob("/sys/bus/w1/devices/28-*/temperature"):
    rom = p.split("/")[-2]
    t = int(open(p).read()) / 1000
    if rom in MAP and t != 85.0:
        vals["cellar." + MAP[rom]] = round(t, 2)
c.publish("v1/telemetry", json.dumps(vals), qos=1)

Key rules are on Telemetry keys.

QoS 1 and a lot of patience.
Accepted solution♥ 2

Two buses on GPIO4 and GPIO17, 2.2k each, and I re-did the run as a line along the racks. 20 of 20 for two days now, not a single 85. Renamed the keys too, deleted the device and started fresh since there was only a week of data. Dashboard reads like a cellar now instead of a serial number list. Thanks all, Kevin maybe next build 😉

Ask me about 4–20 mA.
♥ 0

One small thing while you’re in there: put the device token in a file only your service user can read, not in the script. Saw too many of those in git repos.

Measure twice, poll once.
♥ 1
Viewing 8 posts – 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.

Join the conversation

Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.

Share