if we already switch from UDP to the rest version, at least for now we take one problem away, see if this isn’t the real error and X just ok ?
Connection = UDP
rest_api = 1
SagerInterval = 6
Timeout = 20
Hardware = Pi3
Version = v23.10.1
guess I have to set something else for connection = ??
@peter - I did some retesting on a pi4.
For 32bit bookworm it installs and works fine with demo mode, UDP mode, and UDP+websockets mode as far as I can tell.
For 64bit bookworm it installs fine but I get the ‘Unable to connect to X server’ message here too and no gui comes up even in demo mode. I did not do any poking around under the hood to see if there were any ‘dpkg -l’ differences resulting in missing dpkg(s) or the like for the 64bit os but my guess is there’s a package or two missing perhaps
Let me know if you want me to nuke my SD card to 64bit again and try my handcrafted installer that I last emailed to you a week ago. I can’t recall any more if I tested that on 64bit or not.
But 32bit bookworm definitely installs and runs ok in all configurations on a pi4 in brief testing here…
Try changing Connection = UDP to Connection = Websocket to switch back to the REST version. Do you still see the X error?
Can you also let me know the output of dpkg --print-architecture. Is there any chance you are running 64 bit by mistake?
OK, that’s interesting. I have never tested 64 bit as it is still technically unsupported (the installer should throw a warning), but I will dig into it now. The 64 bit version appears as the ‘recommended’ version of Bookworm in the Raspberry Pi Imager, so that might be catching people out.
Feel free to give your installer a spin if you have the time. It might help identify a missing package
eric@raspberrypi:~/wfpiconsole $ dpkg --print-architecture
armhf
[INFO ] [Kivy ] v2.2.0
[INFO ] [Kivy ] Installed at "/home/eric/wfpiconsole/venv/lib/python3.11/site-packages/kivy/__init__.py"
[INFO ] [Python ] v3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
[INFO ] [Python ] Interpreter at "/home/eric/wfpiconsole/venv/bin/python3"
[INFO ] [Logger ] Purge log fired. Processing...
[INFO ] [Logger ] Purge finished!
[INFO ] [Config ] Verifying station details
[INFO ] [Factory ] 190 symbols loaded
[INFO ] [Image ] Providers: img_tex, img_dds, img_sdl2, img_pil (img_ffpyplayer ignored)
[INFO ] [Window ] Provider: sdl2(['window_egl_rpi'] ignored)
[INFO ] [GL ] Using the "OpenGL ES 2" graphics system
[INFO ] [GL ] Backend used <sdl2>
[INFO ] [GL ] OpenGL version <b'2.1 Mesa 23.2.1-0+rpt2'>
[INFO ] [GL ] OpenGL vendor <b'Broadcom'>
[INFO ] [GL ] OpenGL renderer <b'VC4 V3D 2.1'>
[INFO ] [GL ] OpenGL parsed version: 2, 1
[INFO ] [GL ] Shading version <b'1.20'>
[INFO ] [GL ] Texture max size <2048>
[INFO ] [GL ] Texture max units <16>
[INFO ] [Window ] auto add sdl2 input provider
[INFO ] [Window ] virtual keyboard not allowed, single mode, not docked
[INFO ] [Text ] Provider: sdl2(['text_pango'] ignored)
[INFO ] [GL ] NPOT texture support is available
Unable to connect to X server
[INFO ] [ProbeSysfs ] device match: /dev/input/event1
[INFO ] [HIDInput ] Read event from </dev/input/event1>
[INFO ] [ProbeSysfs ] device match: /dev/input/event0
[INFO ] [HIDInput ] Read event from </dev/input/event0>
[INFO ] [Base ] Start application main loop
[INFO ] [HIDMotionEvent] using <generic ft5x06 (79)>
[INFO ] [HIDMotionEvent] <generic ft5x06 (79)> range ABS X position is 0 - 799
[INFO ] [HIDMotionEvent] <generic ft5x06 (79)> range ABS Y position is 0 - 479
[INFO ] [HIDMotionEvent] <generic ft5x06 (79)> range position X is 0 - 799
[INFO ] [HIDMotionEvent] using <vc4-hdmi>
[INFO ] [HIDMotionEvent] <generic ft5x06 (79)> range position Y is 0 - 479
boots with same X server issue
ok - burned a 64bit SD to be able to test here…
My quickie installer ‘does’ result in a working piconsole on 64bit on a pi4.
For pip:
For dpkg:
I don’t see any other differences. Try the installer I PM’d you a week ago and see if you get the same result. I’m running the 10-10-2023 os and it does report arm64 to ‘dpkg --list-architecture’
sigh - moved my working hand-crafted installation aside and ran the official installer and it also worked on arm64. I can’t explain in the least. I’ll do another cycle and try to make it break/fail again and then see if I can see what made it work this last time (sigh).
You folks are on a pi4 or better ?
bookworm is not using X11 server anymore on those but Wayland.
Only older models rely still on X
On a pi4 ‘today’ a clean 64bit installation piconsole works fine in repeated tests. Yesterday it failed with the unable to connect to X server message. I can not explain it.
I am definitely on wayland in both failed (yesterday) and working (today) tests using the same image from 10-10-2023. “dpkg --print-architecture” returns arm64 as expected.
@pete - just an update - I did a couple more installs on pi4 64bit while fiddling with other things and all succeeded. I can not explain why a couple of us were seeing periodic unable to connect to X server messages. All I can suggest is in that case folks save their wfpiconsole.ini file, rename the tree, and try another clean installation.
I’ll try this week end, no time for now 
will install weewx on a vm on my proxmox to avoid the share udp thing.
Now re install means a lot of work to get both running.
CC @peter fyi, wrong peter tagged
I’ve made a couple of tweaks to the UDP code which should make sure the PiConsole correctly shares the UDP port. The changes are on the development branch. Would you mind testing them out?
switched to beta branch but stil that X server issue.
I have migrated weewx away and will (if time permits later tonight) re install bookworm and wfpiconsole
first see if I can eliminate the X server issue and once that is ok, I’ll re install a weewx and test the share again
Try activating the autostart with wfpiconsole autostart-enable. Someone over on Github found that this fixed the issue
starts but not nice, once I wantto go in settings it crashes
Get forecast and sunrise … all except the station data
Nov 02 12:55:58 raspberrypi systemd[1]: wfpiconsole.service: Failed with result 'exit-code'.
Nov 02 12:55:58 raspberrypi systemd[1]: wfpiconsole.service: Consumed 14.036s CPU time.
Nov 02 12:55:58 raspberrypi systemd[1]: wfpiconsole.service: Scheduled restart job, restart counter is at 2.
Nov 02 12:55:58 raspberrypi systemd[1]: Stopped wfpiconsole.service - WeatherFlow PiConsole.
Nov 02 12:55:58 raspberrypi systemd[1]: wfpiconsole.service: Consumed 14.036s CPU time.
Nov 02 12:55:58 raspberrypi systemd[1]: Starting wfpiconsole.service - WeatherFlow PiConsole...
Nov 02 12:56:03 raspberrypi systemd[1]: Started wfpiconsole.service - WeatherFlow PiConsole.
More things to fix 
. Are you using Websocket or UDP? Can you see whether the develop branch is any better? Navigate to the wfpiconsole directory and run git checkout develop. Then try and enable the auto start again
am on dev channel already and this is extract of the ini file
Connection = UDP to Connection = Websocket
rest_api = 1
SagerInterval = 6
Timeout = 20
Hardware = Pi3
Version = v23.10.1```OK - this is such a weird problem. I have been testing the autostart again on 64 bit Bookworm and see no issues with the console starting or the X window problem. Almost at this point it seems like you just need to install, re-flash the sd card, install again and repeat until you don’t get an error.
There are a couple of things to try though. First, run the raspi-config tool using sudo raspi-config. Navigate to Advanced and then Wayland and try toggling between the Wayland option and the X11 option. Does that change the behaviour in any way?
@eric if you want to do a “dpkg -l” and “pip3 list” after activating your python venv and post it somewhere, I can compare it to mine here that works for some reason. The dpkg list is going to be a long file so you’d need to stick it someplace online we can download it from.