We had the same with tank level boxes in a pump yard and our network guy walked me through it.

Mechanism: with distance the signal-to-noise ratio drops. Wi-Fi then picks a slower, safer modulation and coding rate (rate adaptation), each symbol carries fewer bits, so the data rate falls from tens of Mbps to 1-6 Mbps. On top of that, weaker frames fail more often and get retried, and each retry costs airtime and backs off. So “weaker” turns into “slower”, and twilson’s point is real: at 1 Mbps your sensors use far more of the channel per byte than a laptop.

What helped us, in order of effect:

Fewer, bigger messages. Batch 2-4 readings into one telemetry array with their ts and send every couple of minutes. Same data, a fraction of the frames. Each message also counts once against the monthly quota whatever it holds.

Keepalive at 60-120 s, not 15. The docs recommend something between 30 and 300 s, and a short keepalive on a slow link is what gives you the odd keepalive_timeout.

Wait for PUBACK before deleting a buffered reading. Hermetry acks only after the message is safely queued, and a device can only have a limited number of unacknowledged QoS 1 messages in flight (20 by default), so on a slow link don’t fire them off blindly.

Fix the radio path properly: a point-to-point bridge to a small AP in the yard, or one gateway in the yard collecting the boxes over RS-485 or a short-range radio and sending on its own link. We did the bridge, the boxes now connect at 65 Mbps.

MQTT has the keepalive and in-flight numbers.

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.

Look at the host in your log line. That’s the broker host from the US firmware.

Hermetry runs as separate deployments per region (EU, US, TR) and every organisation lives in one home region. Devices have to connect to the device host of their own organisation’s region, the one on each device’s Connection details card. I’d bet the US plant’s organisation is in the US region and yours, created by your IT from the UK, is in the EU. Your UK devices are knocking on the US broker with tokens that only exist in your organisation’s region. To that broker they’re unknown tokens, so you get a 4. Nothing reaches your Log tab because your org was never asked.

I hit exactly this when we cloned a project between two of our utilities, one in each region. Fix:

1. Open any of your devices, Credentials tab, Connection details. Note the MQTT broker host.
2. Replace the host in the firmware (and the HTTPS host if they use it).
3. Keep connecting by host name. SNI is required, so don’t hardcode an IP from a DNS lookup.

Owners and admins can also see the home region under the organisation settings, Residency. The page is Regions and data residency.

And since you’re getting 4s: the firmware backs off 5 minutes, good. Keep that. Repeated failed logins from one address block that address for a while, and the whole plant is behind one NAT.