New install pi3 with bookworm HELP

Had to start over since the os update of the pi ended so messed, hence clean install of bookworm 32 bit

install smooth, first start asks the usual questions and nothing… long time I played with this so not to sure anymore where to start debugging … seems it can’t lock on X server

rebooted the pi already in case, plenty of room on the sd card …

[^[[1;32mINFO^[[0m   ] [Kivy        ] v2.2.0
[^[[1;32mINFO^[[0m   ] [Kivy        ] Installed at "/home/eric/wfpiconsole/venv/lib/python3.11/site-packages/kivy/"
[^[[1;32mINFO^[[0m   ] [Python      ] v3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
[^[[1;32mINFO^[[0m   ] [Python      ] Interpreter at "/home/eric/wfpiconsole/venv/bin/python3"
[^[[1;32mINFO^[[0m   ] [Logger      ] Purge log fired. Processing...
[^[[1;32mINFO^[[0m   ] [Logger      ] Purge finished!
[^[[1;32mINFO^[[0m   ] [Config      ] Verifying station details
[^[[1;32mINFO^[[0m   ] [Factory     ] 190 symbols loaded
[^[[1;32mINFO^[[0m   ] [Image       ] Providers: img_tex, img_dds, img_sdl2, img_pil (img_ffpyplayer ignored)
[^[[1;32mINFO^[[0m   ] [Window      ] Provider: sdl2(['window_egl_rpi'] ignored)
[^[[1;32mINFO^[[0m   ] [GL          ] Using the "OpenGL ES 2" graphics system
[^[[1;32mINFO^[[0m   ] [GL          ] Backend used <sdl2>
[^[[1;32mINFO^[[0m   ] [GL          ] OpenGL version <b'2.1 Mesa 23.2.1-0+rpt2'>
[^[[1;32mINFO^[[0m   ] [GL          ] OpenGL vendor <b'Broadcom'>
[^[[1;32mINFO^[[0m   ] [GL          ] OpenGL renderer <b'VC4 V3D 2.1'>
[^[[1;32mINFO^[[0m   ] [GL          ] OpenGL parsed version: 2, 1
[^[[1;32mINFO^[[0m   ] [GL          ] Shading version <b'1.20'>
[^[[1;32mINFO^[[0m   ] [GL          ] Texture max size <2048>
[^[[1;32mINFO^[[0m   ] [GL          ] Texture max units <16>
[^[[1;32mINFO^[[0m   ] [Window      ] auto add sdl2 input provider
[^[[1;32mINFO^[[0m   ] [Window      ] virtual keyboard not allowed, single mode, not docked
[^[[1;32mINFO^[[0m   ] [Text        ] Provider: sdl2(['text_pango'] ignored)
[^[[1;32mINFO^[[0m   ] [GL          ] NPOT texture support is available
Unable to connect to X server
[^[[1;32mINFO^[[0m   ] [Base        ] Start application main loop
[^[[1;32mINFO^[[0m   ] [UDP         ] 2023-10-28 18:20:44 - Opening socket
[^[[1;32mINFO^[[0m   ] [UDP         ] 2023-10-28 18:20:44 - Socket open
[^[[1;33mWARNING^[[0m] [request_api ] 2023-10-28 18:21:02 - last_24h call failed
[^[[1;33mWARNING^[[0m] [request_api ] 2023-10-28 18:21:03 - Today call failed
[^[[1;33mWARNING^[[0m] [request_api ] 2023-10-28 18:21:04 - Yesterday call failed
[^[[1;33mWARNING^[[0m] [request_api ] 2023-10-28 18:21:05 - Month call failed
[^[[1;33mWARNING^[[0m] [request_api ] 2023-10-28 18:21:05 - Year call failed```

in the meantime I installed weewx again on that pi (just like before) and I’m afraid @vreihen your trick to share the UDP port fails

[ERROR ] [UDP ] 2023-10-28 21:22:16 - Connection error: [Errno 98] Address already in use

tried with share_socket = False and also True : same problem

nothing special in journalctl regarding that. It is wfpiconsole complaining (wit still the same issue as post above)

Address in use is pretty clear - you have something else listening. My guess is you didn’t get a complete shutdown of your weewx process before you switched it to shared sockets. That happens occasionally.

Try ‘netstat -lnp | grep 50222’ if you have that installed, or alternately I think it’s ‘ss -tupln’

yep weewx is listening to 50222 but with the driver from Vreihen (before) you could set share and wfpiconsole could also listen to the port. I think python 3 isn’t so nice and/or changed the way how to do this. Might need some code change on Vreihen’s code

Disagree. His driver is rock solid as is weewx and both work fine with python3.

My guess is it’s the piconsole code that isn’t handling shared sockets correctly, considering you have to be running some variant of Peter’s beta (develop branch) code, but I’d have to dig into the code to verify.

I have some time to try to recreate your issue if you can quantify your setup…

  • What precise os image did you use ? What does /boot/issue.txt contain ?
  • Which version of weewx and how was it installed (dpkg or pip) ?
  • Which version of piconsole and how did you install that ?

Not really sure what is going on here :cry:. I tested 32 bit bullseye many times on a Pi3 before release, and have just tested it again and it works fine for me.

Are you definitely using the full version of Bullseye with Desktop? Are you trying to start the console using SSH?

It could definitely be the PiConsole. The UDP code is brand new so hasn’t had much testing.

The UDP is now in the main branch. It was incorporated into the latest release

1 Like

I changed the title because after checking I got bookwork (debian 12).
And that changed quite, several things moved around, bit lost right now in there

Ah ok, I’m pretty sure I tried Bookworm as well but let me check that again. You’re definitely not trying to use SSH correct?

to fiddle under the hood but not to see since I have the pi screen on that thing, just like before

btw syslog doesn’t exist anymore on bookworm if someone else reads this

sudo tail -f /var/log/syslog is now journalctl -f

and no hurry neither. I love the console but no need to loose sleep for this. It can be debugged when time. We’re near zzz anyways.

oh you edited your post to say the new os. Yeah that is in /boot/firmware for the deb12 os. They moved things on us.

For syslog you can install rsyslog to get the old behavior rather than using the systemd borg, but “journalctl -xe -u weewx” will get you weewx logs, as one example.

give me 5 minutes to set up a clean SD and I’ll walk you through how to verify whether things are/aren’t sharing the sockets…


Generated using pi-gen,, fb56ad562991cf3ae5c96ab50983e1deeaefc7b6, stage4```

ok - I can verify that the weewx driver shares the socket ok if you add the switch to your weewx.conf in the correct position…

    driver = user.weatherflowudp
    share_socket = True
    [... and so on...]

The test was to install weewx v5 via pip, which makes running multiple copies easier. I started up one instance and it hears my wfudptools simulator (from the mac mini) just fine. I started a second instance and it ‘also’ listened just fine.

I also started my wfudplistener on the same pi so I had ‘three’ things hearing the UDP broadcasts just fine. Two instances of weewx plus my wfudptools listener.

So I’m pretty convinced weewx is ok. Let me add the piconsole and see what we see…

ok - I can confirm the piconsole is ‘not’ sharing the socket.

I installed the newest console in UDP mode and configured it to match the ST-nnnnnnn my simulator emits. Fired it up and got no data. Shut down the console and see the address in use errors a couple times.

I killed the three things I had listening and sharing the socket (my listener and two weewx instances) and started up ‘only’ the piconsole. It worked fine and displayed the udp my simulator was emitting.

Then I tried to start just my listener on the pi with the piconsole running. Fail - address in use.

So it seems pretty clear to me that the piconsole is ‘not’ opening the listening socket and sharing it so other things can listen to that port too…

[…incidentally - the new console installs ‘very’ quickly on the pi4 using deb-11 raspios so that part works perfectly…]


I’ll pass this code snippet along to @peter, which shows the SO_REUSEADDR socket option in Python that is probably missing from PiConsole:

    if self._share_socket == True:
        s.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)

I got a little lost where I thought (thought…) he was doing so around line 97 of

I’m really not sure I understand what is going on here. I have just retested Bookworm 32 bit on a Pi 3 and I have no problems. I run wfpiconsole start directly from the terminal on the Pi screen and it starts with no issues. I don’t see the Unable to connect to X server issue.

I am using the 2023-10-10 image of Bookworm downloaded from here:

Thanks for the snippet. I thought I was sharing the socket, but clearly I’m not! I will take another look at this

1 Like