Solution 02 — Smart Home & Integration
A control layer that belongs to your system.
For hubs, AV integrators and control platforms, the handset is part of the installation. Pairing, firmware updates and recovery decide whether the system feels owned or borrowed.
The brief
Integration is agreed step by step, not just an RF match.
A handset that joins an existing platform has to follow the platform’s rules: how devices are discovered, who owns the keys, what happens when a unit is replaced and how firmware reaches a unit already on a wall.
We start from your protocol document and a working receiver, not from a generic module datasheet. The first deliverable is usually a pairing and recovery sequence both teams can test.
- Radio chosen before the pairing flow is defined
- Installer key map differs from the homeowner map
- No recovery path when a handset loses its binding
- OTA added after the enclosure and memory map are fixed
- Replacement units cannot be provisioned without a site visit
What we build
Four pieces of the integration, agreed in writing.
Each item is a deliverable with a test, so the platform team can verify it before a pilot order is placed.
Match the existing link
We implement your BLE service, 2.4 GHz frame format or sub-GHz profile on our hardware. Where the protocol is proprietary, we work from your receiver and test vectors.
Pairing with a way back
Discovery, binding and unbinding are documented as a state sequence. A failed pairing must be recoverable in the room, not by returning the unit.
OTA without bricking
Update transport, image validation and rollback are defined with your firmware team. Field units keep a known-good image if an update is interrupted.
Provisioning at batch level
Keys, labels and default maps can be loaded per batch or per property. Replacement units ship pre-provisioned against your record, not blank.
Recommended control stack
The protocol is fixed. The rest is a trade-off.
Once the link is settled, the remaining decisions are power, input and how much of the firmware you want us to own.
| Layer | Standard path | When it becomes custom |
|---|---|---|
| Link | BLE 5.x or 2.4 GHz proprietary | Sub-GHz RF, multi-hop or mesh-adjacent behavior |
| Pairing | Button sequence with visual confirmation | Installer app, QR provisioning or proximity binding |
| Update | OTA through the host hub | Direct-to-handset update or staged rollout by batch |
| Ownership | Serow firmware with your key map | Your firmware on our board, or a shared codebase |
Project profile
One handset platform, three product tiers.
A control-platform vendor needed a family of handsets that shared firmware and tooling but differed in key count, display and radio. The program was structured so the tiers did not become three separate developments.
Shared PCB and firmware base
BLE and 2.4 GHz
Batch key and label loading
Protocol freeze to pilot build
Questions
Integration program FAQ
Can you build on our firmware instead of yours?
What if our protocol is proprietary?
How are replacement units handled?
Do you support Matter or Thread?
Start a project
Bring the protocol. We will bring the test plan.
Share the receiver, the frame format and the fleet plan. We will tell you what is standard, what is custom and what needs a discovery step.