The Phase 3 specification (PHASE-3-PROTOCOL, v1.0.0) defines network protocols, security requirements, device discovery and firmware update mechanisms for cleaning robots. Where the Chapter 5 API defines what is exchanged, Phase 3 defines over which channels, and how securely.
On the local network the specification supports four protocols.
| Protocol | Purpose |
|---|---|
| HTTP/HTTPS | REST API (Chapter 5) |
| WebSocket/WSS | Real-time status updates |
| MQTT | Publish/subscribe messaging |
| mDNS/Bonjour | Device discovery |
Other protocols (for example CoAP or gRPC) are not part of the standard. Where they are needed, they must be provided through the protocol translation middleware allowed by section 9.2 of the specification (HTTP-to-MQTT bridge, WebSocket-to-gRPC conversion, legacy protocol adapters) or as vendor extensions prefixed with x_, and they must be clearly identified as non-standard extensions.
MQTT topics follow this structure:
wia/rob/{robot_id}/{category}/{subcategory}
The standard topics defined by the specification are:
wia/rob/{robot_id}/status
wia/rob/{robot_id}/battery
wia/rob/{robot_id}/position
wia/rob/{robot_id}/sensors/lidar
wia/rob/{robot_id}/sensors/camera
wia/rob/{robot_id}/map/update
wia/rob/{robot_id}/command
wia/rob/{robot_id}/event
Message payloads on these topics use the Phase 1 formats from Chapter 4: for example, RobotCommand documents are published on the command topic and RobotEvent documents on the event topic. MQTT wildcards allow a client to subscribe to all of one robot's sensors (wia/rob/{robot_id}/sensors/#) or to the status of many robots (wia/rob/+/status) at once.
| Message type | QoS | Meaning |
|---|---|---|
| Status updates | 0 | At most once (fire and forget) |
| Commands | 1 | At least once |
| Critical alerts | 2 | Exactly once |
Because commands are delivered with QoS 1, the same command may arrive twice. Robots should therefore remember the commandId of each RobotCommand and execute duplicates only once.
Connections using TLS 1.2 or earlier are not permitted. All network communication in transit uses TLS 1.3, and cloud synchronisation uses end-to-end encryption. MQTT and WebSocket must also run over TLS (MQTTS and WSS respectively).
Maps and camera images reveal the layout of homes and facilities and images of people, so these requirements must be applied especially strictly to them.
Robots advertise themselves on the network using mDNS. The service type and TXT records are:
Service Type: _wia-rob._tcp Port: 8080 TXT Records: - version=1.0.0 - manufacturer=CompanyName - model=ModelName - serial=SerialNumber - capabilities=slam,camera,mopping
Discovery takes five steps:
1. Check for updates GET /firmware/check
Response: { "available": true, "version": "1.2.0", "size": 25600000,
"checksum": "sha256hash", "url": "https://..." }
2. Download firmware GET /firmware/download (binary stream with progress)
3. Verify checksum client-side SHA-256 verification
4. Install POST /firmware/install
Response: { "status": "installing", "estimatedTime": 300 }
5. Reboot automatic after installation
6. Verify version check the firmwareVersion field of GET /robot/status
POST /firmware/rollback| Synchronised data | Frequency |
|---|---|
| Status | Real time (WebSocket) |
| Maps (encrypted) | After each update |
| Cleaning history | Daily batch |
| Configuration | On change |
As an example cloud API, the specification gives POST /robots/register, GET /robots/{robot_id}/status, PUT /robots/{robot_id}/config, GET /robots/{robot_id}/history and POST /firmware/update under https://cloud.wiastandards.com/api/v1. Note that this path scheme differs from the local API served by the robot itself (/api/v1/robot/..., Chapter 5).
Phase 3 also defines how cleaning robots map onto the main smart home standards. How the integrations are actually set up is covered in Chapter 7.
| Platform | Mapping in the specification |
|---|---|
| Matter/Thread | Device type Robotic Vacuum Cleaner (0x0074); required clusters On/Off, Fan Control, Robot Vacuum Mode, Battery Status (the specification's informal labels) |
| Apple HomeKit | Service type Fan; characteristics On (required), Rotation Speed (suction power), Current/Target Fan State |
| Amazon Alexa | Voice commands to start cleaning, clean a specific room and check the battery |
| Google Home | Traits OnOff, FanSpeed, EnergyStorage |
Erratum: the Phase 3 specification document gives the Matter device type as 0x0073, which is an error. In the Matter Device Library 0x0073 is the Laundry Washer; the Robotic Vacuum Cleaner is 0x0074. The cluster names in the table above are also the specification's informal labels, not Matter cluster names; an implementation should be based on the RVC Run Mode, RVC Clean Mode, RVC Operational State and Power Source clusters.
GET /health
Response:
{
"status": "healthy|degraded|unhealthy",
"checks": { "battery": "ok", "sensors": "ok", "navigation": "ok", "network": "ok" },
"uptime": 86400
}
GET /diagnostics/logs?level=error&limit=100
Each diagnostic log entry consists of a timestamp, a level (error, warning, info or debug), a component and a message.
Section 9.3 of the specification lists these performance techniques: maintaining persistent connections, reusing TLS sessions, minimising handshake overhead, gzip compression for text data, binary protocols for sensor streams, and adaptive compression based on bandwidth.
When the connection is lost, the robot fails over in the order primary server → secondary server → local mode. The recovery procedure is:
Section 10 of the specification requires the following tests for certification: TLS handshake verification, authentication flow testing, data format validation, error handling verification and performance benchmarking. Certified products must also undergo an annual security audit. These items are reflected in the checklist in Chapter 8.
wia/rob/{robot_id}/{category}/{subcategory}_wia-rob._tcpR-17.