Child devices, the HC3 way

A QA can own child devices — separate devices on the controller that belong to the parent QA and let the rest of the house address its parts individually (a weather station with a temperature child and a wind child, a switch with per-outlet children). flua supports the HC3's basic child API — QuickAppChild subclasses and createChildDevice — offline, children appearing in the simulated device list like on a real controller.

Define a child class with its own actions, create it in onInit:

Child = {}
class 'Child'(QuickAppChild)
function Child:__init(dev)
  QuickAppChild.__init(self, dev)
end
function Child:wave()
  print("CHILD", self.id, "waves back")
end

function QuickApp:onInit()
  local child = self:createChildDevice(
    { name = "Kid", type = "com.fibaro.binarySwitch" }, Child)
  print("created", child.id, child.name)
end

The child is now a real device in the sim:

local found = api.get("/devices?parentId=" .. self.id)  -- [{id = 900001, name = "Kid", ...}]
fibaro.call(child.id, "wave")                           -- CHILD 900001 waves back

Everything the HC3 does with children works the same way offline:

• Children are found by parentId — the same api.get a QA uses on the controller.
• Their actions and properties behave like any device's: call them with fibaro.call, read their state with api.get("/devices/" .. child.id), subscribe to their events.
• self.childDevices holds the instances; initChildDevices runs right after onInit and re-attaches child instances that already exist on the device — so a QA restart picks its children back up, like the HC3.
• Clean up with the same endpoint as the HC3: api.delete("/plugins/removeChildDevice/" .. child.id).

The workflow benefit is the same as everywhere in flua: the child logic is developed and debugged offline — breakpoints inside Child:wave included — and the parent QA uploads as one unit when it is ready.

Example: flua --examples → children_local.lua (uses the basic HC3 child API) · flua: https://github.com/jangabrielsson/flua