Designing connected devices for South African conditions

A connected device that works on a bench in an office can still fail in the field. In South Africa the field is demanding: power that comes and goes on a schedule and sometimes without one, connectivity that varies from street to street, devices left unattended in public places, and sites that are a long drive from anyone who can fix them. None of this is exotic. It just has to be designed for from the start, because it is expensive to add later.

This is how we think about each of those conditions, and what we build into firmware and the systems around it.

Loadshedding and brownouts

Scheduled outages are the obvious problem, but they are not the hardest one. A clean power cut is easy to reason about. What causes real trouble is everything around it: brownouts where the voltage sags but does not quite disappear, surges when power returns, and several short interruptions in a row. A device has to survive all of these without corrupting itself, losing data or needing someone to press a reset button.

Power-fail-safe firmware

The first rule is that power can disappear at any instruction. Firmware should be written so that nothing important is ever half written:

• Atomic writes to storage. Configuration and state are written to a new location and only then marked as current, so a cut mid-write leaves the previous good copy intact.
• Brownout detection. The microcontroller's brownout detector should be enabled and set sensibly, so the device resets cleanly rather than running erratically on low voltage.
• Watchdogs. A hardware watchdog restarts the device if the firmware hangs, whatever the cause.
• Limited flash wear. Frequent power cycles tempt you to save state constantly. Batch writes and use wear-levelled storage so the flash lasts the life of the product.

State recovery

When power returns, the device should pick up where it left off without human help. That means knowing, on boot, why it restarted (a power loss, a watchdog, a brownout or a deliberate reboot), restoring its last known good state, reconnecting to the network with sensible back-off, and reporting that it has been offline. A device that quietly restarts and says nothing makes an outage invisible to the people who need to know about it.

Backup power

Whether a device needs backup power depends on what it does during an outage. A meter that must keep counting needs enough power to keep counting. A device that simply reports status may only need enough to shut down cleanly and save its state. Options range from a supercapacitor for a graceful shutdown, through battery packs, to solar and battery for remote sites. The Woolworths sanitiser stations we built are freestanding and run from a battery pack, so a station keeps working where it stands rather than depending on a nearby plug.

Design for the power cut you expect, and then for the three short ones that follow it.

Patchy connectivity

Connectivity is never guaranteed. Networks go down during outages when towers lose power, in-store signal can be poor, and rural sites may have no cellular coverage at all. A good device treats the network as something that is usually there, not always there.

Store and forward

The device should record readings locally, with a timestamp from a clock it can trust, and send them when it can. When the connection returns, it uploads the backlog in order, and the cloud side accepts it without creating duplicates. On the server, idempotent ingestion means a reading sent twice is stored once. On the device, a bounded buffer means a long outage fills the storage gracefully rather than crashing the firmware, with a clear rule for what to keep if space runs out.

Choosing Wi-Fi, LTE-M, NB-IoT or LoRaWAN

There is no single right answer. The choice depends on where the device lives, how much data it sends and how it is powered:

• Wi-Fi suits devices in buildings with a network you control or can rely on. It is inexpensive per device, but you depend on the site's network, its passwords and its IT team.
• LTE-M is a cellular option designed for devices. It carries moderate amounts of data, supports movement between cells and is independent of the site's network. It needs a SIM and a data contract per device.
• NB-IoT is designed for small, infrequent messages and low power, often with good building penetration. It is less suited to larger payloads or firmware updates, and coverage should be checked for each deployment.
• LoRaWAN reaches long distances at very low power with tiny payloads, which suits sensors on farms, estates and large sites. It usually needs a gateway, either your own or a network operator's.

Whatever you choose, test it at the real sites, not only where the engineers are. Coverage maps are a starting point, not an answer.

Tampering and physical security

Devices in public or shared spaces will be opened, moved, unplugged and occasionally attacked. Physical design and firmware both have a part to play:

• Enclosures with security fasteners and tamper switches that report when a case is opened.
• Secure boot and signed firmware, so the device only runs code you have signed.
• Protected keys, stored in secure elements or protected flash rather than in plain firmware, and unique to each device so one compromised unit does not compromise the fleet.
• Disabled debug ports on production units.
• Plausibility checks in the cloud. Readings that are impossible, or a device that goes quiet at a suspicious moment, should raise an alert. Tampering often shows up in the data before anyone sees it on site.

Updates without site visits

If every firmware change needs someone to visit every device, you will not make many changes, and security fixes will wait. Over-the-air (OTA) updates are essential for any fleet spread across many sites, but they have to be built carefully:

1. Two firmware slots. The new image downloads into a spare slot while the current one keeps running.
2. Verification before switching. The image is checked for integrity and signature before the device boots it.
3. Automatic rollback. If the new firmware does not start properly and confirm it is healthy, the device returns to the previous version by itself.
4. Staged rollouts. Update a small group first, watch it, then widen the rollout.
5. Power awareness. The update process has to survive a power cut at any point, which the steps above make possible.

This is part of our firmware and embedded systems work and of the device management that sits around a fleet.

Remote diagnostics

When something goes wrong at a distant site, the first question is whether it needs a visit. Good diagnostics answer that from a desk. Useful signals include a regular heartbeat, online and offline status, the reason for the last restart, counts of brownouts and watchdog resets, signal strength, battery or supply voltage, firmware version and free storage. Together they tell you whether a device is healthy, struggling or gone.

The Woolworths dashboard shows each station's location and whether it is online or offline, and the system sends refill notifications and alerts when maintenance is needed. That is the pattern that matters for unattended devices across many stores: the people responsible find out from the system, not from a customer. More on this kind of dashboard is on our monitoring platforms page.

A closing checklist

Before a device leaves the bench for South African sites, it is worth being able to answer yes to each of these:

• Can power be cut at any moment, including during an update, without corrupting the device?
• Does the device recover and reconnect on its own after an outage, and report that it was down?
• Has backup power been sized for what the device must do during an outage?
• Are readings stored locally and sent later when the connection drops, without duplicates?
• Has the connectivity choice been tested at real sites?
• Will the device, and the data, show signs of tampering?
• Can firmware be updated remotely, in stages, with automatic rollback?
• Can you tell from a desk whether a device needs a visit?

If any answer is no, it is far cheaper to fix now than after installation. To see how this came together in a real deployment, read the Woolworths case study, or tell us about your devices.