A hub that promises to control "any smart home device" has to actually speak several incompatible radio protocols at once, on shared hardware, and reconcile them behind one coherent app experience. Rivix builds that stack end to end — hardware, firmware, cloud and the mobile app that ties it together.
Multi-radio hardware design for hubs and sensors that need to coexist on shared silicon.
Explore hardware →Local-first processing and protocol coexistence — FreeRTOS, Zephyr and bare-metal; BLE, Wi-Fi, LoRa, Zigbee and cellular.
Explore firmware →Reserved for account sync, remote access and functionality that genuinely needs it — not the default execution path.
Explore cloud →Device-pairing UX and the failure-mode handling that breaks demos if left to AI scaffolding alone.
Explore mobile & web →On-device event classification for alerting use cases, so raw sensor data doesn't have to leave the home to be useful.
Explore AI & Intelligence →Thread is a low-power, IPv6-based mesh networking protocol; Matter is an application-layer standard defining device capability models on top of it, working over multiple transports including Thread and Wi-Fi. Supporting Thread requires an 802.15.4-capable radio — either a dedicated Thread/Zigbee-class radio or a multiprotocol SoC — and Matter support requires going through a formal certification process.
Zigbee, Thread and Bluetooth Low Energy all operate in the 2.4GHz band, and Wi-Fi frequently does too, which makes interference a real design constraint. Z-Wave operates in a separate sub-GHz band, largely avoiding that issue. A hub normalizes these into one internal device-capabilities representation and updates each radio stack's coprocessor firmware independently, in sequence, with rollback safety.
BACnet and Modbus have been the standard for HVAC, lighting and building-controls integration for a long time. Because these systems run safety-relevant building functions, the design pattern shifts to watchdog supervision, fail-safe defaults on comms loss, and firmware update processes built for zero downtime.
Advertising interval trades discoverability speed against power draw — aggressive advertising during the pairing window, falling back to a power-conserving interval after connect or timeout. RSSI-based proximity feedback helps users find the right device, and iOS/Android differ meaningfully in BLE permissions, background scanning, and OEM-level fragmentation.
Pulled from our case-study library — same AI/human split shown in full, industry context included.
A modular smart-home hub connects home devices and sensors while providing local-first voice interaction and automation, reducing dependence on cloud processing.
A central smart-home router/gateway connects distributed home sensors and provides a unified platform for device provisioning, monitoring, automation and user control.
A connected home-protection sensor combines multiple environmental signals to detect water leaks, freezing conditions and other potentially damaging events.
Which one changes your silicon, firmware, and certification path is what actually matters for a product roadmap.
Read the article →Speaking several incompatible radio protocols at once, on shared hardware, reconciled behind one coherent app.
Read the article →Commercial BAS is a different discipline entirely from smart home — legacy protocols, uptime, and live-building retrofits.
Read the article →Getting pairing right is a joint firmware-and-app problem, not just a UI one.
Read the article →FreeRTOS, Zephyr and bare-metal on the RTOS side; BLE, Wi-Fi, LoRa, Zigbee and cellular on connectivity, chosen based on your power and range constraints, not by default.
Pairing UX design and the trickier failure-mode handling — dropped connections, firmware mismatch, multi-device conflicts — stays with a senior engineer.
Local-first where it matters — cloud connectivity is reserved for account sync, remote access and functionality that genuinely needs it, not the default execution path.
Yes. We audit the existing schematic/layout, flag the risks, and either harden it or re-spin the sections that need it — we don't force a full restart by default.