WF PiConsole beta testing: UDP connection

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:

  1. 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.

  2. 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 MenuSettingsSystem, and can switch between the two flavours by toggling the REST API setting also under MenuSettingsSystem.

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

Let me know how you get on!

3 Likes

oooohhh you asked for it :japanese_ogre:

1 Like

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*: 

relavant part of the ini

[Station]
StationID = 26843
TempestID = 86400
SkyID =
OutAirID =
InAirID = 208678
TempestHeight = 9.0
SkyHeight =
OutAirHeight =
Latitude = 43.34315
Longitude = 1.14939
Elevation = 244.3878936767578
Timezone = Europe/Paris
Name = Tp-Européen

First bug :rofl:. Can you send me you .ini file in a PM?

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'
1 Like

Oops, this one slipped under the radar. I’ll get a fix in later

OK, stop the console, run git pull again and restart the console. That should fix the KeyError: 'device_id' messages

done, and I don’t get any new error for now

2 Likes

Just switched to the beta branch … so far so good. Toggled to UDP and all seems to be working as normal with no errors :smile:

@peter : this is boring lol, no more bugs … :rofl:

Boring for you, happy for me :smiley:

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.

Thanks for any help…

here is mine

[Station]
StationID = 72948
TempestID = 245403
TempestSN = ST-00090120
SkyID =
SkySN =
OutAirID =
OutAirSN =
InAirID =
InAirSN =
TempestHeight = 4.0
SkyHeight =
OutAirHeight =
Latitude = 43.34312
Longitude = 1.1494
Elevation = 244.5252380371094
Timezone = Europe/Paris
Name = Hub 25
[System]
Connection = UDP
rest_api = 0
SagerInterval = 6
Timeout = 20
Hardware = Pi3
Version = v23.5.beta
1 Like

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 sorry to say that I am failing in my job beta tester because I have yet to find any bugs. I’ll try harder.

2 Likes

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.

@peter some feedback…

  • 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.

I am still on UDP and REST set to OFF

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)

IMG_9572

my log file has a few new errors

wfpiconsole.zip (6.1 KB)

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