writing an extension to broadcast JSON

64 views
Skip to first unread message

Vince Skahan

unread,
Jun 6, 2023, 3:40:43 PM6/6/23
to weewx-development
Looking for some guidance....

I'm thinking of writing an extension that emits a JSON broadcast of weather station data in a format that matches the WeatherFlow UDP API.   The reason I'm asking is that there's a very nice project called PiConsole that uses a pi3 or pi4 to drive a pretty slick looking console. (link to screenshot)

The new beta of PiConsole supports listening to the WeatherFlow UDP broadcasts, so I was thinking that if there was a generic weewx service that emitted compliant JSON broadcasts, then weewx could drive that slick looking display for any of the dozens of station types weewx supports....

Looking for suggestions re: what approach to take and if there are other services/extensions to use as starting points.  CSV and MQTT certainly came to mind as two things to look at in more detail.  Are there others ?  Perhaps ones that tweet or the like ?

Some nuances about the UDP API if that matters...
  • station observations are emitted as one type of message once a minute
  • 'rapid wind' is emitted every 3 seconds in another type of message
  • lightning and rain start events are emitted as they're detected
  • there are a couple other messages for device status that I can probably skip
  • each message type has a nicely documented API
The kind of things I'm wondering include...
  • given 4-5 types of messages with different periods, do I just do them in one service/extension ?
  • for rapid_wind (3 sec period) and events (when they appear) would I grab that from LOOP ?
  • for a 60-sec observation would I grab that from LOOP too ? Or would it be easier to just grab archive packets and it would only update those things every 5 minutes ?
  • oh - the UDP API is in metric and my station runs US units.   I'd like weewx to do the heavy lifting for unit conversions back to metric for me if possible.
Consider my station to be a VP2 at 5-minute interval if that helps any, but what I'm trying to do is consider a more general approach for broadcasting station data that would work for any vendor gear, making the PiConsole display nice and generic regardless of hardware vendor for the actual station.

Suggestions appreciated...

Greg Troxel

unread,
Jun 6, 2023, 4:07:40 PM6/6/23
to Vince Skahan, weewx-development
Vince Skahan <vince...@gmail.com> writes:

> I'm thinking of writing an extension that emits a JSON broadcast of weather
> station data in a format that matches the WeatherFlow UDP API. The reason
> I'm asking is that there's a very nice project called PiConsole that uses a
> pi3 or pi4 to drive a pretty slick looking console. (link to screenshot)
> <https://global.discourse-cdn.com/business7/uploads/sws/original/2X/2/25c6fa1d496d5a0fb4504392188e5f2112762ed9.png>

My $0.02 (and I know you know some of what I am saying but thought it
better to explain more for others who might not):

- It would be nice if PiConsole could consume the json from the
existing MQTT extension. It is not great to use a vendor format as
an interface. But I get where you are comign from.

- In the Home Assistant community, there is a culture of creating a
python module to talk to some vendor thing (callable from python),
and then an integration (analogous to a weewx service). This lets
others use part of the logic and I think leads to better sharing of
work and more use in more places. So I recommend doing that,
basically a py-weatherflow-talker.

- Within weewx, I think this should be one extension that's sort of
like MQTT, but invokes py-weatherflow-talker instead of MQTT. And
all of the messages should be in the same extensinon.

- I would expect you can listen to both LOOP and ARCHIVE and so
something more complicated to merge them. This is unlike the mqtt
service which exposes weewx semantics. For things that are
supposed to be every 60s I would just keep watching loop and keep
variables with latest and when the 60s time fires ship it and clear
the variables and repeat.

- This may surface cases where the weewx architecture needs extending,
but it may not. Consider adding a lightning detector to your setup
which is prompt, in addition to the VP2, and what you'd like the
weatherflow packets to look like.



I suspect mqtt is a good starting place, but you need custom logic to
change loop/archive to match the intended rates.

Vince Skahan

unread,
Jun 6, 2023, 4:55:51 PM6/6/23
to weewx-development
On Tuesday, June 6, 2023 at 1:07:40 PM UTC-7 Greg Troxel wrote:
- It would be nice if PiConsole could consume the json from the
existing MQTT extension. It is not great to use a vendor format as
an interface. But I get where you are comign from.


I think I've bugged Peter enough re: UDP support to call his new beta as-is a major thank-you win :-)

But I'd agree.  Something to add on the PiConsole pi to listen for weewx MQTT and broadcast (to loopback) the UDP the PiConsole listens for would be another way of slicing and dicing the components.   I'd still need to convert US units back to metric but that's not a heavy lift.

So a weewx add-on ala the MQTT extension that instead broadcasts UDP is one option.  A pi-console add-on that listens MQTT and broadcasts UDP would be another option.  Plusses/minuses for both I guess.


Reply all
Reply to author
Forward
0 new messages