Codec readiness

A codec listing, an approved version and a connected tracker describe different things. Use the checks below before directing fleet or cargo devices to a deployment. The catalogue records each adapter's implementation limits; it does not certify a customer installation or a device model.

Check each boundary

Check	What it establishes	What it does not establish
Catalogue	The declared protocol, settings and implementation status	A running customer installation or support for every model or firmware
Version approval	The registry accepted a signed version and its recorded conformance result	Device connectivity, a production load result or provider acceptance
Organisation access	A built-in codec is available, or the organisation has an active installation of an approved adapter version	A network route or a successful decode
Runtime preparation	A particular artifact compiled, linked and passed its health probe in one runtime process	Installation permission, a permanently warm runtime or a device round trip
Device check	The actual model and firmware report the expected position or event in the target organisation	Every firmware variant, every command or sustained production capacity

Built-in codecs do not need a marketplace installation. For marketplace codecs, installation, version approval and organisation access still apply. A successful runtime preparation does not bypass them. An API key also needs the scopes for each public API operation; check the organisation's plan access in the console.

Runtime preparation limits

Runtime preparation is an internal platform operation. There is no public preparation API or browser action in this guide. Do not put internal service credentials in API keys, browser code, manifests or support tickets. The preparation implementation and registry client exist in source; their presence alone does not mean a deployment has activated and connected the workflow. The installation's active label is not a readiness receipt.

Preparation checks the signed artifact and runs compilation, linking, instantiation and the codec health probe under runtime limits. Its receipt identifies the organisation, codec, version and artifact hash for that probe. The probe uses isolated, temporary key-value storage; it does not validate the operational storage provider or retain a device session. It does not decode a device frame or send a device command.

A receipt does not promise persistent precompiled artifacts, warm capacity on every runtime process, device compatibility or throughput. Confirm deployment readiness with ZAITRACK before routing devices; do not treat a source test or a compilation result as production acceptance.

Validate a fleet or cargo device

1. Check the catalogue's protocol, supported messages, limitations and transport for the exact model and firmware.
2. Confirm the organisation and approved version in Adapter Studio when an installation is required. Check the target organisation's plan access and the API key's scopes in the console and Developer Studio.
3. Ask ZAITRACK for the deployment's reachable transport address and allocated port. A registry installation does not allocate a public hostname or open a network route by itself.
4. Follow Register a tracker. Confirm that the actual device's report appears under the intended organisation, device and vehicle with the expected timestamp, position and event values.
5. Verify each required command against the catalogue and the actual device. A decoded location does not prove that remote locking, unlocking or other commands work on that firmware. Use an agreed device test procedure.

For a failure, provide the deployment, organisation, codec version, artifact hash when available, device model, firmware, transport, UTC timestamp and request identifier. Redact keys, signatures, credentials and personal data. Keep raw device payloads in the agreed secure support channel.

JT808 terminal identity and native routing

The reviewed native route selects exactly jt808.generic and jt808.huabao_elock for a dedicated JT808 runtime. jt808 is a protocol name, not another codec ID; aliases, unknown IDs, other native codecs and installed adapter identities keep their existing primary route. This route is default-off and does not install or upgrade a signed adapter. A failed dedicated call has no fallback to older decoding behavior. The showcase has refreshed the dedicated JT808 native runtime and its TCP, UDP, MQTT and command-bus callers. The retained primary adapter runtime and dedicated Teltonika runtime are unchanged. Independent checks establish selective component readiness and protected-state preservation; they do not establish a new real device report, an authenticated customer workflow or hardware acceptance. No signed JT808 module was published and no installation pin changed.

For named TCP/UDP conversations, Hello resolves the wire terminal number and returns opaque connection state. Pass that state back unchanged with the same wire terminal identity. The updated codec validates the frame terminal, supplied connection identity and state before Hello, decoding or a success reply. Do not substitute a canonical platform device UUID for the wire terminal number. Stateless Message decoding uses the canonical frame identity and does not establish connection binding.

Legacy two-byte state, malformed state, a different terminal or a named connection without state is refused. Reconnect to establish compatible state rather than fabricating it. Runtime and caller compatibility must be coordinated. For signed adapters, the reference module used for Hello and the installed pinned decoder must also be compatible: a new Hello with an old decoder does not establish this binding; an old Hello with the new decoder is refused. Publishing or changing catalogue metadata does not update an installation pin or an existing connection.

