The below is a write up of the actions I took via Claude - So before you come at with "This is an AI post - Yes it is. I asked Claude to write up a summary of what worked. My Switch is back in my HomeKit So I don't give a crap if it's done by AI or not.

Reading a HomeKit-capable Wemo after a factory reset, without the Wemo app

So my 4 year old son thought he was helping during a Wifi outage and accidentally factory reset one of my wemos. I had them all running thru Apple Homekit so they all have been working fine since the shutdown. 

I was able to get it back up and running via Claude and pyWemo. And I was able to re-add to Homekit, which I have seen a few people say was not possible. 

This writeup is the procedure that ended up working. It uses pywemo for the WiFi part and two extra UPnP calls for the HomeKit part. Should apply to any HomeKit-capable Wemo (Light Switch v2 / WLS040 / LS2G, Mini, Insight, Dimmer, etc.).

The gotcha that cost me an hour: pywemo's setup() puts the device back on WiFi just fine, but it never tells the device to start advertising HomeKit again. So the plug joins your network, you can ping it, pywemo can see it, and the Home app still spins forever because nothing is broadcasting on _hap._tcp. The two extra UPnP calls below fix that.

TL;DR

1. Provision WiFi with pywemo while connected to the device's WeMo.* setup AP.
2. Once it's on your home WiFi, call basicevent.removeHomekitData() and basicevent.setHKSetupState(HKSetupDone='0') on it. This is the missing step.
3. Pair in the Home app with the 8-digit code printed on the device.

Once you've done it once, the whole thing is maybe 2 minutes.

What you need

• A Mac or Linux box on the same LAN where the Wemo will live
• Python 3
• dns-sd (built into macOS) or avahi-browse (Linux) to verify mDNS
• The 8-digit HomeKit setup code from the device's label

Set up pywemo in a venv:

mkdir -p ~/wemo-setup && cd ~/wemo-setup
python3 -m venv venv
./venv/bin/pip install --upgrade pip
./venv/bin/pip install pywemo

Procedure

0. Factory-reset the device

Hold the reset button until the LED enters setup mode. The device will broadcast an open WiFi network named something like WeMo.<model>.<macsuffix>.

1. Get it back on your home WiFi

Save this as ~/wemo-setup/setup_wemo.py:

#!/usr/bin/env python3
import getpass, sys, time
import pywemo

def find_device(attempts=6, delay=2.0):
    for i in range(1, attempts + 1):
        print(f"[{i}/{attempts}] Discovering Wemo...", flush=True)
        devices = pywemo.discover_devices()
        if devices:
            return devices[0]
        time.sleep(delay)
    return None

def main():
    print("Make sure your computer's WiFi is connected to the 'WeMo.*' AP first.\n")
    d = find_device()
    if not d:
        print("No Wemo found. Check you're on the WeMo.* SSID and the LED is blinking.")
        return 1
    print(f"Found: {d.name}  model={d.model_name}  mac={d.mac}")
    ssid = input("Home WiFi SSID: ").strip()
    password = getpass.getpass("Home WiFi password (hidden): ")
    try:
        result = d.setup(ssid=ssid, password=password)
        print("setup result:", result)
    except Exception as e:
        print("setup() raised:", e)
    return 0

if __name__ == "__main__":
    sys.exit(main())

Then:

1. On your computer's WiFi menu, join the WeMo.* network. It's open, no password. You'll lose internet on that machine, that's fine.
2. Run ~/wemo-setup/venv/bin/python ~/wemo-setup/setup_wemo.py.
3. Type in your home SSID and password when prompted.
4. At the end you'll probably see:setup() raised: pywemo lost device ... Setup status is uncertain That looks like a failure but it isn't. What happens is the plug accepts your credentials, immediately drops the setup AP, and starts joining your home WiFi. From pywemo's point of view the device just disappeared, so it gives up. The device itself is doing the right thing.
5. Reconnect your computer to your home WiFi.

2. Confirm the plug joined

~/wemo-setup/venv/bin/python -c "
import pywemo
for d in pywemo.discover_devices():
    print(d.name, d.host, d.serial_number)
"

The freshly-set-up device shows up with the generic name Wemo Light Switch (vs. whatever your other ones are named).

3. Check that HomeKit advertising is missing

macOS:

dns-sd -B _hap._tcp local

Linux:

avahi-browse -r _hap._tcp

The new device won't be in the list, even though it's on your network. That's the problem the Home app is hitting.

If you don't have the HomeKit setup code (label peeled off, wrong sticker, device was second-hand, etc.) you can pull it straight off the device. See the "Getting the HomeKit code" section below.

4. The actual fix

~/wemo-setup/venv/bin/python <<'PY'
import pywemo
# replace with your device's serial, or just pywemo.discover_devices()[0] if it's the only one
d = [x for x in pywemo.discover_devices() if x.serial_number == 'YOUR_SERIAL'][0]
be = d.services['basicevent']

print(be.removeHomekitData())                  # wipe stale HK pairing state
print(be.setHKSetupState(HKSetupDone='0'))     # mark unpaired, so it advertises
print('after:', be.getHKSetupState(), be.GetHKSetupInfo())
PY

