Broker local, un topic par écran, publication JSON à environ 10 Hz. Pourquoi MQTT bat WebSocket et polling pour du multi-écrans découplé.
Piloter plusieurs petits afficheurs déportés depuis une source unique pose un problème de découplage : la source ne doit pas connaître le nombre, l’état ni la disponibilité des écrans. MQTT répond exactement à ce besoin, là où WebSocket et polling imposent un couplage gênant.
Topologie et cadence
Un broker local centralise les échanges. La source publie l’état de chaque écran sur un topic dédié, un topic par afficheur, en JSON, à une cadence d’environ 10 Hz qui suffit pour un rendu fluide sans saturer le réseau. Chaque afficheur s’abonne uniquement à son topic et ignore le reste.
Ajouter ou retirer un écran ne change rien côté source : il suffit de s’abonner ou de se désabonner.
Pourquoi pas WebSocket ni polling
Le WebSocket crée une connexion point à point que la source doit gérer écran par écran, ce qui réintroduit le couplage qu’on cherchait à éviter. Le polling force chaque écran à interroger en boucle, gaspillant bande passante et fraîcheur. MQTT, en pub/sub, diffuse une fois et laisse le broker router, avec retain pour resservir le dernier état à un écran qui se reconnecte.
Le principe à retenir : pour du multi-écrans découplé, publiez sur des topics et laissez le broker faire le routage.