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.