Repository navigation
fix(gateway): WHO 13 valid MAC, four-digit year, weekday, timezone 100, product firmware log; conformance matrix read form; #Z#C wording (Encyclopedia audit, group 7) - #161
Draft
gdluck wants to merge 5 commits into
Conversation
…uators_status report 21 G5 and the OpenWebNet-HA#140 leftover. docs/protocol_conformance_matrix.md showed `*OpenWebNet-HA#13*0*0##` / `*OpenWebNet-HA#13*0*22##` (WHERE 0) as the verified WHO 13 examples. The published read form has an empty WHERE, `*OpenWebNet-HA#13**DIMENSION##` (Encyclopedia who-13-integration-gateway/dimensions.md "Read form", capabilities.md "Command-session behavior"); the review-session oracle run of 2026-11-03 (audit_ency/ORACLE_CONFIRM.md row G5) has `*OpenWebNet-HA#13*0*0##` nack, silent on all twelve emulated gateways and `*OpenWebNet-HA#13**0##` answered on all twelve, and the builders (`request_time`, the event keepalive) already emit the empty form. OWNHeatingCommand.actuators_status called `#Z#N` "an actuator addressed through the central unit"; per who-4-temperature-control/addressing.md "Historical central-unit variants" the form is `#Z#C`, zone Z through a four-zone central unit C. Wording only; the accepted grammar is unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ekday, tz 100 and log wording report 21 G2, G3, G4, G6, G7, G8, G9, G10. G1 not changed: settled by OWNd#144 (closed 2026-10-28), master keeps raising ValueError for out-of-table clock values and the sessions catch it. G2 / G3: Dimension 12 decodes six decimal octets in 0..255 only (Encyclopedia who-13-integration-gateway/dimensions.md "DIMENSION 12 - MAC address"); an octet above 255 or an eight-value reply (the ZigBee interface IEEE address, zigbee-network-management.md "DIMENSION 12 - Interface IEEE address", ENCY_CONFIRM ZB-108) leaves mac_address None with the values raw in dimension_value. G4 / G10: a Dimension 1 / 22 year must be four digits (dimensions.md "DIMENSION 1 - Date"): `*OpenWebNet-HA#13**1*04*15*10*26##` stays a valid message as on master, with date None instead of 0026-10-15. New `weekday` property, 0..6 from `00..06`, None outside, date unchanged and no calendar cross-check (the TS10 client writes a fixed `00`, ENCY_CONFIRM G10). G7: `T` 100 (GMT-0) reads `+00:00` like `000`. G6: a parsed write frame `*OpenWebNet-HA#13**#0/michnovka#1/OpenWebNet-HA#22*...##` logs "Setting gateway time/date to: ..." (dimensions.md "Write form": client -> gateway writes, ENCY_CONFIRM G6); the reply form built by report_* keeps "broadcasting". G8: an addressed Dimension 16 reply (`*OpenWebNet-HA#13*123400#9*16*1*2*3##`) logs "Product 123400#9's firmware version" (zigbee-network-management.md "DIMENSION 16 and 17", ENCY_CONFIRM ZB-109/110); firmware_version and where are unchanged. G9: device_type docstring and the WHO13_DEVICE_TYPES comment say that an unlisted code stays `Unknown (N)` and that the non-unique 200 is a list of sharers, not a product identity (capabilities.md "Product identification", dimensions.md "DIMENSION 15 - Device type"). Tests: tests/test_message_protocol.py (tz 100 and 0530 still raising, year / weekday, write-frame logs, MAC range, eight-value dimension 12, addressed dimension 16). The pinned-raise tests of tests/test_message_edges.py and test_malformed_gateway_clock_is_rejected are untouched. Golden fixtures unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…nly WHO 13 helpers (decisions D59, D12, D14) report 21 G2, G3 (precedent gate). MyHOME#804 pins that OWNGatewayEvent.mac_address formats any six values without a 0..255 range check (tests/test_config_flow_identify.py: an octet 256 reads "100" and the config flow refuses it itself), so mac_address keeps that behaviour and the range-checked value moves to the new valid_mac_address property (six decimal ASCII octets in 0..255, Encyclopedia who-13-integration-gateway/dimensions.md "DIMENSION 12 - MAC address"; None for the eight-value ZigBee interface IEEE address of zigbee-network-management.md). _gateway_weekday, _gateway_date and the octet check take ASCII digits only (OWNd#139 rule: non-ASCII digits never decode). The docs-only CHANGELOG bullet is dropped (OWNd#143: no CHANGELOG entry when no runtime behaviour changed). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ock writes (MyHOME pin) report 21 G6 (precedent gate). MyHOME pins the log of the write form *OpenWebNet-HA#13**#0*22*50*00*## as "Gateway broadcasting internal time: 22:50:00." (tests/test_f461_who13_clock_tz_live_2026_10_26_trace.py::test_written_strings_fail_before_pass_after), so the "Setting gateway ... to" wording is not applied to parsed frames; the set_* builders keep their own "Setting gateway ..." text as on master. CHANGELOG bullet trimmed accordingly. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…w follow-up) report 21 G4. _gateway_date validated day / month only for a four-digit year, so *OpenWebNet-HA#13**1*04*99*32*26## parsed with date None where master raised on month 99 / day 32 (OWNd#144: out-of-table clock values keep raising inside parse). Day and month are now validated first exactly as on master (against a leap year, so 29 February passes), for dimension 1 and dimension 22 on both OWNGatewayEvent and OWNGatewayCommand; only a well-formed date with a non-four-digit year gives date None (Encyclopedia who-13-integration-gateway/dimensions.md "DIMENSION 1 - Date"). Tests cover both orders. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Requested by A
Summary
Before: a WHO 13 dimension 12 reply with an octet above 255 or with eight values (the ZigBee IEEE address) is formatted as a MAC; a two-digit year is accepted as year 26; the weekday field is never read; timezone code
100decodes as-00:00; an addressed dimension 16 reply is logged as the gateway's firmware; the conformance matrix shows*#13*0*0##as the read form (refused by all twelve emulated gateways); the device-type docstring does not say that unlisted or shared codes stay unknown; the merged #140 docstring ofactuators_statuscalls#Z#Can actuator form.After:
valid_mac_address(six octets 0..255, else None; eight values logged as the IEEE address) beside the unchangedmac_addressMyHOME's identify flow pins; a date needs a four-digit year (dateNone otherwise, frame still valid, day and month still validated first exactly as on master);weekday0..6 else None;100->+00:00; the addressed dimension 16 is logged as a product firmware; the matrix shows*#13**0##/*#13**22##; docstrings corrected;#Z#Cdescribed as zone Z through 4-zone central unit C. Out-of-table clock values keep raising fromOWNMessage.parseand the sessions keep catching them, as settled when #144 was closed.Context and how it was found. A asked for OWNd
masterto be checked against the OpenWebNet Encyclopedia functional pages (audit of 2026-10-28; 94 rows reproduced by running the code; confirmed by a firmware-oracle replay on the twelve emulated gateways and a whole-Encyclopedia search). This is the WHO 13 group (rows G2..G10, G1 deliberately not changed) plus the #140 leftover. Oracle:*#13*0*0##refused 12/12,*#13**0##answered 12/12.Changes
OWNd/message/gateway.py(who-13-integration-gateway/dimensions.md"DIMENSION 1", "DIMENSION 12", "DIMENSION 16",zigbee-network-management.md"DIMENSION 12";capabilities.md"Read form"):valid_mac_address(G2 / G3),_gateway_date(day / month validated first as on master, then the four-digit year, elsedateNone; same for dimension 22) (G4),weekday(G10),100->+00:00(G7), addressed dimension 16 log (G8;firmware_versionstill populated), device-type docstring andWHO13_DEVICE_TYPEScomment (G9), ASCII-only digit checks in the touched helpers (G12 decision). G1 not changed: out-of-table clock values (124,0530, hour 25, month 13, empty fields) keep raising, settled by OWNd#144 (closed 2026-10-28): the values are synthetic oracle stimuli, the sessions already catch theValueError, and a degraded message would let_locked_sendput malformed clock writes on the wire and clear MyHOME's unconfigured-timezone repair. G6 (write-frame log wording) dropped: MyHOME'sf461_who13_clock_tz_live_2026_10_26trace test pins the current text.OWNd/message/heating.py:actuators_statusdocstring:#Z#Cis zone Z through a four-zone central unit C (Encyclopediawho-4-temperature-control/addressing.md), not an actuator form (feat(heating): OWNHeatingCommand.actuators_status(where) builder for *#4*WHERE*20## #140 leftover).docs/protocol_conformance_matrix.md(G5): WHO 13 read form*#13**0##/*#13**22##, with the oracle rows.CHANGELOG.md:[Unreleased]### Changedbullets for the behaviour changes only (no bullet for docs-only edits).State Diagram
N/A — small decoder additions and documentation; the clock decode path is unchanged.
Where are the traces
tests/test_config_flow_identify.py,tests/test_f461_who13_clock_tz_live_2026_10_26_trace.py(OpenWebNet-HA/MyHOME#823)mac_addressformatting and the clock log texts MyHOME pins are unchanged: MyHOME suite 5187 passed against this branchownd-audit-framesreplay (2026-10-28, emulated)*#13*0*0##refused 12/12,*#13**0##answered 12/12What does the Oracle say
See the table above (row G5 of the audit).
Testing
tests/test_message_protocol.py(new WHO 13 cases: valid MAC range, eight-value address, year / weekday in both validation orders, timezone 100, addressed dimension 16, ASCII digits) andtests/test_message_edges.pyunchanged (its pinned-raise tests still hold).test_runtime_version_matches_installed_package);scripts/verify_coverage.py7,027 / 7,027, branch rate 1.0 ongateway.pyandheating.py;ruff check,mypy OWNd,scripts/verify_library_standards.py,scripts/sync_documentation.py --checkpass.v2-phase1-architecturesuite against this branch: 5187 passed, 1 deselected (the pin-bump doc test).Precedent check
Kept: #144 (clock values keep raising, send-path validation keeps rejecting malformed clock writes, whole-hour timezones only); #129 builders'
ValueErroron non-whole-hour offsets; MyHOME'sidentity.pyreads rawdimension_value(dim_val[3]/999untouched); the #139 decoder untouched. Changed back after running MyHOME's suite and a second-opinion review:mac_addresskeeps master's formatting (the range-checked value is the newvalid_mac_address), the write-frame log text stays, and day / month are validated before the year width.🤖 Generated with Claude Code