I am looking for some willing users to test a brand new feature of the PiConsole: UDP connection. If you would be willing to do some testing, and accept that there may be bugs that cause you console to crash, please read on!
I have recently implemented a new feature for the PiConsole that allows it to fetch data from the UDP interface rather than the Websocket connection. The UDP connection comes in two flavours:
UDP only - this flavour uses only data available from the UDP connection. No historical data is available. Some fields will remain blank while others will only start to calculate (i.e. max/min fields) or accumulate (e.g. rainfall totals or lightning counts) when the console starts. Resetting the console will lose all fields that require accumulation.
UDP and REST API - this flavour continues to use the UDP interface to display real time data, but the REST API is used to fetch historical data when the console is initialised, or to calculate trends that cannot be derived from the UDP data alone (the PiConsole does not store observations).
You can enable UDP mode by changing the Connection type under Menu → Settings → System, and can switch between the two flavours by toggling the REST API setting also under Menu → Settings → System.
To switch to the beta branch, stop your existing instance of the PiConsole and run wfpiconsole beta. The console should update to the latest beta version and you can start the console with wfpiconsole start. It will automatically use the Websocket, so head into the settings to change to UDP
I did the upgrade and first start I get this. I have no Sky and in the ini field that field is empty
===================================================
New version detected
Starting wfpiconsole configuration wizard
===================================================
Required fields are marked with an asterix (*)
API keys
---------------------------------
No changes required
Station and device IDs
---------------------------------
SKY not found. Please re-enter your SKY device ID*:
first bug is identified and Peter is already fixing this. Now toggled to UDP and I get following on regular interval in the logs
I do get my usual screen with data
Task exception was never retrieved
future: <Task finished coro=<udp_client.__async__decode_message() done, defined at service/udp.py:119> exception=KeyError('device_id')>
Traceback (most recent call last):
File "service/udp.py", line 167, in __async__decode_message
self.app.obsParser.parse_evt_strike(self.message, self.config)
File "/home/pi/wfpiconsole/lib/observation_parser.py", line 404, in parse_evt_strike
device_id = message['device_id']
KeyError: 'device_id'
update - ‘bash wfpiconsole.sh install’ and ‘bash wfpiconsole.sh beta’ seems to do the trick. Guess I figured it out…
[…original post…]
In the dumb questions category - can we install it from scratch configured as UDP and ‘not’ need to toggle it at all ?
(Thinking of my old use case for using the piconsole as a general purpose coolest looking display in the history of displays…and perhaps also of writing a weewx extension to emit WF API-compliant UDP to be able to use the console for any of the 70+ models of gear weewx supports)
Can somebody using the beta UDP functionality please post their [Station] and [System] portions of their wfpiconsole.ini ?
I’d like to try to test this vs. my UDP Simulator but don’t have a full setup of gear any more so I need to kinda hand-edit the .ini file to match my simulator tool.
Exactly what I was looking for. The ID numbers are one thing the websockets use, but the SN are the identifiers in the UDP messages it seems. Thanks again !
I’m not sure if this is a bug – There are incoming thunderstorms and when used with UDP & REST API it doesn’t seem like the lightning panel is automatically displayed after a strike and the values on that panel aren’t being updated. I do see historical data as well as the 10 minute and 3 hour strike frequency rate.
If I swap back to websocket it works as it did previously.
the console seems to run great vs. my wfudptools simulator, within the (limited) bounds of what my sim emits. Pretty cool indeed.
you’ll recall that my UDP use case has really no station in place, just a faked UDP emitter for data. I do have the two API keys still valid so I do see forecasts (good) but the installer is adamant looking for a valid sensor ID and bugged the heck out of me for a non-existent Tempest ID. I hacked around that in config.py to hard-set a value to match what my simulator emits to get around that for testing.
to get into UDP mode, I did the installation, then a ‘wfpiconsole beta’ and then did the one-time start attempt and lastly hand-edited the .ini file to set a TempestSN to match the simulator and to set the (fake) Tempest elevation. I also edited [System] to set it to UDP and set rest_api=0 to turn that part off. It then started up and ran ok.
=> it would be nice to query up front for which mode to run in (websockets, UDP, or UDP+websockets) and to jump right there. Again, in a UDP-only mode I would ‘hope’ that users never need to enter any WF keys or info and that ‘no’ internet connectivity is ever required to WF even to install the console.
=> it would be nice(r) to get my PR merged when you get a chance to install a working demo mode that folks could reconfigure to taste, or alternately add a ‘skip’ feature for the questions it asks and put some failsafe into place. That would let folks set the console up without the WF side being done (yet).
But it works ‘great’ for me after getting the .ini file edited to salt to taste. Very very cool feature additions.
the 24 hour trend is not showing yet and that is ok since it rebooted not so long ago.
But the trend °C/hr and barometer trends are empty since last re boot (where I disabled REST)
It sure looks like rest is set enabled from all the request_api calls. Also looks like wherever it’s getting data from you’re getting a lot of partial messages with ‘none’ for values. Also it’s banging the heck out of someplace every minute in those ‘no data in 24 hour window’ messages when if rest is off shouldn’t that never happen ?
My clean setup running vs. my simulator (ie, only some data) looks like this on startup. I see the one last_6hr message (why?) but nothing else in 15 minutes up so far. I’ll leave it running vs. my sim for the day and see if anything else pops up.
Oh - your os looks old based on the python version, if that matters. Mine is the latest 32-bit raspbian
[INFO ] [Logger ] Record log in /home/pi/.kivy/logs/kivy_23-06-03_0.txt
[INFO ] [Kivy ] v2.1.0
[INFO ] [Kivy ] Installed at "/home/pi/.local/lib/python3.9/site-packages/kivy/__init__.py"
[INFO ] [Python ] v3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110]
[INFO ] [Python ] Interpreter at "/usr/bin/python3"
[INFO ] [Logger ] Purge log fired. Processing...
[INFO ] [Logger ] Purge finished!
[INFO ] [Factory ] 189 symbols loaded
[INFO ] [Image ] Providers: img_tex, img_dds, img_sdl2, img_pil (img_ffpyplayer ignored)
[INFO ] [Window ] Provider: sdl2
[INFO ] [GL ] Using the "OpenGL ES 2" graphics system
[INFO ] [GL ] Backend used <sdl2>
[INFO ] [GL ] OpenGL version <b'2.1 Mesa 20.3.5'>
[INFO ] [GL ] OpenGL vendor <b'Broadcom'>
[INFO ] [GL ] OpenGL renderer <b'V3D 4.2'>
[INFO ] [GL ] OpenGL parsed version: 2, 1
[INFO ] [GL ] Shading version <b'1.20'>
[INFO ] [GL ] Texture max size <4096>
[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
[INFO ] [UDP ] 2023-06-03 10:16:45 - Opening socket
[INFO ] [UDP ] 2023-06-03 10:16:45 - Socket open
[INFO ] [Base ] Start application main loop
[WARNING] [request_api ] 2023-06-03 10:16:46 - last_6h call failed
. Can you send me you 
