4.32.7 — local /v2 API resets the connection (ECONNRESET) on BD-1000, native HomeKit is fine
Posting this in case it helps other folks on 4.32.7 and to get it in front of Bond. It lines up with the other 4.32.7 HomeKit regression threads, but the failure here is specifically the local HTTP API, not native HomeKit, so I wanted to call it out separately.
Setup
- Bond Bridge BD-1000, Bond ID ZZFG26634, firmware v4.32.7
- 2.4GHz wifi, strong signal, reserved IP 192.168.68.75 (DHCP reservation on a TP-Link Deco mesh, Device Isolation off, single flat subnet, no VLANs)
- AT&T gateway with its wifi disabled, wired into the Deco, which runs DHCP
- 3 devices on the Bond: one 6-speed ceiling fan and two Somfy RTS shades
- Shades reach Apple Home through Bond’s native HomeKit. The fan reaches Home through Homebridge (homebridge-bond v3.3.0), since native HomeKit doesn’t carry the fan on my setup
- Homebridge host is a Mac on the same subnet, also reserved (192.168.68.54)
What changed Everything worked reliably for a long time. Right after I updated to 4.32.7 yesterday, two things broke at the same moment:
- The ceiling fan lost its speed range. It now only really does low and full (roughly 33% and 100%), the middle speeds are gone. This seems to match the “6 speeds became 3” report in the other 4.32.7 thread.
- The Bond started intermittently dropping off entirely, taking the fan with it.
The actual failure homebridge-bond keeps logging this:
read ECONNRESET ... GET http://192.168.68.75/v2/devices
No valid Bonds available.
I confirmed it has nothing to do with Homebridge by hitting the local API directly from the Mac:
curl http://192.168.68.75/v2/devices -H "BOND-Token: <redacted>"
curl: (56) Recv failure: Connection reset by peer
So the Bond accepts the TCP connection and then resets it mid-request. Thats the key detail. This isn’t a timeout and isn’t the network dropping packets. The hub is reachable, the local API just kills the request partway through.
What I’ve already ruled out (to save us a round trip)
- IP drift: the Bond has a DHCP reservation at .75, confirmed in the router. The address never changes.
- Network isolation / VLAN: none. Device Isolation is off, flat subnet, and the Homebridge host is reserved on the same subnet.
- Reachability / mDNS: Bond app local control works perfectly and native HomeKit shades work, so the bridge itself is reachable on the network.
- Homebridge: cache cleared, no duplicate accessories, plugin healthy. The failure is the API not answering, not anything on the Homebridge side.
- Auth: correct local token. The call actually succeeds for a second right after a cold reboot, then starts resetting again once normal polling resumes.
A hard power-cycle of the Bond temporarily fixes everything (shades get their % back, all devices come online), but the /v2 resets return once Homebridge picks polling back up. So it’s stable when idle and falls over under load, which is what makes me think this is the local API and not the radio or the network.
Questions
- Is there a known regression in 4.32.7 affecting local /v2 API stability under repeated polling on the BD-1000?
- Is firmware rollback possible while this gets sorted?
- Is a corrective firmware already in progress?
Happy to pull more logs or a packet capture if that helps.