vNext: Fix the DHCP step for the sub-units of a gateway

[Twintop]

Context

This is a bug fix in preparation for Gree zone controller support. I found it while porting the changes I made for my own zone controller (Gree LE60-13/GH) to this project. The zone controller support itself will come in a later PR. Background and the full plan: https://github.com/Twintop/ha-gree-zone-controller/blob/main/upstream/README.md

Symptom

When Home Assistant reports the DHCP lease of a VRF gateway or a zone controller, the DHCP flow fails:

  File "/config/custom_components/gree_custom/config_flow.py", line 363, in async_step_dhcp
    new_data[CONF_DEVICES][discovery_info.macaddress][
    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: '<gateway mac>'

Seen on Home Assistant 2026.10 after a restart, with the 5 sub-units of a zone controller configured.

Cause

1. The lease MAC is the MAC of the gateway. async_step_dhcp() scans that IP and gets the sub-units back. It finds the entry with the MAC of each sub-unit (d.mac), but then looks up the device with the lease MAC, which is not in the entry. For a normal unit the two MACs are the same, so this only fails behind a gateway.
2. new_data = dict(entry_match.data) is a shallow copy. The host is changed inside the nested dicts, and those are the same objects as in the entry. async_update_entry() then compares two equal dicts, sees no change, does not save the new IP and does not reload the entry. This part also affects normal units.

Change

• Look the device up with d.mac. For a normal unit that is the lease MAC, so nothing changes there.
• Copy the entry data with copy.deepcopy(), so the entry sees the change and saves it.
• docs/configuration.md: the automatic IP update also covers the sub-units of a gateway.

Testing

• The test suite does not cover the config flow. pytest: 254 passed, as before.
• Ruff passes. Mypy and Pylint show nothing new compared with 5.0-dev. I ran them without Home Assistant installed, so I compared the findings with the base branch.
• Real device, Home Assistant 2026.10 with the 5 sub-units of a LE60-13/GH zone controller: before the change, the error above was in the log after a restart. With the change, it is gone. I could not test a real IP change, because the controller kept its IP.

[RobHofmann]

Thanks, this is a clean fix and both causes are right.

What I checked:

• In Home Assistant 2026.10, async_update_entry only saves when entry.data != data. With the old shallow copy, the nested dicts were changed in place, so the comparison saw no change: the new IP was not saved and the entry was not reloaded. The deep copy fixes that.
• d.mac is always a key in the entry, because get_entry_matching_mac(d.mac) already matched it.
• I ran the real async_step_dhcp in my fake-device harness against 5.0-dev and against this PR merged onto the current 5.0-dev tip. Base: a gateway lease raises KeyError, and a plain unit with a new IP is not saved and not reloaded. PR: the sub-units of a gateway and a plain unit both get the new IP, with one reload per entry. An unchanged IP causes no update and no reload.
• On my dev instance with my test unit, the PR starts clean and polls normally. I could not test a real DHCP lease there.

Two small things for a later PR, not blocking: the TODO: Check if this only returns True if the IP Changed can go now (it does), and copy.deepcopy(entry_match.data) does not need the dict().

[RobHofmann]

Correction to my review: the dict() in copy.deepcopy(dict(entry_match.data)) is needed, so please leave it in.

ConfigEntry.data is a MappingProxyType, and copy.deepcopy cannot copy one:

TypeError: cannot pickle 'mappingproxy' object

Without the dict(), the DHCP step would fail for every unit. The other point still stands: the TODO can go, and I will remove it in a small follow-up PR.