LAN Communications

Use This Dashboard Area Safely

Use this guide when event work may happen on local devices, offline files, or LAN-only tools instead of the live online dashboard. In this guide, LAN Communications narrows that work to lAN-only communications guide for channels, announcements, DMs, groups, media, calls, PTT, notifications, pins, reactions, and presence. Because this is a surfaces page, read it as part of the EMS LAN learning path rather than as an isolated checklist.

EMS LAN keeps an event moving when internet access is unreliable, but it also creates a second place where event records can change. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What The Screen Controls

This page explains a specific surface. Treat every button, field, filter, and table as a way to view or change real records, not just as a visual layout. The intended readers are Communications leads, Event operators, and Support leads. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: /admin/:eventId/communications and /workspace/:eventId/communications.
• Records or contracts involved: Communication channels, Messages, Pins, Presence, Conversations, Call sessions, and Notification events.
• Main care point: Watch for losing track of which file, device, person, or import is trusted while attendee, staff, inventory, POS, or check-in records change offline.
• Proof worth keeping: event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note.

Read The Screen From Top To Bottom

1. Confirm you are on the right event, report, route, or file: Begin by naming the EMS LAN situation, the owner, and the exact item involved in LAN Communications.
2. Read the current state before changing it: Use /admin/:eventId/communications and /workspace/:eventId/communications to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Use the smallest action that matches the task: Keep Communication channels, Messages, Pins, Presence, Conversations, Call sessions, and Notification events in view so the work stays tied to the records or contracts it can affect.
4. Check the list, detail view, history, or public page afterward: Before handing off, save proof such as event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note so the next lead can tell which file and device state are trusted.

Before You Leave The Screen

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on offline files, check-in access, staff rosters, inventory counts, POS totals, and import history.
3. Proof is findable: The handoff points to evidence that the next lead can tell which file and device state are trusted.

End-to-end operator runbook

Use this numbered runbook to operate LAN communications.

1. Step 1 - Open the exact screen for the event. Open Communications from admin or workspace for the correct event. This ensures messages stay inside the right event.
2. Step 2 - Identify what the screen reads and writes. Choose whether the situation needs a public channel, announcement, pinned message, direct message, group message, voice room, video room, or private voice intercom. This picks the least noisy tool.
3. Step 3 - Use one control at a time. Send the message, start the room, invite the direct/group participants, pin the decision, or use PTT for intercom. This creates local communications records.
4. Step 4 - Check who or what was affected. Confirm recipients, notification delivery, presence, call state, and whether media requires HTTPS or Android permissions. This prevents missed or broken instructions.
5. Step 5 - Confirm the screen and history agree. Check the channel feed, dock preview, notification state, or active call tray. This proves the message or call reached the local runtime.
6. Step 6 - Leave notes another operator can follow. Pin final decisions, end calls that should not remain open, and record unresolved operator requests. This keeps communications auditable.

LAN-only communications features

Feature	Operator use
Channels	Shared room-style event coordination.
Announcements	High-signal broadcast updates.
Pins	Keep decisions or key instructions visible.
Presence	See who is active and where.
Attachments and voice notes	Share local evidence or spoken updates.
Reactions	Fast acknowledgements without noisy replies.
DMs and private groups	Small-team coordination.
Voice rooms and video rooms	Live coordination when text is too slow.
Private voice intercom	Immediate listen-through with PTT talkback.
Notifications	Browser/service-worker/native alerts for messages, calls, and system notices.

Media requirements

1. Checkpoint 1. HTTPS or trusted WebView context is available for microphone, camera, and AudioWorklet features. Use it to confirm the work is still on the right path.
2. Checkpoint 2. Android wrapper permissions are granted for camera, microphone, notifications, and NFC where needed. Use it to confirm the work is still on the right path.
3. Checkpoint 3. LiveKit media status is healthy or the team accepts fallback limits. Use it to confirm the work is still on the right path.