Where Hardware Meets Software
A connected device is five layers pretending to be one product. This is a field guide to the layers — firmware, radios, updates, cloud and security — and the seams where most projects break.
Plug in a smart switch. Within seconds your phone discovers it, pairs it, puts it on the network, and it shows up in an app with the right name and a working toggle. It feels like one thing. It is at least five: a circuit board, firmware, a radio protocol, a cloud service and an app — each built by different people with different tools, all of which have to agree on every detail.
Hardware and software integration is the craft of making those layers behave as one product. It's where most connected-device projects quietly succeed or fail, and it's the part we care about most at Incrix Automation. This is a field guide to the layers and the seams between them.
The connected-device stack, layer by layer
Each layer has its own specialists and its own failure modes. The trouble usually starts where one layer hands over to the next.
Layer 1: Embedded software
Embedded software is where hardware becomes behaviour. On our boards it ranges from bare-metal code for tight, single-purpose loops to RTOS-based firmware when a device has to juggle radios, sensors, storage and cloud sync at the same time.
Good embedded software for connected devices does a few things that a lab demo never tests:
- Fails gracefully. A dropped connection, a corrupt message or a sensor glitch should never lock the device.
- Survives power loss. In India, power cuts are routine. Firmware must save state and recover without a human.
- Buffers when offline. Readings and events are stored locally and synced when the link returns.
- Separates control from connectivity. The relay should still switch, and the safety check should still run, even when the cloud is unreachable.
That last point connects directly to why intelligence is moving to the edge: the more decisions a device can make on its own, the less fragile the whole system becomes.
Layer 2: Connectivity — choosing the right radio
No single radio is right for every device. The choice follows from where the device lives, how much data it sends and how it's powered.
| Technology | What it's good at | Typical fit |
|---|---|---|
| Wi-Fi 6 (802.11ax) | Higher efficiency on crowded networks, with power-saving features such as Target Wake Time | Devices inside homes, offices and factories with existing Wi-Fi |
| Bluetooth LE | Short-range, low-power links to phones | Setup, commissioning and nearby control |
| Thread | Low-power, IPv6-based mesh on IEEE 802.15.4 | Battery sensors and smart-home devices; a core transport for Matter |
| Zigbee | Established low-power mesh on IEEE 802.15.4 | Home and building automation with a gateway |
| Matter | Application-layer standard for cross-brand interoperability over IP (Wi-Fi, Thread, Ethernet) | Smart-home products that must work across ecosystems |
| LoRa | Long range, low data rate, low power | Farms and remote sites where Wi-Fi can't reach |
| GSM / cellular | Direct link via operator networks | Remote sites with coverage and no local infrastructure |
Where our boards fit
Our Horizon Dev-2 C6 is built on Espressif's ESP32-C6, which combines 2.4 GHz Wi-Fi 6, Bluetooth 5 (LE) and an IEEE 802.15.4 radio for Thread and Zigbee on one chip. That's what makes it a natural base for Matter-ready devices, mesh sensor networks and gateways. The 30×25 mm Hexon Atom C6 brings the same chip family into a module small enough to embed inside machines and panels.
Matter itself is maintained by the Connectivity Standards Alliance. Its promise is simple: a device certified for Matter should work with other Matter ecosystems, rather than locking customers into one brand's app.
For the field, the answer is different. Our smart irrigation design, currently in development, uses LoRa and GSM precisely because farms rarely have Wi-Fi and power isn't guaranteed.
Layer 3: OTA updates — the lifeline after launch
The day a device ships is the day its firmware starts ageing. Over-the-air updates are how you fix bugs, close security holes and add features without a site visit. They are also one of the easiest ways to brick a fleet if done carelessly.
A safe OTA design usually includes:
- Dual partitions, so the new image is written alongside the working one.
- Signed images, so the device only accepts firmware from you.
- Verification before switching, then a boot into the new image.
- Automatic rollback if the new image fails its health check.
- Staged rollout, starting with a small slice of the fleet.
We design firmware to be OTA-ready from day one, because retrofitting it later means touching the flash layout, the bootloader and the cloud all at once.
Layer 4: Cloud and fleet dashboards
One device is a gadget. A thousand devices is a fleet — and fleets need infrastructure: device identity and provisioning, telemetry ingestion, command delivery, OTA release management, alerting and dashboards that people can actually read.
This is where our hardware and software streams meet most directly. Our software team designs on serverless infrastructure for cost-effectiveness and low maintenance — the same approach behind Classory — and that model suits device fleets well, because traffic is spiky and devices come and go. We explain the reasoning in why we build serverless.
Our AI 3D printer in R&D is a good example of the split: on-board AI monitoring runs on the printer, while a cloud fleet dashboard lets a lab or print farm manage every machine from one place. Open-source communities such as LF Edge work on exactly this boundary between edge devices and the cloud.
Layer 5: Security basics, across every layer
Security can't live in one layer. It has to be threaded through all of them.
- Trust the bootSecure boot ensures only signed firmware runs. The ESP32-C6, for example, offers RSA-3072-based secure boot and AES-XTS flash encryption in hardware.
- Unique identity per deviceNo shared passwords or keys across a fleet. Each device gets its own credentials, provisioned at manufacture.
- Encrypt every linkDevice-to-cloud and app-to-cloud traffic should be encrypted and authenticated, always.
- Sign every updateOTA images are signed and verified before they're allowed to run.
- Close the back doorsDebug ports and development shortcuts are disabled or locked on production units.
None of this is exotic. What makes it hard is that it spans the board, the firmware, the factory and the cloud — which is exactly why it gets missed when those are built by different teams.
Hardware and software integration: who owns the seams?
Every section above ends up at the same place: the hard problems are at the boundaries. Power loss is a board problem, a firmware problem and a cloud problem. OTA is a flash-layout problem and a release-pipeline problem. Security is a silicon feature and a manufacturing process.
That's the practical case for doing hardware and software integration inside one team — the argument we make more broadly in why Incrix builds across software, hardware and design. If you want the board-level view of how we get there, read from PCB to product.
The best connected products feel like one thing because someone took responsibility for making them one thing. For the full picture of how this fits into everything we do, see what we're actually building at Incrix.