If anyone is interested in testing an OctoPi nightly build - which you can find here, you can try the new 'connection monitor' feature
A setting in the octopi.txt file will enable a regular ping to the specified host very similar to @egar's script.
Thanks for the link to the pull request. I just got things stable (at least I think so), so I may not go for a nightly build yet. I'll keep an eye on it and may test it soon-ish.
At least several people seem to be on the same track to eliminate the issue. That's a good sign that this is a viable solution.
Thanks to your script, my octopi is now almost always accesible. Although i see 14 Network Restarts from 22.3. till today - and i dints print/have it online 24/7...
So i hope there will be a real fix sometimes.
Also i dont see a repeating chema in the intervalls between Network-restarts - one Restart came right 10 Minutes after another - and then i have several hourse without interruption...
I'm glad to hear this is helping you. Though I've been running it for more than a week now, I've yet to have the script do a reset. Since I put it in place, I've not had any disconnects -- so no resets. I wasn't even sure it would work. Thanks for being the tester. 
After more than a week with no network failures, I've had 6 failures this afternoon. In all 6, the script I posted above detected the failure and reset the connection. This restored may access to the Octopi and Octoprint GUI. The print job running was unaffected and continued as if nothing happened.
Now, as they say, I've gotten to "eat my own dog food". I'm glad the script is working. I may even consider running it more frequently, just so I don't have to wait as long for the connection to be restored.
Now that I have data from actual resets, I have updated my script to make it log more cleanly. I realized that when a reset was done, there were two log entries made. The new version, below, will log either OK for a good connection or RESET when the connection is reestablished.
#!/bin/bash
# Set variables
NOW=$(date +"%m-%d-%y %r")
IFACE='wlan0'
PINGIP='192.168.50.1'
LOG_PATH="/var/log/network.log"
# Ping remote IP and reset interface if needed
/bin/ping -c 2 -I $IFACE $PINGIP > /dev/null 2> /dev/null
if [ $? = 0 ] ; then
echo "$NOW - OK" >> $LOG_PATH
else
echo "$NOW - RESET" >> $LOG_PATH
ip link set dev $IFACE down
sleep 5
ip link set dev $IFACE up
fi
By nightbuild, does that mean every night there is a new version? Is the current nightbuild stable? I recall that last year I tried a nightbuild and everything got messed up. I ended up reinstalling to the stable build.
Exactly that. Every night, there is a new build pushed. However, these are untested and contain the latest changes to the codebase. You will never know if there is in-progress work, something was changed that shouldn't, or new features that conflict with others. They're development builds used for testing.
I finally solved this on my network after struggling with it for months - note, YMMV - I have two wireless mesh networks in my house, connected to each other, with printers on both networks, so not completely clear to me exactly what combination of problems was causing my printers to periodically lose their network connections. The other symptom I had was that my video feeds would periodically drop out. Neither symptom could be solved by anything except restarting Octopi.
In my Netgear Nighthawk settings, I turned off the Access Control option.
Weird I have started getting this now as well. I have a mesh network but the same one I have had for 5 years, and the printer hasn't moved, the only change was an upgrade from 0.17 to 0.18 Octopi and swapping from a pi3b+ to a pi4, and even then pi4 with 0.18 ran without issue for several weeks. Now I get the losing wifi a couple of times a day.
I have also updated everything O/S related, turned off wlan sleep, and put the above script in place. Although sometimes the wifi module seems to crash completely (I have a long ethernet cable I can plugin when it doesn't come back). And as others have said it keeps printing happily.
Will have a more indepth look when I get 5 mins, and if I can find a spare SD card try a nightly build.
For what its worth, I've had not a single lost connection sind I changed my router's settings.
So I would assume, that this is indeed related to crouded network channels.
There are several parallel forum topics going on this same issue. A commonality that I think I see across all is that people experiencing this issue are on mesh wifi networks. Perhaps the hand-off from one node of the the mesh to another is something that the Pi cannot handle gracefully.
If this is the case, I'm going to stick with my reset script that seems to be working reliably for me. I would rather have that fix my network disconnects than to turn off the mesh network and affect all of the devices that I have that roam between floors within my house.
I dont think this is related to Octoprint or Octopi in any way. There is a lot of similar discussions around the net on Raspberry Pi 3 and 4 models that experience the same issues. Wifi dropping out, but ethernet continues to work.
And its not exactly a new issue either. Check out the discussion from 2018 by a Rasberry Pi Engineer (Love that title btw)
And later on in 2020 it is still a problem
https://www.raspberrypi.org/forums/viewtopic.php?t=278393
So I think we are trying to sort out what is really a PI problem, and not an Octoprint/OctoPi issue.
But oddly I ran octopi 0.17 with the same network, in the same physical location for over a year with no issues (I have used Mesh for many years with the same hardware, first manufactured used there own fudged version of the protocol before updating to the certified mesh protocol), was only issue after going to 0.18, something must have changed in the PiOS or some slight different in Pi4 hardware vs Pi3b+.
Yes, agreed turning off mesh isn't really an option as that messes up everything else.
Yes definitely a PiOS issue (but doesnt mean someone here might not work out the answer), but if you cant connect to octopi that is a quite fundamental issue.
And it must be quite recent as my other Pi running Plex has no issue at all.
I dont see this being related to Mesh. I am seeing this across all 3 of my OctoPi machine, and one running Mainsail. 1 of the Octopi is a 3B+ and the others are Pi4 with 8GB. All are connected on 2.4GHz on my unifi access points. And all are seeing the issue. Also the one running Mainsail, instead of Octoprint.
Interesting. It could of course be there are a couple of issue with similar symptoms and different fixes.
I was very confused when it first happened as all i had done was moved my spool holder!
Hahaha ... yeah it could definitely be several different issues. Its a tall tech stack we are looking down into here. And I don't think the Spool Holder is involved. At least I haven't moved mine. 
I am moving my printers to another room, where I can setup a switch to get them all on ethernet to work around this.
Seems sensible.
One of my printers is hardwired, and obviously that has no issue. Or maybe its because I havent moved the spool holder for that one .....
