Repository navigation
Support Area-0 point-to-point lighting addresses (A=0, PL=1–15) assigned by Home + Project #684
Description
Problem Description
Installations configured using Legrand's Home + Project app (e.g. paired with an F460 or MyHomeServer1) assign light point addresses progressively starting at A=0, PL=1, A=0, PL=2, etc. Legrand support confirms this allocation rule cannot be changed.
When interfacing such an installation through an OpenWebNet gateway (observed on physical MH200 firmware 2.1.0, reported by @peterbeepping in OpenWebNet-HA/own-firmware-oracle#35):
-
Discovery Rejection as Broadcast:
- When an Area-0 actuator (such as an F411/4 channel 1 at
A:0 PL:2) operates or reports status, the gateway emits*1*1*2##(single-digitWHERE 2). - In
custom_components/myhome/light.py,build()explicitly drops single-digit WHEREs:This leaves newly added Area-0 devices completely undiscoverable in Home Assistant.if where in ("0", "00", "1", "2", "3", "4", "5", "6", "7", "8", "9", "100"): LOGGER.warning( "Refusing to create a light entity for broadcast WHERE %s (must be group or point-to-point)", where, ) return None
- When an Area-0 actuator (such as an F411/4 channel 1 at
-
APL Command / Status Query Rejection:
- In
custom_components/myhome/const.py,is_apl_address()classifies0001–0015as canonical 4-digit APL for Area 0. - However, physical MH200 gateways NACK both 4-digit
*1*1*0002##and 2-digit*1*1*02##. - Polling status with
*#1*0002##or*#1*02##is likewise NACKed.
- In
-
Collision with Area Commands:
- If configured as
where: "2", sending*1*1*2##acts as an Area 2 command and switches all lights in Area 2 instead of the target device.
- If configured as
-
Local Bus & DALI Channels:
- F429 DALI channels assigned to
A:0 PL:2–9on local bus#4#01(*1*1*0002#4#01##vs*1*1*2#4#01##) require verified address routing.
- F429 DALI channels assigned to
Proposed Plan
- Gather Authentic On-Wire Hardware Captures:
- Capture live bus traces from an installation containing Area-0 devices (MH200, F460, F411/4, F429) to determine how the physical gateway, wall switches, and Home + Project app communicate.
- Oracle Cross-Firmware Verification:
- Add
area0.casestoown-firmware-oracleto determine which gateways (F460, MyHomeServer1, F454, MH200N) accept0001–0015vs02vs2. - Also request the original MH200 CD-ROM firmware to emulate the physical MH200 directly.
- Add
- Gateway Profile & Disambiguation in MyHOME:
- Allow YAML-configured Area-0 entities where the user explicitly defines the device as point-to-point.
- For gateways that accept 4-digit addressing (F460 / MyHomeServer1), preserve
0001–0015. - For gateways that emit single digits (MH200), establish whether command translation or specific framing is required.
Related
- Request: lighting test cases for area-0 point addresses (A=00, WHERE 0001–0015) assigned by Home + Project own-firmware-oracle#35
- [Bug]: Point-to-Point APL address parsing collision (APL 0015 vs 15) and WHO 14 button naming #250 (Point-to-point APL address parsing collision)
- trying to add manual entries for bticini by yaml becuase no bus state shared from switches. #171 (User attempting manual YAML entries for Home + Project A:00 PL:15)
Activity
wave68runner commentedon Oct 10, 2026
I could be wrong, but I don't have any problem with the addresses created by Home + Project.
Discovered with MH200 and MHS1
GreenGrassBlueOcean commentedon Oct 10, 2026
@wave68runner how is the b15 experience sofar are you happy?
peterbeepping commentedon Oct 11, 2026
Thanks for the quick and detailed reply. I ran controlled captures on the real hardware. Setup: one event session (
*99*1##) and one command session (*99*0##) open at the same time, frames sent one by one, all traffic timestamped. The target point was switched physically on the actuator before each run, so its state was known.Hardware
The point is rendered as
2in both cases. With the physical press only, every point of area 2 reports its state right afterwards, without switching, as if a*#1*2##had been issued. This was reproduced on all four presses. No client sent anything during the capture. From the event session alone I can't tell which device issues that implicit area-2 query: the MH200, the F460, or the actuators themselves reacting to the frame.My working hypothesis is that the MH200 misreads the spontaneous state report of A0PL2 as "area 2 changed" and refreshes its state cache with an area-2 status query. With a commanded change it has already seen the command, so it doesn't need to query. I plan to confirm this with two tests: physically switching an ordinary point (e.g. 21), where I'd expect no burst, and repeating the A0PL2 press with the F460 disconnected from the bus. Does your knowledge of the SCS framing explain why a local state change of an A=0 point triggers an area-status cycle, while a commanded change does not?
Result 3: F460 as OWN gateway
HMAC-SHA256 (
*98*2##) authentication succeeds.*#13**15##and*#13**16##are ACKed. Every WHO 1 and WHO 2 frame (status and command) is NACKed, including frames for ordinary points such as*#1*12##, which the MH200 answers normally. This looks like a WHO filter rather than an addressing issue. Is this known or emulated in the F460-family profiles?Other observations that may be useful for emulation
*#1*2##and*#1*0##are ACKed only about 6 s after the last real reply. During that window the MH200 forwards all bus frames into the command session, including unrelated ones (*1*19*29##,*1*2*97#4#01##). Clients have to filter.*1*19*29##plus*#1001*29*11*111111111111111111101111##about once per second, unprompted. On a general status, six more actuators reply WHAT 19 with a*#1001bitmask: 39, 49, 59, 89, 95#4#01 and 98#4#01. For example, 59 replies111110111111111101100111and 39 replies111110111111111111100111. Is WHAT 19 strictly a fault, or could it also mean something like "no load" or "configuration"?Current workarounds (for context, neither is satisfactory)
*1*x*2##. The drawbacks:71) with MyHOME_Suite works immediately through OWN:*#1*71##replies*1*0*71##, and commands work. But Home + Control and Home + Project can then no longer control the object. As soon as the object is edited in Home + Project, the address is reset to A=0 PL=2. Home + Project assigns addresses itself, starting at A0PL1, and Legrand confirmed this cannot be changed. So this only works if you give up Home + Project / Home + Control for that object, which isn't an option alongside the F460.Questions
0n/000non input for A=0 points and A=00 PL10–15, on both the private riser and the local bus#4#01? Replacing the gateway may solvethe problem.
Full logs are attached. Happy to run further frames on this hardware.
own_capture_verwarming_20261010_161733.txt
own_capture_verwarming_20261010_161043.txt
own_capture_luister_20261011_175623nfysieke knog.txt
own_capture_luister_20261011_175140 homecontrol.txt
GreenGrassBlueOcean commentedon Oct 13, 2026
@peterbeepping thanks, this capture is very useful. I checked it against the firmware oracle (OpenWebNet-HA/own-firmware-oracle, suite
lights-area0) and went through your three questions.1. Will an MH200N / F454 take
02for an A=0 point?In the oracle, yes. MH200N (010108), F454 (020051), F459 (020105) and F453AV (030014) all ACK
*1*1*02##and*1*1*02#4#01##, and put a telegram on the bus that differs from the one for*1*1*2##, so it is a point-to-point address and not area 2. The four-digit*1*1*0002##is NACKed or dropped by every emulated gateway (the MH202 ACKs it but turns it into*1*1000#1*02##), so the 4-digit form is not the one to use for A=0.Caveat: your MH200 2.1.2 NACKs
02, and the emulated MH200N ACKs it. They are different models and the oracle runs emulated firmware, so I can't promise a replacement gateway behaves the same. If you can borrow an MH200N or F454 to try*1*1*02##, that is the test that decides it.2. F460 NACKing WHO 1/2.
The oracle reproduces it: the F460 (020012) and F461 (020011) NACK every
*1*1*…variant I tried, so it looks like it simply does not take OWN lighting commands. Your live F460 also NACKs status requests; the emulation ACKs*#1*2##, so the emulation differs from your unit there.3. Why does a press trigger an area-2 burst?
Your capture shows it clearly. The press emits
*1*1*2##/*1*0*2##, and 0.1-1.1 s later the gateway sends*1*0*21##..*1*0*29##, about 40-50 ms apart. That is what a refresh of area 2 looks like, so your hypothesis (the MH200 reads WHERE 2 as area 2) fits. Your two planned tests, a normal point and the F460 disconnected, will tell the MH200 and the F460 apart; the capture alone can't.What this means for MyHOME
*1*1*2##), so MyHOME cannot tell them apart from the frame alone. The guard against single-digit WHEREs stays.02is the form to aim for. I'm looking at an opt-in for a YAML light declared as02, but I can only test it on the emulated firmware, so I will need your hardware to confirm it.WHAT 19. I can't say yet whether it is strictly a fault. Your six extra actuators carry a
*#1001DIM 11 mask like the one I saw on another MH200, and the bit meanings are not documented. Your masks differ per device (…01100111vs…11100111), so treat them as evidence only. In the current beta, WHAT 19 sets the light to unknown (not off) instead of failing.Session limit. Thanks for the reset/refuse pattern (back after about 7 minutes). I'll check how MyHOME backs off when it sees that.
GreenGrassBlueOcean commentedon Oct 13, 2026
@peterbeepping one more request: do you still have the original MH200 firmware, for example the
MH200_2_1_2.fwzservice pack you mentioned or the installation CD-ROM that came with the gateway (and, if it's a different file, the 2.1.0 one)?The firmware oracle (OpenWebNet-HA/own-firmware-oracle) so far only emulates the MH200N, which accepts
*1*1*02##where your physical MH200 2.1.2 NACKs it. With the real MH200 firmware we could replay these frames and see why, instead of guessing from the model difference. Only the firmware file is needed, no capture or access to your gateway.Merge pull request #700 from OpenWebNet-HA/feat/area0-684
test(fixtures): add A=0 PL=2 physical press trace from an MH200 (Open…
Merge pull request #713 from OpenWebNet-HA/feat/issue-684-area0-point…
gdluck commentedon Oct 15, 2026
Another data point, F461 firmware 2.0.11 on a Home + Project plant with an F411/4 (channels at A=0 PL=6 and PL=7, earlier today PL=1 and PL=4):
*#1*06##answers*1*0*06##and*1*1*06##switches the light;*#1*0006##is NACKed in 14 ms;*#1*6##is ACKed after 1.0 s with no reply and*1*1*6##is echoed as an area-6 command with no light reacting. On this gateway the 2-digit0Pform is the only working one (the F461 itself emits*1*1*06##), the 4-digit form is refused and single digits are areas, the opposite of the MH200 2.1.0 behaviour in the report.peterbeepping commentedon Oct 15, 2026
I solved the problem in my home by using an old touchscreen (my home touchscreen 3,5" axolute h4890) as the openweb gateway. This old touchscreen handles the zero adresses correctly.
I asked and got the old firmware of the mh200 from Legrand support. I'm going to try to update the mh200 with it. Maybe then it will work again. But you were also interested in it, so I included the file in this post. I don't have the original cd rom.
MH200_020102.zip
GreenGrassBlueOcean commentedon Oct 21, 2026
Resolved in PR #700 (
2c3531c7) and PR #713 (3d033ebc), with additional live F461 Area-0 (WHERE 06,07) hardware verification in PR #752 (1b3486cf) and PR #753 (0f7ae38d). Thank you @peterbeepping and @gdluck for the traces and firmware data!