Print working, but can't connect to http://octopi.local/

Get Help Networking
1

I just installed Octopi earlier today and did a small print and everything was fine. Now I'm a few hours into a larger print, and my printer is still printing but I can no longer access the UI at http://octopi.local/

What is the problem?
Can't connect to http://octopi.local/ (printer is still printing just fine, and my router 'sees' the octopi) still, but http://octopi.local/ times out, and trying to ssh into it also times out)

What did you already try to solve it?
I have tried reaching http://octopi.local/ with no luck (even after waiting about an hour) I tried to ssh into the octopi and it times out still.

I'm sure restarting the raspberryPi will fix it(temporarily at least), but I'm in the middle of a 16 hour print and I just wanted to see if others are also experiencing this bug?

EDIT/UPDATE
My print kept going over night and it was finished when I got up. I still couldn't connect to http://octopi.local/

I restarted my raspberryPi and now I can connect to http://octopi.local/ just fine.

I would Like a way around this bug, because I would like to be able to control my printer while it's printing.

EDIT/UPDATE (part 2)
I have since reflashed my main control board and my TFT board and I have not had this problem since.
For reference, I have an Artillery Sidewinder X1 and I upgraded to TFT_Rawr_X1 (GitHub - bigtreetech/BIGTREETECH-TouchScreenFirmware: support TFT35 V1.0/V1.1/V1.2/V2.0/V3.0, TFT28, TFT24 V1.1, TFT43, TFT50, TFT70) and Marlin 2.0.

2

does just http://octopi or http://theipofyourpi work?

3

It could be the wireless connection of the raspberry pi has stopped working, eg due to a drop in voltage because you might not be using a proper PSU. Or the raspberry pi could have gotten a new ip address from your router, and your computer still has the old IP address "cached". In the latter case, look up the ip address of your raspberry pi in your router.

4

I tried both, neither worked.

5

The router still 'sees' the raspberyPi as connected (at the same IP) and the printer is still printing, so I know the Pi is still running, and has wifi.

6

I have same issue with my Pi4 4GB.
After some time, connection is unavalaible, but print is beeing finished.

7

So can you connect to the IP of the Pi when this happens? If the router still sees it connected, then it should route the calls. If it doesn't, then this is likely an issue with your network before it hits the Pi.

It depends on what response you get from the Pi. Maybe we should start with some ping commands, such as ping octopi.local or ping <pi IP> and see if this works.

Please upload the logs - these should not be missed when opening 'get help' threads.

8

Can the wireless stop working, but everything else keep working fine? I've got my Pi connected to a 5v 2A source, does it need more?

9

Yes.

Yes. A Raspberry Pi 3 B+ officially requires 2.5A AFAIK, and it has to be stable. Phone chargers are not power supplies and may not supply a stable enough voltage. Your phone won't mind, a raspberry pi will. Also make sure the Raspberry Pi does not waste power on powering the printer motherboard by taping the 5V line of the USB cable between the Pi and the printer.

10

To add slightly to fieldofviews post, I believe the pukka Raspberry PSU is 5.1V.

11

Yes. If you don't have a stable wifi connection to begin with or not enough signal strength where the pi is located. This can definitely happen.

Are you able to check if the Pi is still connected to your wireless access point/router? Or are you able to attempt to connect to the pi using Putty?

12

Just some networking infrastructure knowledge... The ip in the list you see on the router isn't live, it's just a record of what ip the router had handed out to the device when it first connected to the network. After the expiration of the ip lease,it will disappear (unless the device renewed it)

13

Thanks, I'll have to look into that.

14

I tried connecting with octopi, and I tried to ssh into the Pi, both just timed out.

15

My router has a "Connected Devices" section where it shows some details about recently connected devices, if the device is currently connected the icon by the device lights up. That is how I knew the device was being "seen" by the router.

16

I just experienced this as well, though it self-recovered. Sometime after the print finished I was able to access the Pi over the network again. Checking the logs suggests that the wireless network interface was flapping:

