Samples

One short, real example per path, taken from the official integration documents. They show the shape of a working exchange — enough to design against before the full specifications and credentials arrive.

1. Method A · Cloud to Cloud

HTTP Server API — obtain a 24-hour accessToken, then call agent APIs

                    # 1. Authenticate with the agentId/agentKey OWON provisions
POST ${OWON_SERVER}/busproc/nt/agent/getaccesstoken
Content-Type: application/json; charset=utf-8

{
  "agentId": "testagentid",
  "agentKey": "testkey",
  "cmd": "getaccesstoken"
}

# Response — accessToken valid 24h, refreshToken to renew it
{
  "code": "100",
  "accessToken": "***",
  "refreshToken": "testRe…oken"
}

# 2. Every later call carries agentId + accessToken
{ "agentId": ..., "accessToken": ..., "cmd": "userGw" ... }
Full details → Method A · Cloud to Cloud

2. Method B · Gateway to Cloud (MQTT)

Official payload sample — switch a smart plug (entire Gateway API package in the payload)

                    # Publish to the gateway's command topic
api/device/{'$'}{gateway_mac}/{'$'}{your_client_id}

{
  "type": "smartPlug",
  "sequence": 1017,
  "command": "setSwitchgear",
  "argument": {
    "ieee": "0100000000221100",
    "ep": 1,
    "switchgear": "off"
  }
}

# Gateway answers on reply/device/{'$'}{gateway_mac}/{'$'}{your_client_id}
{
  "result": true,
  "switchgear": "off",
  "ieee": "0100000000221100",
  "ep": 1,
  "description": "setOnOff back success",
  "sequence": 1017
}

# The docs' own CLI test command:
mosquitto_pub -h broker.xxx.com \
  -t "api/device/{'$'}{gateway_mac}/{'$'}{client}" \
  -m '{"type":"smartPlug","sequence":1017,"command":"setSwitchgear","argument":{"ieee":"0100000000221100","ep":1,"switchgear":"off"}}'
Full details → Method B · Gateway to Cloud (MQTT)

3. Method D · Device to Gateway

ZCL on your coordinator — DWS332 IAS Zone enrollment

                    # Device → your gateway (cluster 0x0500, generated)
ZoneEnrollRequest  zoneType = 0x0015  (contact switch)

# Your gateway → device
ZoneEnrollResponse enrollResponse = SUCCESS

# Every open/close event
ZoneStatusChangeNotification
  zoneStatus bit0 = 1  → opened
  zoneStatus bit0 = 0  → closed
Full details → Method D · Device to Gateway

4. Wi-Fi Direct · Your Broker

Real device-side flow from the Device API document — nothing transits OWON

                    # 1. Put the device in configuration mode (BLE or Wi-Fi AP)
#    Configure: Wi-Fi credentials, MQTT broker settings,
#    device identity, MQTT connection parameters,
#    time zone & location — via X5 Config Tool or your
#    own app built on the Configuration API. All
#    application-layer messages are JSON.

# 2. Send startRegister → device exits config mode,
#    joins your Wi-Fi, connects to YOUR broker

# 3. Steady state: device publishes attribute reports
#    (string or raw payloads), your server publishes
#    set-attribute commands; OTA, weather and time
#    sync run over the same broker connection.

# Broker options from the official guide:
EMQX · Mosquitto · VerneMQ · AWS IoT Core
Full details → Wi-Fi Direct · Your Broker

Where Credentials Come From

agentKey / agentSecret (Method A) are provisioned per project by our engineering team after NDA on request; Methods B–D and the Wi-Fi direct line need no OWON credentials at all — the devices talk to your server, broker or coordinator. Endpoint hosts and topic names follow the pattern shown; request the specification documents for production values.

Continue