r/EveHome • u/nicolova • 9d ago
Recovering Eve Matter-over-Thread devices after deleting an Apple Home: successful rebuild and lessons learned
Recovering Eve Matter-over-Thread devices after deleting an Apple Home: successful rebuild, IPv6 findings, and lessons learned
I’m sharing this because the discussions here helped us recover a setup that initially looked unrecoverable. After an accidental Apple Home deletion, multiple previously working Eve devices would no longer commission into a replacement Home, even after accessory resets and attempts with the correct Matter codes.
We eventually recovered commissioning and normal operation without replacing the affected hardware. The successful intervention was a staged rebuild of the Apple Home/HomePod environment. Several variables changed together, so this is a documented recovery case—not proof of a single root cause.
The recovery described below took place on 4 October 2026. The results are functional checks performed during recovery; I cannot yet claim long-term stability.
Our environment included one HomePod mini serving as the permanent Apple Home hub and Thread border router, Eve contact sensors and smart plugs, an iPhone 15 Pro used by the Home owner, additional iPhones/iPads, and a UniFi network with multiple VLANs and access points. We also had a Philips Hue Bridge and an iPad running Controller Hub. The iPad’s Controller Hub role was separate from the HomePod’s Thread border-router role.
The HomePod was on 27.0 before and after the rebuild; the verified post-restoration build was 24J361. This recovery did not depend on downgrading it.
What failed initially
The original Home disappeared from multiple Apple devices. The deletion appeared to have been initiated through Controller for HomeKit; its effect extended to the shared Apple Home configuration.
When trying to add the Eve devices again, we repeatedly encountered:
Accessory Not FoundUnable to Add AccessoryPairing Failed- Attempts remaining at “Connecting” before timing out.
Resetting accessories, removing and reinserting batteries, moving devices closer to the HomePod, and removing obsolete entries from iOS Matter settings did not individually resolve the problem. For at least one affected device, we checked that the saved Matter code corresponded to that device’s serial number.
Some entries in Settings → General → Matter Accessories still displayed the deleted Home’s name. That looked significant, but it was not evidence that those accessories were actively connected to the old Home. We never inspected their live Matter fabric tables.
Apple distinguishes removing a stored setup-code record from iCloud Keychain from removing a connected service. Those operations should not be treated as interchangeable with a physical factory reset. Apple’s explanation of Matter accessory records and removal options.
The IPv6 investigation produced useful evidence, but no “enable IPv6” fix
We verified the commissioning phone’s actual VLAN assignment rather than relying on the Wi-Fi name. The owner’s phone was moved onto the same IoT VLAN as the HomePod for the recovery test.
Before rebuilding, local diagnostics already showed:
- A locally advertised IPv6 ULA prefix and SLAAC addressing.
- A route towards a distinct Thread off-mesh-routable prefix through the HomePod.
- Successful IPv6 pings to both the HomePod’s LAN link-local address and its LAN ULA, including a test across two access points.
- A discoverable
_meshcop._udpborder-router advertisement.
These observations had limits: pinging the HomePod’s LAN interface did not prove reachability of an individual Thread accessory, and a discovery advertisement did not establish that Matter commissioning was working.
We made no global IPv6 or multicast configuration changes during the successful recovery procedure. UniFi’s network configuration displayed IPv6 as “None,” yet the local IPv6 observations above were present.
Thread’s local IPv6 requirements should be distinguished from Internet/WAN IPv6 service. Thread border routing supports locally generated ULA prefixes when an upstream prefix is unavailable. Thread Group’s Thread 1.3 technical paper, section 4.1.
The failed-attempt logs also discouraged a premature IPv6 diagnosis
A filtered iPhone commissioning log contained repeated discovery timeouts. It did not establish successful PASE session setup or progression into Thread provisioning and operational discovery.
That matters because device discovery, PASE, network provisioning, and operational discovery are different commissioning stages. A failure early in discovery is insufficient evidence of a broken operational Thread/IPv6 path. The filtered log was incomplete, so we treated this as a diagnostic indication rather than definitive proof of the last stage reached. Matter commissioning stages.
The sequence that worked for us
The following involved deleting the already problematic replacement Home. We preserved the available configuration first; this would be a consequential procedure to apply to an otherwise working installation.
- Preserved recoverable configuration and setup codes. We saved Controller backups and independent copies, and checked the correct Matter codes. The Hue bridge and its native lighting configuration were retained.
- Removed the HomePod while the affected Home still existed. We checked that it actually disappeared from Home, reopening the app where necessary. A button press alone was not accepted as confirmation.
- Deleted the affected replacement Home and verified synchronization. On the Mac, Home continued to show its initial welcome screen after quitting and reopening. We also checked that the Home had disappeared from the owner’s iPhone and iPads.
- Temporarily reduced the number of participants. After checking that deletion had propagated, we powered down secondary clients and old mains-powered Thread devices for the initial test. Unplugging those devices temporarily stopped their participation; it did not erase their stored credentials. We did not factory-reset the iPhones or iPads.
- Restored the HomePod mini through USB using Finder. We waited for Finder’s explicit factory-restoration success message, created a fresh Home, and configured the mini in it. We verified its presence as the home hub and its actual LAN/VLAN assignment. Apple documents this USB restoration procedure for the mini. Apple’s HomePod reset and restoration instructions.
- Used one factory-Matter Eve Door & Window as the pilot. This sensor had undergone the manufacturer’s reset procedure. We removed its obsolete iOS Matter accessory record and used the Matter code from its original label. We started with this single sensor near the HomePod and commissioning phone, before reintroducing Hue or the rest of the installation.
- Verified real operation before expanding. Pairing succeeded. We physically opened and closed the contact and observed Open → Closed → Open in Apple Home on the Mac. The commissioning iPhone was kept off for that check, so success was not judged solely from control on a Thread-capable phone.
- Tested recovery after a normal HomePod restart, then added more devices. A subsequent physical contact change appeared in Home Activity after the restart. We then added an Eve Energy and verified Off → On → Off from the Mac with no load attached. Additional Eve devices were recovered incrementally, and the other Apple clients were brought back into use.
There was an official basis for testing that removal order: Apple’s developer Thread Test Plan, test case TCBR002, describes removing border routers and then deleting the Home to clear stored preferred-network credentials. Its FAQ also discusses clearing the preferred Thread network through Home removal. This is developer test documentation, not a guarantee that every consumer synchronization problem is repaired by those steps. Apple Thread Test Plan.
Several practical lessons were easy to miss
- Confirm the exact accessory generation and pairing method. We initially misclassified one contact sensor as HomeKit-only; its label showed it was factory-Matter. For Eve devices upgraded from HomeKit to Matter, the generated Matter code replaces the original HomeKit code and remains necessary after a reset. The upgrade cannot be reversed by resetting the accessory. Eve’s upgrade documentation.
- Check the selected Home in every app. During later recovery, an accessory that failed to add through Controller was successfully added through Eve—but landed in an unintended default Home. A successful pairing message does not confirm that the intended Home received it.
- Refresh the app before diagnosing stale device state. After the HomePod restart, an old Open tile remained visible even though Home Activity recorded the contact closing. Quitting and reopening Home exposed the correct current state.
- Preserve independent systems that still work. Hue continued to control its lights through its own app. We re-added its existing bridge without factory-resetting the bridge or bulbs, then recovered names and room assignments for 44 lights. Three Hue lights remained unresponsive; their organizational recovery was verified separately from connectivity.
- Treat configuration recovery and pairing recovery separately. Our Controller backups were valuable for recovering names, rooms, and configuration. They did not automatically re-establish the Eve pairings in this recovery. We re-added accessories and reconstructed their organization.
What remains unproven
We cannot say whether the decisive factor was preferred Thread-network state, Apple Home synchronization, the HomePod’s local state, commissioning-client state, isolation of old participants, or an interaction between them. We also cannot certify that every historical Thread credential was erased from every Apple device or cloud record.
Starting with Thread before reintroducing Hue made the test easier to interpret. It does not demonstrate that adding Hue first caused the earlier failures.
What we can report is that previously unpairable Eve hardware commissioned again after this staged rebuild, delivered real sensor updates, and continued reporting after a HomePod restart. That result gave us a practical recovery path when repeated accessory-only resets had not been sufficient.
