Your QA workflow inside VS Code — the extension grew up

The flua extension started as a thin layer: run tools from the explorer menu, check on save, read .fqa packages. It is still that thin layer — every feature is a flua --tool command with a button on top — but the surface now covers the whole loop: browse the controller, view, download, edit, test, upload, and switch controllers, all from the editor. This post tours it.

The hub view

Install or update the extension (GsonSoft-development.flua), and a flua icon appears in the activity bar. It opens the HC3 hub view: the hub's model and firmware at the top, its QuickApps as a tree — name, id, type, room. The title bar has filter (name or id), sort (name ↔ id), and refresh. The data is one command, the same one you can run yourself:

flua --tool hubList

One JSON document: the hub plus its QAs, each carrying its modified timestamp — which the tree turns into a "hub newer" badge when a downloaded copy has fallen behind.

View, download, edit, upload — without leaving the editor

Click a QA for its actions:

• View (.fqa) — opens the QA in the package viewer (metadata, variables, a Lua preview per file). The package is downloaded into the extension's local cache, keyed by hub and QA id, and the hub's modified timestamp decides freshness: view twice, download once. A cached package opens even with the controller unreachable.
• Download — unpacks the (cached) package into <workspace>/<name>-<id> for real editing.
• Run (UI) — starts flua --ui on the project; the viewer opens, F5-style.
• Update / Pack — upload the edited project back to the controller, or pack it as a .fqa.

The loop is: browse → download → edit → test → update. The cache exists so the controller never re-exports what it already gave you, and entries unused for 30 days prune themselves.

Completions that know your house

The editor completes HC3 API shapes (LuaLS types), but IDs are just numbers — until now. Inside these calls, completion offers real names:

fibaro.call(45, "turnOn")        -- 45 completes as "45 — Kitchen light"
fibaro.getValue(57, "value")     -- "57 — Heating"
fibaro.getGlobalVariable("Ala")  -- completes the variable name
fibaro.scene("execute", 3)       -- "3 — Evening lights"
fibaro.emitCustomEvent("Door")   -- completes the event name

The data comes from flua --tool house — the real hub when credentials exist, or a simulated house from a seed file, so completions work for a house that does not exist yet:

flua --tool house --db house.json

And for readable code, one command writes a LuaLS-annotated home table so HT.kitchen.light completes room by room and means something to a reader:

Flua: Generate home table (ht.lua)   -- the command palette; data from --tool house

Switching controllers

More than one HC3? Give each a name once, then switch from the view's title bar:

flua --tool hub add cottage http://192.168.2.30 admin    # prompts for the password
flua --tool hub switch cottage                            # the global default (~/.env)
flua --tool hub switch cottage --project                  # pin this project only

The extension's switch button lists the profiles (name, address, serial — the active one marked, passwords never shown) and switches the same .env chain every flua command reads. Project pins still win over the global default, so a folder can stay on the cottage while the rest of your work follows the switch.

The rule that keeps it honest

Nothing in the extension exists only in the extension. Every tree action is a --tool command first — hubList, house, hub — so agents and scripts get the exact same surface as the GUI (flua-mcp exposes it as typed tools), and the extension can never drift into behavior the CLI cannot reproduce. flua is the engine; this extension is the first app on top of it, not the last.

Next time: endpoint packages — wrap a simulated endpoint in a QA and distribute it as a .fqa, emulation like any other QA.