Run a whole house: many QAs, one flua

Real smart-home logic is rarely one QA: the door sensor talks to the lamp, the lamp asks the weather QA, the scene reacts to both. With flua you can run several QAs in one process — each isolated, each with its own device, all talking to each other over the same HC3 REST API the real controller uses.

flua --api local door.lua lamp.lua scene.lua

(F5 runs the current file — for a multi-QA house, the terminal command is the way; single-QA runs are always F5-able. And --api local is only there for clarity — offline is the default, so flua door.lua lamp.lua scene.lua does the same.)

Device ids are assigned by the engine (starting at 5000), so QAs find each other the way they would on a real HC3 — by name, through the API:

local function findDevice(name)
  local devices = api.get("/devices?name=" .. name) or {}
  return devices[1] and devices[1].id
end

A complete example ships with flua — two QAs that call each other's actions. flua --examples prints the examples directory; run the pair from there:

flua qa3.lua qa4.lua

qa4 finds qa-three, turns it on and off over the API, and qa-three calls qa4 back — exactly the fibaro.call/action pattern you use against the real controller:

[qa4]: turning qa-three on
[qa3]: turned on
[qa4]: got qa3 is on
...

Reactions work the same way: trigger.lua in the examples directory starts a door sensor QA and a lamp QA in one run, subscribes the lamp to the door's state changes, and the lamp reacts when the door opens — the refreshState event flow, offline.

Why this matters:

• The simulator is your test house. Seed it with your real device names and ids (--seed devices.json) and the QAs talk to "your" devices — offline.
• Race conditions show up. QAs run cooperatively in virtual time, so cross-QA timing is deterministic — the intermittent bug that needs three devices and a scene to reproduce is now a fixed, rerunnable scenario.
• One log, every device. Each line is tagged with the QA's name and id, so a conversation between five QAs reads like a chat log.

Next post: turn that house into a test suite — let your QA assert its own behavior and report success or failure.

Examples: flua --examples → qa3.lua/qa4.lua, trigger.lua · tutorial: docs/tutorial/04-the-house-comes-alive.md