I’m scoping a rollout where 120 Modbus registers per site need 15-second updates over a 64 kbps satellite link, and I’m weighing an on-site MQTT broker (Sparkplug B) against pushing raw reads to the cloud and normalizing there… We typically spec an Advantech UNO with Ignition Edge and store-and-forward, but the client wants to minimize on-site maintenance. Have you seen better outcomes with aggressive edge filtering/aggregation, or did cloud-side dedupe and backoff logic get you there faster without missing alarms?
On similar 64 kbps VSATs, the biggest saver was enabling Sparkplug B metric “alias” with Ignition Edge deadbands so after the NBIRTH you only send changes (spec: GitHub - eclipse-tahu/tahu: Eclipse Tahu addresses the existence of legacy SCADA/DCS/ICS protocols and infrastructures and provides a much-needed definition of how best to apply MQTT into these existing industrial operational environments.). That kept 120 Modbus regs at 15‑second cadence around 6–8 kb/s sustained; small caveat: bump MQTT keepalive to about 300 s or pings/QoS1 acks get chatty on high latency. If you want less on-site maintenance, you can still host the broker in the cloud but keep that edge filtering — raw reads upstream blew past our link.
Quick win: batch the 120 registers into 2–3 Modbus reads and let Ignition Edge do change-detect, then publish only deltas; that cut our 64 kbps VSAT airtime about 60% versus cloud-normalizing raw polls. @davidson_j92’s alias tip helps, and we also bumped MQTT keepalive to about 90s and used QoS 0 with store-and-forward to curb chatter. If they really want minimal on-site, a read‑only Mosquitto bridge has been “set‑and‑forget,” but pure cloud normalization got touchy with VSAT jitter.