Skip to content

feat(firmware_oracle): read gateways[].reply_semantics and explain empty-bus NACKs - #21

Closed
gdluck wants to merge 1 commit into
OpenWebNet-HA:mainfrom
gdluck:feat/reply-semantics
Closed

gdluck wants to merge 1 commit into
OpenWebNet-HA:mainfrom
gdluck:feat/reply-semantics

Conversation

@gdluck

@gdluck gdluck commented Oct 24, 2026

Copy link
Copy Markdown
Contributor

Requested by A

Summary

lookup_firmware_verdict currently explains every NACK as "Gateway refused/rejected the command", and compare_gateways groups NACK + OUT as a separate outcome class. On F460 020012, F461 020011 and MyHomeServer1 028206 that reading is wrong for most rows: those firmwares report success only after a device TX-ACK, which the empty emulated bus never gives, so NACK with verdict OUT means "the frame went out, no device answered", not a refusal (own-firmware-oracle findings/empty-bus-reply-semantics.md; 228 of the 309 OUT rows of each of those gateways are NACK). Since schema 1.2.0 the index says this per gateway in gateways[].reply_semantics (empty_bus_txack / pic_ack / unknown); MyHOME already reads verdicts that way (MyHOME#766). An AI agent reading the current tool output concludes that e.g. *#1*06## is refused by the F461, which it is not (a live F461 answers it).

Changes (src/openwebnet_mcp/firmware_oracle.py)

  • load() keeps a product -> reply_semantics map (empty string for an index without the field).
  • reply_meaning(product, reply, verdict): one sentence per row. NACK + OUT on an empty_bus_txack gateway: "Frame went out on the bus; the NACK is this firmware's empty-bus rule (no device TX-ACK on the emulated bus), not a refusal." NACK + SILENT: "Gateway refused the frame (*#*0##); nothing reached the bus." Other replies keep their wording.
  • format_verdict_markdown (the Ground Truth lines of lookup_firmware_verdict) uses it.
  • compare_gateways(frame=…) adds a note under the outcome classes when such rows are present: NACK + OUT on those gateways is not a divergence from ACK + OUT.
  • The fleet summary table gets a Reply Semantics column; status() exposes the map.
  • An index without the field (the bundled 1.1.0 snapshot until chore(oracle): sync the bundled oracle index to own-firmware-oracle 53f9514 (schema 1.2.0, 529 inputs) #20 lands) keeps the plain reading: no behaviour change until the field is present.

Tests

tests/test_firmware_oracle.py: five new tests on a schema-1.2.0 index built in tmp_path (F461 empty_bus_txack, MH200N pic_ack, a catalogued F455): the map is loaded and exposed; reply_meaning for every reply/verdict pair; the Ground Truth text for an empty-bus row, a refused row and a pic_ack NACK; the compare_gateways note and the fleet column; and an index without the field. One existing assertion changed with the wording (refused/rejected → refused the frame … nothing reached the bus).

Verification

🤖 Generated with Claude Code

…pty-bus NACKs

Schema 1.2.0 of own-firmware-oracle's index says what a reply means per
gateway: on F460, F461 and MyHomeServer1 the firmware reports success only
after a device TX-ACK, which the empty emulated bus never gives, so a NACK
with verdict `out` is "went out, nobody answered", not a refusal
(findings/empty-bus-reply-semantics.md). The oracle tools read that field
now: the Ground Truth lines of lookup_firmware_verdict say so instead of
"refused/rejected", compare_gateways adds a note under the outcome classes
when such rows are present, the fleet summary shows each gateway's
semantics, and status() exposes the map. An index without the field keeps
the plain reading.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@gdluck

gdluck commented Oct 26, 2026

Copy link
Copy Markdown
Contributor Author

Heads-up: this PR shares tests/test_firmware_oracle.py with #22 and will conflict once that lands; I will rebase it on #22 right after the merge (the reply_semantics reading here is not part of #22, so both are needed).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants