diff --git a/docs/runbooks/slzb-mr1u-zigbee-coordinator.md b/docs/runbooks/slzb-mr1u-zigbee-coordinator.md index 7bb3e95..933f84b 100644 --- a/docs/runbooks/slzb-mr1u-zigbee-coordinator.md +++ b/docs/runbooks/slzb-mr1u-zigbee-coordinator.md @@ -6,7 +6,7 @@ Moved onto the IoT VLAN 2026-09-04 and handed to Home Assistant. address 10.0.90.10 slzb-mr1u.esh.internal network esh-iot, VLAN 90, 10.0.90.0/24 switch USW Pro XG 10 PoE - ESH-Media (10.0.250.164), port 4, PoE ~1.0-1.5 W - zigbee tcp/6638 web UI tcp/80 + zigbee tcp/6638 web UI tcp/80 also open: tcp/7638 consumer Home Assistant container at 10.0.50.46 (esh-docker-vm, macvlan on VLAN 50) ## The shape, and why it is this shape @@ -21,20 +21,31 @@ nothing about its own address. one pre-existing reservation on this network — the Brother printer at `10.0.90.125` — is *inside* the pool; the out-of-pool convention starts here. -## ⚠ The MAC is locally administered, and that was worth checking +## The MAC is a derived ESP32 interface address — stable, not fragile - ea:f6:0a:ca:f5:b4 no OUI, LAA bit set + ethernet (what DHCP sees) ea:f6:0a:ca:f5:b4 LA bit SET + base (what mDNS advertises) e8:f6:0a:ca:f5:b4 Espressif Inc. (verified against IEEE) -A DHCP reservation keys on the MAC. A device that regenerates its MAC at boot -would silently miss the reservation, land on a pool address, and take the DNS -record stale with it — long after anyone remembers this change. +⚠ **An earlier version of this runbook called the MAC "locally administered, no +OUI" and treated it as the kind that may regenerate at boot. That framing was +wrong and ha-dev corrected it.** The two addresses differ in exactly one bit — +the locally-administered bit — which is the standard ESP32 pattern: one factory +base MAC in eFuse, sibling interface MACs derived from it deterministically. The +Ethernet interface gets the derived `ea:` variant; mDNS advertises the base +`e8:`. `E8:F6:0A` resolves to **Espressif Inc.** in the IEEE registry and +`EA:F6:0A` correctly resolves to nothing, which is what confirms the two are the +same address wearing different bits rather than two unrelated MACs. -**Tested rather than assumed, and free:** the PoE power-cycle needed to make the -device re-DHCP onto the new VLAN is also the MAC-stability test. It rebooted -(client uptime reset to 66 s) and came back on **exactly 10.0.90.10** — which -only happens if the reservation matched, i.e. the MAC survived. If a future -firmware changes that behaviour, the symptom is the device appearing somewhere in -`10.0.90.40–250`. +So the reservation is keyed on the right address and the derivation cannot drift +on its own. Independently consistent with the test below. + +**Tested anyway, and it was free:** the PoE power-cycle needed to make the device +re-DHCP onto the new VLAN is also a reboot. It came back on **exactly +10.0.90.10** — which only happens if the reservation matched. + +The residual risk is real but narrow: only a firmware update that changed the +derivation scheme would move it. Symptom if that ever happens — the coordinator +reappears somewhere in `10.0.90.40–250`. ## ⚠ port_overrides is a WHOLE-ARRAY PUT @@ -87,3 +98,22 @@ Backups of both mutated objects are transient (session scratch), so the durable path is: set ESH-Media port 4's `native_networkconf_id` back to `687985eae5d15b673cef1a73` (esh-userland), clear `use_fixedip` on the client, and drop the `slzb-mr1u` line from `dns/internal.yaml` + re-run `scripts/dns-sync.py`. + +## mDNS crosses the VLAN boundary — and that has one sharp edge + +`esh-iot` has `mdns_enabled: true`, so the coordinator's advert reaches the +Home Assistant container across VLANs and HA rediscovers it without help. + +⚠ **HA's pending `smlight` config flow is keyed on the mDNS service name, which +did NOT change across the move — so the same flow id survived and may still hold +the dead 10.0.10.58.** Dismiss and re-discover rather than confirming the stale +flow. This is the kind of thing that makes a device look broken after a clean +network change. (Reported by ha-dev, 2026-09-04.) + +## Resolver: ha-dev declined the `dns:` fix, deliberately + +Offered and turned down: pointing the homeassistant service at `10.0.50.45` +would couple HA's name resolution to AdGuard's uptime for a benefit they do not +currently need, since configuring by IP costs them nothing. Recorded on their +side as a standing foot-gun with the fix written down. Revisit only if something +inside the container actually needs a name.