Energy & digital infrastructure

IoT hardware

In connected-hardware projects, protocols and exception handling are most of the work. When a device counts as offline, how buffered data is replayed, and what happens when a firmware upgrade fails all belong in the design.

Cluster Digital infrastructure
Focus Onboarding · firmware
Delivery Gate by gate, acceptable and operable

How we see this industry

Devices and protocols

On IoT hardware, screens are rarely the work. Protocol, register, auth, shadow state, offline rules, catch-up after a drop, OTA fail-and-rollback decide whether devices stay online in the field. We write the device model first: class, firmware, capabilities, gateway, space. When one platform meets several vendors, the adapter layer must be addable—not a core rewrite per vendor. How long is offline, how often a heartbeat, how wide the catch-up window, follow field network, not lab Wi-Fi acceptance.

Downlink commands

Commands down are more dangerous than telemetry up: mis-control, retries that execute twice, busy rejects all need a state read-back. Alarms distinguish sensor fault from a process limit. Bulk config and groups matter; thousands of devices cannot be tapped one by one. Install, replace, and retire enter the system or warehouse units and platform IDs will not match.

OTA and rollback

One failed full-fleet upgrade bricks the site. We grey, check versions, trip a fail threshold, and keep a rollback package. Whether process pauses during upgrade is a scene decision. Certificates, keys, and rogue devices follow the project’s actual threat—not a pile of security nouns.

Install and accept

Onboarding needs install location, photos, and acceptance or platform online rate will not match the site. Gateway and child topology must be visible; swapping a gateway cannot orphan children. Alarm suppression sits with the on-call roster; blasting every heartbeat fail to one phone at night gets push turned off. Certificate expiry, rogue devices, and weak passwords follow real threat, not a security word salad.

A small real site

Go-live installs a small batch in the real environment, running offline, catch-up, upgrade, and replace, then expands. Field install manuals and RMA swap flows are deliverables, not attachments. Training is implementers and operations, not a demo wall for a PM. An IoT system that works finds devices, trusts state, dares to upgrade, and can swap a fail—platform numbers and physical units are the same set.

Typical scenarios

Device onboarding

Multi-protocol onboarding with uniform registration and authentication, and new models added from a template.

Firmware and remote control

Staged firmware rollout with automatic rollback on failure, and remote commands recorded with acknowledgements.

Data and alerts

Reported data is parsed per point and stored, with buffered replays de-duplicated by timestamp.

Common blockers and how we handle them

Blocker

Every vendor has its own protocol and each new device means new code

How we handle it

The onboarding layer handles protocol adaptation and point mapping, so a new device is configuration rather than code.

Blocker

Offline detection is unreliable and produces a pile of false alerts

How we handle it

Offline detection is configured by heartbeat interval and tolerance, so network jitter does not raise alerts.

Blocker

Failed upgrades brick devices and require a site visit

How we handle it

Rollouts are staged and signature-checked with rollback on failure, and results are visible per device.

Common system modules

Devices and models

Model templates, device register, authentication.

Protocol onboarding

Multi-protocol adapters, point mapping, parsing.

Firmware and control

Staged upgrades, rollback, command acknowledgements.

Data and storage

Time-series data, replay de-duplication, retention.

Alerts and operations

Offline detection, threshold alerts, work-order links.

Open interfaces

Public APIs, webhooks, third-party integration.

Delivery gates

  1. Scope

    Write the device model, offline rules, catch-up window, and OTA scope. List vendor protocols this phase will connect and install site conditions.

  2. Architecture

    Fix register/auth, shadow state, and command read-back. Confirm gateway design, staged firmware, and swap flow.

  3. Build & integrate

    Measure offline, catch-up, mis-control protection, and upgrade trip on a real network. Failed upgrades can roll back, written as acceptance first.

  4. Launch & operate

    Small-batch install through swap and RMA, then expand. Deliver the install manual; train implementers and operations so platform and physical ledger match.

Related capabilities

Related industries

Industries we ship in

Walk us through your process before anything gets built

Tell us how the work happens today, where it breaks, and when you need it live. We will come back with a scope you can check and a phasing plan.

Contact Us

Email
service@wehoope.com
Phone
+86 139-2520-6166
Address
W903, Shenzhen-Hong Kong Industry-Education-Research Base, 201 Gaoxin South 7th Road, Nanshan District, Shenzhen