Update on my script to monitor the wifi connection --
I printed for about 7 hours yesterday and did not have any disconnects. The script to reset the interface never needed to execute. I'm uncertain if I just did not experience the intermittent failure or if the first part of the script that pings my router every 5 minutes is keeping the connection alive.
More testing will be needed to determine if the problem still occurs and if so, will the interface reset recover the connection. I've got success and failure logs being written from the script, so I'll be able to determine if it happens again. Stay tuned...
well, after many days of my newest pi4 being online with no issues I went to connect to it today and it's disconnected from the network.
In my case now, the pi is still showing an ip address assigned, and it is able to ping the router, but another client on the same network cannot ping the pi.
For what it's worth. I'm having the same issues. The Pi can stay up for several days and then seems to inconsistently lose WiFi during a print job. The good news is that the print job is unaffected and completes normally (including one that ran for 42 hours after I lost comms).
I checked the router and the Pi is registered ok to DHCP, but will not respond to a Ping. I tried changing routers and that hasn't seemed to have made any difference in behaviour. Only a power cycle reset restores the comms.
The reset of the network devices are running properly, including two WEMO switches that I use to control the Pi and the printer.
My Octopi has now been up 5 days since I put in my script to monitor for a failed network connection. During that time, I have 37 hours of printing. No network failures have occurred.
I suspect that the cron job that pings my router every 5 minutes is keeping the network connection alive. Although I don't know why the failure was happening, I'm going to call this problem done (for now). I seem to have an effective workaround in place.
If anyone is interested. Here is my script and the crontab setup. This isn't all original work, I borrowed pieces from a lot of other's work I found on Raspberry and Linux forums.
Script - I called it netcheck.sh
#!/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
echo "$NOW - Run Check" >> $LOG_PATH
/bin/ping -c 2 -I $IFACE $PINGIP > /dev/null 2> /dev/null
if [ $? != 0 ] ; then
echo "$NOW Network is down - RESET" >> $LOG_PATH
ip link set dev $IFACE down
sleep 5
ip link set dev $IFACE up
fi
I've also been (and probably still am) struggling with this issue. Same symptoms as most of you have described.
I am currently experimenting with the the octoprint settings "Serial Connections -> Intervals & timeouts": Have anyone else tinkered with this as a potential fix to this problem?
I have generally increased all timeouts in one go, and so far it looks promising (although too ealy to celebrate anything). I just wanted to throw it out there in case the idea makes sense to any of you. I'll update again here once it fails, or in a week or so if it's stable.
Here's a cope of my settings (sorry for the messy copy):
Query intervals
Temperature interval (polling)
5s When printing or idle
2s When idle and a target temperature is set
Temperature interval (autoreport)
2s Autoreport interval to request from firmware
SD status interval (polling)
1s When printing from the printer's SD
SD status interval (autoreport)
1s Autoreport interval to request from firmware
Timeouts
Communication timeout
120s busy protocol support not detected
10s busy protocol support detected
Connection timeout
60s
Autodetection timeout
30s First handshake attempt
3s Consecutive handshake attempts
Position query timeout
10s
Advanced options
Initial baudrate detection pause
1s
Some controllers need a bit of a breather before baudrate detection after initial connect. If baudrate detection fails due to a hanging controller, try increasing this value.
Max. consecutive timeouts while idle
0 Set to 0 to disable consecutive timeout detection and handling.
Max. consecutive timeouts while printing
0 Set to 0 to disable consecutive timeout detection and handling.
Max. consecutive timeouts during long running commands
0 Set to 0 to disable consecutive timeout detection and handling.
Sounds like you are confusing two things - you are looking at the serial connection settings (this is for connection to your printer), this thread is about Wifi connection dropping.
If you have WiFi issues, feel free to stay but I think it is unlikely adjusting serial settings will make a difference.
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.
