Repository navigation
Conversation
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Closed
3 of 4 tasks
gdluck
marked this pull request as draft
October 24, 2026 13:39
gdluck
force-pushed
the
fix/parse-hash-setpoint-and-clock-echoes
branch
from
October 24, 2026 15:44
78948c9 to
c09238e
Compare
This was referenced Oct 24, 2026
gdluck
pushed a commit
to gdluck/HomeAssistant-MyHOME
that referenced
this pull request
Oct 25, 2026
…; drop the OWNd#138 attribution Review of OpenWebNet-HA#815 (5644290768): the replay tests asserted the whole _actuator_states dict including the base branch's "valve" key, which OpenWebNet-HA#792 moves to _zone_active; they now assert the per-actuator keys only. The 'OpenWebNet-HA#20' write-form echoes are not covered by OpenWebNet-HA/OWNd#138 (dimension 14 values only), so that attribution is removed from the READMEs and tests. The F461 tx check accepts is_dimension_request beside the archived is_status_request value, so a later OWNd classification cannot fail the conformance gate. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
GreenGrassBlueOcean
pushed a commit
to OpenWebNet-HA/MyHOME
that referenced
this pull request
Oct 25, 2026
… (actuator status, fan speed and humidity per zone) Two physical captures behind #792 (actuator status at startup, hvac_action from dimension 20) and #793 (humidity gate), asked for in review 5642758778 of #792. f461_actuators_live_2026-10-25: a local Home Assistant at #792's head restarted with an event-only listener on the F461 2.0.11 / KW4691 zone 2 plant. The startup sweep is followed by *#4*#0*20##, answered by both actuators within 0.13 s (ACK after 2.13 s); climate.set_temperature 26.0 makes the valve report itself on 2.2 s after the dimension 12 echo (*#4*2#1*#20*1##, then *#4*2#1*20*1##), the restore to 23.5 makes it report itself off 2.1 s after the echo; the fan coil stays 5 / off. Every request is Home Assistant's, from its debug log, placed on the listener clock (source: home_assistant, t_estimated). The replay through the climate entity gives hvac_action idle -> heating -> idle and 23.5 -> 26.0 -> 23.5; the actuators attribute is asserted only where the entity exposes it. myhomeserver1_live_2026-10-25: status reads only on the MyHomeServer1 3.87.13 plant (zones 35-70): *#4*#0*20## ACKed in 0.50 s ahead of a 1.9 s burst of 43 distinct actuator frames (34 Z#1, 5 Z#2, the pumps 0#1..0#4, every one off); per zone *#4*Z*19## / *#4*Z*20## ACK on 34 zones and NACK on 54 / 56, *#4*Z*11## NACK on all 36 (the fan-speed dimension is refused on a valve zone), *#4*Z*60## ACK on the 17 zones with a probe and NACK on 19, *#4*0*60## answers the same 17; a 600 s listen with the house's own traffic. The replay of zones 35 and 47 through the climate entity gives idle with every actuator off; the pump frames have no route key and reach no zone. The 34 per-zone *#4*Z*60## reads join PHYSICAL_ONLY_TX_FRAMES (no oracle stimulus for a per-zone humidity read). Every rx frame parses in the pinned OWNd; the '#20' command forms parse as OWNHeatingCommand (OpenWebNet-HA/OWNd#138 decodes them, both are accepted). Synthetic MACs 00:03:50:00:10:25 / 00:03:50:00:10:26, documentation IPs; no log, no local path. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
`*michnovka#4*michnovka#1*14*#0230*1##` (MyHOME#139, "Data received is not a message") is a WHO 4 Dimension 14 setpoint reply whose value carries a '#' prefix. The general dimension-reply regex accepts digits only, so OWNMessage.parse returned None. A narrow allowlist (_HASH_VALUE_REPLIES, WHO 4 dimension 14 only) routes that shape to OWNHeatingEvent, which strips the '#' before decoding the temperature; dimension_value keeps the raw value and str(message) is the frame as received. A '#' in any other value still does not parse. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
gdluck
force-pushed
the
fix/parse-hash-setpoint-and-clock-echoes
branch
from
October 26, 2026 08:56
c09238e to
9991dd5
Compare
Contributor
Author
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
*#4*#1*14*#0230*1##(OpenWebNet-HA/MyHOME#139, "Data received is not a message") is a WHO 4 Dimension 14 setpoint reply whose value carries a#prefix, sent by a user's central unit every few seconds. The dimension-reply regex accepts only digits in values, soOWNMessage.parsereturnedNoneand MyHOME logged every occurrence as an unparsable event instead of using the setpoint.Fixes
OpenWebNet-HA/MyHOME#139on the OWNd side (the MyHOME log rate limit,OpenWebNet-HA/MyHOME#802, was closed at the maintainer's request: this parser change is the fix, and the warning disappears once the OWNd pin includes it). The WHO 13 clock-echo timezone fix that this PR carried at first is now its own PR (see Companion); the two have different evidence and different reviewers' checks.Changes
OWNd/message/base.py:_HASH_VALUE_REPLIES, a narrow allowlist of reply shapes that carry a#inside a value, limited here to WHO 4 Dimension 14 (*#4*WHERE*14*#TTTT*M##, one#, digits after it)._match_hash_value_replyis tried after the general reply regex, which is unchanged, andparse()routes those shapes to events. The new branch fills the same fields as the general one (_who,_where,_where_param,_dimension,_dimension_param,_dimension_value). A#value on dimension 12, on WHO 1, on the mode field,##0230,#02#30or a bare#still returnsNone.OWNd/message/heating.py: the Dimension 14 decoder strips the#beforewho4_temperature, givingset_temperature == 23.0;dimension_valuekeeps["#0230", "1"]andstr(message)is the frame as received.CHANGELOG.md: entry under[Unreleased]/Fixed.State Diagram
stateDiagram-v2 direction TB state "OWNMessage.parse(frame) for a dimension reply" as Parse { [*] --> General General --> Event : *#4*#1*14*0230*1## , digits only\nOWNHeatingEvent, set_temperature 23.0 , unchanged General --> HashAllowlist : value with a # - general regex does not match HashAllowlist --> Event : *#4*WHERE*14*#TTTT*M## only , new\nOWNHeatingEvent, set_temperature 23.0, dimension_value [#0230, 1]\n, before - None, MyHOME Data received is not a message HashAllowlist --> NoneResult : any other # value\n*#4*#1*12*#0230*1##, *#1*11*1*#5##, *#4*#1*14*0230*#1##\nNone , unchanged }Where are the traces
No physical trace of ours applies: the
#-prefixed setpoint is in no oracle suite and in neither of our captures. The live F461 2.0.11 and MyHomeServer1 3.87.13 (trace PROpenWebNet-HA/MyHOME#799, merged) answer dimension 14 with plain values (*#4*2*14*T*3##,*#4*35*14*...##). The evidence for the shape is the user log inOpenWebNet-HA/MyHOME#139(frames*#4*#1*14*#0230*1##,*#4*#1*14*#0231*1##,*#4*#2*14*#0205*1##, replayed inOpenWebNet-HA/MyHOME#802's test).OpenWebNet-HA/MyHOME#799run 6 holds a#-prefixed dimension echo (*#4*2#1*#20*0##), a different shape that this PR does not touch.What does the Oracle say
No oracle stimulus exists for this frame: no suite sends or emits a
#-prefixed dimension 14 value.Testing
tests/test_who4_hash_setpoint.py(new, 11 cases): theOpenWebNet-HA/MyHOME#139frame parses asOWNHeatingEvent/MESSAGE_TYPE_TARGET_TEMPERATURE/ 23.0 °C with the raw value kept anddimension_param == []; three zone forms (#1,1,#0#2); the plain setpoint is unchanged; six#shapes elsewhere still giveNone.master4 fail, 7 pass (OWNMessage.parse('*#4*#1*14*#0230*1##')isNone); on this branch all 11 pass.1918 passed, 1 skipped(master:1907 passed, 1 skipped); 100 % statement coverage,mypyclean,ruffclean,scripts/sync_documentation.py --checkandscripts/verify_library_standards.pypass.Live retest (2026-10-24)
Not exercised live: parser-only, and the F461 sends no
#-prefixed setpoint (no*#4*...*14*#TTTT##on this plant).Companion
MyHOME: none (
OpenWebNet-HA/MyHOME#802closed; the warning stops once this parser change is pinned). Related OWNd PR (split from this one):fix(gateway): WHO 13 clock echoes with timezone 0530/124 no longer raise: #144.🤖 Generated with Claude Code