Thanks - I’ll fix my sensor map for sure, didn’t know what the Tempest values were, so that’s helpful and def saves me some time, so I appreciate it. But my problem is something else. Even when I turn on Log Raw Packets, I get the Errno 49 Can’t assign requested address problem.
It is most likely a problem with text indenting in weewx.conf, or perhaps the entire [WeatherFlowUDP] not being at the end of the file and mixed somewhere in the middle.
There is a sample Tempest sensor_map in Github:
I didn’t see a mention of what platform you are trying to run WeeWX on, but this description of udp_address from the readme file may be useful if it isn’t a Raspberry Pi or Debian-derived Linux:
udp_address = <broadcast>
# udp_address = 0.0.0.0
# udp_address = 255.255.255.255
This is the broadcast address that we should be listening
on for packets. If the driver throws an error on start,
try one of the other commented-out options (in order).
This seems to be platform-specific. All three work on
Debian Linux and my Raspberry Pi, but only 0.0.0.0 works
on my Macbook running OS-X or MacOS. Don't ask about
Windows, since I don't have a test platform to see
if it will even work.
I don’t know how tolerant Linux Python is to files edited with a Windows text editor, but I can’t count how many times I’ve seen Windows’ different line terminators have invisibly messed up text files on Unix/Linux over the years.
naaaah - weewx doesn’t care about indenting in weewx.conf, nor does it care about where in the file the station’s block is.
I don’t recall if it cares about Windows vs. unix end of line, but running weewx.conf through ‘dos2unix’ might be worth trying. I’ve seen that kind of craziness elsewhere too many times.
The posted weewx.conf looks ok to me at quick glance, once they substitute in the right ID for their tempest etc. of course. Perhaps try running my udp listener in --raw --decoded mode to see what’s going over the wire(less). If my listener also doesn’t work, it’s something in the pi setup.
Wow, I’m dumb, thanks for that @vreihen. Right in the ReadMe, of course. I’m using MacOS so needed to set udp_address = 0.0.0.0 not broadcast. Thanks so much!! (facepalm)
Funny story. Back when I was in college and dinosaurs roamed the Earth, professors from the Technical Writing department made several pitches to have me change majors from Computer Science (CS) to Technical Writing. One of my English professors tipped them off that I was a top-tier CS major who could also write well, and apparently finding a computer geek who could write was like finding a unicorn or something at the time. Long story short, I told them that I would rather make things that people actually use as a CS major than write something that absolutely nobody will ever read as a Technical Writing major!
As the person who wrote both the station driver and readme file, I want to thank you for reaffirming that I picked the correct major way back then…
One more question for you experts. I’m happy with where I’ve gotten WeeWx for a few hours of tinkering today. Thank you all for all your awesome help in this forum! (Also got a rudimentary version of the Belchertown skin going!)
Anyway, wanted to run my sensor map for my Tempest past you all to see if it looks right to you all or if I’ve missed anything good that you all might do differently. Def made it easier that v4.1.1 already had lightning in the schema, although I had to use soilMoist4 for the one missing.
I see a lot of sensor maps using the wind info from rapid_wind. Is that just because it’s more frequent observed vs the wind data in obs_st? And then does WeeWx average it when it records into the database every 5 mins? Edit: Answered this one myself by reading the technical docs. The archive routine will average (or sum or max) various values from the LOOP data when it writes the archive, so better to get the rapid wind data. (I’ll assume that it’s probably better to ignore the wind_gust from the obs data and let WeeWx calculate it, since in theory the same data should be included in the rapid wind data packets as well. Anyone test this?)
I’ve been experimenting recently with weewx, @vreihen’s UDP driver, and the Belchertown skin with MQTT enabled. I think I am slowly understanding how everything works, but I can’t work out why the “Feels Like” temperature reported in the Belchertown skin (which I think is the Heat Index) via MQTT is always higher than the “Feels Like” temperature defined by the Heat Index in the Tempest App. Does anyone know why there is a difference, or can you point me in the direction of the right websites to read?
I guess my question did beg for a simple answer! I have read through much of the documentation and from what I can see the Weewx “Feels Like” is derived the same as the WF “Feels Like”. I think I need to dig more through the Belchertown source to see exactly what is going on.
What you need to do is figure out if Pat is calculating something custom or if he’s just picking an element that weewx calculated and stored on the db. Shouldn’t be too hard to do some ‘grep -Ri’ for the word ‘feels’ to figure it out.
Hey guys, I got mine all up and running. And @jamesbellanca good job man, I am a server and network engineer and this took me a bit to get figured out how everything works.
I am using the Tempest and noticed something flawed on mine and was wondering if you guys have as well. I know its not a driver or weewx issue.
So check this out… My pressure is reporting correctly in the WeatherFlow and Weather Underground apps. Its sitting about 29.62 right now which is about right on. Oddly though… my UDP packet reports it waaay lower down at 26. So from wireshark I see that it is reporting in MB. Mine is 913.44 and if I divide that by 33.864 like we are supposed to I get 26.92.
The pressure reported in the UDP data is the raw station pressure. This will always be lower than the pressure reported in the app/weather underground/weewx, as they’ll be reporting the pressure corrected for your station’s altitude.
@peter Man, , That makes sense, I finally figured out the issue. Looks like my altitude on weewx was not set correctly ha. Ok… well… thats embarrassing. Thanks peter. That fixed my issue.
I’ve installed WeeWX on a Raspberry Pi. I’ve also installed Apache and when configuring WeeWX with the Simulator driver, I’m able to see the WeeWX webpage with the sample data.
I’ve also installed the WeatherFlow UDP driver. I’ve reconfigured WeeWX to use that driver however, I don’t see the HTML pages being recreated when using the UDP driver (http://IP/weewx). I’ve enabled log_raw_packets = True and I do see the packets being captured when looking at the syslog.
Any tips to help me figure out why the HTML pages are not being re-created when using the UDP driver?
Did you restart WeeWX after editing the config file? Did you check the web pages at least 10 minutes after restarting WeeWX? They are only rebuilt every 5 minutes…
I’m happy with where I’ve gotten WeeWx for a few hours of tinkering today. Thank you all for all your awesome help in this forum! (Also got a rudimentary version of the Belchertown skin going!)
, That makes sense, I finally figured out the issue. Looks like my altitude on weewx was not set correctly ha. Ok… well… thats embarrassing. Thanks peter. That fixed my issue.