WiFi connection lost every ~2 minutes immediately after updating to 2.2.1(5)

[mmmm]

Hello,

I have an OpenSprinkler v3.x controller that became unable to hold a WiFi
connection immediately after the firmware update to 2.2.1(5). I would like to
ask whether this is a known regression, and whether an older build is available.

TIMELINE

13 Aug 2026, 05:08:40 controller rebooted, reboot cause “firmware update”
13 Aug 2026, 05:14:23 first WiFi disconnect

That is 5 minutes 43 seconds after the update. In the 8 days before the update
there was not a single disconnect. In the ~30 hours after it, there were 37.
The controller has been reassociating roughly every 1-2 minutes ever since.

MEASUREMENTS (taken from the access point, not from the controller)

Signal -75 to -77 dBm, noise floor -96 dBm
TX retry rate 63% (137 of 218 frames), later 49% after I changed channels
Reassociation every 60-120 seconds, continuously
Negotiated rate pinned at the minimum allowed by the SSID

THE PART I CANNOT EXPLAIN

The controller sits about 1 metre from a WiFi 6/7 access point (Ubiquiti U7),
and roughly two rooms away from an older WiFi 5 access point. It connects only
to the distant WiFi 5 unit, at -76 dBm, and never to the one 1 metre away.

When I configured the network so that the nearby access point was the only one
it was allowed to use, the controller did not connect to it at all – it stayed
completely offline for the full 6 minutes of the test, then recovered as soon
as the distant access point was permitted again. This is reproducible.

A cold power cycle does not change the behaviour: after a full rescan it still
selects the distant access point.

WHAT I HAVE ALREADY RULED OUT

– Co-channel interference: the nearby AP was moved to a different channel.
Retries improved from 63% to 49%, but the disconnections continued unchanged.
– Solenoid / valve current: 0 of the 37 disconnects occurred while a station
was running (watering accounts for 3.8% of the time, so chance alone would
predict more).
– Controller reboots: only one power_on reboot in the whole period; the
disconnects are not accompanied by restarts.
– Access point moves or reconfiguration: the AP layout was unchanged for two
days before the update, with zero disconnects during that time.

QUESTIONS

1. Is a WiFi regression known in 2.2.1(5)? I noticed the release notes mention
updates to the OpenThings Framework and TinyWebsockets libraries.
2. Could the new build have changed how the ESP8266 scans or selects an access
point, or how it behaves with 802.11ax/be beacons? The AP it refuses is the
only one here advertising WiFi 6/7.
3. Is os_221_rev4.bin available anywhere? https://raysfiles.com/os_compiled_firmware/v3.x/
only hosts os_221_rev5.bin, so I cannot roll back to test whether the
previous build works.

Controller: OpenSprinkler v3.x, firmware 2.2.1(5), hardware unchanged.
I am happy to run any diagnostics or provide logs.

Thank you

[Ray]

1. No, this is not a known issue. Firmware 2.2.1(5) did not touch anything about WiFi or wired Ethernet connection. The release notes about OpenThingsFramework and TinyWebsockets are for OpenSprinkler Pi / Linux, they are unrelated to OpenSprinkler v3.x.

2. No, as I said, 2.2.1(5) made no change to WiFi functions.

3. All previous firmwares are in the archived subfolder. Please check that subfolder.

[RfxiEmil]

That behaviour does sound odd, especially with the timing lining up so closely with the update. The fact that it consistently ignores the nearby AP and reconnects to the older one makes me think something changed in the WiFi scan or association code rather than it being a normal signal issue.
I’d be interested in seeing whether anyone else with a U7 or other WiFi 6/7 AP has seen the same thing on 2.2.1(5). Rolling back to rev4 would be a pretty useful test too if the file is still available somewhere.

[mmmm]

Resolved — and it was not the firmware. My apologies for the misdiagnosis.

Short version: the 2.2.1(5) update was the trigger, not the cause. The reboot that comes with flashing forced the ESP8266 to re-select an access point, and it picked one that was below my controller’s usable signal. Ray was right that nothing in that release touches WiFi.

What actually happened

Two days before the update I physically moved one of my access points. The ESP8266 does not roam on its own, so it happily stayed on its old AP and nothing looked wrong. The firmware reboot made it choose again — and this time it landed on a distant AP at -81 dBm (Unusable), which is exactly the “connection lost every couple of minutes” symptom.

So the timing was real, the causation was not.

The part that cost me the most time

Earlier I had tried to pin the controller to the nearer AP and it would not associate at all. I blamed the antenna and the location. The real reason was the AP’s own minimum RSSI threshold: during association the signal is weaker than in steady operation, so the threshold rejected a client that afterwards runs happily at -48 dBm.

If you are chasing the same symptom, check that first. A client that “refuses to connect to a specific AP” is often being refused by that AP.

What fixed it, in this order

Disable minimum-RSSI on the target AP (it was the one doing the rejecting).
Remove the SSID from the source AP so the client is forced into a real scan.
Once it has moved, put both settings back — the ESP is sticky and stays put.
Result: -81 dBm to -48 dBm, and eight days of uninterrupted uptime since.

One tip that helped

The controller’s own System Diagnostics page (hamburger → Advanced) reports RSSI as the controller sees it, plus Last Reboot and Reboot Reason. Your AP only tells you one side of the link. Comparing both numbers is what isolates a genuinely weak receiver from a policy problem — a 3 dB difference is healthy; on another device here a 24 dB gap turned out to be a failing radio.

Sorry again for pointing at the release notes. A version number that lines up with a symptom is a coincidence until something explains the mechanism, and I posted before I had one.

[Author]

Posts