[gdluck]

Requested by A

What is the problem

Every frame OWNd hands back as a plain string is logged at WARNING by GatewayEventDispatcher ("Data received is not a message"). A device that repeats such a frame (in #139 a zone thermostat behind an MH202 pushing *#4*#1*14*#0230*1##-style frames every few seconds) fills the log with identical warnings; the message is user-visible but not user-actionable after the first occurrence. The parser side of #139 (making OWNd understand the #-prefixed dimension 14 setpoint) is OpenWebNet-HA/OWNd#138; this PR only stops the flood in MyHOME, so it does not close the issue.

Refs #139.

---

What is the solution

1. gateway_events.py:
   • frame_shape() collapses digit runs to N (*#4*#1*14*#0230*1## → *#N*#N*N*#N*N##), so frames that differ only in values share one shape. The key is the whole collapsed frame (no prefix truncation).
   • The first frame of a shape is logged at WARNING with the suffix "(further frames of this shape are logged at DEBUG)"; repeats go to DEBUG. At most UNPARSED_SHAPES_MAX = 64 shapes are remembered per dispatcher; beyond that everything is DEBUG, so the set cannot grow without bound.
   • The regex touches the raw string only for logging; no frame is decoded in MyHOME. Collapsing digits also merges e.g. dimension 14 and 15 shapes of the same layout; that is accepted for a log-level decision.
2. tests/test_unparsed_frame_logging.py: three dimension 14 frames of one shape plus the live F461 answer to *#13**27## (*#13**27*70#52#54#49##, the model name as ASCII codes, a str in OWNd 2.0.0b11) yield exactly two WARNINGs and two DEBUG lines; the dedup key keeps the whole frame (two long frames differing past 120 characters stay apart); the 64-shape cap (patched to 2) sends the third shape to DEBUG. Fixture host 192.0.2.5, MAC 00:03:50:00:00:01.
3. .github/release-notes/2.0.0b16.md: one line under "Other changes", naming the 64-shape ceiling.

---

Companion PR: OpenWebNet-HA/OWNd#138 (fix(message): parse '#'-prefixed dimension 14 setpoint values): once it is released, the #139 frames parse and never reach this code path; the rate limit stays for any other unparsed frame.

---

State Diagram

stateDiagram-v2
    direction TB
    state "GatewayEventDispatcher.process_message(frame OWNd returned as str)" as Dispatch {
        [*] --> Shape : frame_shape, digits collapsed to N
        Shape --> FirstOfShape : shape not seen and fewer than 64 shapes remembered
        Shape --> Repeat : shape seen, or 64 shapes already remembered
        FirstOfShape --> Warning : WARNING Data received is not a message - `*#4*#1*14*#0230*1##` , further frames of this shape are logged at DEBUG - shape remembered
        Repeat --> Debug : DEBUG with the same text
    }
    state "Before this PR" as Before {
        [*] --> EveryFrame : WARNING for every frame , *#4*#1*14*#0230*1##, *#4*#1*14*#0231*1##, ...
    }

Loading

---

Hardware Verification

• No unparsed frame occurred on the physical F461 2.0.11 plant while the integration ran; the only live str frames are the *#13**27## replies captured on request (below). The #-prefixed dimension 14 frames of Data received is not a message #139 exist only in the reporter's MH202 log; nobody on our side can put them on a bus safely (they are central-unit writes), so the rate limit is unit-test only.
• Live retest 2026-10-24 (report-15 consensus label not exercised live): no Data received is not a message line in any run; the F461 produced nothing unparsed and no safe injection exists.

---

How is it tested

• tests/test_unparsed_frame_logging.py::test_unparsed_frame_warns_once_per_shape (failed before: four WARNINGs instead of two), ::test_frame_shape_keeps_the_whole_frame, ::test_unparsed_shapes_are_capped (new).
• Fail-before / pass-after, the test file on the original source: 3 fail (the once-per-shape test with four WARNINGs instead of two, and the two tests that import the not yet existing frame_shape / UNPARSED_SHAPES_MAX); all pass after.
• Full suite against OWNd master (f04d8aa, the behaviour of the 2.0.0b11 pin): 4421 passed, 1 skipped (base v2-phase1-architecture ddc6d60: 4418 passed, 1 skipped).
• scripts/verify_ownd_coverage.py 100 %, scripts/typing_ratchet.py 0 errors (baseline 0), ruff check ., scripts/verify_ha_standards.py, scripts/sync_documentation.py --check, scripts/manage_translations.py check all pass.

Live retest (2026-10-24)

Consensus label: not exercised live (no unparsed frame on the plant, no safe injection).

---

Where are the traces

Subsystem	Capture	Plant	Frames verified by this PR
WHO 13 dimension 27 reply as an unparsed str	tests/fixtures/traces/f461_live_2026-10-23/ run run1_oracle_replay_readonly, step plant_reads (trace PR: #799, open)	F461 2.0.11	*#13**27## → *#13**27*70#52#54#49## on the command session and echoed on the event session, ownd_class: str (no decoder in OWNd 2.0.0b11; OpenWebNet-HA/OWNd#139 adds one). The test's second shape is this frame.
Same, second gateway family	tests/fixtures/traces/myhomeserver1_live_2026-10-24/ run run1_identify (trace PR: #799, open)	MyHomeServer1 3.87.13	*#13**27## → *#13**27*77#121#72#111#109#101#83#101#114#118#101#114#49##, ownd_class: str on the event session
#-prefixed dimension 14 setpoint frames	Issue #139 log only (reporter's MH202); not in any fixture of this repository	MH202	*#4*#1*14*#0230*1## (the shape the test replays)

---

What does the Firmware Oracle / Encyclopedia say

No oracle stimulus exists for this change: the oracle records what a gateway answers, not how a client logs a reply it cannot parse. The *#4*#1*14*#…## form itself is the subject of OpenWebNet-HA/OWNd#138.

---

Checklist

• PR Description: Follows the structured sections above (What is the problem, What is the solution, State Diagram, How is it tested, Where are the traces, What does the Firmware Oracle / Encyclopedia say).
• Trace-Backed (if protocol/device change): log level only; the str frame in the test is the live F461 / MyHomeServer1 *#13**27## reply from test(trace): ingest live F461 2.0.11 2026-10-23 capture and MyHomeServer1 3.87.13 reads behind OWNd #136-#142 and MyHOME #791-#798 #799, the dimension 14 frames are the ones reported in Data received is not a message #139.
• V2 Architecture: N/A, no entity changes.
• Tests & Linters: pytest, ruff, and scripts/verify_ha_standards.py pass.

🤖 Generated with Claude Code

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[GreenGrassBlueOcean]

This change is a logging rate-limit for frames that OWNd returns as plain strings (“Data received is not a message”).The root cause is in OWNd: frames such as #4#114#230*1## (WHO 4 Dimension 14 setpoint replies with a #-prefixed value) are not parsed by OWNMessage.parse because the general dimension-reply regex only accepts digits. That is exactly what OpenWebNet-HA/OWNd#138 addresses.This PR does not parse the frames and does not close #139. It only suppresses log noise while the real fix lives elsewhere.Recommendation: close this PR here and land the parser fix in OWNd (#138). Once that is released and pinned by MyHOME, these frames stop arriving as unparsed strings and the rate-limit becomes unnecessary.The logging hygiene may still be useful as a general safety net for any future unparsed frames, but it is not the fix for this issue.

[gdluck]

Agreed: the fix for #139 is the parser change in OpenWebNet-HA/OWNd#138, and this PR only quietened the symptom. Closing it as you recommend; if a general safety net for unparsed frames is wanted later it can come back as its own small PR once the OWNd pin includes the parser fix.