Wi-Fi Devices · Direct to Your Broker
DEVICE → YOUR MQTT BROKER → YOUR SERVER
The second integration family needs no gateway and no OWON cloud. OWON Wi-Fi devices — energy meters and the PCT-series thermostats — speak MQTT straight to a broker you operate. Device and business systems are fully decoupled by the publish/subscribe model, so data collection, command delivery and business logic all live on your side and your data never transits ours.
Three-Layer Architecture
Device Nodes Layer
OWON Wi-Fi devices — thermostats, power meters, gateways and other embedded or sensor devices. Each one opens a TCP/IP connection to your MQTT broker, publishes telemetry, status and events to predefined topics, subscribes to control topics and executes what your server sends.
MQTT Broker Layer
The broker you run is the core routing component: persistent connections, authentication, session and keep-alive management, topic-based routing. It decouples device communication from your business logic entirely.
Your Server Layer
Your systems subscribe to the topics they care about to receive device data, and publish control or configuration commands back. Bidirectional, real-time, and nothing transits an OWON server.
Integration in Five Steps
Prepare your MQTT broker
EMQX, Eclipse Mosquitto, VerneMQ or AWS IoT Core are recommended. Any standards-compliant broker works.
Configure the device
Wi-Fi credentials, broker address/port, MQTT connection parameters, device identity and time zone. Use the X5 Config Tool (search the App Store) or build your own tool on the Configuration API. Devices support BLE and Wi-Fi AP configuration modes.
Device data publishing
After the startRegister command the device leaves configuration mode, joins your Wi-Fi and connects to your broker, then publishes per the topic list.
Server subscription & processing
Subscribe to the attribute-report and event topics; payloads are JSON (raw data streams are Base64/Hex encoded inside JSON).
Command publishing & control
Publish set-attribute and control commands on the command topics; the device executes and reports the new state back.
What the Device API Covers
Device API per model
Each family ships a Device API document — e.g. PCT513 covers topics, attribute lists, set/report examples, firmware upgrade (OTA), weather forecast pull and time synchronization.
Firmware upgrade over the same broker
Upgrade query, trigger and feedback run through documented topics, so your server controls the rollout.
Lightweight by design
MQTT over TCP/IP keeps bandwidth low and delivery reliable — suited to constrained devices and unstable networks.
Get the Topic Lists & Device API
The full topic definitions, attribute lists (string and raw payloads), configuration-command set and firmware-upgrade flows are documented per device family — the Device Integration Overview plus each model's Device API document. Our engineering team delivers them together with sample devices for evaluation.
Request Device API DocsLooking for Zigbee devices behind a gateway instead? See the 6000 system paths (Methods A–D).