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

Visit site
Video · The live preview on the Nexop site: the AI proposes a scene, walks it through the house, and stops for approval
Channel
02
Period
2025 —
Domain
Hardware + Software
Role
Founder-engineer in a 3-person team: product, backend, AI engine, desktop app and hub hardware

Stack

  • FastAPI
  • Next.js
  • TypeScript
  • PostgreSQL
  • Redis
  • Zigbee2MQTT
  • KNX
  • Home Assistant
  • Docker
  • Jetson Orin Nano Super
  • Gemma via llama.cpp
  • Tauri
  • LLM tool-use
  1. A phone crowded with a dozen smart-home apps, next to an automations list with no rules in it12 appsAutomations0rules written
    BeforeAn app per device, and automation rules nobody writes.
  2. Zigbee, KNX and Home Assistant feed one local hub, which offers a suggested rule with Approve and Ignore buttonsZigbeeKNXHANEXOPHubSuggestionStudy lights onat dusk onweekdays?ApproveIgnore
    AfterOne local hub spots the routine and proposes the rule.
Command with no model call
~0.3 s
Power-on to AI ready
~78 s
Backend tests passing
1,300+
To MVP; 16 planned
3 wk

How a routine becomes a rule

  1. A histogram of a study light switching on by hour of day, peaking around 18:30, with the events falling on weekdays onlyStudy light · on events000612182418:30MTWTFSSWeekdays
    observeSwitch-ons bucketed by hour: a steady weekday peak is a routine.
  2. A suggestion card reading "Turn the study lights on at dusk on weekdays?" with Approve, Edit and Ignore buttonsAI suggestionTurn the study lights onat dusk on weekdays?Routine · weekdaysConfidenceApproveEditIgnore
    proposeWritten up in plain English. Nothing runs until approved.
  3. Events become a pattern, then a suggestion, then a decision: approve turns it into a rule, ignore sends it back with a lower scoreEventsPatternSuggestYOUIgnoreScore ↓ApproveRuleRuns only now
    ResultApprove: it becomes a rule. Ignore: that pattern scores lower.

Why it lives in the house

  1. Zigbee bulbs over MQTT and KNX modules over KNXnet/IP connect to the hub directly; other devices arrive through Home AssistantZigbeeKNXOtherHAMQTTKNXnet/IPHA APINEXOPHubJetson
    nativeZigbee and KNX natively; everything else via Home Assistant.
  2. A spoken command is matched first: simple ones take the heuristic path in about 0.3 seconds, the rest go to the local model at 12 to 22 seconds"Hall light on"MatchComplexLocal LLM12–22 sSimpleHeuristic~0.3 sNo model call
    fastSimple commands skip the model: 0.3 s, not 12–22 s.
  3. A house containing the devices, the hub and a local AI model, with a dashed opt-in link to a cloud model outsideHUBLocal AIDevicesCloud AIOpt-in
    localControl and AI run in the house. Cloud is opt-in.
Read the engineering detail

The problem

Smart-home hardware works. Living with forty connected devices is a different matter: 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.

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

What Nexop does

Nexop sits on the local network and logs device and sensor events over time. A scene engine turns them into per-device features (a time-of-day histogram, which days, how long things stay on), then looks for two kinds of pattern: routines (the study lights come on around dusk on weekdays but not weekends) and correlations between devices. Each pattern is scored on consistency and recency, and the strong ones are written out as a suggestion in plain language.

You approve it, edit it in conversation, or ignore it. Approving converts it into a rule; ignoring dismisses it, and the rejection history counts against similar suggestions later. The detectors are heuristics behind a fixed interface, so a learned model can replace them without touching the pipeline around them.

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.

The fast path

A local model on a Jetson takes 12–22 s to answer a turn. That is fine for writing an automation and unbearable for “hall light on”. So every command is matched first: a simple, unambiguous one (lights, fans, an absolute thermostat setpoint) is turned into exactly the tool call the model would have produced, and run through the same safety check, dispatcher and audit log, in about 0.3 s. Locks and covers still stop for a confirmation. Anything ambiguous or conditional goes to the model. Tests fake the model to assert that a simple command never calls it and a complex one always does.

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 default model is a Gemma model served by llama.cpp on the hub. Hosted models from Gemini or Claude are an opt-in setting, and the product works without them.

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 over KNXnet/IP, alongside Zigbee through zigbee2mqtt, 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 hub was part of the build: a Jetson Orin Nano Super in a custom 3D-printed case, with the airflow path and the radio dongles planned into the layout. On power-up the whole stack starts unattended, and the local model is answering in about 78 s.

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.

How it was built

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. A living tracker (docs/TASK_BREAKDOWN.md) is the single source of truth for what is shipped, verified and pending.

Product 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 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. Identifiers left over from the pre-rename codebase (“HomeAI”, renamed Nexop in May 2026) are documented and left where they are, because a cosmetic rename across live data buys nothing and can lose records.

Suggestion and execution are separate systems. The suggestion pipeline can only ever produce a pending suggestion; only the homeowner’s approval turns it into a rule the engine will run.

Media

Video · One typed sentence becomes a working rule
Video · Threshold rules, then the fast path
Video · The proposal loop in the desktop app: a routine nobody asked for, found in three weeks of simulated events, edited, then approved as a rule
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 CAD, 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 on a live hub
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 · Where each part runs
A Nexop suggestion card at 95% confidence proposing that when the front door lock is unlocked, the living room main light turns on, with its explanation expanded and Accept, Modify, dismiss and delete controls.
Screen capture · One proposal, with its reason: what the hub saw, and the rule it wants to add

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

  • Feature-first: every feature has a plan, a flow test and a completion record an agent can resume from.

The discipline around it

  • The repo map is fixed in the same change that moves a file.
  • The API contract is generated from the running server.

What stayed human

  • Nexop never acts on its own inference: it proposes, the homeowner decides.
  • Device control runs locally; cloud AI is opt-in.

Process artifacts in the repo

docs/features/
Plan, flow test and completion record per feature
docs/reference/CODEBASE_MAP.md
The repo map