Wireless Topologies

The Wireless Bobulator runs the same firmware whether it’s alone in a broom closet or one of two hundred units across a campus. What changes is the topology — how devices relate to each other and where decisions get made. There are three to choose from, and you can mix them on one site. Pick by deployment size, latency needs, and how much you care about surviving a dead node.

Hub model

One Bobulator, many devices. Every sensor and actuator in the space talks to a single unit that owns all the rules and the audit trail.

            ┌──────────────┐
   sensors ─┤              ├─ lights
   doors   ─┤   WB-1 HUB   ├─ HVAC
   beacons ─┤              ├─ displays
            └──────────────┘

When to choose it: single-floor offices, one gym, a retail unit — anywhere a single device’s 12 channels and three radios cover the footprint. Typical size: 1 device, up to ~150 endpoints. Failure mode: the hub is a single point of failure; if it drops, the space goes dark until it reboots (~4 s) or a cold spare is swapped in. Rule propagation: trivial — there’s one rule set, on one device, no sync.

Mesh network

Many Bobulators sharing state. Each unit owns its local zone but gossips decisions and rule updates to its neighbours over a self-healing mesh, so the fleet behaves as one system without a central brain.

     WB ──── WB ──── WB
      │  ╲   │   ╱   │
      │    ╲ │ ╱     │
     WB ──── WB ──── WB
        (gossip + shared state)

When to choose it: large facilities, multi-court sports complexes, campuses — anywhere one device can’t physically reach everything, or where losing the whole site to one failure is unacceptable. Typical size: 3–200 devices. Failure mode: none catastrophic — a dead node drops only its local zone; neighbours detect the gap in ~1 s and the rest of the mesh runs on. Rule propagation: push a rule to any node and it gossips to the fleet in under 2 s, with a version vector so late-joining nodes catch up automatically. This is the most common topology, and the one we tune for.

Edge + cloud hybrid

Local-first decisions with cloud coordination for the heavy lifting. Every device still decides in real time at the edge; the cloud layer adds fleet-wide analytics, model training, and cross-site orchestration on top.

   ┌──────── cloud: analytics · ML training · fleet view ────────┐
   │              ▲                              ▲                │
   └──────────────┼──────────────────────────────┼───────────────┘
              ┌───┴───┐                      ┌────┴──┐
              │ MESH  │   (site A, offline-  │ MESH  │  (site B)
              │ WB×12 │    capable)          │ WB×8  │
              └───────┘                      └───────┘

When to choose it: multi-site operators, anyone wanting predictive ML trained across the whole fleet, or environments that must keep running through an internet outage. Typical size: any mesh, ×N sites. Failure mode: lose the cloud and every site keeps making real-time decisions locally — only analytics and cross-site coordination pause, then sync on reconnect. Rule propagation: the cloud is the source of truth for fleet-wide rules; each site’s mesh pulls and gossips locally, so a WAN hiccup never stalls a local interlock.

Comparison

Most customers start with a hub, grow into a mesh as they add zones, and turn on the cloud layer once they have enough sites to want fleet-wide ML. The firmware is identical at every step — you’re flipping config, not forklifting hardware.

See how decisions get made inside each node in the Bobulation Engine, or match a topology to your world in our use cases.