Thanks for the info. I tried the suggested URL in the "Snapshot URL" (originally, mine was looking just like yours except "Enable watermark") When tested it failed.
I provided my screenshot from earlier. In this context, 127.0.0.1 is actually octopi.local only faster. It's a good idea to put that one back. The octopi.local version of that is useful if you remotely want to see what's going on without using OctoPrint to hand it to you.
(I turn off the OctoPrint octopus watermark on mine since I publish my videos.)
Oh, I love the Pi NoIR camera. That's what's on my rig. At the end of my tutorial is something to test the camera in a remote shell session as well as some suggestions about running sudo raspi-config to verify that the port is turned on.
You can ignore anything about "Turn on the camera in OctoPrint" because the Robo-specific version is dated and worked like that. OctoPrint should automatically turn on the camera.
ALL That said, once I rebooted the pi again it is WORKING!! I would quote your solutions to call the case closed but not sure what it was that i did different?
Sorry I'm such a challenge, one would never guess I was a Postscript color Guru outputting 2400 DPI printing plates for 50" presses for 25 years. I MUST be old..
Gold Star
Thanks
Uh, looks like you're trying to connect to raspberry.local rather than octopi.local (since you established earlier that you're using the OctoPi image download).
hostname: octopi (octopi.local)
username: pi
password: raspberry
Try simply ping octopi.local and see if it finds it. If it does, then it will add it to your workstation's arp cache which helps things along.
http://octopi.local/ for the snapshot URL looks wrong. That will make it have to resolve the .local domain when in fact it can just use localhost and be happy.
See
You can also get a test page served directly by the webcam server by going to http://octopi.local/webcam/:
I am at my wits end. All I did was move my PIE back to my printer and plugged it in and now my cam don't work again. The only difference is that its no longer hooked to Ethernet. Now its on WIFI and it is on cause I can ping it and octoprint loads. I tried loading the two URLs Foosel suggested and no go. I am lost why I can't log in ssh i get to the password (the one i changed in the pie Config and logged in with) but it refuses me.
Thanks
EDIT: Now that I think about it it was E-net cable straight to my mac now its WIFI
cat /var/log/syslog|grep "wlan0: leased"
...
May 11 16:17:12 charming-pascal dhcpcd[641]:
wlan0: leased 192.168.1.250 for 86400 seconds
In my case that 86400 seconds equates to (a mere) 24 hours. I don't really mind since my firewall/router has a static lease of this IP address to my printer by its MAC address so it will keep getting the same one.
For most people, though, they run multi-day print jobs and that sort of short-leasing can be a problem. You could research your router to find out how to lengthen the lease but an easier solution is to dedicate an IP address to your printer.
Also remember, the IP you get from the wired connection will be different from the IP you get from wifi. In fact, you can actually have TWO IP's on the same machine at the same time, one from wired, one from wifi. So, when you unplugged the wire, and went wireless, you automatically got a new IP
All 3 don't load. But octopi 10.0.1.34 dose. When I had it E-net to my Mac, and the camera worked, I did notice it gave me 2 PI address when I ssh in to the Octopi. I didn't take note of the other one though. NOTE: It has given me challenges in the past but my router is a AirPort Extreme? I am not able to just log in to it with safari as you would normally??
It has issued the 10.0.1.34 IP address to the Raspberry Pi 3 B+ (which has a Pi NoIR V2 camera module)
OctoPi 0.15.0 and OctoPrint 1.3.8
Hostname = octopi and username = pi
ssh is running since you get a prompt
Neither ssh pi@octopi.local nor ssh pi@10.0.1.34 seems to work from your Mac
Sometimes http://10.0.1.34 gives you OctoPrint's interface
What we don't know:
What does arp -a |grep 34 show on your Mac? (In theory, it should be a single line which represents the MAC address of the wifi adapter on the Raspi)
Did you try ping octopi.local? If not, try that first and then see if the arp command now includes a line for it.
What do you get on your Mac if you run either ipconfig getpacket en0|grep lease or ipconfig getpacket en1|grep lease? If the answer is lease_time (uint32): 0x15180 then your Airport is giving out 24-hour leases, for what it's worth.
Mac's Airport Utility might allow you to see what's going on in the Airport's configuration. Here are their suggestions for getting that setup. It sounds like the Raspi is getting an IPv4 lease... only I'm not convinced that the Airport is doing its job as a Bonjour server for name resolution.
Make sure that on both the Airport and the Raspi, you've set the country of origin for the wifi. On the Raspi, this is at the bottom of the /boot/octopi-wpa-supplicant.txt file. Not setting this correctly may prevent the Raspi from connecting well. Assume that the SSID value in this file is case-sensitive, btw.
This may be a name resolution issue. It could be server side (Airport), host side (Raspi) or client side (Mac). If you get really frustrated with this and ping octopi.local fails it's certainly possible to either dedicate an IP address in the Airport or to manually set the IP address in the Raspi, followed by you manually editing your Mac's file with sudo nano /private/etc/hosts.
The 169.254.x.x address means that there isn't a DHCP server on the ethernet segment that your Pi is connected to. It's an automatic address (self-selected, theoretically non-conflicted address) that is designed to allow DHCP clients to communicate with each other when they can't find a working DHCP server. I noticed you said you plugged it directly into your Mac...that's where that came from.
I'd be interested to see the Network tab of your AirPort setup, and to know if you have another router on the network somewhere. When you connected to the Pi using octopi.local, the problem was most likely that it was preferring the Ethernet over WiFi for bonjour, since there were no other resolution services available on that link, and eth0 or en0 come before wlan0 or wl0, so your machine likely cached octopi.local before. Probably explains why it magically worked the next day...all the (in)appropriate caches expired.
You never did give us that arp cache, though, did you? Just FYI, I run my OctoPi via Ethernet, and I'm on a Mac most of the time.