Mixed-vendor fleets¶
RG manages mixed-vendor fleets by placing three integration levels under one control surface: fully integrated, partially integrated, and non-integrated. There is no "unsupported" tier. Devices and bridges are modeled as separate entities with separate lifecycles, bridges come in two form factors, and a device's attachment state is observable — so hardware can turn over without re-pairing.
Three integration levels, one control surface¶
Every device fits one of three levels, and all three are operated the same way from the top. A fully integrated device is driven by an adapter through its API — canonical settings map straight to native calls. A partially integrated device uses an adapter for what its API exposes and tunneled native GUI access for the rest, so nothing is out of reach. A non-integrated device — closed, legacy, or API-less — is represented through a bridge in appliance form factor that fronts it. Crucially there is no fourth "unsupported" bucket: any IP device lands in one of these three levels, which is what lets a genuinely heterogeneous fleet sit under a single control surface with a uniform device shadow.
Devices and bridges as separate entities¶
RG models the managed device and the RG Bridge that connects it as distinct entities with independent lifecycles. A device is the thing being managed — its shadow, settings, and firmware. A bridge is the connectivity element that establishes the outbound tunnel. Keeping them separate is what makes fleets durable: a bridge can be replaced without redefining the device behind it, and a device can be swapped without discarding the bridge's identity and pairing. This separation also draws a clean ownership boundary — firmware and model belong to the device, connectivity belongs to the bridge — so responsibility for each never blurs as hardware changes over time.
Two form factors¶
A bridge has exactly one of two form factors, describing where it runs relative to the device it connects.
| Form factor | Where it runs | What it fronts |
|---|---|---|
agent |
Embedded on the device itself | Tunnels the device's own management interface outward |
appliance |
A standalone small Linux device | Fronts one or more external devices reached over Ethernet |
An agent suits hardware that can run the connectivity element directly. An appliance suits closed or legacy hardware that can't host an agent: it sits on the same Ethernet segment as the target device or devices and tunnels their services on their behalf. One appliance can front multiple external devices, which is what brings API-less hardware into the fleet without modifying it.
Attachment state¶
A device's relationship to a bridge is captured by its attachment state, one of exactly three values: never_attached, attached, or detached. never_attached means the device has not yet been linked to a bridge; attached means a bridge is currently linked and connecting it; detached means it was linked before but is not now. Because attachment state is observable, operators can see at a glance whether a device is currently fronted and act on stale relationships. This state is what makes device turnover clean: detaching and attaching is a tracked transition, not an opaque re-onboarding.
The payoffs¶
Modeling devices and bridges separately, with form factors and attachment state, produces concrete fleet-operations benefits. Device turnover without re-pairing: swap the device behind an appliance bridge and the bridge's identity persists. Multiple devices per bridge: one appliance fronts several external devices over Ethernet, so a site needs fewer connectivity elements. A clean firmware and model ownership boundary: because firmware and model belong to the device entity and connectivity to the bridge, upgrades, replacements, and audits each have an unambiguous owner. Together these let a mixed-vendor fleet evolve — devices added, replaced, and retired — without churning its connectivity or its identities.