Transport, topics and CRC

Supported transport models

IoT middleware package

CoreCharge can provide a deployable middleware package. Device traffic is wrapped over MQTT, while the operator system calls the middleware through HTTP POST and receives callbacks. The HTTP business API is versioned separately from this device protocol.

Per-device IoT credentials

Each cabinet receives a ProductKey, DeviceName and DeviceSecret. The default topic template is:

Direction	Topic
Device subscribes	/{ProductKey}/{DeviceName}/user/get
Device publishes	/{ProductKey}/{DeviceName}/user/update

Generic MQTT broker

The operator provides an approved broker host and port, authentication model and topic profile. Authentication may be one credential per device or one scoped account shared by a controlled device group. The same default topic template can be used when the selected profile supplies ProductKey and DeviceName.

Production values

Broker addresses, ports, usernames, passwords, device secrets, Wi-Fi credentials and real device identifiers are deliberately absent from this public site. Their absence does not change the protocol.

CRC16/MODBUS rule

1. Remove the outer braces and the final CRC field.
2. Keep the command, every data field and the comma after the final data field exactly as transmitted.
3. Take the first six characters of configured PW; right-pad with 0 when shorter than six.
4. Append that six-character secret to the retained text.
5. Calculate CRC-16/MODBUS over the ASCII bytes: initial value 0xFFFF, polynomial 0xA001 in reflected form.
6. Render the 16-bit result as four uppercase hexadecimal characters, high byte on the left.

For a query whose visible fields are CQ,17000000,0 and whose non-production PW is DEMO00, the CRC input and frame are:

CRC input: CQ,17000000,0,DEMO00
CRC result: 6F75
Wire frame: {CQ,17000000,0,6F75}

The PW suffix is not present in the wire frame.

Reference implementation

export function crc16ModbusAscii(input) {
  let crc = 0xffff;
  for (const byte of new TextEncoder().encode(input)) {
    crc ^= byte;
    for (let bit = 0; bit < 8; bit += 1) {
      crc = (crc & 1) ? ((crc >>> 1) ^ 0xa001) : (crc >>> 1);
    }
  }
  return (crc & 0xffff).toString(16).toUpperCase().padStart(4, '0');
}

export function protocolCrc(dataWithoutCrc, password) {
  const secret = String(password ?? '').slice(0, 6).padEnd(6, '0');
  return crc16ModbusAscii(`${dataWithoutCrc},${secret}`);
}

Download the complete frame builder and verifier.

Receipt and retry behavior

• A device repeats CN every 60 seconds until the server acknowledges it.
• A device repeats DS every 60 seconds until acknowledged.
• The default AC or CQ inventory interval is 180 seconds.
• The default AE extended report interval is 600 seconds.
• A duplicate rental command with the same order ID must return the cached prior result where the command specifies idempotency.
• BR acknowledgements use a new message ID; do not reuse the request ID.
• Integrity acceptance, command acceptance and physical outcome are separate states.

Parser order

1. Locate one complete {...} frame.
2. Verify ASCII and the outer markers.
3. Split on English commas.
4. Select the schema using the command and negotiated firmware profile.
5. Validate field count, types, ranges and identifier lengths.
6. Recalculate CRC using the configured PW suffix and compare in constant time.
7. Apply message-ID and order-ID idempotency.
8. Handle the command, then persist transport, business and physical outcomes separately.