Developer Center
OWON supports two integration families. The 6000 gateway system exposes four symmetric paths between your stack and ours — cloud-to-cloud, gateway-to-cloud, gateway-to-gateway and device-to-gateway. Separately, our Wi-Fi devices (smart meters, thermostats) talk MQTT straight to your own broker, with no gateway and no OWON cloud involved. This portal summarizes the architecture so you can pick the right path; complete specifications are delivered to project partners by our engineering team.
6000 System — Four Integration Paths
Google Assistant / Alexa / IFTTT bridges are implemented on your server in Methods A and B — OWON exposes the device layer, your platform owns the voice and automation layer.
Family 1 · Gateway System (6000)
Zigbee devices behind an OWON gateway (or gateway board). Four symmetric paths let you attach at whichever layer fits your product — server, gateway, or device.
Method A · Cloud to Cloud
The gateway stays connected to the OWON server. Device data uploaded by the gateway and commands sent to it are forwarded to your platform over HTTP/HTTPS; your server accesses its gateways through agent authorization.
Best for: SaaS platforms and quick pilots — no gateway-side work at all
Method B · Gateway to Cloud
The OWON gateway connects directly to your own server. All data management and communication lives on your side — no OWON cloud in the loop. MQTT topics plus a TCP frame mechanism are fully specified.
Best for: Private deployments, energy-management platforms, data-sensitive customers
Method C · Gateway to Gateway
Use only the PCB inside an OWON gateway: dock the board to the MCU of your own device (gateway or hub) over UART and drive it with the Gateway API command set. Your hardware gains a full ZigBee master.
Best for: OEM / ODM manufacturers embedding gateway capability in their own product
Method D · Device to Gateway
OWON Zigbee end devices join a third-party gateway and exchange data with it only. Each device model ships with a cluster & attribute document — standard ZCL clusters plus OWON-specific ones where needed.
Best for: Hub makers, smart-home platforms, building-automation controllers
Family 2 · Wi-Fi Devices, Direct to Your Broker
Smart meters and Wi-Fi thermostats connect straight to an MQTT broker you run. Three layers — device nodes, your broker, your server — fully decoupled by publish/subscribe. No gateway, no OWON cloud, your data stays on your infrastructure.
Device Nodes
Energy meters · thermostats · sensors
Your MQTT Broker
EMQX · Mosquitto · VerneMQ · AWS IoT Core
Your Server
Subscribe to data, publish commands
- 1
Prepare your MQTT broker
EMQX, Eclipse Mosquitto, VerneMQ or AWS IoT Core — the device connects to you, not to OWON.
- 2
Configure the device
Use the X5 Config Tool (App Store) or build your own tool on the Configuration API: Wi-Fi credentials, broker address, device identity, time zone.
- 3
Device publishes data
Telemetry, status and events go to predefined MQTT topics as the device sees them.
- 4
Your server subscribes
Consume the topics relevant to your business logic.
- 5
Publish commands back
Control and configuration flow down the command topics; the device executes them.
One Command Dictionary Across Methods A–D
Requests from your server, your hub or your MCU to an OWON gateway all follow the same Gateway API command format — type, command, argument, sequence. MQTT payloads, TCP frames, UART commands and forwarded cloud traffic share it, so an integration built on one path transfers to the others.
The Gateway API document, Server API document, topic/payload definitions, device-model mapping table and per-device cluster lists are delivered to project partners together with credentials.
Full Documentation on Request
This portal gives you the architecture and the parts you need to design against: real topic schemes, frame formats, sequence samples and published cluster examples. The complete integration package — authentication (agentId/agentKey → accessToken), the Gateway API command dictionary, device-model table, per-device API documents and cluster lists — is provided by our engineering team along with the credentials your project needs.
Common Questions
Which family / method should I pick?
Zigbee devices behind our gateway → the 6000 system (A for a quick cloud pilot, B for private servers, C to embed our board in your hardware, D if you already run your own Zigbee hub). Wi-Fi meters and thermostats → the direct MQTT line, straight into your broker.
Do devices work without internet?
Yes. Gateways keep local Zigbee control and device interoperation running offline; data and commands sync when the link is back. Direct Wi-Fi devices only need reachability to your broker.
How do I get API credentials?
agentId / agentKey and access tokens are provisioned per project by our team — contact us with your use case.
Can I both read telemetry and control devices?
Both ways: telemetry uplink (energy, temperature, status) and command downlink (relay, setpoint, configuration) are defined in the Gateway API document, the device API documents and the per-model cluster lists.