How do we reach out to developers about this matter? I think it’s beyond our scope. I doubt it’s something we can do.
Likely network component or Raspian OS (based on Debian Linux).
Where can we raise a ticket?
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
Crontab entry
*/5 * * * * /home/pi/scripts/netcheck.sh > /dev/null 2>&1
Hi all,
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.
Wow I definitely add this to my cron job! Will continually use it till the fix comes in then I’ll remove it.
Egar , you’re amazing
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.
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
1 Like
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.
1 Like
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)
https://www.raspberrypi.org/forums/viewtopic.php?t=188891
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.