Intesis

Thank you for your sarcastic and mostly useless AI evaluation of the QA. You should perhaps refer to the original version before deciding if this one is a waste of time. I look forward to utilising your complete and perfect QA when it's published.

1. "+" and "−" buttons behave identically when leaving AUTO (fan speed & vane position) Location: uilessVelocOnReleased / uiplusVelocOnReleased and uilessPositionOnReleased / uiplusPositionOnReleased Issue: Both the increase and decrease handlers use the exact same branch for the AUTO case (CFG.fanSpeedMin / 1), so pressing "+" while in AUTO produces the same result as pressing "−" — it jumps to the minimum instead of increasing. Why it matters: Looks like a copy-paste error where the "+" handler was cloned from the "−" handler and the AUTO branch wasn't updated. Confirm intended behavior and fix the "+" branch to move upward from AUTO. 2. TCPPort and acNum variables are never validated Location: onInit Issue: IPAddress is checked for empty string and shows a clear warning in the UI before polling starts. TCPPort and acNum get no equivalent check — if TCPPort is empty or non-numeric, tonumber() returns nil and the app silently proceeds into loopRefresh(), producing repeated connection errors with no clear diagnostic message. Why it matters: Inconsistent UX for misconfiguration; a user will see generic TCP errors instead of a clear "port not set" message like they get for the IP field. 3. Initial sock:connect() call is not wrapped in pcall Location: QuickApp:tcpExchange Issue: Every other failure path in the function (write, read, watchdog timeout) is caught and routed through fail(), but the very first call — sock:connect(self.ip, self.port, {...}) — is not protected. If the underlying HC3 socket API throws synchronously (e.g., on a nil port from issue #2, or a malformed IP), the exception would propagate uncaught instead of being handled. Why it matters: This is the one gap in an otherwise consistently defensive function; a synchronous throw here could stop the QuickApp instead of just logging a connection error. 4. Intesis protocol traffic is unencrypted and unauthenticated Location: Protocol-level (not fixable in the QuickApp code itself) Issue: All communication with the Intesis gateway is plain-text ASCII over TCP with no authentication. Why it matters: Anyone with network access to the same LAN/VLAN as the gateway can send arbitrary SET commands to the AC unit. Recommend documenting this as a deployment note (isolate the gateway on its own IoT VLAN) rather than a code fix. 5. acNum variable is inserted into the command string without format validation Location: QuickApp:intesisSend, QuickApp:intesisRead Issue: self.acNum is concatenated directly into the command ("SET," .. self.acNum .. ":" .. func ...) without checking it's a valid number. Why it matters: Low real-world risk (requires HC3 admin access to edit the variable), but a stray CR/LF or unexpected character in this field could inject an extra line into the TCP stream. Cheap to add a numeric-format check. 6. Position variable comparison is case-sensitive Location: onInit, applyVaneControlVisibility, vane button handlers Issue: The check is self.position == "True" (exact string match). Entering "true" (lowercase) silently disables vane controls with no warning. Why it matters: Easy to trip over when configuring the variable manually; consider case-insensitive comparison or a boolean-style variable. 7. CFG.commandTimeout is reused for two unrelated purposes Location: CFG config table Issue: The same constant controls both the delay between sequential poll reads and the delay between sending ONOFF and MODE during a mode change. Why it matters: Not a bug today, but a maintainability risk — tuning polling cadence would unintentionally also change mode-change timing. Suggest splitting into two named constants.