Skip to content
Husain Bootwala
02Active R&D

Nexop

A smart-home appliance that learns a household's routine and proposes the automations for it

Channel
02
Period
2025 —
Domain
Hardware + Software
Role
Founder-engineer: product, backend, hardware enclosure, brand and marketing site

Stack

  • FastAPI
  • Next.js
  • TypeScript
  • PostgreSQL
  • Redis
  • Zigbee2MQTT
  • KNX
  • Home Assistant
  • Docker
  • Jetson Orin Nano
  • LLM tool-use

The problem

Smart-home hardware works. Living with forty connected devices is a different matter.

That house has forty apps, three ecosystems that half-talk to each other, and a rules engine built on the assumption that the owner will sit down and write automations by hand. Almost nobody does. The devices settle into life as expensive light switches, and the house never gets round to adapting to anyone.

Connectivity was never the shortfall. What is missing is a system that holds any model of the household and can propose something without being asked.

What Nexop does

Nexop sits on the local network and watches device and sensor events over time. When a pattern repeats often enough (the study lights come on at dusk on weekdays but not weekends; the aircon goes off when the last person leaves), it writes the automation out in plain language. You approve it, edit it in conversation, or ignore it.

You can also just ask it something. Questions are answered against the home’s own state, and any proposed automation can be refined in conversation and previewed before it is allowed to run.

Why local, and why KNX

Two decisions shape the rest of the product.

The first is that it runs in the house. Device control does not depend on a vendor’s cloud being up or a subscription being current. Privacy is part of that, though the stronger argument is reliability: a light switch that needs an internet connection is a worse light switch.

The second is native KNX support rather than Home Assistant alone. KNX is the backbone of professionally installed European homes, and consumer smart-home AI has largely ignored it. Speaking it directly opens a route to installers and high-end homes that app-first competitors cannot reach.

The hardware

Nexop ships as an appliance rather than software you install, so the enclosure was part of the build. It is a custom case around a Jetson Orin Nano, modelled and revised several times, with the Zigbee radio placement and the thermal path designed in from the start.

The hardware side of my background is the only reason that part of the product exists, which is why Nexop is the project I point at when someone asks what I do.

Media

Three-quarter CAD view of the Nexop enclosure: a low rectangular case with the Nexop wordmark embossed on the lid, vent slots along the top and side, and a recessed port bay across the front face.
CAD · Enclosure design, front three-quarter
The Nexop desktop application, signed in, with a "Hub connected" status in the title bar. A sidebar lists Overview, Rooms, Devices, Scenes, AI Suggestions, Automations, Chat, Activity, Integrations and Settings. The overview shows tiles for active devices, temperature, security and energy, above a grid of rooms with the device count and lights on in each.
Screen capture · The desktop app, connected to a live hub in an occupied house
An architecture diagram in three parts. On the left, devices in the home: Zigbee over zigbee2mqtt and MQTT, KNX over KNXnet/IP, and everything else through Home Assistant. In the centre, outlined as one boundary, the appliance: protocol bridges, a FastAPI core, Postgres and Redis, a heuristic fast-path that answers simple commands without a model, a local Gemma model served by llama-server, and the desktop and web client. On the right, connected by a dashed line, hosted models from Gemini or Claude, marked optional and off by default as the only path that leaves the house.
Diagram · Local first, cloud optional: where each part runs
The Nexop marketing site hero: the wordmark and navigation above a headline reading "Your home, finally intelligent", a line describing a local-first AI brain that never sends a byte to the cloud, and an ambient chat panel showing a spoken request to dim the lights. To the right, a line-drawn floor plan with sensor points marked and the hub highlighted.
Screen capture · The marketing site, from brand and copy through to build

How this was built

The spec sheet above lists the stack. This section covers how the work was run, which a screenshot cannot show you.

Where AI did the work

  • Built feature-first: every feature gets its own folder with a plan, a flow test and a completion record, so an agent picking the work back up can see what was intended and what was verified.
  • Product, brand and engineering live in separate repos with their own working rules. A market claim and a function signature need different kinds of evidence, and one rulebook for both ends up too loose for one and too strict for the other.

The discipline around it

  • The repository map is authoritative. If it disagrees with the directory, the map is what gets fixed, in the same change that moved the file.
  • The API contract is generated from the running server instead of maintained by hand, so it cannot drift.
  • Identifiers left over from the pre-rename codebase are documented and left where they are. A cosmetic rename across live data buys nothing and can lose records.

What stayed human

  • Nexop never actuates on its own inference. It proposes an automation and the homeowner approves, edits or ignores it. Suggestion and execution are separate systems.
  • Device control runs locally. Cloud inference is opt-in, and the product works without it.

Process artifacts in the repo

docs/features/
One folder per feature: plan, flow test, completion record
PROJECT-OVERVIEW.md
The repo map, updated in the same change as any file move