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…
I am still not able to get back to the beta so that I can utilize the UDP.
Am getting an error:
“main: line 304: /home/pi/wfpiconsole//venv/bin/python3: No such file or directory”
Hi @vinceskahan, do you mind testing this again for me? I couldn’t recreate the venv activation error. Do you mind testing again and sharing the error output if you see it again. I should have fixed the trailing / issue too.
I’ll work on the prompts for the UDP setup - it didn’t occur to me that I had to explain things to people
@peter - sure I can give it a try today or tomorrow
@lenny - I thought I answered your question. Unfortunately the workaround does require a bit of CLI and git/python expertise. A ‘click here and go’ switch to beta/UDP was not possible 20 days ago when I last tried it.
More info just so it’s here someplace…
Important: with the new pi5 coming out this month, they will have a new os with it that has breaking python changes under the hood that will ‘prevent’ wfpiconsole from installing at all until Peter can catch up to the upstream changes he’s working on via the beta branch. The coming pi os also changed the windowing system so it’s uncertain what else that might break. Patience is needed.
Bottom line: nobody running piconsole should run the coming-soon ‘bookworm’ (deb12) based raspi os nor try to run it on the pi5 until Peter says it’s ok.
@peter you need to patch wfpiconsole.sh to add the source $VENVDIR/bin/activate on line 243.
I did not find an official way to get to beta but I did find a manual CLI way. The basic problem is the install script ‘really’ wants to do a git pull of latest and also always installs ‘main’.
Here’s what I did to do a clean installation that starts up on develop (beta) and does show the beta prompts etc. as expected…
# clone the current github repo manually
cd /home/pi
git clone https://github.com/peted-davis/WeatherFlow_PiConsole.git
cd WeatherFlow_PiConsole/
# checkout the develop (aka beta) branch
git checkout develop
# patch the local develop branch wfpiconsole.sh script
# add one line "source $VENVDIR/bin/activate" on line 243
# above the 'already exists' line
vim wfpiconsole.sh
# run the locally-modified installer manually
# this does the right thing using 'develop'
bash wfpiconsole.sh install
# move the generated .service file aside
# temporarily to let us switch the installed
# tree to develop in the next step
mv wfpiconsole.service /home/pi/wfpiconsole.service
# checkout develop for the 'installed' /home/pi/wfpiconsole tree
git checkout develop
# put the generated service file back into place
cp /home/pi/wfpiconsole.service .
# at this point a start works with 'develop' prompts
wfpiconsole start
# presumably you'd later want to manually
# install the wfpiconsole.service file to start on boot....
# you might also patch (again)
# the wfpiconsole.sh script
# if you had to patch it to install above
Are you sure this is still necessary? Whenever the .sh script calls python, it is pointed to the venv version of python (i.e. ~/wfpiconsole/venv/bin/python3) rather than the system version of python. This should avoid the requirement to activate the venv. I prefer this solution as it means when a user stops the console, they don’t also have to deactivate the venv in order to get back to their system python.
Experimentally I’d say yes it’s needed for my scenario if you follow the exact steps I indicated.
I also agree with the rest of your commentary.
Remember, I’m trying to go straight to the venv future to-be without altering my os with the current ‘install modules to the os trees’ old way that main uses.
My guess is there’s something in your switch to beta flow that is either skipping something or clearing something out, but my memory is a little hazy there. Let me instrument my local copy of the script and see if I can get you some diagnostics to figure out where it’s happening…
