flua compatibility notes — what changed to match the real HC3

flua's promise is that the same QA file behaves the same on your laptop and on the controller. To keep that promise honest, flua's behavior is now regularly pinned against a real HC3 — every REST response shape and status, the QA runtime's own view of the api, and the fibaro table. That work surfaced a batch of differences, and flua now matches the controller. If your QA asserts statuses or leans on sim-only conveniences, here is what changed.

The QA's own api layer

• Unknown routes answer 501 inside QA code — the HC3's local layer answers 501, not the external REST's 404. api.get on a path no route serves now returns (nil, 501).
• GET /plugins/<id> answers 501 from QA code — even for the QA's own id. QAs on the HC3 don't read that route; the variable endpoints (/plugins/<id>/variables...) stay readable and are the supported way.
• POST /plugins/updateProperty is own-device only — external callers get 400, like the HC3. A QA updates its own properties (and its children's); self:updateProperty keeps working as always.

QuickApp methods

• self:getProperty is gone. The HC3's QuickApp has no such method — read self.properties.name instead. A sim-only method was a trap: the QA would work on the laptop and break on the controller.
• self:getView stays, but as a documented flua extension — handy for verify QAs that assert UI state on the laptop; it does not exist on the HC3, so keep it out of code that ships.

Status codes

• POST /quickApp (create QA) → 201 (was 200).
• DELETE /devices/<id> → 200 (was 204).
• POST /customEvents → 201 (was 200); deleting an absent event answers 204 (was 404).
• POST /globalVariables → 201 + the full variable dto; DELETE /globalVariables/<name> → 200 (idempotent, was 204/404).

Name rules

customEvent and globalVariable names are validated like QA variable names: [A-Za-z][A-Za-z0-9_]*. A name like my-event is rejected at creation (400) — the HC3's rule, hyphens and all. On the customEvents name routes an invalid name answers the HC3's own quirk, 501.

fire and publish are forgiving

Firing a customEvent that was never created (POST /customEvents/<name> or the publish GET) answers 204 — the HC3 does not error on unknown names, it just does nothing. flua used to 404; QAs that treated the 404 as "not created yet" should check the event list instead.

/plugins is a catalog

GET /plugins answers the HC3's plugin-type catalog ({installed, all}), not a device list. In online mode flua passes the controller's answer through. QA devices live in /devices, like on the HC3.

Everything above is pinned by the offline test suite — the same capture-based parity checks that will re-run against each new firmware, so the differences stay honest rather than drifting back.