[GreenGrassBlueOcean]

Fixes #777.

Problem

A Legrand 067226 detector has no relay. It sits at the A/PL of the F411 channel it switches (52) and reports WHAT 34 / 39 there. Once binary_sensor discovered <mac>-52-motion, _ForeignAddresses treated 52 as a sensor address. As a result:

• ghost() removed the configured light.myhome_spots_wc on reload, logging only at INFO.
• accept() skipped the myhome.yaml entry.
• WHAT 39 was unknown, so the light logged unknown lighting WHAT 39.
• Startup dimension queries (*#1*52*5##, *#1*52*7##) are answered by the 067226 with WHERE=0 (*#1*0*5*2##, *#1*0*7*0*0*45##), which were dropped as general frames so the motion sensor kept its defaults (Timeout: 315, Sensitivity: medium).

Commits

1. gdluck's patch (authorship kept), from the [2.0.0b16] Configured light removed on reload after motion sensor discovery at the same WHO 1 address (F454 / Legrand 067226) #777 discussion:
   • _ForeignAddresses knows the configured lights. blocks_light() still blocks switch and cover addresses, and sensor addresses with no configured light, so the [Feature / Bug]: Dynamic discovery for WHO 1 light/motion sensors (Legrand 048834) & ghost light prevention #244 / fix(sensor): dynamic discovery for WHO 1 light/motion sensors and ghost light prevention (#244) #245 ghost pruning is unchanged.
   • WHAT 39 counts as a sensor frame, and the motion sensor turns off on it.
2. Trace replay of the reporter's F454 capture:
   • Detector cycle 34 → 1000#1 → 1, then 39 → 1000#0 → 0.
   • The *#1*0*5|6|7*…## dimension replies come back with WHERE 0. They must not create or change a light.
3. Audit follow-ups:
   • One WHAT 39 test. is_motion_end() in discovery.py is shared by light and binary_sensor. It checks motion_end (OWNd with WHAT 39) or unknown_state == 39 (b11). The patch's broader fallback is gone: it treated any motion_detected with motion False as the end of movement. So is its read of the private _state.
   • Bus interface respected. A configured light only protects its own bus interface: a light at 52#4#01 no longer keeps a ghost at plain 52.
   • Visible removal. Removing a light because its address reports motion or illuminance now logs a WARNING. It names the entity and says to declare the light in myhome.yaml. On/off frames at such an address log a one-time INFO hint.
   • force_update reset after the motion sensor writes a WHAT 39 state.
4. Leftover warning from the reporter's retest:
   • What remained. With the patch on b16, light 52 reports unknown lighting WHAT 39; keeping its last state was still logged once per cycle (comment [2.0.0b16] Configured light removed on reload after motion sensor discovery at the same WHO 1 address (F454 / Legrand 067226) #777 (comment)).
   • Why. The binary_sensor motion discovery publishes WHAT 34 / 39 to WHO 1 key 52, which the light at 52 also listens on, so route_foreign never sees those frames.
   • Fix. MyHOMELight.handle_event now ignores sensor frames: motion, end of movement, and dimensions 5–7. The new test reproduces the reporter's exact warning without this guard.
5. Evidence citations:
   • The test module and is_motion_end() used to cite a firmware corpus file that is not in our oracle.
   • They now cite feat(oracle): add who1-motion-detector suite for a detector sharing an actuator address (MyHOME#777) own-firmware-oracle#56 (merged).
6. In-flight correlation for anonymous WHERE=0 dimension 5 and 7 replies:
   • Confirmed by the reporter's reload log and tcpdump capture ([2.0.0b16] Configured light removed on reload after motion sensor discovery at the same WHO 1 address (F454 / Legrand 067226) #777 (comment)): for both *#1*52*5## and *#1*52*7##, the WHERE=0 reply (*#1*0*5*2## / *#1*0*7*0*0*45##) arrives on the event session ~140 ms after the worker unqueues the request, while the command session is still waiting ~2.0 s before returning *#*0## (NACK).
   • CommandWorkerPool tracks messages currently inside await _command_session.send(...) and exposes claim_in_flight_dimension_where(who, dimension) (forwarded by MyHOMEGatewayHandler across secondary delegation and warm-standby failover).
   • When a WHERE=0 dimension 5 or 7 frame arrives on binary_sensor's WHO 1 on_general hook and exactly one point-to-point target WHERE is in flight for (1, dimension), it consumes the in-flight entry immediately and routes the reply to that motion sensor (Sensitivity: high, Timeout: 60.0 s). If zero or multiple workers have concurrent requests for the same (who, dimension), or a second stray frame arrives before the NACK, it is dropped.

Evidence

• WHAT 39 = end of movement:
  • Specified in the ZigBee OpenWebNet spec (KB ownkb:claim:c001481).
  • Observed on the reporter's F454 about 45 s after the last WHAT 34, matching the DIM 7 timeout *#1*0*7*0*0*45##.
  • Firmware-observed in OpenWebNet-HA/own-firmware-oracle#56 (merged): suite who1-motion-detector (findings), 12 emulated gateways, each run twice and byte-identical in CI (run 39967360131).
  • B8 52 1D 00 / 01 give *1*34*52## / *1*39*52## on F454 2.0.51, F459, F460, F461, MH200N, MH202 and MyHomeServer1. F453 / F453AV give only WHAT 34.
• The WHERE 0 replies are on the bus and precede the command-session NACK:
  • Firmware oracle: *#1*0*5*2##, *#1*0*6*0## and *#1*0*7*0*0*45## come out byte-exact from D5 00 21 44 {10,15,16} … frames whose address byte is 00.
  • Physical F454 reload + tcpdump capture (#777 comment): *#1*0*5*2## (+138 ms) and *#1*0*7*0*0*45## (+139 ms) arrive on the event connection ~1.86 s before the command connection receives *#*0## (+2.11 s / +2.02 s).
• Status polling of a shared address is safe: *#1*52## returned exactly one reply, from the F411.
• Reporter's retest on b16 + OWNd b11:
  • The light came back with its entity ID and settings.
  • A config-entry reload keeps both entities.
  • WHAT 39 clears the motion sensor immediately instead of after 315 s.

Deliberately not done

• Lights at sensor addresses without configuration. These stay blocked. On the bus, a 048834 in scenario mode ([Feature / Bug]: Dynamic discovery for WHO 1 light/motion sensors (Legrand 048834) & ghost light prevention #244) and a 067226 driving its own F411 look the same, so the user declares the light in myhome.yaml. The new WARNING / INFO lines say so.
• Anonymous WHERE=0 illuminance (DIMENSION 6). Every reading in the reporter's capture was *#1*0*6*0## even with the spots on, so DIMENSION 6 is not attributed until its behaviour on the 067226 is understood.
• OWNd WHAT 39 as a first-class event. That is fix(lighting): WHAT 39 is the end of movement of a WHO 1 motion detector OWNd#135. This PR works with b11 and with that branch.
• myhome.send_message errors. The ERRORs in the reporter's first trace came from sending these requests by hand with that service. That is fixed separately in fix(services): send status and dimension requests from send_message as requests #782 (merged).

Testing

• [2.0.0b16] Configured light removed on reload after motion sensor discovery at the same WHO 1 address (F454 / Legrand 067226) #777, light, binary_sensor, and gateway suites pass against both editable OWNd and the released OWNd 2.0.0b11 pin.
• mypy --strict (scripts/typing_ratchet.py), ruff, verify_ha_standards.py, and sync_documentation.py --check are clean.

[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]

merging this as it is confirmed working by topic starter

#777 (comment)