Message Schema
The v2 message format removes several fields, renames others, and introduces new ones. Review the table below and update your message parsing logic before migrating.
| v1 field | v2 field | Change |
|---|---|---|
uuid |
uuid |
Unchanged |
| — | customer_site |
Added |
device_uuid |
— | Removed |
sensor_uuid |
sensor_uuid |
Unchanged |
channel_id |
channel_no |
Renamed — now a channel index rather than a generated identifier |
device_serial_no |
— | Removed |
sensor_serial_no |
serial_no |
Renamed |
tenant_uuid |
tenant_uuid |
Unchanged |
timestamp |
timestamp |
Unchanged |
timestamp_local |
timestamp_local |
Unchanged |
measurement |
measurement |
Unchanged |
physical_property_name |
physical_property_name |
Unchanged |
physical_unit |
physical_unit |
Unchanged |
physical_extension |
physical_extension |
Unchanged |
| — | model_code |
Added |
processed_at |
processed_at |
Unchanged |
Update your parsing logic before switching
Fields that are removed (device_uuid, device_serial_no) will no longer be present in v2 messages. Fields that are renamed (channel_id → channel_no, sensor_serial_no → serial_no) will arrive under the new name only. Make sure your application does not depend on the old field names before scheduling the switch.