IT admin, I look after networks more than sensors. We have 8 ESP32 sensor boxes in an outdoor storage yard, at the edge of coverage of two APs mounted on the building wall, 60-90 m away. They publish to Hermetry over MQTT every 30 s.
When I check the APs, those clients are connected at 1-6 Mbps while laptops near the building get 300+. The devices‘ Log tabs show a keepalive_timeout or two a day, and when I watch one with serial debug, a publish sometimes takes 2-4 s to get its PUBACK.
Two questions. I’d like to actually understand the mechanism: why does Wi-Fi get slower with distance and not just „weaker“? And practically, what should I change, the APs, the devices or the way they send?
Are the APs on 2.4 or 5 GHz for those clients? 5 GHz dies much faster through the yard clutter.
2.4 GHz, 20 MHz channels. The ESP32 can’t do 5 GHz anyway.
Also those slow clients eat airtime for everyone on that AP. A frame at 1 Mbps occupies the channel for a long time.
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.
Agree on batching. Also give the APs a minimum data rate of 6 or 12 Mbps if the yard boxes can still hold that, it stops one far client from dragging the whole cell down.
Thanks, the explanation helped me write it up for my manager. Batched to one message every 2 minutes with 4 readings and keepalive 90 s first: no keepalive timeouts in a week. The yard AP on a bridge is approved for next month.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.