Local broker, one topic per screen, JSON publishing at about 10 Hz. Why MQTT beats WebSocket and polling for decoupled multi-screen setups.
Driving several remote displays from a single source poses a decoupling problem: the source must not know the count, state or availability of the screens. MQTT answers exactly this need, where WebSocket and polling impose an awkward coupling.
Topology and rate
A local broker centralizes the exchanges. The source publishes the state of each screen on a dedicated topic, one topic per display, in JSON, at a rate of about 10 Hz, which is enough for smooth rendering without saturating the network. Each display subscribes only to its own topic and ignores the rest.
Adding or removing a screen changes nothing on the source side: you simply subscribe or unsubscribe.
Why not WebSocket or polling
WebSocket creates a point-to-point connection the source must manage screen by screen, which reintroduces the coupling we wanted to avoid. Polling forces each screen to query in a loop, wasting bandwidth and freshness. MQTT, with pub/sub, broadcasts once and lets the broker route, with retain to serve the last state again to a reconnecting screen.
The takeaway: for decoupled multi-screen setups, publish to topics and let the broker handle the routing.