I have no idea what to tell you, other than to try (a) disabling weewx from running and (b) rebooting your pi to clear everything running out. At least at that point you’d know you have a clean system to start with.
share_socket = False Whether or not the UDP socket should be shared with other local programs also listening for WeatherFlow packets. Default is False because I suspect that some obscure Python implementation will have problems sharing the socket. Feel free to set it to True if you have other apps running on your weewx host listening for WF UDP packets.
DOH - of course. I thought the default was True. Go figure. Thanks !!!
switched it to True .
nohup python /home/pi/wf/listen.py --decoded --limit=‘rapid_wind’ > /tmp/wf.log 2>&1 &
checked the log and got this:
nohup: ignoring input
sudo python /home/pi/wf/listen.py --decode
it started to populate all the data.
Thank You both for all your help! I truly do appreciate it. I started reading up on the introduction to linux.
Remember, you wanted to see evt_strike there, so you probably want to kill the process and restart it using evt_strike instead especially if you get strikes often.
Your first command backgrounded the listener looking for wind only. Your second command is looking for everything in the foreground, but it’ll exit when you close your shell or log out. So you have two copies running (plus weewx) but you’re not saving evt_strike data to the file in /tmp.
how do I kill the process?
Google is my friend . I was able to kill the process and set it to lightning strikes .
it’a a miracle I say, a miracle !!!
(I’m kidding I’m kidding)
Glad to say you have something working. Go do the edx.org class to spin up on Linux a bit and you’ll be all set !
Sorry to resurrect a thread from the dead, but @ronselljr, did you ever get this working?
Thanks to the driver @vreihen wrote, I was successful in getting a Tempest setup in WeeWX over the past few days. I’m still working on wrapping my head around how WeeWX works and trying to understand the best way to record data from the lightning sensor. It looks like WeeWX’s default schema in 4.x includes fields appropriate for distance (lightning_distance) and count (lightning_strike_count).
Is it as simple as just setting these fields up to pull the strike and distance from evt_strike?
lightning_strike_count = distance.ST-00000025.evt_strike
lightning_distance = energy.ST-00000025.evt_strike
yup - all you’re doing is telling weewx which database element to map which data coming in to.
You have distance and energy swapped. Also, don’t forget to use a StdCalculate adjustment to “coerce” the energy observation (that WeeWX apparently can’t store) into the number 1 (since evt_strike doesn’t have a count and should apparently always be 1). Here’s my note from above on the whole StdCalibrate setup:
If you just want per-minute summary info and not instantaneous packets, you might want to map to the obs_air (Air) or obs_st (Tempest) since they contain a strike count and average distance. Remember, the whole reason for the sensor_map scheme is to give each person an easy, no-coding choice for what from WF to map where in WeeWX!
If WeeWX 4.x now has the lightning schema and it works, I’ll update the sample sensor_map and instructions to reflect this…
It doesn’t count each strike. I had to add some code to do this.
I’ll send to you later.
Thanks for noting the mixup, @vreihen . I hadn’t had my second cup of coffee yet this morning, so I’ll blame it on that. I’ll give this a try this afternoon. I checked and the lightning tables are definitely in the sqlite database, so that’s one less thing to do.
@ronselljr, I’d definitely appreciate seeing how you approached this. I’ll have to put some thought into what exactly I’d like to do with this data and figure out the best way to capture it.
I also need to troubleshoot an occasional missed packet that I’m seeing in my setup. I’d love to blame the Raspberry Pi (4) that I’m running this on, so I can justify buying a NUC for it, but in reality, I think the hub is jumping between our two access points. I thought to check the logs for the missed packet this morning and see that it jumped between AP’s around the same time.
It’s the raspi. You need to buy a NUC.
FWIW, make sure your pi is wired and things get much more stable on that end, but it’s certainly possible the hub is missing emitting packets. Man I wish we could (a) wire or (b) go 5GHz in the hubs. Being on 2.4 GHz is just chaos around here due to misconfigured neighbors.
You might use the aggregation in weewx skins to handle this. Maybe ask on the weewx google groups. I’m sure other stations have similar counting sensors.
You always have the option of relocating “here” to an RF-quieter location. Having thousands of acres of woods as my neighbors is also great for getting to the top of the Blitzortung most-used station report…
Yeah, that’s another reason for the NUC. The pi is serving double duty as a display console in the kitchen, so there is no way to wire it up there. I can just throw a NUC down in the basement with our Ubiquiti network gear. Thankfully, the RF environment is relatively empty here. I’ve had the hub sitting in our living room since I set it up, so I’ll try throwing it in the basement where it should only see the downstairs AP and see if it clears up that problem.
lightningYYY = distance.AR-00015732.evt_strike
lightningZZZ = energy.AR-00015732.evt_strike
lightningZZZ = lightningZZZ - lightningZZZ + 1
I used energy map to count each strike. Because I figured each energy packet was unique.
Its hard to test because I cannot trip the lightning sensor. But sometimes it is off when I check it off of the weatherflow app.
So I’m going to try loading this data into two of the fields that are present in the new schema in WeeWX 4.
lightning_distance = distance.ST-00002742.evt_strike lightning_strike_count = energy.ST-00002742.evt_strike [StdCalibrate] [[Corrections]] lightning_strike_count = lightning_strike_count + 1
Now correct me if I’m wrong, but I think I can skip the [StdCalibrate] directive above and just deal with this using accumulators, since lightning_strike_count should always be a non-null energy value. So, count the non-null lightning_strike_count packets seen in the archive interval and average the lightning_distance (which is the default accumulator behavior, so I shouldn’t need to specify this one…).
[Accumulator] [[lightning_strike_count]] extractor = count [[lightning_distance]] extractor = avg
Suggest you ask these kind of detailed things on the weewx google groups, so you get to the core developers who almost always answer promptly…