Action Checks and Result Boundaries

2026-10-04: implemented in the software candidate, awaiting centralized regression and subsequent device verification; the following does not constitute field acceptance.

Before a rule is saved, the device is asked to run a configuration check. If the precheck rejects it, communication fails, or the response is invalid, saving does not continue. When there is a risk warning or a level toggle is used, read the check result first, then click Save again to confirm; modifying the form, reopening the form, or a new check result triggers a fresh check. Ordinary configuration does not require extra confirmation just because an explanation field is missing.

The expandable "Action Results and Retry Notes" covers check results that need a decision:

• Success for GPIO/PCA9685 means the device accepted the command; success for DAC means the driver accepted the write. Neither proves that the real load or voltage is correct.
• Repeating a level toggle changes the output again; when the result is unknown, do not simply retry.
• ADS1115 returns the sample plus quality/freshness, and may reuse a cache that keeps the original sample time. The conversion budget is not a deadline for the whole action; expired or failed readings must not be treated as valid measurements.
• A thermostat action reads the persistent controller state; actual switching and fault-off are managed by the controller, and pin state is not load feedback.
• Action semantics that are not provided and the overall timeout are explicitly unknown; do not infer device support or physical acceptance from the description fields.

Both rule-based and manual DAC writes accept only decimal integers 0-255; invalid values are no longer clamped or wrapped as a byte. Before writing, re-check the enabled/running state and ownership; manual writes also re-check the configuration version captured at check time — after re-configuring the same ID, a new check must be initiated. Failed resources are kept for explicit cleanup; outputs are not replayed automatically.

This check only validates configuration and the documented software boundaries; it does not execute rules, drive physical outputs, or verify wiring. Field testing must still confirm device identity, a stable candidate, configuration preservation, and wiring safety.

Manual Output Ownership and Execution Results

The successor candidate has connected source-ownership checks for ordinary native digital outputs, still pending centralized verification. Web sessions, saved screen cards, rules, and MQTT requests each carry their own ownership; manual ownership defaults to 30 seconds. Dedicated outputs such as thermostat and RESET/OE cannot be taken over by ordinary manual actions. This note does not extend to DAC, PWM, or expander outputs.

When a conflict occurs, the UI shows the specific target, the current source, and the remaining ownership at query time; re-verify after state changes. Manually executing an entire rule may include multiple targets and will not auto-confirm takeover. Confirmation for the direct single-target interface must be bound to that target, the configuration version, and the current ownership version; old confirmations cannot be reused for new configuration.

After clicking Execute, only one submission is made, and the UI queries execution records at most three times. Unconfirmed results, network failures, or not-yet-appearing records do not trigger automatic re-execution; never click again after a timeout to guess the result, especially for level toggles. Execution completion only means the device recorded it; it does not prove relay contact or load action. After switching pages, late results for the old page are no longer shown.

Ordinary rule outputs on the screen are bound to the saved layout and cards. A failed save does not give the new layout output identity; when the card binding or version you see has changed, refresh and re-verify. Device/load acceptance has still not been performed.