Thank you to everyone for providing helpful suggestions.
After further investigation, it appears that 13.1 may not be the cause of the problem. A device with 13.1 was able to connect to something other than my Wi-Fi Access Point. It appears that a recent update to the AP’s firmware may be the culprit.
What exactly prevents the Tasmotized devices to connect and remain connected to the AP, whereas other Wi-Fi devices have no problem, remains a mystery.
Two days ago I upgraded five identical switches from version 12.2 to 13.1.
All five upgraded without a problem and continued to work normally.
Today I restarted my Wi-Fi access point.
None of the five switches are able to connect to Wi-Fi.
Other devices using the same 2.4Ghz Wi-Fi network are successfully connected.
Only two of the five devices are acting as hotspots (i.e. they appear in my phone’s list of available Wi-Fi networks).
I logged into both, selected my Wi-Fi network from the list of available networks, supplied the correct password and the device tried but failed to connect (i.e. behaving like the password is incorrect). I repeated this process several times with no success.
The other three devices don’t appear in the network list and I have no idea why not because all five are configured exactly the same way. They’re all programmed to turn on their connected load at startup so at least the appliances connected to them continue to work.
These five switches were flashed OTA using Tuya Convert many, many versions ago. This is the first upgrade that has caused them to misbehave. They’re wall-plugs with sealed cases (no screws); attempting to flash them serially would require destroying their case.
Screenshot of one of the devices showing it’s been unavailable since I restarted the Wi-Fi access point 6 hours ago.
I would love to reflash the switches to ESPHome. They are all Athom 1, 2, 3-gang Switches preflashed with Tasmota. Unfortunately I see no headers/pins for serial flashing on the boards
Did you try the infamous fast power cycle device recovery that tend to reset tasmota devices in the past occasionally by themselves?
Fast Power Cycle Device Recovery
Implemented for situations where a device cannot be reset to firmware defaults by other means (no serial access, no button). It resets ALL Tasmota settings (equal to Reset 1) after 7 power cycles.
SetOption65 must be set to 0(default) in order for this feature to be enabled.
The thought of switching to ESPhome crossed my mind, but these switches have been working well with Tasmota for several versions so I never did (when it would have been easy via OTA).
Now that they’re in this state, opening their ‘welded’ plastic case to access the pins would be a destructive process. Even if the flashing process was a success, the end-result would be physically unsafe, unusable device.
Thanks for that. I started reviewing recovery options late last night and I haven’t tried that one yet. I’ll report my results later today.
FWIW, last night I picked a device that wasn’t acting as an AP and tried the procedure where you depress the button for 40 seconds and then release it. That caused it to revert to some sort of recovery state and announce its default SSID (as opposed to the one I had configured). It felt like progress.
I logged in, selected my local network, supplied my password and … that’s the last I ever heard from that device. It’s not connected to my network, doesn’t start in AP mode, and its button appears to be unresponsive. Not sure if it’s bricked now.
I just tried the ’ Fast Power Cycle Device Recovery’ procedure on the device that I thought I had bricked (described above) and it started up in AP mode using its default SSID.
Bad news
It refuses to connect to my Wi-Fi network; that part remains unchanged. Nevertheless, at least it’s not bricked.
After some googling it appears that this problem (unable to connect to Wi-Fi) has also been reported by others for previous versions of Tasmota (so it’s not unique to 13.1). The discussions often gravitate to the configuration of the AP; changing some of the AP’s parameters allowed the Tasmotized device to connect.
The reason I bring that up is because I have a modem/router/AP supplied by my Internet Service Provider and I suspect it received a firmware update late yesterday morning. Whenever they tinker with the device, it always loses the configuration settings I selected. That happened yesterday and I had to factory-reset it then manually reconfigure it (I have never had success restoring from backup for this device).
To be clear, there’s not much you can change to influence its Wi-Fi behavior. I configure it to have separate SSIDs for 2.4GHz and 5GHz bands and, aside from setting the channel, there’s nothing else available for tweaking it.
Speculation: Perhaps the AP’s firmware update introduced some new behavior (that I have no control over) that affects my Tasmotized devices but not other gadgets I have that use the same 2.4GHz network (like Sonos speakers, a Wemo switch, several Ecobee Smart+ switches, etc).
As an experiment, I’ll try connecting the Tasmotized device to another AP, either an old one I have or at a family member’s home.
As nice as this testing is, you should really think about changing to ESPHome now, when you have access to the device… Just saying!
I don’t own a Tasmota device, but I’m not unfamiliar with Wifi APs and unasked manufacturer updates. Have you tried switching the Wifi channel(s)? With FritzBox and its APs this is a known problem, maybe it applies here as well?
Yes, I switched it from its default, Auto, to channel 2. Neither choice helped the Tasmotized device to connect. It offers nothing else to tweak. If my “alternate AP experiment” proves to be successful, I’ll be replacing the ISP’s modem.
In the last month I “lost” 24+ Tasmota flashed devices. For some reason one day they would not connect anymore, though they had been working fine for 18 months.
Some were totally unreachable, some I could get to the AP and I reflashed with ESPhome.
I am still in the process of attempting to get them all back to normal.
The most difficult ones “Treatlife Fan/Light Switch” because I have to go throght the cloudcutter to get them working again. So far I am 0 for 4. Though they work, no go with cloudcutter.
Nothing is wrong with FritzBoxes, I do own a few and use them without problems. What I was reffering to, is the default setting in the FritzBox, where you (or better AVM) installs updates to connected FritzBox APs (these devices you put in the socket to extend your Wifi range). When you run an update to a new firmware for the FB, the APs will get automatically updated and that is known to cause problems with channels.
Everything is fine with FritzBoxes! Back to topic.
If you can gain access to the device and are able to flash a firmware via web ui it might be worth a try to do that. Not sure if you can flash a tasmota (maybe back to v12 as that worked for you at the time) and at the same time do a factory reset of the user configurable data - if that’s possible. Just to be sure to don’t have any old config messing things up and try with a fresh/default device instead.
The other way would be to directly install esphome on it (can upload the bin in the tasmota web ui) - just make sure you have all the saftey nets like the safe mode, ap mode, etc. and give yourself the treat (as your devices have buttons) to set up a Safe Mode Button — ESPHome which will be triggered when you keep a hardware button pressed for minimum x seconds
I moved all my devices over to esphome years ago as this was (or is?) the only for reproducible and solid device configuration that don’t get Alzheimer or loose configurations and such.
After reading a few issues from the Tasmota repo, and some I found via Google, it seems to be some kind of understanding, that a “feature rich grown” Tasmota might not leave enough power for the ESP8266 to run properly? I can’t believe that, but it seems, some people do have success by using the “lite” image from Tasmota.
That being said, I’d really suggest flashing ESPHome onto them. That should at least lower your losses.
I will look into this.
Just saying! 
Back to topic. 
