Quanergy · AsyncAPI Specification

Quanergy Qortex Dtc Events

Version

View Spec View on GitHub CompanyLiDARSensorsPhysical SecurityPerimeter SecurityPerceptionCrowd ManagementIndustrial AutomationInternet of ThingsgRPCStreamingHardwareAsyncAPIWebhooksEvents

AsyncAPI Specification

quanergy-qortex-dtc-events.yml Raw ↑
generated: '2026-08-05'
method: derived
source: https://downloads.quanergy.com/qortex/Qortex-API-Reference-RevA-120824.pdf
x-evidence:
  fetched: '2026-08-05'
  url: https://downloads.quanergy.com/qortex/Qortex-API-Reference-RevA-120824.pdf
  http_status: 200
  document: QORTEX DTC for Q-Track API Reference, QPN 96-00134 Rev A

api: QORTEX DTC API
asyncapi_spec_published: false
webhooks_published: false
x-note: >-
  Quanergy publishes NO AsyncAPI document and NO webhook catalogue, so no `AsyncAPI` or
  `Webhooks` pointer is wired in apis.yml — this file is an honest catalogue of the event surface
  the API Reference documents, not a specification we authored on the provider's behalf. QORTEX
  DTC's eventing is not HTTP callbacks: it is (a) raw TCP fan-out publishers the consumer dials
  into, and (b) a gRPC bidirectional PubSub stream. Both are pull-side subscriptions on the
  customer's own network.

surfaces:

  - kind: tcp-publisher
    protocol: TCP (raw socket)
    description: >-
      The QORTEX DTC server serialises its processing output onto configurable TCP ports. Any
      number of third-party host applications may subscribe. Encodings are protobuf (recommended),
      json, xml or ndjson; `none` disables the channel and is the shipped default. Changing an
      encoding requires a server restart.
    configuration: '`<TCPPublishers>` section of settings.xml, or the SetSettings gRPC method'
    security: >-
      When Security mode is enabled the payloads are AES-256 encrypted with the key obtained from
      the `Q-Token` header, and `<AddDataSize>true</AddDataSize>` must be set on the publisher.
    channels:
      - name: trackable list
        port: 17161
        listener_topic: qtrack
        payload: QTrackableArray
        rate: 'capped by <TrackerPipeline><frequency> (Hz); cannot exceed LiDAR spin rate for a single-sensor area'
        purpose: >-
          Detailed position, size, velocity, acceleration, heading and classification for every
          tracked person/vehicle.
      - name: zone list
        port: 17172
        listener_topic: qzone
        payload: QZoneArray
        rate: 'per frame, typically 10 Hz'
        levels:
          0: publishes zones with the list of objects inside
          1: 'publishes on trackable state change — Enter, Exit, Appear, Disappear'
          2: 'as level 1, additionally gated by the zone event configuration'
        purpose: Perimeter breach and occupancy events for alarm handling and PTZ slaving.
      - name: counter line object list
        port: 17163
        payload: counter line object list message
        purpose: >-
          Counts and timestamps of trackables crossing a configured counter line in the FORWARD or
          BACKWARD direction. A separate counter-line detection message is also documented, along
          with a zero-count variant and an NDJSON variant.
      - name: sensor health / state list
        port: 17168
        listener_topic: qsensorstate
        payload: SensorStateList
        rate: '0.2 to 0.05 Hz (every 5 to 20 seconds); slower as more sensors are polled'
        purpose: 'Per-sensor CONNECTED/DISCONNECTED, masking status and SNMP telemetry (temperature, frame rate, error code).'
      - name: point cloud
        port: 17173
        listener_topic: pointcloud
      - name: state
        port: 17178
        listener_topic: qstate
      - name: configuration client data
        port: 17175
        audience: QORTEX DTC configuration client
      - name: monitor client data
        port: 17176
        audience: QORTEX DTC monitor client

  - kind: grpc-pubsub
    protocol: gRPC bidirectional streaming
    port: 17177
    method: 'rpc PubSub(stream PubSubRequest) returns (stream PubSubResponse) {}'
    description: >-
      A client subscribes by topic; the server then pushes state changes to every subscribed
      client. Documented triggers include starting/stopping a location, a sensor spinning up or
      disconnecting, recording start/stop, zone add/edit/remove, playback start/complete, sensor
      status (temperature, error code), and licence state.
    topics:
      - name: UNKNOWN
        value: 0
        note: reserved, to avoid the default enum value
      - name: CONNECTION_STATUS
        value: 1
        note: >-
          Streaming type; only meaningful for the C++ client, used to notify that a connection was
          established or interrupted. Other clients receive blank messages.
      - name: SERVER_MESSAGE
        value: 2
        note: 'General messages — server error, replay status, etc. Delivered to monitor clients as well as config clients.'
      - name: SERVER_STATE
        value: 3
        note: 'Play status changes — start/stop/pause/resume, live/playback position. Config clients only.'
      - name: SENSOR_STATE
        value: 4
        note: 'Published on a fatal SNMP-field error or when a sensor changes to disconnected. Config clients only.'
      - name: ZONE_STATE
        value: 5
        note: Published when a zone is created, updated or deleted. Config clients only.
      - name: JSON_PUSH
        value: 6
        note: Used for pushing notifications from the server in JSON format.

  - kind: grpc-push-notification
    group: Security
    description: >-
      Server-initiated JSON notifications pushed to one or all clients, carried in the
      `{"group": "...", "command": {"id": "...", "params": {...}}}` envelope.
    events:
      - id: State
        params: {secured: 'v2 | none', pwd_change: 'true (only when an admin changed the password)'}
        note: '`v2` means secured under version 2; `none` means not secured at all.'
      - id: Expiring
        params: {hours: 'hours until the account expires'}
        scope: one client
      - id: Expired
        params: {}
        scope: one client

  - kind: outbound-notification
    description: >-
      The product overview states the object list "provides a basis for further action outside of
      QORTEX DTC, such as the notification of external alarm systems via LAN, TCP, UDP, and HTTP
      GET", and the Rules API supports a `NetworkAction` rule type. No catalogue of these outbound
      calls — payloads, headers, retry behaviour — is published, so they are recorded here as a
      named capability only.
    documented_detail: none

consumption_tooling:
  - name: qortex_listener
    note: 'Reference C++ listener; handles Digest auth and AES-256 decryption. See cli/quanergy-cli.yml.'
  - name: netcat / PuTTY
    note: >-
      The reference sanctions `nc x.x.x.x 171xx` to confirm a publisher is live. Works only for the
      human-readable JSON and XML encodings, not for protobuf.

gaps:
  - No AsyncAPI document for a surface that is entirely event-driven.
  - No HTTP webhook catalogue, so there is no way to receive events without holding a socket open.
  - >-
    The counter-line, point-cloud and `qstate` payload schemas are not printed in the reference the
    way the trackable, zone and sensor-state messages are.
  - >-
    The `NetworkAction` rule type and the "HTTP GET to external alarm systems" capability are named
    but never specified.