Attributes

Unlike telemetry, attributes are not time-series — they represent the current state or static configuration of an entity and persist until explicitly changed. Edge stores attributes locally in its PostgreSQL database, making them available for rule logic, dashboards, and external integrations even when the server connection is unavailable.

ThingsBoard supports three attribute scopes:

• Server attributes: Set by a user or a rule chain, on the server or on Edge. Not reported by the device. Used for configuration, metadata, and context — like an installation location or a threshold value.
• Client attributes: Reported by the device to Edge and stored locally. The default Edge Root Rule Chain forwards them to the server through a push to cloud node. The server saves them as server attributes, unless you set the Attributes scope of that node to Client attributes.
• Shared attributes: Set on the server or Edge and pushed to the device when it subscribes. The device can read and react to them.

Attribute changes are synchronized by rule chains:

• Edge → server: The default Edge Root Rule Chain already sends Post attributes, Attributes Updated, and Attributes Deleted messages to a push to cloud node. Change these connections only to stop or filter the sync.
• Server → Edge: The default server Root Rule Chain does not send attribute changes to Edge. Connect the Attributes Updated and Attributes Deleted outputs of the message type switch node to a push to edge node. Attributes of the Edge entity itself are sent to the Edge automatically.

During a connectivity outage, attribute updates are queued locally and sent once the connection is restored. For a step-by-step configuration walkthrough, see Attribute synchronization.

Attributes can be assigned to the Edge instance itself — not just to devices or assets. This is a distinct concept introduced in release 3.9. Edge instance attributes act as placeholders in rule chains, letting a single rule chain template serve multiple Edge instances with different configurations at runtime — eliminating the need for a separate template per instance.

For example, you can store an edgeAccessToken attribute on the Edge instance and reference it in a REST API call node via metadata — so the same rule chain works across Edge deployments with different tokens.