The private native command-reply path applies only to frames recognised by the existing JT808 reply classifier. It validates identity before command-waiter delivery, suppresses raw telemetry publication for that path and sanitises decoder errors. Parameter-answer details discard parameter values. Malformed checksum/header frames that cannot be classified retain the existing raw/quarantine policy; the generic signed AdapterServer also retains its existing raw-frame behavior. Do not treat this bounded native path as universal parameter-reply secrecy or include credentials in support payloads.

This connection check is not terminal credential authentication. Segmented messages remain unsupported. Native ACK/command serial allocation remains the existing global 16-bit behavior; this slice does not establish durable replay or wrap protection. Owned tests cover 2013/2019 headers, both native identities and full payload/state/ACK expectations, not every firmware or physical device. A separate three-minute owned HTTP load trial is not an hour soak, full ingress throughput or hardware/production capacity acceptance.

Follow the product JT/T 808 connection guide and verify the actual model, terminal number, organisation, transport and firmware before routing a customer device. Do not replay historical traffic to test a deployment or infer new payload/EventID guarantees from terminal binding.

Teltonika named sensors and trailer cargo authority

The showcase has refreshed native Teltonika decoding for teltonika.codec8 and teltonika.codec8e, together with the downstream trailer consumer, Web BFF and Console components. Native calls use the dedicated Teltonika runtime; installed adapter calls retain their separate path. WASM candidate 1.0.2 is still not published or pinned by this delivery. Catalogue metadata, a native component refresh and an installed adapter upgrade are different boundaries.

This delivery has not established an authenticated live test of the new cargo fields or source-selection workflow, a new real device report through that workflow, or physical probe/hardware certification. Confirm the reported channel and wiring for the actual installation before relying on cargo monitoring. The source and owned execution proofs do not replace these customer/device checks.

The codec emits Dallas channels dallas-1 through dallas-4 as separate sensors entries with type: "temperature", unit: "C" and the observed numeric value. It does not assign the first present probe to cargo.temp_c. The named observation does not prove its physical compartment or wiring location. A supported 115°C observation remains a sensor fact; it is not a valid value for the root CargoBlock, whose maximum remains 100°C. Do not clamp it or copy it into that block.

The trailer's optional reefer.cargoSensorBinding contains sourceDeviceId and channel. The source ID must be the asset's assigned trackerDeviceId; the application also checks the telemetry tenant and device. For example, the binding fragment for a verified fitted probe is:

{
  "cargoSensorBinding": {
    "sourceDeviceId": "<assigned tracker UUID>",
    "channel": "dallas-1"
  }
}

This is a reefer-field fragment, not a complete create/update request. Use the current trailer API or Console form with its full required monitoring profile and version handling. Registration fits the tracker before the final binding update; report partial failures and verify saved state instead of treating these steps as a distributed transaction. Do not use an installation-wide codec setting to assert per-asset wiring authority.

A configured named binding accepts exactly one matching Celsius reading with a finite numeric value. A missing, duplicated, wrong-unit or invalid channel does not fall back to another sensor or legacy root cargo. Without a named binding, explicit root cargo.temp_c retains its legacy path. On update, omitting cargoSensorBinding preserves the existing binding when the tracker is unchanged; explicit null clears it. Replacing the tracker clears the old binding unless an explicit new binding is supplied for that tracker. An older server may discard unknown binding JSONB, so coordinated writer/schema rollout is required.

cargoTempAt records the accepted temperature's event time independently of lastSeenAt. GPS/door-only updates do not refresh it; historical missing timestamps remain null. Source/tracker changes reset the old stored temperature and detection window. Profile changes also reset detection. Excursion endReason distinguishes in_range, monitoring_source_changed, monitoring_profile_changed and asset_retired; historical missing reasons remain null. Administrative closure is not measured recovery. Future-dated event versus administrative closure chronology remains a separate host-policy gap; do not infer chronological validation from this projection.

For the deployed components, verify the fitted tracker, exact channel and physical wiring; then check an accepted reading, its temperature timestamp and the configured excursion duration. A missing reading must not select a replacement source. Do not send device commands or alter real cargo temperatures merely to validate this documentation. A changed CTM payload changes payload-hashed EventID; follow the agreed codec-version/pin and replay policy rather than replaying historical traffic as if identity were unchanged.

See the product Cold chain guide for the operator workflow.

Suspension, upgrades and revocation

An installation can be suspended or uninstalled, and a signed version or key can be revoked. Runtime registry lookups cache successful responses for up to 30 seconds, so access changes are not an instant network disconnect. After an upgrade or access change, repeat the relevant device checks. The registry's latest approved version is not proof that a customer's installed version or a live device session has changed.