NC01-NC04 Independent User Acceptance Cards
Ownership: overall improvement plan G05/G06, V14. Materials are written; all actual trials are NOT_RUN. This document is not a support list and does not prove the listed page capabilities are complete; when forms, templates, diagnostics, or migration previews are missing, record a product gap — do not let developers hand-edit configs to work around it. Candidate version, hardware, wiring, trial personnel, and acceptance thresholds are not yet filled in; do not backfill with historical device pass records.
The current software's operation scope and entry points are listed below; trials must still be bound to the actually installed firmware/web, and devices must not be passed just because development documentation exists.
| Scenario | Corresponding instructions | Scope to verify before starting |
|---|---|---|
| NC01 Thermostat | Local Thermostat Rules | Local Celsius producer and a dedicated native low-level-energized output; do not fit arbitrary UART/Modbus values or expanders into thermostat control |
| NC02 Collection reporting | MQTT Configuration, PeriphExec | Local enqueue/retention and actual platform receipt are separate; define message fields and the receiving end first |
| NC03 Read-only meter | Meter Templates and Word Order | Exact model/version, wiring, registers, and scaling must be verified; importing a template only generates a disabled draft |
| NC04 Board migration | Device Configuration and Migration | A reusable plan does not include identity, network, or protocol field configs; target protocol, wiring, and rule semantics must be verified separately |
Actual test and build results for the software candidate are unified in Candidate Status; the field still records the 20 cases below independently.
1. Confirm Before Starting
- Log in with an authorized account and confirm "Device Configuration → Advanced Config → Developer-mode features" is enabled; peripheral/rule editing, meter templates, and migration endpoints depend on this switch.
- The trial user did not participate in implementing the corresponding feature. The implementer may provide this document and wiring notes but does not operate on their behalf and does not provide hidden APIs, JSON, scripts, or C++ modifications as normal steps.
- Record the device model/board revision, a desensitized MAC identifier, firmware and web artifact hashes, config version, and wiring diagram. The source version cannot be just a Git HEAD; it must reference the candidate input summary.
- Back up the field config first, preserving the target device identity, auth, network, MQTT, and existing rules. Published material must not contain passwords, tokens, private addresses, or full backups.
- Operate only within the authorized device scope. Unverified relays, motors, pumps, valves, and power loads are not operated; NC01 should first use a confirmed low-risk test load. This document adds no device or dangerous-output authorization.
- Fill in the applicable scope and expected results independently. Missing hardware/wiring/safety conditions/trial users are recorded BLOCKED; missing necessary UI capabilities are recorded FAIL (product gap); N/A items state the reason and must not be silently skipped.
- Before testing, confirm the old config is recoverable and that recovery will not overwrite the device identity. Fault injection, restarts, and disconnects each have authorization and recovery entry points; do not insert operations into an ongoing deployment or long-term-stability window.
2. Unified Recording Rules
Each item uses one of PASS, FAIL, BLOCKED, NOT_RUN, N/A, distinguishing page save, actual effect, valid sampling, command response, device readback, and physical feedback. Write PASS only with the corresponding evidence.
| Field | Filling requirements |
|---|---|
| caseId / operation time / trial user | e.g. NC02-03; use a timezone-aware time; the trial user is a non-sensitive identifier |
| Candidate and config | Input summary, firmware/web hashes, board type, config summary; do not stitch together passes from multiple candidates |
| Preconditions / inputs | Wiring, load, sampling/thresholds/units, verified template source; leave unfilled if not provided |
| Expected / actual | Fill expected first; actual records visible values, time, state, and errors; do not backfill thresholds from actual results |
| Evidence | Screenshots, desensitized report records, device state, and physical observations linked separately; an independent directory per round, not overwriting failures |
| Help / sticking points | Hint text, click paths, whether developer intervention was needed and what it involved |
| Conclusion / recovery | Status, issue ID, recovery process and recovery result; a successful recovery does not erase the original failure |
Automated/Mock regressions can only be linked as E2 attachments. Real hardware E4, continuous runs E5, and independent users V14 are listed separately; automation cannot sign off on manual records.
3. NC01: Thermostat Relay
Prerequisites: supported temperature sensor, output module, verified wiring, and a low-risk load; reviewed units, upper/lower thresholds, hysteresis, minimum on/off times, staleness limit, and fail-safe state. Do not enable the output without these verified parameters.
| Case | Trial user completes via the UI | Acceptance points | Initial state |
|---|---|---|---|
| NC01-01 | Select the sensor and output in Feature Config and Peripheral Configuration, filling pins/channels per the wiring notes | Precheck explains resource conflicts; readings carry correct units and validity; saving vs taking effect is distinguished | NOT_RUN |
| NC01-02 | Select data source, temperature condition, hysteresis, minimum on/off times, and fail-safe policy in PeriphExec | All required capabilities have form fields; any missing required field is a product gap — do not patch with scripts | NOT_RUN |
| NC01-03 | Change the temperature per the reviewed method and observe operation on both sides of and near the threshold | Consistent with the pre-filled thresholds/timings, no jitter; command, readback, and physical load feedback recorded separately | NOT_RUN |
| NC01-04 | With permission, cause sensor staleness/disconnection and recover | Staleness does not become a valid 0; state is understandable; fail-safe and recovery policy match the agreement | NOT_RUN |
| NC01-05 | After a confirmed restart, check rules and outputs, then disable via the UI and restore the original config | Restart does not unexpectedly drive the load; disable result is verifiable; recovery does not overwrite identity/credentials | NOT_RUN |
4. NC02: Data Collection and MQTT Reporting
Prerequisites: existing sensor, an approved MQTT test receiver, and agreed sampling period/fields/units/staleness policy; do not send field data to an unauthorized platform.
| Case | Trial user completes via the UI | Acceptance points | Initial state |
|---|---|---|---|
| NC02-01 | Add the sensor in Peripheral Configuration and check readings | Successful, failed, and unsampled are clearly distinguished; fields/units/time are explainable | NOT_RUN |
| NC02-02 | Configure MQTT in Communication Protocols, binding sampling fields and monitor display | No hand-written scripts/JSON; credentials do not enter screenshots; page and receiver fields match | NOT_RUN |
| NC02-03 | Compare local display, rule values, and MQTT messages | Same source, scaling, units, and quality semantics; sampling time and message arrival time recorded separately | NOT_RUN |
| NC02-04 | With permission, disconnect the test network, then restore the connection | Offline/cache age visible; queue bounded and justified; recovery per agreement, no passing old values as new samples | NOT_RUN |
| NC02-05 | With permission, restart, then check saved state and resume collection from the UI | Identity/rules/bindings preserved; invalid samples are not reported as valid zeros | NOT_RUN |
5. NC03: Read-only Modbus Meter
Prerequisites: exact meter model/revision and a verified read-only template, including serial parameters, address, function codes, registers, scaling, word order, and units. Without a verified template, record BLOCKED; never guess registers in the field or open write commands.
| Case | Trial user completes via the UI | Acceptance points | Initial state |
|---|---|---|---|
| NC03-01 | Select/import a verified read-only template from the UI | Model/version/applicable scope clear; needing hand-written frames or JSON to proceed is a product gap | NOT_RUN |
| NC03-02 | Fill in address, serial, and wiring, and bind engineering-value display | Business logic unchanged; conflict precheck blocks invalid resource combinations before they take effect | NOT_RUN |
| NC03-03 | Verify scaling, word order, and units against the meter reference reading | Tolerance agreed first; protocol readback and calibration/physical measurement recorded separately | NOT_RUN |
| NC03-04 | With permission, verify timeouts, short frames, and CRC errors on the authorized test link, then recover | Failure types and staleness shown; old values not reused as new samples; unverified write capability never auto-enabled | NOT_RUN |
| NC03-05 | With permission, restart and restore the template config | Bindings and logical IDs preserved; display valid only after fresh valid samples are obtained post-recovery | NOT_RUN |
Steps requiring professional tools to produce bad frames are performed separately by the test lead with evidence; target users only need to understand the problem and recovery through the UI and are not required to program. Do not fake a pass when fault-injection conditions are missing.
6. NC04: Migrating to a Supported Board
Prerequisites: source/target boards within the declared support scope, target's existing config backed up, and identity/credential preservation policies clear for both; business outputs are disabled by default.
| Case | Trial user completes via the UI | Acceptance points | Initial state |
|---|---|---|---|
| NC04-01 | Export a reusable desensitized plan from the source device | Version/dependency/resource requirements identifiable; no field passwords/tokens smuggled in | NOT_RUN |
| NC04-02 | Preview import differences on the target and remap wiring | Shows incompatible drivers, missing capabilities, reserved pins, and bus conflicts; no preview is a product gap | NOT_RUN |
| NC04-03 | Fix issues in the UI and save | Failure does not wipe valid old config; dangerous outputs not auto-enabled; target identity and credentials not overwritten | NOT_RUN |
| NC04-04 | Check data sources, logical IDs, rules, and display bindings | IDs/rules whose business meaning is unchanged are preserved where possible; necessary changes are shown explicitly with no dangling references | NOT_RUN |
| NC04-05 | With permission, restart and restore the original config | Migration plan is recoverable; identity preserved; when lossless rollback is impossible, explicitly block and record | NOT_RUN |
7. V14 Exit Criteria and Handover
- One or more target users who did not participate in implementation complete the applicable scenarios independently; record all help and sticking points, not just success screens.
- Every required case has candidate-bound actual evidence; FAIL/BLOCKED/NOT_RUN do not count as passes; N/A has a written reason and does not waive the committed support scope.
- At least the applicable restarts and fault recoveries are completed, the device config is recoverable, and secret data is not leaked.
- Feed UI gaps back to G05, action/quality gaps back to G04, resource/lifecycle gaps back to G01-G03; physical/long-term stability is handed to G06 separately.
- Completing only this document does not mean the wizard, templates, four scenarios, or V14 are complete. Final conclusions are written back into the Release Acceptance Checklist; document counts must not substitute for product acceptance.