Smart Home & Consumer IoT

What changes when a connected product has to live in a home

A smart home product is judged where its engineers are not: in a hallway, on a router that gets replaced, by a person who has never set up a device. Indeema builds connected products for that environment, where the device, its network, the cloud and the app in a person’s hand have to behave as one product. It applies to smart home, consumer IoT and connected building products alike.

See what the home changes

The environment

A home is not a lab

These conditions come with the environment, whatever the product does.

Diagram of a home: sensors, lighting, power, audio and a fan or motor connected over Bluetooth and Wi-Fi to a microcontroller, with a user interface on a tablet or phone

A home, drawn as the parts a product has to reach.

  1. Set up by someone who is not an engineer

    Onboarding is part of the product. Pairing, provisioning and instructions are designed across the device, the app and the cloud.

    SETUP
  2. Placed among products it did not choose

    The home already has hubs, assistants and devices from other makers. How the product must speak to them is set by the ecosystem it joins, not by its maker.

    INTEROPERABILITY
  3. Sharing the air with every other radio

    Many small sensors talk to one hub. Radio traffic and latency decide whether the system feels dependable.

    RADIO
  4. On a network the household controls

    Routers are replaced, passwords change and connections drop. The product has to be designed for that day, and for recovering without a service call.

    CONNECTIVITY
  5. Small, visible and always on

    The enclosure, the board layout and the indicator light are decisions people live with. Fitting a board into a fixed shape is engineering.

    PHYSICAL
  6. In service for years, and near doors, water and fire

    Updates, cloud environments and access rights are kept up long after launch. When a system guards a door or a water pipe, they are security matters.

    LIFETIME

The system map

One product, four places it has to behave

A smart home product lives in the room, on the household’s network, in a cloud service and on a phone.

  1. PRODUCT

    in the room

    Board, radios, firmware and enclosure. It is placed once and then left alone, so setup, recovery and update behaviour have to be built in before it ships.

    Hand over Hardware & Electronics Hand over Embedded & Firmware
  2. HOME NETWORK

    in the walls

    Bluetooth LE for setup, Wi-Fi to the router, and a radio to the hub where the product joins one. Every link belongs to the household, not to the maker.

  3. CLOUD

    run by the maker

    Accounts, device state and the update jobs that reach every home. A two-way path, not only a place to store readings.

    Hand over Cloud & Connected Systems
  4. APP

    in the person’s hand

    Setup, control and status on a phone the product does not own. It is the part of the product a person touches most.

    Hand over Applications & Experience

UPDATE New firmware travels the same way in reverse: from the cloud to the product, over the household’s own network.

What has to work together

The seams between the places decide the product

Smart home integration is rarely one component failing. It is two parts designed apart, meeting in a home. The four seams below come from the example that follows.

A model of a two-storey house with icons for heating, lighting, water and locks, a white hub and a phone showing the home app

The hub, the app and the house they serve.

  1. Setup × app × firmware

    A device is onboarded over Bluetooth LE from the app and then handed on to the cloud. The connection interface and the provisioning section of the app were built alongside the firmware, not after it.

  2. Hub × sensors × radio

    One hub, many sensors, one shared band. Radio traffic was tuned to keep latency down, and a logging system spanning several embedded processors let a fault be traced across them.

  3. Product × other ecosystems

    A universal hub has to work with what is already installed. The starting point was other makers’ technical documentation, and HomeKit, Alexa and Siri support was first proved at firmware level in proofs of concept.

  4. Device × cloud × time

    Firmware and backend were built and tested through one pipeline. Cloud environments ran from sandbox to production, update jobs delivered new firmware, versions could be rolled back, and access roles were audited.

Patterns across projects

What repeats from one home to the next

The same four things kept coming back across home and building projects. The projects are not named and no results are claimed.

  1. Setup is engineered, not documented

    The people who install these products are not technical, so the first run was always in scope: a tank gauge homeowners can fit, an app understood without technical knowledge, a short path from device to app.

    • Tank gauge
    • Air-quality monitor
    • Air-quality device and app
    • Integrated home system
  2. The product is fitted to where it sits

    One air-quality monitor was reworked as a portable desktop unit for its second generation. The board layout was rearranged to meet fixed dimensions, and an LED scheme made air quality readable at a glance.

    • Air-quality monitor, two generations
  3. The cloud talks back

    Alerts when a tank runs low or air leaves its range. Two-way communication and remote updates with the device. Update jobs across a home system.

    • Tank gauge
    • Air-quality device and app
    • Air-quality monitor
    • Integrated home system
  4. New phones meet old buildings

    A door camera’s analog video was converted on a hardware codec and streamed to a resident’s phone, in a prototype of an indoor intercom.

    • Indoor intercom, prototype

What this has looked like

One example, and what Indeema owned in it

The client and the product are not named, and no results are shown.

A wall-mounted hub listing the devices it has found, a thermostat dial below it, and a tablet showing the hub, the thermostat and two locks connected

The first-run experience, as a person goes through it.

  1. ONBOARD · HUB RADIO · CLOUD · UPDATEIntegrated smart-home system: hub, sensors, cloud and app

    A company that already sold a water-leak detection product wanted a full smart-home system: energy monitoring, lighting, door locks, fire alarms and heating. It had clear requirements, a leak product with limited device integration, and many sensors without optimised communication.

    Indeema owned
    Embedded firmware, beginning with proofs of concept; the Bluetooth LE connection interface and provisioning section of the app; cloud environments on AWS; build and deployment pipelines; UX design; testing.
    What changed
    A universal hub that works with the devices the client listed. Onboarding over Bluetooth LE. Tuned radio traffic between sensors and hub. Logging across several embedded processors. Update jobs and reviewed access roles after launch.
    The hard part
    Working with other makers’ devices from their technical documentation alone, and keeping many sensors talking to one hub without lag.
    The team
    Embedded, cloud and DevOps, mobile, UX and QA engineers, working with the client’s teams in other countries.

Where to start

Start with the home your product has to live in

  1. Connected Product Engineering

    The same one-system discipline for any product that spans device, cloud and app.

  2. Product Discovery & Technical Strategy

    Settle the conditions of the home before the first board is drawn.

Bring us

  • The product, and where in a home or building it sits
  • Who installs it, and how
  • What it must work with once installed
Discuss your connected-home product