Data conventions

The gateway’s four interfaces were built at different times and do not share one convention. This page collects the differences so you do not carry an assumption from one into another.

Nothing here applies to the HTTP APIs

The gateway does not use the Key/Value response envelope of the EI-Analytic™ API or the PHANTOM® Web Service. Its JSON interfaces use a type property instead.

Message shape

Interface	Shape
Modbus	Binary holding registers, no JSON
MQTT telemetry	Flat JSON object with a dataType field
Management API	JSON object with a type field: stateupdate, statepatch, observeerequest
OPC UA	A variable tree, no messages

Timestamps

⚠️ The unit changes between interfaces. This is the single easiest thing to get wrong.

Interface	Field	Unit
MQTT telemetry	timestamp	Seconds since 1970
Management API	lastseen, lastseqchange, lastcollection	Milliseconds since 1970

Management API timestamps are on the gateway’s clock

They are not your server’s time. If the gateway’s clock drifts, so do they.

Numeric scaling

Modbus registers carry integers, so values are pre-multiplied:

Value	Encoding	To read
Temperature	°C × 100	Divide by 100
Battery voltage	centivolt	Divide by 100
Current	centiampere	Divide by 100

All Modbus registers are little endian. The JSON interfaces report the same quantities already scaled — "battery": 3.28 is volts, "temperature": 30.75 is °C.

Identifiers

Name	Where	Refers to
phantomCode	Management API state, MQTT telemetry	Sensor serial number
phantomcode	Management API commands	Sensor serial number
gwSerial	Management API over MQTT	Gateway serial number

The casing differs between state and commands

The state object reports phantomCode; commands expect phantomcode, all lowercase. They are the same value. Transcribed as published.

The source is also inconsistent about whether phantomcode in a command is a string or a number — see the note on the Management API page.

Sensor type codes

The gateway uses one table across Modbus and the Management API — triaxial sensors are 3, 5 and 6 — with slightly different labels in each document.

⚠️ That table is not the one the Phantom Web Service uses, where triaxial sensors are 10 and 11. Gateway-side and service-side appear to be two deliberate encodings, but that is pending confirmation. Never reuse one for the other.

• Modbus type codes
• Management API type codes

Battery type codes

Also inconsistent between interfaces:

Interface	Codes
MQTT telemetry, OPC UA	1 = 1/6D, 2 = AAA, 3 = CR2032, 4 = CR2477
Management API	The same four, plus 6 = D size PHANTOM® Max. Code 5 is absent

The PHANTOM® Web Service instead publishes voltage thresholds per type, with no battery names. Whether its type 1–3 line up with these is pending confirmation.