Treat the application database as the authority for last-seen state, and publish one consolidated status batch on a fixed interval to the dashboard channel. That is the operational recommendation. For a live poll during a clinical education session, presence accuracy matters more than the apparent immediacy of one event per device.

TL;DR: Devices should report through the normal API; they should not become dashboard subscribers. Persist each report first, assemble one batch for the next interval, and make the dashboard a replaceable projection of that durable state. Use a client-generated batch ID across retries. If the realtime provider changes, the reporting endpoint and database contract stay put.

Why is a connected socket not reliable presence?

A socket answers a transport question: is this connection open now? The poll operator needs a product answer: which invited participant reported recently enough to be counted, and which answer revision is current?…