Payloads and input matching

Both transports — MQTT and HTTP — resolve a payload the same way. Understanding that resolution explains nearly every “the data is not showing up” case.

The resolution path

There are two separate gates. A key must match an input name, and that input must be connected to an entity. Failing either gate is silent from the device’s point of view over MQTT, and reported as No connections configured over HTTP.

Payload rules

• The payload must be a JSON object. Arrays and bare values are rejected.
• Keys are matched against the device input name, not its label.
• Matching is exact — case, spelling and separators all count.
• Unmatched keys are ignored; they do not cause the rest of the payload to fail.

{
  "temperature": 23.4,
  "humidity": 58
}

{
  "Temperature": 23.4,
  "hum": 58
}

Names and labels

Partial matches

A payload with a mix of matched and unmatched keys is processed for the keys that match. The others are dropped without an error. This is convenient when a device reports diagnostic fields you do not need, and a trap when a key is subtly misspelled — the reading looks delivered and simply never appears.

If a value is missing while others from the same payload arrive, suspect the key name before anything else.

Timestamps

Readings are recorded with the time the platform processed them. A device that buffers readings while offline and flushes them later will have those readings recorded at flush time, not at sample time. Take this into account when interpreting charts after a connectivity outage.

Device status and reporting interval

A device’s online status is derived from the freshness of its data relative to its configured data interval, not from configuration alone. A device that reports less often than its interval suggests will be shown as offline between reports.

Set the data interval to match the device’s real reporting period. See Devices and I/O.