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 .....
1 Like
I'm also quite certain that this is NOT an OctoPi problem. I have been using a 3B+ for USB-Over-IP and experience the same network loss. The Pi do not respond to ping and needs reboot, occationally multiple times to get WiFi/LAN up and running. One odd thing I noticed when using OctoPrint on the 3B+: When loosing connection on octopi.local, I still can reach it full featured thru octoeverywhere.com. This suggests to me that it is not the physical WiFi/LAN that is down but something else deeper down in the OS and somehow octoeverywhere bypasses the problem.
There are also various automatic WiFi/LAN restart solutions available online...
Yes I don't think anyone thinks it is the octoprint software per sa, just that it happens on octopi's running pios.
I think it is hard to say exactly what the issue is, there could be multiple issues or one issue with multiple symptoms. For instance (for me) sometimes it loses wifi but it comes back (using the corn restart script), other times the actual wifi driver crashes, and the only way to get it back is to remove and rebuild wlan0 (quicker to reboot), but a wired in LAN never fails, and that is how I get into a failed box.
But if you look at the error messages often these issues are from years ago and were fixed. So it is quite hard to track.
But there was a wps_supplicant package update last week, and since then the wifi has not crashed, but that could just be a coincidence.
New plugin adopted into the plugin repo just now that has a similar approach as the script file.
1 Like
Nice solution -- very similar to my script. I'll keep an eye on this one to see how it works out. Nice to have it integrated in the Octoprint plugin library and logging utilities.
There's been reports that it might not actually work due to permission errors, so you might want to hold off testing until after this issue is resolved.
Yep, quite a few updates released in the past two hours. Since my script is working well for me, I don't plan on moving over to the plugin anytime soon. Just going to keep an eye on it to see how it performs in the long run and across many Octoprint deployments.
Permissions are something that are critical here. Most of the commands must be run as root or with sudo privileges.
Yeah, the plugin page just got updated with instructions for setting sudoers for the ip command.
Should work now provided the instructions are followed. Kind of wish the name was a bit more specific to the Pi/OctoPi tho.
I don't know if this adds anything to the debate, but i have this issue on a 3B+ and a reboot of the Pi always solves it. What I can add is that I also run OctoDash with a touch screen, and when I lose network connectivity to the Pi, OctoDash also loses (temporarily) connection to OctoPrint - usually I get a popup saying that "layer progress cannot be retrieved", but occasionally I get other 502 (gateway) errors. Clicking on that error on the touchscreen clears it, and OctoDash displays progress correctly again. Prints always complete perfectly.
This leads me to think it's something to do with an interplay between the OctoPrint web server, and the PiOS network interface, and Egar's script resetting the network interface "brute forces" the error. I haven't had any time to investigate yet, though.
Depending on how you have configured OctoDash, it may still trying to reach out to your network to resolve the IP address, so this will still fail if the Pi disconnects from the network. What URL do you have configured in OctoDash? Try using localhost:5000 or 127.0.0.1:5000, which should work without needing to contact your network.
Yeah, it's IP-independent - localhost:80. My Pi is on DHCP so although it usually ends up on the same IP address, that's not guaranteed.
[edited to say] - I was wrong, it wasn't localhost - it was octopi.local, which does indeed call out to the network. Changed to loopback on 127.0.0.1 it is now working properly.
There is a couple of different issue with similar symptoms floating about, which confuses things. In my case I usually find the WiFi network stack is completely corrupted (dish via plugin in a cable) and only a reboot brings things back, others have found that removing and reinserting the kernel modules bring it back but I had no luck with that. Sometimes it goes months without doing it other times it will do it multiple times in a day. Makes diagnosis and fixing difficult.
So, I tried the Network Health plugin, and had some new problems with the print - I was watching the bed at the time the network went down: Pi stopped responding to pings, and my Octodash threw a http "layer progress" error - but unusually, the print also halted briefly for a second or two, then carried on. Thereafter the print frequently (but with no specific pattern) halted, and the error seen in Octodash couldn't be cleared. The print finished successfully (with a few scars and blobs from the points where it halted briefly).
Looking at the octoprint logs, I can see that nothing at all was logged during the time from where the network went down to when I rebooted - and I do mean nothing at all. There's a half-hour gap in the logs.
I've since removed the Network Health plugin and added Egar's script, and will monitor to see if anything like this happens again.
Sorry for spamming - more information. After I posted the last reply, the Pi network went down again - Egar's script logged that it had reset the interface however it didn't come back up on the network. I forced a shutdown from Octodash, and I could see during the shutdown process linux hung on stopping the dhcpd process for about a minute, which it doesn't do when shut down under normal circumstances. So it looks like it's a dhcp issue to me.
Instead of taking wlan up and down (as in Egar's script) - I think this might be more reliable - testing it now.
`sudo wpa_cli -i wlan0 reconfigure`Most clearly a DHCP issue. Since I additionally set my PI to a static IP besides having the DHCP giving it the same IP, I never had a dropout again. Also switched from 2.4 to 5Ghz, which seems more stable.
sudo wpa_cli -i wlan0 reconfigure didn't work - logs show the network went down, but didn't recover with this command.
Configure a static IP in your /etc/dhcpcd.conf file, as documented here and you should be good to go:
Yeah, I was trying to avoid that because I wanted to understand the problem rather than fixing the symptoms - but I did configure static first thing today and will monitor it.
I've got a number of Pis around the house, including one configured as a NAS that has been running continuously for about 2 years without a reboot...so I really wanted to understand why Octopi seems uniquely to have this issue in my fleet of Raspberries...