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/__init__.py"
[^[[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```
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 . 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?
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
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…
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…
[WeatherFlowUDP]
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’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.