Building vBus: A Universal Sensor Protocol for Smart Pet Products
At Hoomanely, we set out to build connected pet products that could genuinely understand pet behavior and health through multiple sensors working together. Trackers needed to monitor activity, detect vocalizations, track location, and communicate over long distances. Smart bowls needed to measure food consumption precisely, detect presence, capture video, and monitor audio. The smart hub needed to orchestrate all incoming data and run edge compute on it in real time, alongside data from its own sensors.
Each product needed fundamentally different sensor types operating at wildly different scales, from discrete events to continuous streams.
The initial approach failed
We started conventionally, different protocols for different sensors, the standard, proven approach. What went wrong: each sensor spoke a different protocol, our microcontroller ran out of peripheral interfaces, we added converters, firmware complexity exploded, and memory became scarce. Battery-powered devices couldn't sleep effectively, constantly polling different interfaces and waking for every interrupt, and we were off our power target by an order of magnitude. Priority handling became impossible, health alerts got blocked behind diagnostic data, and software patches added complexity without fixing the root cause. Adding a new sensor took weeks, new driver code, new message formats, new filtering logic, extensive testing. The smart bowl's sensor crystallized the problem: high-frequency data saturated the bus and prevented other sensors from communicating at all, forcing an impossible trade-off between precision and reliability.
We weren't fighting individual technical challenges, we were fighting the wrong architecture. Multiple incompatible protocols forced us to treat fundamentally different sensors uniformly while preventing effective coordination between them. We needed one communication layer handling any sensor, regardless of native protocol, while preserving each sensor's unique characteristics.
Semantic transport layer fusion
The breakthrough insight: what if message semantics could participate in hardware-level routing decisions? Traditional protocols separate concerns, the transport layer moves bytes, the application layer interprets meaning. That's elegant but wasteful, since every received message wakes the CPU, consumes power for deserialization, and only then gets discarded if irrelevant.
vBus inverts this by encoding semantic information directly into transport-layer addressing. Message type and subtype aren't just payload metadata, they're routing primitives hardware can filter on before the CPU ever wakes.
We built a three-tier semantic hierarchy: message type (command, response, or event), message subtype (a specific capability identifier), and structured payload (capability-specific data). Commands represent control flow, configuration and actuation. Responses close control loops, acknowledgment and status. Events represent data flow, sensor readings and state changes. Making this distinction first-class in the protocol enables hardware filtering by intent ("wake me only for events, not commands"), priority inheritance where event urgency lives in routing rather than payload, and zero-copy discrimination that discards irrelevant messages without deserializing them at all.
Intelligent message framing
By encoding semantics in transport-layer addressing, components can filter at the hardware level, a battery-powered processor ignoring certain message types never wakes its CPU, the messages simply don't trigger an interrupt. The addressing structure embeds priority level, destination and source, and message subtype together. The trade-off is a small amount of per-message overhead in exchange for orders-of-magnitude power savings through avoided processing.
The protocol supports multiple priority levels: highest for emergency events and critical health alerts, high for real-time sensor data needing immediate action, medium for regular readings and status updates, and low for diagnostic data and background telemetry. High-priority messages preempt lower-priority processing at the hardware level through built-in arbitration, so critical alerts get delivered quickly even under heavy data load.
Multi-layer transport
The same message structure works across multiple physical layers. A high-speed bus handles time-critical sensor data, video frames, high-frequency motion data, continuous analog streams, with hardware filtering, large payloads, and built-in error detection with automatic retransmission. A low-speed control bus manages device configuration, status polling, and firmware updates over a simple two-wire interface with flow control and packet error checking.
Priority levels traverse transport boundaries intact, a high-priority message on the low-speed bus gets promoted appropriately when bridged to the high-speed bus, so urgency survives end to end.
Capability discovery
When a component initializes, it broadcasts a structured capability descriptor: the data streams it offers (type, rate, precision), the commands it supports, the power modes available, and its protocol version and feature flags. The receiving system doesn't need prior knowledge of that specific sensor combination, it discovers capabilities and dynamically routes them to interested consumers. The descriptor itself is versioned and extensible, so future sensors can advertise capabilities that don't exist today, while old firmware gracefully ignores anything it doesn't recognize while still using what it does.
Capabilities renegotiate continuously too. Battery state changes trigger renegotiated sampling rates and power modes. Thermal conditions adjust duty cycles and disable high-power features. Network congestion switches raw data streams to processed summaries. Feature activation requests higher fidelity only when actually needed. All of this happens through the same Command/Response protocol, no separate configuration channel required.
Dual-capability sensor abstraction
Sensors advertise multiple simultaneous capabilities for the same physical sensor. A weight sensor might offer raw readings at high frequency for calibration, consumption events based on threshold detection, and continuous monitoring as averaged readings at lower frequency. Consumers subscribe to whichever capability matches their needs, and the sensor responds to actual demand.
That's the efficiency gain: when no consumer subscribes to raw data, the sensor never transmits it. When battery runs low, high-frequency capabilities can shut off while essential event detection stays active. It's demand-driven sensor operation, production automatically matching consumption.
Beyond pet tech
These innovations generalize to any multi-sensor, power-constrained system: wearables like activity trackers, health monitors, and AR glasses; IoT devices like smart home sensors and environmental monitoring; automotive sensor fusion for ADAS and in-cabin monitoring; and industrial distributed sensor networks in manufacturing. The common thread is diverse sensors, real-time requirements, power constraints, and evolving feature sets.
Impact on development
Before vBus, adding a new sensor type took weeks of integration work. After vBus, it takes days, define capabilities, implement the sensor interface, test integration. Engineers now focus on sensor innovation rather than communication infrastructure.
Conclusion
vBus solved our immediate problem, connecting diverse sensors within and across our products. The longer-term value is rapid experimentation with new sensors, seamless field updates, and a platform scaling from prototype to production. The real innovation is in the integration, how semantic information flows through hardware filtering, how capabilities negotiate continuously, how synchronization falls out as a byproduct of normal communication, and how one protocol handles everything from precision measurements to video streams. For Hoomanely, this means faster product iteration. We're not just connecting sensors, we're redefining how they communicate.
