Skip to main content

End-to-end flows and checklist

This page turns the command reference into an implementation path. All frames below use synthetic identifiers and test-only PW DEMO00.

Minimal online sequence​

  1. Connect to the assigned MQTT broker using the approved profile.
  2. Subscribe to /{ProductKey}/{DeviceName}/user/get.
  3. Publish device traffic to /{ProductKey}/{DeviceName}/user/update.
  4. Send CN; repeat every 60 seconds until acknowledged.
  5. Apply the returned CN.settings keys that are present.
  6. Send DS and receive acknowledgement.
  7. Send AC, then continue at the configured inventory interval.

Synthetic examples with valid CRC:

Device -> server
{CN,DEVICE-000001,MODEM-000001,V1.51,-67,SIM-000001,0,0,796B}

Server -> device
{CN,DEVICE-000001,HB:60;BP:180;,8E6D}

Device -> server
{AC,17000003,DEVICE-000001,MODEM-000001,SIM-000001,-67,V1.51,2,1:1:PB-000001:88:1110,2:1:NULL:0:0110,40AA}

Rental sequence​

Test-only downlink examples:

{BW,17000004,ORDER-0001,1,E6AD}
{BR,17000005,ORDER-0001,B87F}
{FB,17000006,ORDER-0001,2,8395}

Return sequence​

  1. Cabinet detects insertion and sends RS (or FR for an abnormal return).
  2. Server validates CRC, device, slot, power-bank ID and current rental association.
  3. Server persists the raw report and the business decision separately.
  4. Server sends RS acknowledgement with a new message ID.
  5. Cabinet updates the return state reflected in later AC/CQ inventory.
  6. Billing/reconciliation closes only after rental, return and payment evidence agree.
{RS,17000007,DEVICE-000001,1,2,PB-000001,88,1,1,D1B9}

Integration acceptance checklist​

Transport and security​

  • MQTT authentication and topic authorization are scoped to the intended device.
  • TLS and certificate validation are enabled where supported.
  • Production PW never appears in browser code, analytics, screenshots or support exports.
  • Incoming frames are size-limited before parsing.
  • CRC comparison, field validation and authorization occur before any privileged action.

Parser​

  • Accepts complete frames split across transport packets and multiple frames in one packet.
  • Rejects invalid braces, non-ASCII command bytes and wrong field counts.
  • Preserves empty optional fields and distinguishes them from NULL.
  • Supports both three- and four-digit slot state only after profile negotiation.
  • Treats unknown enum values as unknown, not success.

Idempotency​

  • Message IDs are monotonic and reconnect behavior is tested.
  • Same order ID returns the prior result for BW, KW and FB.
  • A repeated RS/FR report does not create a second return.
  • Each BR uses a new message ID and records the acknowledged stage.

Physical UAT​

  • Online/reconnect, weak signal and broker interruption.
  • Empty, charging, full, disabled, lock-error and brand-mismatch slots.
  • Normal, 22 W, 45 W and 65 W profiles that the target hardware actually supports.
  • Prepare, payment success, payment failure, release success, pickup timeout and unlock failure.
  • Online return, offline return, lock-not-seated return and duplicate return.
  • Power cycle before/after return acknowledgement.
  • Maintenance eject, slot disable/enable and ID write with operator audit.
  • Staged firmware query/upgrade/stop/recovery on non-production hardware.

Evidence​

  • Store raw receipt time, parsed command, CRC result, business result and device outcome separately.
  • Preserve UNKNOWN when provider, device or payment evidence is unavailable.
  • Keep firmware model, version and supported-command profile with each cabinet.
  • Export logs with device, SIM, Wi-Fi, broker and credential values redacted.

Passing this checklist establishes protocol conformance for the tested device profile; it does not automatically certify every cabinet model or firmware.