I have done a couple of temperature measuring projects with different PIs (a Pi3 and a Pi Zero W) and am quite familiar with running them headless via VNC.
I thought I would try my hand with a camera on a PI zero W and having got the basics sorted have installed the "motion" package and was starting to play with that.
but now when running headless initial attempts to access the machine via VNC result in
VNC Server is not currently listening for cloud connections
I discovered by chance that if I leave it long enough it does eventually come up and having done some testing by trying to access every 30 seconds from boot I can not get access at 11 minutes but can at 11 minutes 30 seconds.
If I connect the pi to a display via the HDMI port and keyboard/mouse via USB, the machine boots in about a minute or two, VNC starts and I can log in from my remote machine, straight away.
I have done quite a bit of googling and did find this page
formatting link
but setting consoleblank to 60 did not improve matters.
I have tried @reboot vncserver start in crontab with no effect.
I have uninstalled the motion package but still no improvement
Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to a Pi4.
I found that the following lines in /boot/config.txt solved it for me:
hdmi_force_hotplug=1 # allow Pi to boot with no monitor connected hdmi_group=2 hdmi_mode=82 # force 1920x1080x60 even though monitor can?t be auto-detected
Thanks for the suggestions which I have now had time to look into. The first two lines were already set in my /boot/config.txt
The third line was hdmi_mode=16. I changed it to 82 and although this had a major effect on the VNC display it did not reduce the VNC access time which remains at in excess of 10 minutes from reboot
Hmmm. I wonder what it different about your setup. In my case the Pi refused to boot, and stuck as a solid (not flickering) green LED. I never thought to leave it to see if it would eventually boot. VNC may be a slight red herring here, because a Pi ought to be able to boot without any remote connection. What happens if you set up a recurring ping to the Pi: does that start responding any sooner than the > 10 mins that you've found for VNC.
As far as I am aware, the hdmi_force_hotplug=1 is the only parameter which matters as regards ability to boot; the hdmi_mode=82 is there just to make sure what VNC sees a full-resolution display when it connects, rather than defaulting to 640x480 or giving a white-writing-on-black-background error message.
Thinking about this a bit more, I can't see that any software which auto-starts on your Pi (but which I don't have on mine) would be started early enough to cause a no/go-go on the booting process. So I wonder if the reason your Pi doesn't respond to VNC is different to the reason mine didn't boot until I added hdmi_force_hotplug=1. Maybe your Pi is booting OK but Real VNC server isn't starting until after a long timeout. There is probably a log file somewhere which contains details of all the processes and their time-since-boot (it will be a fictitious time because the Pi will boot with a semi-random time because it has no real-time clock hardware, and the time will only be corrected when the Pi then syncs with an NTP server),
If you can ping the Pi from long before VNC responds, you could try enabling SSH on the Pi and connecting to it by PuTTY (Windows) or JuiceSSH (Android) - get those working when the Pi is booted and responding via VNC (or connected to a monitor) so you know that they normally work, before rebooting and trying with the Pi headless. Those are diagnostic rather than solutions, but at least they help diagnose how far the Pi is getting in its boot process - ie whether it is even leaving the starting blocks.
Use 'sudo raspi-config' to configure VNC, that should be enough. Do not add another 'vncserver start' somewhere.
Desktop + Motion + VNC sounds a bit much (by which I mean a LOT) for a Pi Zero.
Start over from scratch: download a fresh image of the latest 32-bit RaspiOS, burn it to SD card and connect to that.
If running headless, you do need those config.txt settings. Group 1 mode
16 is the same as group 2 mode 82. CEA (group 1) was originally for TV compatible hdmi, DMT (group 2) is for DVI over hdmi to a computer monitor, but effectively they're the same. If you want sound output over the physical cable, use a CEA mode. This makes no difference for VNC. I have this:
hdmi_force_hotplug=1 # 1/16 = CEA 1920x1080 @ 60 Hz # 1/31 = CEA 1920x1080 @ 50 Hz # 1/95 = CEA 3840x2160 @ 30 Hz (only for Pi 4) # 2/69 = DMT 1920x1200 @ 60 Hz # 2/82 = DMT 1920x1080 @ 60 Hz hdmi_group=1 hdmi_mode=16
More modes available at
formatting link
(scroll down to "hdmi_mode" where they have two enormous tables for CEA and DMT).
This explains why when I was using 2/82 = DMT 1920x1080 @ 60 Hz, I couldn't get any sound if I connected the Pi by HDMI cable, having set the Pi to boot headless with
hdmi_force_hotplug=1 hdmi_group=2 hdmi_mode=82
I'll change it to
hdmi_force_hotplug=1 hdmi_group=1 hdmi_mode=31
Which are the parameters I have for my Pi3 which doesn't need the hdmi_force_hotplug=1 to allow it to boot headlessly. I Couldn't find any reference to the CEA modes or 50 Hz rather than 60 Hz when I was researching for the Pi4 - maybe it is that 50 Hz modes are not offered by raspi_config.
On Saturday, 12 June 2021 at 11:13:53 UTC+1, Andy Burns wrote:
Apologies if this formats incorrectly but I am away from home at the moment using Google Groups rather than the more familiar T Bird
I have uninstalled the "motion" package
I rebooted and tried to ping immeadiately
chris@Johns-iMac ~ % ping 192.168.1.22 PING 192.168.1.22 (192.168.1.22): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 Request timeout for icmp_seq 5 Request timeout for icmp_seq 6 ping: sendto: No route to host
{lots of similar lines deleted}
Request timeout for icmp_seq 43
64 bytes from 192.168.1.22: icmp_seq=44 ttl=64 time=8.094 ms
64 bytes from 192.168.1.22: icmp_seq=45 ttl=64 time=4.997 ms
64 bytes from 192.168.1.22: icmp_seq=46 ttl=64 time=7.650 ms
64 bytes from 192.168.1.22: icmp_seq=47 ttl=64 time=5.090 ms
64 bytes from 192.168.1.22: icmp_seq=48 ttl=64 time=6.026 ms
64 bytes from 192.168.1.22: icmp_seq=49 ttl=64 time=5.279 ms
64 bytes from 192.168.1.22: icmp_seq=50 ttl=64 time=5.696 ms
64 bytes from 192.168.1.22: icmp_seq=51 ttl=64 time=5.697 ms
64 bytes from 192.168.1.22: icmp_seq=52 ttl=64 time=2.083 ms
64 bytes from 192.168.1.22: icmp_seq=53 ttl=64 time=7.380 ms ^C
--- 192.168.1.22 ping statistics ---
54 packets transmitted, 10 packets received, 81.5% packet loss round-trip min/avg/max/stddev = 2.083/5.799/8.094/1.628 ms
So then I tried to SSH and do a ps aux (results below)
chris@Johns-iMac ~ % ssh pi@192.168.1.22 pi@192.168.1.22's password: Linux pizero2 4.19.66+ #1253 Thu Aug 15 11:37:30 BST 2019 armv6l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Ok. so we've established that the Pi *is* booting - and taking about 43 seconds to start responding to pings - assuming that you started the ping command as you applied power to the Pi to start it booting, and that your pings are once a second.
And SSH is working OK: its listener process must be starting long before VNC's starts.
So it's not the failure-to-boot problem of not having an HDMI monitor to detect. But something else is preventing the VNC listener starting when there's no HDMI device present.
Ah, a thought has just occurred to me. That word "cloud" in "VNC Server is not currently listening for Cloud connections". There are two ways of establishing a VNC connection. One involves referring to the computer (in your case, the Pi) by its name, and goes via a central cloud server. The other is a direct connection by IP address and does not rely on a cloud server. The default is to use the cloud server: it works for RealVNC server on *any* platform, even if you have the free rather than paid-for subscription version of VNC.
The VNC server component that is built into Raspian/RasPiOS is a special case: even without a paid-for subscription, clients can connect to it directly by IP address.
At your VNC Viewer client (on your non-Pi computer), try configuring a direct connection. For the Windows version, to the right of the "VNC Connect" logo there is a box with the default wording "Enter a VNC Server address of search". Hopefully it's similar for your Mac client. In this box, type the IP address of the Pi. And see whether you can connect any sooner this way than via the cloud.
VNC was always direct (either forward on TCP/5900 or reverse on TCP/5500) when I was using it, having a rendezvous with a 3rd party server in the cloud was the teamviewer or anydesk way of doing it (with pros and cons).
How long does the Pi take to register with this VNC cloud?
In my RealVNC address book I have two entries for my Pis - one using the normal cloud method (*) and the other using direct connection. And the connection speed reported by VNC is very different: the cloud one is capped at roughly the upstream (slower) speed of my broadband connection. That does rather suggest that a cloud connection routes data out onto the WAN and then back in again.
I've just connected directly from my Windows PC to one of my Pis, where both computers and the router are Gigabit compatible. In the pull-down menu at the top of the remote desktop, there is an "i" icon. It reports Connection Type = Direct TCP and Line speed estimate = 750110 kbits/sec. Having closed that connection and opened one via the cloud to the same Pi, results are Connection Type = Cloud connection to [LAN IP}:50556 and Line speed estimate = 10560.kbits/sec - and Ookla Speedtest gives my current speed as
29.18 Mbps D and 9.78 Mbps (ie 9780 kbps) U. That suggests that a direct connection is almost full Gigabit speed and cloud speed is similar to upstream WAN speed.
(*) I only use this if I need to access the Pi from outside my LAN - eg from my phone or laptop when away from home.
Just tried that and in the period when the cloud connection is "VNC Server is not currently listening for Cloud connections."
the direct connection method you suggest gives "Timed out waiting for a response from the computer"
as soon as the cloud connection is up and running so is the direct method.
Once up and running the CPU usage is very low - usually well below 5% with the odd spike to 20% or so, so its not as if something else is using all of the processing power.
I asked myself what is different about this machine and my other 2.
1) This one has the camera interface enabled
2) This one has had the motion package installed and removed.
So I have disabled the camera interface - no change. Perhaps 2 has corrupted something somewhere.
It looks like this isn't a quick and easy fix that lots of people know but I don't so perhaps it is time for the SD card reformat option and start again from scratch. This time play with the camera without trying motion. Its all part of the learning experience :-)
Could be an excessive amount of time to obtain a DHCP lease. If you use raspi-config to set wait for network at boot, you should see this happening with an attached display.
Yes, that's how I rationalised it when I had to reinstall my Pi: once because something catastrophic happened between a clean shutdown and a clean startup (no power cuts at that time), so the Pi failed very early in the boot process; secondly when I bought a Pi4 and migrated software from the Pi3; thirdly because an update on the Pi4 invoked by sudo apt update followed by sudo apt full-upgrade caused a program (or a device driver) to misbehave (the Pi was running TVHeadend as a video recorder; after the upgrade recordings from the satellite decoder started intermittently experiencing massive numbers of data errors, as if the satellite signal had become badly degraded by noise). I will not be installing any updates on the Pi - especially ones which update the kernel.
Luckily I made detailed notes of all the customisations I made as I was doing the first reinstallation (Pi wouldn't boot) and was able to refer to those to make sure I carried out the same stages (with appropriate modifications when going from Pi3 to Pi4) for initial installation and then the reinstallation (duff satellite tuner driver).
In your case, I'd get VNC server working early in the build process, and prove that it works, and then retry it periodically as new software is installed, to find out what provokes it. Maybe also take an image of the SD card before each significant new installation so you can roll back to just before, rather than having to go right back to the beginning.
That reminds me: it's probably about time I updated the SD images of my Pis as rollback insurance, so I roll back to as late a state as possible rather than to how they were several months ago.
LOL. I was just about to point that out, but you got there first.
Another off-the-wall suggestion to the OP (you may already have tried this). What happens if you boot up headless and then some time in the expected 10 minute delay plug the monitor in? Does that immediately allow VNC to accept connections?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.