Telemetry synchronization

Telemetry synchronization in ThingsBoard Edge is controlled by the push to cloud and push to edge rule nodes, which determine what is synchronized and when. This gives you precise control: you can filter by device, entity type, or telemetry key, transform data before forwarding it, or keep certain data local entirely.

All incoming data is always written to the Edge local database first, regardless of whether it is forwarded to the server. The push nodes only control what is also sent upstream — not what is stored locally.

When a telemetry or attribute message passes through the push to cloud rule node in an Edge rule chain, it is stored locally as a Cloud Event — in either the local PostgreSQL database or Kafka, depending on the queue type. The Cloud Manager then picks up the event and pushes it asynchronously to the server over gRPC. Once the event reaches the server, it is handled by the corresponding server-side rule chain.

The default Edge root rule chain already includes a push to cloud node connected to the Post telemetry and Post attributes message types — so device telemetry and attributes are synchronized to the server automatically for any device assigned to the Edge.

The server uses the push to edge rule node within a server-side rule chain to send data to an Edge instance. The node converts the message into an Edge Event and stores it in the Edge queue on the server. The event is then pushed asynchronously to the target Edge instance, where it is handled by the corresponding Edge rule chain.

Cloud Events and Edge Events are persisted before they are pushed — either in the local PostgreSQL database or in Kafka, depending on the queue type configured on the server.

When the connection between Edge and the server is lost, events continue to accumulate in the local queue. Once the connection is restored, the Cloud Manager sends all queued events to the server in the order they were stored.

Time-series data carries a timestamp and is stored independently on both Edge and the server — there is no conflict. Attribute updates follow last-write-wins semantics: if both sides update the same attribute key while offline, whichever update arrives at the destination last takes effect.

Only messages that pass through the push to cloud or push to edge node are synchronized. Data that does not reach these nodes stays on Edge and is never forwarded — it is not discarded. You can use filter nodes before the push node to limit synchronization to specific devices, entity types, or telemetry keys.