Migrating 8,000 Washing Machines from Ad-Hoc Topics to a Modelled IoT Platform
An appliance maker has 8,000 connected washing machines in customers' homes and plans to reach 200,000 within two years. Today each machine publishes to a self-managed MQTT broker on topic device/{imei}/data with a 400-byte ad-hoc JSON payload every 30 seconds; nothing is modelled, so every dashboard is a hand-written parser. The company is migrating to Huawei Cloud IoTDA and wants 12 named properties per machine, a remote descaling command with three parameters that returns an acknowledgement within 20 seconds, and firmware of 2.5 MB delivered over the air in campaigns of 500 units with rollback. Machines are Wi-Fi connected behind home routers, some are powered off for weeks, and support staff must still see their last known state. During the pilot, batch registration of the first 8,000 devices failed at row 4,000 with a duplicate node identifier error, and the command interface returned device not online for about 30% of machines the OEM believed were connected.
1. Design the device model and the topic migration, and explain what breaks if the ad-hoc topics are kept.
Read the worked answer
Define one product with one or more services, each holding the 12 properties with a declared data type, access mode and unit, plus the descaling command with its three input parameters and its response parameters. Declare the reporting format (JSON first, binary later) and keep the device identifier stable and unique: use a logical device ID issued at manufacture, and carry the IMEI as a read-only property rather than embedding it in the topic.
Topics must move to the platform's reserved system topics for property reporting, command delivery and command response. If the ad-hoc topic is kept, the platform treats the device as connected but opaque: it cannot parse properties, cannot drive dashboards, cannot run rule engine actions, cannot target OTA by property, and cannot maintain a device shadow. You have moved bytes, not devices.
Migration sequence that avoids a big-bang: keep the old broker in parallel, ship firmware that connects to the new endpoint and reports a small subset of properties, verify shadow updates and command round-trip on a 200-unit cohort, then expand and switch dashboards to platform queries. Keep the old topic as a temporary mirror for the legacy dashboards rather than retrofitting them later.
One design point worth defending in review: model the 12 properties with realistic types and enumerations now. Changing a property type after 200,000 devices are reporting is far more painful than the extra day spent on the model.
2. Diagnose the duplicate node identifier failure at row 4,000 and the device not online condition affecting 30% of machines, and then define correct command semantics for the 20-second acknowledgement.
Read the worked answer
The registration failure is a data problem, not a platform limit: the import file contains a device identifier that already exists, either a genuine duplicate from the legacy IMEI list, a re-flashed unit reusing an identifier, or a trailing space or case difference that the platform treats as identical. Fix by validating the file first (uniqueness, allowed characters, length, empty rows), importing in chunks, and diffing against existing registrations before retrying. Expect the true culprit to be two source systems with different notions of device identity.
Device not online usually has one of three causes. Most likely here is duplicate client identifier: two machines, or an old and new firmware build, connecting with the same device ID cause mutual disconnection in a loop, which presents as a stable percentage that never connects. Second is keepalive versus NAT: a 300 s client keepalive expires after a home router or carrier NAT has already dropped the mapping at 60 to 120 s, leaving a half-open session the platform eventually times out. Third is a firmware cohort that never re-pointed to the new endpoint. Check the disconnect reason codes and connection logs per device before changing any firmware.
For commands: the platform can only deliver when a session exists. Set the 20 s timeout server-side, require an explicit response on the response topic with a result code, mark timeout distinctly from failure, and queue requests for offline devices as desired state rather than returning an opaque error. Support staff should see last reported state from the shadow, with the timestamp, never a stale value presented as live.
3. Plan the OTA campaign and the message-rate budget for 200,000 machines.
Read the worked answer
OTA first. The platform hands out a download URL; the device fetches and verifies. At 2.5 MB over home Wi-Fi the transfer is seconds, so the risk is not time, it is flash and power. Confirm the device has room for two application banks plus the download buffer; if 2.5 MB x 2 does not fit, an A/B rollback promise is fiction. Require signature and hash verification, resume or restart on interruption, and a progress report per phase so a failed campaign is diagnosable. Campaigns of 500 are sensible: they cap concurrent downloads, limit blast radius, and let you stop on an error-rate threshold. Include the previously powered-off population explicitly; they will upgrade whenever they next appear, so version skew must be a first-class query, not a surprise.
Messaging budget. Today 8,000 devices at 30 s is 267 msg/s. At 200,000 it becomes 6,667 msg/s, and at 400 bytes that is roughly 2.7 MB/s, or about 230 GB/day. That is a cost and quota conversation, not just a capacity one.
Reduce it at the source: report on change with a deadband for the 12 properties, keep a 5-minute heartbeat so presence is still visible, and send immediate reports only for fault and cycle-complete events. That typically cuts steady-state volume by an order of magnitude while improving, not degrading, the data that support actually uses. Set per-device rate limits so one faulty machine cannot flood the pipeline.