The HC3 web editor gives you self:debug prints and not much
else. flua gives you a real debugger: breakpoints, step over/into, call
stacks, and variable inspection — in VS Code, on the QA code you are editing,
no changes to the file.
If you ran flua --tool setup (post 1), the launch
configurations are already in .vscode/launch.json:
Press F5 with a .lua file open, or pick a configuration from
the Run and Debug panel. Put a breakpoint on any line of onInit,
start "Debug Current File (UI+mobdebug)", and VS Code stops there — before
anything else runs. You can then step through your QA line by line, hover
variables, and watch self, while the UI viewer sits in the
browser showing the device you are debugging.
Two flua-specific niceties you get for free:
api.get,
fibaro.call, UI events — everything the QA touches is fake, so
a misbehaving QA can never turn the house on and off while you are
stepping through it.Prefer the terminal? No setup needed:
flua --debugger 8172 quickapp.lua
...and attach a debugger client to port 8172 — the same protocol the mobdebug VS Code extension speaks, so the extension works out of the box.
There is also a static check for the quick wins before you even run:
flua --check quickapp.lua # syntax, --%% directive typos, deprecated APIs
Next post: stop testing one QA at a time — run a whole house full of devices in a single flua process.
flua: https://github.com/jangabrielsson/flua · setup guide: USAGE.md