# /var/log/syslog
[...]
Dec 26 15:39:08 octopi dhcpcd[591]: wlan0: carrier lost
Dec 26 15:39:08 octopi dhcpcd[591]: wlan0: deleting address fe80::aaff:c7ef:53cd:d128
Dec 26 15:39:08 octopi avahi-daemon[405]: Withdrawing address record for fe80::aaff:c7ef:53cd:d128 on wlan0.
Dec 26 15:39:08 octopi avahi-daemon[405]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::aaff:c7ef:53cd:d128.
Dec 26 15:39:08 octopi avahi-daemon[405]: Interface wlan0.IPv6 no longer relevant for mDNS.
Dec 26 15:39:08 octopi dhcpcd[591]: wlan0: deleting default route via 172.3.3.1
Dec 26 15:39:08 octopi dhcpcd[591]: wlan0: deleting route to 172.3.3.0/24
Dec 26 15:39:08 octopi avahi-daemon[405]: Withdrawing address record for 172.3.3.252 on wlan0.
Dec 26 15:39:08 octopi avahi-daemon[405]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 172.23.32.252.
Dec 26 15:39:08 octopi avahi-daemon[405]: Interface wlan0.IPv4 no longer relevant for mDNS.
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: carrier acquired
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: IAID eb:e8:5b:4b
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: adding address fe80::aaff:c7ef:53cd:d128
Dec 26 15:39:17 octopi avahi-daemon[405]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::aaff:c7ef:53cd:d128.
Dec 26 15:39:17 octopi avahi-daemon[405]: New relevant interface wlan0.IPv6 for mDNS.
Dec 26 15:39:17 octopi avahi-daemon[405]: Registering new address record for fe80::aaff:c7ef:53cd:d128 on wlan0.*.
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: rebinding lease of 172.3.3.252
Dec 26 15:39:17 octopi dhcpcd[591]: wlan0: probing address 172.3.3.252/24
Dec 26 15:39:18 octopi dhcpcd[591]: wlan0: soliciting an IPv6 router
Dec 26 15:39:22 octopi dhcpcd[591]: wlan0: leased 172.3.3.252 for 7200 seconds
Dec 26 15:39:22 octopi avahi-daemon[405]: Joining mDNS multicast group on interface wlan0.IPv4 with address 172.3.3.252.
Dec 26 15:39:22 octopi avahi-daemon[405]: New relevant interface wlan0.IPv4 for mDNS.
Dec 26 15:39:22 octopi avahi-daemon[405]: Registering new address record for 172.3.3.252 on wlan0.IPv4.
Dec 26 15:39:22 octopi dhcpcd[591]: wlan0: adding route to 172.3.3.0/24
Dec 26 15:39:22 octopi dhcpcd[591]: wlan0: adding default route via 172.3.3.1
Dec 26 15:39:30 octopi dhcpcd[591]: wlan0: no IPv6 Routers available
Dec 26 15:40:03 octopi dhcpcd[591]: wlan0: carrier lost
[...]

No relevant logs from OctoPrint itself. This setup has been rock-solid over the past few months (maybe a year?), and I only ran into issues after upgrading to 1.5.2 today. :woman_shrugging:

env.hardware.cores : 4
env.hardware.freq : 1200
env.hardware.ram : 917016576
env.os.bits : 32
env.os.id : linux
env.os.platform : linux2
env.plugins.pi_support.model : Raspberry Pi 3 Model B Rev 1.2
env.plugins.pi_support.octopi_version : 0.16.0
env.plugins.pi_support.throttle_state : 0x0
env.python.pip : 19.0.1
env.python.version : 2.7.13
env.python.virtualenv : true
octoprint.safe_mode : false
octoprint.version : 1.5.2
printer.firmware : Marlin 2.0.5 (GitHub)

17

Faced the same issue. Got the same feedback about network déconnection etc.., but this a bug deep rooted in the Py3 migration., reverted back to 0.17 and 1.5.2 solved everything.

18

On windows by any chance? If you don't have mDNS set up, windows may not support that by default. https://stackoverflow.com/questions/23624525/standard-mdns-service-on-windows
I opted to install bonjour print services for windows, I think it is the easiest way to go. See:
https://support.apple.com/kb/DL999

19

Oh, a bug in something I created. Interesting. I'd like to know, if you wouldn't mind :thinking:.

Though I am not sure how using a different python version to run OctoPrint affects your network, so it would be great if we could know the full details.

20

Hi @Charlie_Powell look at my previous post regarding the issue I had with octoscreen and octodash pretty similar to what is described here. However reverting back to 0.17 and still running 1.5.2, I don't have the same issue on exactly the same print... and I didn't change anything to the network. So there is something that create this problem which is in 0.18. It behaves like a memory leak but it is not as the memory stays stable during the whole run. No info in the log (I have spent some time looking at them) - I don't see this carrier lost message. The only thing that I could come accross is the printer firmware. But as the revert to old version stop this issue, I choose not to change the firmware.