Within about 5 seconds the device starts advertising on _hap._tcp. No reboot needed.

Verify:

dns-sd -B _hap._tcp local                       # new entry appears
dns-sd -L "Wemo LS2G XXX" _hap._tcp local       # TXT record should include sf=1

sf=1 means unpaired and available for pairing. Already-paired Wemos show sf=0.

5. Pair in the Home app

1. Long-press the old non-responsive tile, hit Remove Accessory. That clears the stale pairing record on the controller side.
2. Add Accessory, scan the QR or pick the device by name, enter the 8-digit code.
3. Put it back in the right room, rename it.

Done.

Getting the HomeKit code

Normally it's printed on the device — usually a small sticker on the side or back with the 8-digit number (formatted like XXX-XX-XXX) and sometimes a QR code. On in-wall switches it can be on the side of the body, so you might have to pull the wall plate off to see it.

If the label is gone or unreadable, the device itself will tell you. It's stored in firmware and exposed over UPnP, so once the plug is on your home network you can just ask:

Via curl (UPnP port varies, loop through the candidates):

for p in 49152 49153 49154; do
  curl -s -o /dev/null -w "$p %{http_code}\n" http://<plug-ip>:$p/setup.xml
done
# whichever port returned 200:
curl -s http://<plug-ip>:<port>/setup.xml | grep -E 'hkSetupCode|hwVersion'

Or via pywemo, which also gives you the X-HM://... payload (the same thing a HomeKit QR code decodes to, in case you want to regenerate one):

~/wemo-setup/venv/bin/python <<'PY'
import pywemo
d = pywemo.discover_devices()[0]   # or filter by serial / name
print(d.services['basicevent'].GetHKSetupInfo())
PY

You'll get something like:

{'HKSetupKey': 'X-HM://008XXXXXXXXXX', 'HKSetupCode': 'XXX-XX-XXX'}

HKSetupCode is the 8-digit number to type into the Home app. HKSetupKey is the URL a printed QR code would encode if you want to make a fresh sticker.

Note: this works because the code is baked into each device individually at the factory. There's no master code, no "default" for the model, and Belkin's servers aren't involved. So even with the Wemo cloud dead, the code is still recoverable as long as the device boots and answers UPnP.

Stuff that doesn't work, that I tried first

A few dead ends so you don't go down them:

• Setting HKSetupDone='1' (and/or SetSetupDoneStatus(SetupDone='1')) suppresses the HAP advertising instead of starting it. You want 0.
• Power-cycling without changing the flags doesn't do anything. The flag state persists across reboots.
• SetSetupDoneStatus(SetupDone='0') gets silently ignored. The device treats SetupDone as monotonic. Only HKSetupDone is the one that controls HAP advertising.
• basicevent.Reset and basicevent.ReSetup re-enter setup mode and wipe WiFi, which undoes step 1.
• Just waiting longer won't do it either. The advertising is gated on flag state, not on time.

Why this step is even needed

The Wemo app's original onboarding flow had four parts:

1. Push WiFi credentials to the device (WiFiSetup.ConnectHomeNetwork)
2. Close the setup channel (WiFiSetup.CloseSetup)
3. Wipe any leftover HomeKit state and tell the device to advertise as pairable (basicevent.removeHomekitData + basicevent.setHKSetupState)
4. Register with Belkin's cloud (smartsetup.PairAndRegister)

pywemo does 1 and 2. Step 3 was baked into the official app and nobody really documented it, so it's the bit that's missing. Step 4 doesn't matter, the cloud's gone.

The important thing is that the HomeKit code, the setup payload, and the _hap._tcp machinery all live on the device itself. They don't need Belkin's servers to work, they just need to be told to start.

What's on the device, for the curious

If you fetch /setup.xml and the per-service descriptors from the device's UPnP port, you'll find:

• WiFiSetup (setupservice.xml) has GetApList, ConnectHomeNetwork, CloseSetup, GetNetworkStatus. pywemo's device.setup() uses these.
• basicevent (eventservice.xml) is where the HomeKit hooks live: getHKSetupState / setHKSetupState, GetHKSetupInfo (returns the code and the X-HM://... payload), HKSetupDone, removeHomekitData, GetSetupDoneStatus / SetSetupDoneStatus.
• smartsetup (smartsetup.xml) is the Belkin cloud registration stuff. Ignore it.

Notes

Confirmed working on a Wemo Light Switch v2 (firmware WeMo_WW_2.00.11563.PVT-OWRT-LIGHTV2). The basiceventHomeKit actions show up in the descriptor XML of every HomeKit-capable Wemo I checked, so it should also work on the Mini HomeKit plug, Insight, Dimmer, etc., I just haven't personally tested those.

If setup.xml on your device doesn't have an <hkSetupCode> field, the device isn't a HomeKit model and none of this helps. In that case Homebridge with homebridge-platform-wemo is the usual workaround.

The basicevent HomeKit actions aren't called out in pywemo's README, you only find them by pulling the device's own eventservice.xml.