I’m fiddling around with trying to modify the PiConsole to get its data from the local UDP broadcasts rather than from the WF REST data and have it mostly ready enough for others to try, if anybody has interest.
If so, let me know via PM and we can coordinate via email
[…TL;DR…]
Architecturally it requires the following:
install and run my wfudptools listener with a certain set of command-line options so the data is saved to /var/tmp tmpfs files, to not write to SD card
modify a couple files in Peter’s product
very lightly edit your .ini file
Testing is very reversible. Basically “cp -a” the wfpiconsole tree to another name for safekeeping, do the few modifications above, and fire it up. Reversing it is just putting the original official wfpiconsole directory back into place.
Note - there ‘are’ some limitations of going with UDP for data because that API does not provide accumulated data (rain, strikes) nor trends (min/max), but for a realtime display it works pretty nicely. Also would support indoor data from a Air with some modifications if that’s important to you.
Long term goals - I hope to go further to let weewx be the listener and map to some standard kind of schema for the data, which would let the PiConsole display data from any of the 70+ vendors and stations that weewx supports. Initially I’m doing just the Tempest to see how well the vision might work out long term.
Again - please let me know if you have any interest and we can coordinate via email.
This is certainly an interesting thing, especially for the case where there is no internet access, and PiConsole would still display the basic data from Tempest.
However, the ideal solution would be if @peter could build such functionality into PiConsole, and for the local station it could be switched to UDP mode.
Or, if PiConsole found Tempest UDP traffic on the local network, it would offer to display that weather station as well, and fill in the missing information from the cloud if it also had Internet access.
Can’t you and @peter agree on some kind of collaboration so that it is still a single software product?
Personally, I would like to run both options simultaneously
I’m certainly not trying to do an integrated product nor support one. All I’m trying to do is use the PiConsole to display data coming from other kinds of sources.
We ‘are’ talking about integrating the small changes to the PiConsole code needed to make that possible.
The PiConsole is really great for what it does, so I’m trying to leverage it’s very slick look’n’feel for data coming from other sources. Basically anything that can generate JSON following the WF UDP API could probably work.
I think I’m going to punt at this time on this one. It’s just too complicated under the hood for me to reverse engineer enough. Sorry if I got anybody’s hopes up too much.
hey … sounds like something similar to what Gary Funk did a few years back. I still have a rpi running with it still doing it’s thing.
Not sure what happened to Gary or his project “ArchiveSW” it also allowed a sensor attached to the GPIO - for indoor temperature. I really liked having it as a backup - and the best part is it is totally local.
And… This is exactly how WeatherBox is doing it… All data that WeatherBox displays is via the local UDP (or from other station types: Davis, Peet etc).
And you get a local -network web display in addition to the internet based display.
Just sayin’.
WxBox is still on beta form…but getting more and more stable by the day.
If you have found this thread and are looking for information about different methods to extract and display your data you may be interested in this thread:
UDP works for me.
But today, when I ran “wfpiconsole beta” to update
am getting an error:
main: line 304: /home/pi/wfpiconsole//venv/bin/python3: No such file or directory
Seems to be a typo in the beta script?
The beta branch (or development branch) is not always stable. Right now I am in the middle of adding some new functionality which is not complete yet. It’s not recommended to switch to the beta branch unless I indicate that it is currently in a stable state
I had the beta running well - receiving UDP data directly from the Weatherflow onsite.
I noticed a prompt that an upgrade was available.
I ran the update, but am unable to get back to beta so that I can receive UDP data directly from the Weatherflow unit.
Pete - I took a quick look and found a few nits that should hopefully be quick edits for you to try. Apologies for this reply being a little long but I wanted to document how I got it to work.
First, I started with a clean raspi SD card…
I did a ‘git clone’ of your repo and ‘git checkout develop’ to get to the develop branch, then ran ‘bash wfpiconsole.sh install’ procedurally to try to work off a local develop clone of your current repo dated today.
It blew up. Simple fix. You need to activate the venv in install_python_venv( ) above the ‘already exists’ line so that subsequent installation of modules goes into the venv. I think this is most of what lenny was running into and is definitely needed for a clean new install.
diff --git a/wfpiconsole.sh b/wfpiconsole.sh
index 3b64032..d89ea01 100755
--- a/wfpiconsole.sh
+++ b/wfpiconsole.sh
@@ -240,6 +240,7 @@ install_python_venv() {
exit 1
fi
else
+ source "$VENVDIR/bin/activate"
printf " already exists\\n"
fi
}
At this point, the install correctly seeds the venv with the python modules and completes, but your script ‘really’ wants to run off main, so the wfpiconsole stuff it installs is actually off main. Sigh. Fortunately your installed wfpiconsole tree is actually a git clone (whew) so I got around this by manually switching to the develop branch after the installation finished.
cd wfpiconsole && git checkout develop
I also copied my lightly hacked wfpiconsole.sh file into place as wfpiconsole/wfpiconsole.sh
At that point a ‘wfpiconsole start’ worked as expected, giving me the develop branch prompts for whether to run the example configs, use UDP, and the like. So I basically got beta to work with a little sleight of hand.
A couple other nits:
you set the VENVDIR variable with a trailing slash to assemble the python3 path (ok) but in other places you seem to expect ‘no’ trailing slash in the directory name. This makes a filename ala /some/dir//filename which while benign is ugly. I think Lenny’s last reply showed an example. The .service file similarly has two // in a row mid-filename as another example.
I like the prompts for units and timezone etc. (nice) but you might want to give some help on how to answer the questions. I know that Western lon is negative but the prompt doesn’t help. Similarly the elevations etc. should be in meters (?) and the like. It was uncertain how to answer from the questions you answered but I guessed ok it seems.
one really interesting bug is that the prompts for degrees C/F looked awful for the degree symbol. I’ve run into this in the venv setup of weewx re: the web pages it generated and we never got a resolution there, but my guesstimate is it’s something in the i18n or localization stuff. For weewx it doesn’t happen on ubuntu AWS but is very consistently broken on debian and raspi os (which is deb-based).
Bottom line - the venv stuff looks ‘really’ close. Try adding that ‘one’ line to wfpiconsole.sh on develop and let us know if you want more testing done…
