Realtime Telemetry Flow

Purpose

Developer documentation for how telemetry moves through backend ingestion and query paths into frontend hooks, stores, realtime handlers, and runtime consumers such as dashboards and device views.

Overview

Realtime telemetry flow connects backend telemetry and realtime services with frontend API layers, hooks, stores, and runtime consumers.

Backend Telemetry Flow

• Telemetry modules handle ingestion, persistence, and querying.
• Realtime infrastructure distributes live events to interested frontend consumers.
• Related backend services coordinate current values, historical data access, and runtime event fanout.

Frontend Telemetry Flow

• API modules fetch telemetry data from backend endpoints.
• Hooks normalize telemetry access for runtime consumers.
• Stores maintain shared state and derived telemetry values used by widgets and views.
• Realtime handlers merge incoming updates into the data used by runtime UI.

Historical versus Live Behavior

• Historical mode resolves a selected time window and fetches data for that range.
• Realtime mode focuses on current values and incoming updates.
• Widgets may support one or both modes depending on their purpose and implementation.

Dashboard Consumption

• Dashboard runtime uses telemetry-aware hooks and stores so widgets can render using shared data resolution patterns.
• Toolbar controls such as selected time window can change how widgets query and display telemetry.
• Runtime context can also affect which entity and keys are resolved for a widget.

Device and Runtime Views

• Device-focused views rely on the same telemetry foundations for current values, history, and live updates.
• Runtime consumers should share common telemetry resolution patterns instead of duplicating fetch and merge logic.

Developer Notes

• This document should explain the movement of telemetry through the system, not just list telemetry-related files.
• Widget-specific runtime behavior should be complemented by the dashboard realtime developer docs.