Multi-file QAs: grow your project, keep it organized

A QA on the HC3 is a set of named Lua files — one is main, the rest are libraries it loads. flua keeps the same model: your files stay on disk, and the main file declares the extras in its header:

--%%name:weather-app
--%%type:com.fibaro.binarySwitch
--%%file:lib.lua,lib
-- --------------- EOH ---------------

function QuickApp:onInit()
  print("helper says:", helper())   -- defined in lib.lua, loaded before main
end

The rules:

• --%%file:path,name — the on-disk path and the QA file name it gets on the HC3. Paths resolve relative to the main file.
• Files load in declaration order, main last — so helpers are available when onInit runs.
• Everything below the EOH marker line is code; the directives live above it.

Run it like any QA — flua --ui weather_app.lua — and the files behave like they do on the controller. Even the file API works offline:

local files = api.get("/quickApp/" .. self.id .. "/files")
for _, f in ipairs(files) do print("file:", f.name) end   -- main, lib

And when you deploy (--tool uploadQA / updateQA / pack), exactly the declared files travel into the .fqa package — the HC3 gets the same file set you developed against. One deliberate difference from the controller is useful for testing: plain Lua require("name") also finds name.lua next to the main file — but require'd files are not packaged, so test helpers (mock servers, assertions) never ship to the HC3. --%%file = ships, require = stays local.

Next post: listen to the house — the refreshState event flow.

Example: flua --examples → multifile.lua · flua: https://github.com/jangabrielsson/flua