Modbus Control Results and Sources

Corresponds to the 2026-10-04 software candidate. At 10:46, focused r11 actually passed 385/385, covering the accurate-frame core, Protocol42, virtual peripherals 35, HTTP52, frozen reports 22, and boot/report compatibility; earlier subsets such as MQTT scalar55 also passed. The full precheck r7 is still running, and none of these results are nine-environment, device, resource/memory, or long-term-stability acceptance.

Web sessions, saved screen cards, and rule motor operations share control ownership of the same actual Modbus instance and slave. After configuration, rule, UART, or screen source changes, old operations must not be redirected to a new device. Read-only status checks do not request output ownership.

The submit endpoint returns an operation ID, which only means the operation was accepted. Continue to query pending, success, and outputSteps for that operation. commandAcknowledged=true per step means only a communication acknowledgment; it cannot replace mechanical motion, limit switches, or load feedback. On failure, the completed prefix is kept; the whole batch is not retransmitted.

When the caller times out while the backend is still running, attemptKnown=false and attempted=null in the ordinary control result mean whether a write occurred is still unknown; backendOperationId points to the retained motor operation, and acknowledgedSteps is the number of acknowledged steps. Do not treat this situation as "not executed" and immediately reissue motion commands.

The current software emergency stop uses only the stop register and value saved in the configuration and executes after the in-flight transaction finishes; it cannot replace an independent hardware E-stop. Stop acceptance, communication acknowledgment, and mechanical standstill are three different states.

Direct MQTT motors use the same source and worker path. PWM/PID, PM virtual peripherals, typed rules, named scripts, and delayed execution have been connected to the original sources; it is not just the motor/relay two paths. Address ownership is checked before value validity; overlapping mappings cannot be hidden because another device rejects the value. Actual wiring, motion, memory overhead, fault recovery, and long-term stability are still unfinished.

MQTT modbus_raw_send keeps FC1-4 as read-only passthrough. Write frames first validate the accurate frame and saved mappings, then the server generates the MQTT source; standard FC05/06/15/16 and explicitly supported relay-proprietary frames are under the same arbitration. On rejection or when no callback is available, the frame no longer falls into a same-named rule or another direct-write path, and there is no direct UART write fallback. A returned complete exception frame is still an exception and must not be treated as a successful write.

MQTT results matching rules use only the frozen attribute identifiers, values, reasons, and sampling quality captured at execution time; failed values are empty — the original request values are not passed off as observations. A batch report is rejected if identity is lost or serialization fails, and cannot be redirected to the current configuration; already executed actions are not rolled back or retried because of this.

Single Write, Batch, and Maintenance

The candidate's generic HTTP write, single/batch registers, and relay batch control first verify the saved slave and register mappings. Missing, overlapping, or submit-time-changed mappings reject execution; source control cannot be bypassed by filling in arbitrary addresses. Fields must be the POST fields allowed by the corresponding endpoint; duplicate fields, file fields, or self-chosen actor/source are not accepted. Values must be complete decimal integers; batch registers accept at most 123 uint16 values, address ranges must not cross 65535, and a second trailing JSON is not accepted.

success=true means the communication steps required by this request were acknowledged. outputAttempted means an output was attempted; acknowledgedCommandCount and acknowledgedSteps keep the acknowledged prefix, and the step list holds at most 32 items. After an exception, short write, CRC error, or timeout, the whole batch is not retransmitted and subsequent outputs are not continued; existing ACKs are not erased by later failures. physicalOutputVerified stays false. When independent readback is unavailable, states elements are null and must not be read as all-off.

Address/baud-rate writes additionally require developer mode and use bus-maintenance permission; they may be rejected when ordinary output ownership exists or an unfinished delay window is open. Maintenance endpoints do not accept holdMs and provide no takeover-confirmation operation for other outputs. A communication ACK does not automatically rewrite the saved slave address/baud-rate configuration — configurationUpdated=false in the response means the configuration must still be verified per the device maintenance flow. A broadcast address change especially requires confirming on site what is connected.

In 2026-10-04 focused r8, the accurate-frame/maintenance core 101 items, five HTTP entry points 29 items, and motor compatibility 10 items passed locally; this is 140-item subset evidence, not a nine-environment, physical, or deployment conclusion.

Three Layers of Delayed Results

Delayed control uses the saved channel, protocol, and NC configuration; submitted NC parameters inconsistent with the configuration are rejected. An explicit software delay mode is not converted to hardware flash-on. The software final write keeps the original source and operation deadline and re-verifies at expiry; old operations are not reissued after source retirement, instance replacement, or expiry. Request completion and timed-producer completion are different states.

initialCommandAcknowledged means only the preceding communication steps were acknowledged; finalScheduled means only that the software final step was registered; finalCommandAcknowledged holds only after the actual final write is acknowledged. A hardware delay command may have started even if its ACK is lost, so the core still keeps the possibly active hardware window and rejects other operations from taking over the same slave during it. A passed window only means the wait period ended; it does not prove the contact or load reached the target state.

2026-10-04 focused r9 passed HTTP batch/delay 61 items; the full 268-item batch once had 2 core failures after a hardware window expired; the fix was re-verified in successor r10/r11, and the original FAIL evidence is kept. A failure response requires examining the acknowledged prefix and unknown results; do not retrigger immediately just because the UI reports failure. The final state of a real load must be confirmed by independent feedback.