Skip to content
reMaestro Docs

The driver model

Out of process, over gRPC

Section titled “Out of process, over gRPC”

Drivers are not in-process plugins. The hub launches each configured driver as its own OS process and talks to it over gRPC on loopback. That buys three things:

  • Crash isolation — a misbehaving driver can’t take the hub down.
  • Lazy start — a driver’s process starts only when something uses it, and stops when nothing does. The cost is proportional to what you actually run, not to how many types ship. This matters on a Raspberry Pi.
  • A complete catalogue without running everything — each driver is introspected once and its descriptor cached, so the device picker, discovery and the remote-template gallery are complete even for drivers that aren’t running.

Drivers are written to be Native-AOT-clean (source-generated JSON), so they publish as small self-contained executables.

How a driver describes itself

Section titled “How a driver describes itself”

Every driver exposes a descriptor:

  • Config schema — what you must supply (address, serial port, credentials, API key). Fields can be plain values, secrets, or hardware pickers that list what’s physically plugged in (serial ports, input devices, audio inputs).
  • Commands — the actions it exposes, with parameters. A driver names its commands whatever its hardware calls them (power_toggle, setinput, KEY_PLAY); the hub matches those against a canonical vocabulary (power.toggle, volume.up, input.select, transport.play, nav.up…) by alias, so a new driver auto-maps onto remotes and rules without anyone hand-editing a table.
  • Events & state — what it reports, which drives the rule editor’s autocomplete.
  • Traits — the roles a type can play (ir.emitter, display, media.player, lighting, bridge, proxy…), used to scope pickers sensibly.
  • Discovery services — the mDNS/SSDP/UDP signatures the hub’s prober matches to find gear automatically.
  • Remote templates — a ready-made remote layout for the hardware, with buttons bound to capabilities the hub resolves to each device’s real commands.

Some drivers are bridges (Hue, HEOS, Sonos, WattBox, Home Assistant, Hubitat): you add one, and each thing behind it — a light, a speaker, an outlet, an entity — becomes its own device sharing the one connection.