Set debug=1 in weewx.conf and restart weewx, then check your syslog for details when (if) it happens again.
Okay, done. I’ll report back if anything happens.
Okay, here’s a crash from yesterday. weewx had been running for about three weeks proir without any issues.
2018-07-27 06:05:17.955210-0700 0x339 Default 0x0 110 Python: (syslog.so) **** File “/Users/Shared/weewx/bin/weewx/engine.py”, line 871, in main
2018-07-27 06:05:17.955250-0700 0x339 Default 0x0 110 Python: (syslog.so) **** File “/Users/Shared/weewx/bin/weewx/engine.py”, line 187, in run
2018-07-27 06:05:17.955291-0700 0x339 Default 0x0 110 Python: (syslog.so) **** File “/Users/Shared/weewx/bin/user/weatherflowudp.py”, line 284, in genLoopPackets
I restarted and things are good. This is on a macOS Sierra machine.
That’s odd. Line 284 in the current code is the socket bind before it starts generating loop packets. Did it fail as you were restarting the software, or in the middle of running?
I was under the impression that weewx only called GenLoopPackets once, and am trying to understand why it would be opening the socket a second time…
1 Like
It had been running for about three weeks, uninterrupted. I hadn’t touched the machine, and I’m not aware of any network interruptions, though that could have happened.
Looks like I had the exact same crash again yesterday:
2018-08-02 15:55:17.943241-0700 0xcfb4cd Default 0x0 85218 Python: (syslog.so) **** File “/Users/Shared/weewx/bin/weewx/engine.py”, line 871, in main
2018-08-02 15:55:17.943271-0700 0xcfb4cd Default 0x0 85218 Python: (syslog.so) **** File “/Users/Shared/weewx/bin/weewx/engine.py”, line 187, in run
2018-08-02 15:55:17.943302-0700 0xcfb4cd Default 0x0 85218 Python: (syslog.so) **** File “/Users/Shared/weewx/bin/user/weatherflowudp.py”, line 284, in genLoopPackets
I don’t know of anything happening with the network or with WeatherFlow. I gave it a bounce this morning and it’s good to go.
I’ll dig into it over the weekend…
1 Like
Hey weewx users - set your weewx.conf to register your station ‘and’ remember to set a unique station_url so the registration has a key for their database (even if you make one up).
Looks like I’m the first to do so, there is now ‘one’ station showing as WeatherFlowUDP in the map !
2 Likes
Thanks, did that. There’s at least one more now.
1 Like
Hi @eric how do you push the data from weewx with the udp grabber from @vreihen captain coredump to meteotemplate ? I just got the default skin running on my raspi2 but I want to use the data for my hosted meteotemplate.
Thanks in advance
Here’s Matthew Wall’s Meteotemplate uploader for weewx:
https://github.com/matthewwall/weewx-meteotemplate
If you want to feed multiple Meteotemplate sites, I imagine that you could make a copy of the above into a second filename, and then edit the class names and weewx.conf settings to make it a different name for the second feed…
2 Likes
Thanks for that @vreihen will try to install
Yep done (had to use sudo for install the extension) thank you very much
1 Like
I’m missing a value Windgust
[[sensor_map]]
outTemp = air_temperature.AR-00004444.obs_air
outHumidity = relative_humidity.AR-00004444.obs_air
pressure = station_pressure.AR-00004444.obs_air
# lightning_strikes = lightning_strike_count.AR-00004444.obs_air
# avg_distance = lightning_strike_avg_distance.AR-00004444.obs_air
outTempBatteryStatus = battery.AR-00004444.obs_air
windSpeed = wind_speed.SK-00001234.rapid_wind
windDir = wind_direction.SK-00001234.rapid_wind
# lux = illuminance.SK-00001234.obs_sky
UV = uv.SK-00001234.obs_sky
rain = rain_accumulated.SK-00001234.obs_sky
windBatteryStatus = battery.SK-00001234.obs_sky
radiation = solar_radiation.SK-00001234.obs_sky
# lightningYYY = distance.AR-00004444.evt_strike
# lightningZZZ = energy.AR-00004444.evt_strike
The value isn’t displayed in meteotemplate , any clues ? no ide why this is bold text 
An interesting article:
https://github.com/weewx/weewx/wiki/windgust
Since the UDP driver is offering wind_gust from the per-minute obs_sky packets, this should fill in the value in weewx (I haven’t tested it):
windGust = wind_gust.SK-########.obs_sky
Note that WF is not providing anything to populate windGustDir…
2 Likes
Yes I know there are different implementations for windgust anyway thanks for the article, I ll try the code tomorrow thanks !
actually it ‘does’ if you check out rapid_wind near the top of WeatherFlow Smart Weather UDP Reference - v94
I’ve been using this since day one…
windSpeed = wind_speed.SK-000NNNNN.rapid_wind
windDir = wind_direction.SK-000NNNNN.rapid_wind
I view rapid_wind as the gust measurement (almost - I think I read someplace that a gust is a 3-second duration high speed, not a ‘measure every 3 seconds’ instantaneous measurement).
We already know ‘wind’ as WF uses the term is the average of all the 3-second readings (assuming you’re not in battery saving mode of course), and I’m thinking wind_direction is the average of all the wind readings.
If you look at weewx’s vantage.py driver, just to use the one matching my VP2, looks like Tom took the same approach…
def new_loop_packet(self, event):
"""Calculate the max gust seen since the last archive record."""
# Calculate the max gust seen since the start of this archive record
# and put it in the packet.
windSpeed = event.packet.get('windSpeed')
windDir = event.packet.get('windDir')
if windSpeed is not None and windSpeed > self.max_loop_gust:
self.max_loop_gust = windSpeed
self.max_loop_gustdir = windDir
event.packet['windGust'] = self.max_loop_gust
event.packet['windGustDir'] = self.max_loop_gustdir
1 Like
From the weewx page above, they have four wind variables:
The wind-related fields in the weeWX database include:
windSpeedwindDirwindGustwindGustDir<=======
The WF UDP obs_sky packet does not contain an equivalent for windGustDir:
Observation (Sky) [type = obs_sky]
{
"serial_number": "SK-00008453",
"type":"obs_sky",
"hub_sn": "HB-00000001",
"obs":[[1493321340,9000,10,0.0,2.6,4.6,7.4,187,3.12,1,130,null,0,3]],
"firmware_revision": 29
}
Observation Value Layout
| Index | Field | Units |
|---|---|---|
| 0 | Time Epoch | Seconds |
| 1 | Illuminance | Lux |
| 2 | UV | Index |
| 3 | Rain Accumulated | mm |
| 4 | Wind Lull (minimum 3 second sample) | m/s |
| 5 | Wind Avg (average over report interval) | m/s |
| 6 | Wind Gust (maximum 3 second sample) | m/s |
| 7 | Wind Direction | Degrees |
| 8 | Battery | Volts |
| 9 | Report Interval | Minutes |
| 10 | Solar Radiation | W/m^2 |
| 11 | Local Day Rain Accumulation | mm |
| 12 | Precipitation Type | 0 = none, 1 = rain, 2 = hail |
| 13 | Wind Sample Interval | seconds |
I stand by my original statement that WF does not send a windGustDir value to use alongside windGust in the per-minute obs_sky packets. (Which “Wind Direction” being reported in index 7 and how it relates to index 4-6 is not very clear, but that’s another story.)
FWIW, as you pointed out, the provided sensor_map example uses rapid_wind for all wind measurements, and intentionally ignores wind data in obs_sky…
2 Likes
Agree. It’s not in obs_sky although the speed part is there, as you mentioned. It would be nice if it could be there some day so app developers wouldn’t have to do the heavy lifting N times in parallel apps.
To fake it currently your driver would need to be enhanced to grab the direction of the max windspeed in the rapid_wind observations that came in during that 60-second obs_sky period and add it as a calculated observation element, like the vantage driver snippet I posted does.
I seem to recall seeing a web page listing the things WF calculates on their end from the observations, but I can’t find that page currently in a quick search. Same thing would apply for those things - if your driver wanted to match (or exceed) what the WF app displays, it would take some enhancements to the as-is weewx driver.
Given we’re all free (grateful) consumers of your driver, that’s really up to the author unless you wanted some pull requests from the user base. Maybe add an ‘issues’ thing to your github page for the driver where people could put in feature requests ? Really comes down to how much you want to tweak the driver moving forward in time…
[edit - found the derived metrics page here courtesy of a different thread]
2 Likes
Is anything (but MeteoTemplate’s uploader) actually broken because windGust and/or windGustDir are missing?
The link that I provided above to weewx’s windGust discussion page says that not all stations report windGustDir, even if they do report windGust. WF is technically not doing anything out of the ordinary by not reporting it.
Inside the weewx developer’s camp, they even seem to be split. Here is Matthew Wall’s SDR driver output from my Acu-Rite 5-in-1, which apparently does not report windGustDir:
Here’s Tom’s Vantage driver and my weewx UDP driver, which are apparently filling in the direction from somewhere:
(Are these even being populated from windGust/windGustDir data, or max/min queries from the loop packets? Hmmm…)
Tom’s Vantage code above seems to go against my understanding of the weewx philosophy, per their own published guidelines:
http://weewx.com/docs/customizing.htm#General_guidelines
General guidelines
- The driver should emit data as it receives it from the hardware (no caching).
- The driver should emit only data it receives from the hardware (no “filling in the gaps”).
- The driver should not modify the data unless the modification is directly related to the hardware ( e.g. , decoding a hardware-specific sensor value).
- If the hardware flags “bad data”, then the driver should emit a null value for that datum (Python None).
- The driver should not calculate any derived variables (such as dewpoint). The service StdWXService will do that.
- However, if the hardware emits a derived variable, then the driver should emit it.
If there is a compelling reason to populate the gust data, then it isn’t exactly rocket science to capture the max data from each rapid_wind packet and clear the counters when obs_sky arrives. Of course, I would make it a weewx.conf setting, since it goes against the above guidelines if I read them correctly.
In any case, I agree that the gust info should be mentioned in the driver’s docs…
2 Likes
I’ve not tried the windgust yet , but just looked up the defintion of windgust from the KNMI (Dutch weatherservice)
maximum gust of wind (gust):
This is meant the maximum wind speed in a certain period of time.
Operationally it concerns the highest recorded 3 " (3 seconds ?) average value
in a defined period of time10 minutes in m/s.
I’ve no idea how weatherflow calculates this I’ve never heard of windGustDir (should that be the direction where the gust come from…)
2 Likes