btw, I’m not sure if it is the average distance, unless you average something yourself. The chip itself reports the distance to the nearest strike (basically the front of the storm, if the storm is approaching), so it is just the distance of that reported strike, not the average.
The “average” header came from “Lightning Strike Avg Distance” in the WeatherFlow docs for each of the APIs - but certainly not in the chipset doc you linked. I appreciate both the link and help for sure @sunny. I’m sure I’m probably reinventing the wheel here - but trying to visualize rain/lightning over time and having negative and positive numbers on an energy field seems strange without any unit of measurement. May just hide it until I can get more data loaded to see any trends. (Energy happens to be one of the metrics that isn’t available historically…)
The energy is stored as a 2 byte number. I don’t know if it is a signed number or should be interpreted always as positive. The number you get for Savannah crossing, is much bigger than the max 2 byte value (65535). That might be a bug in the implementation.
I just realized that as the chip reports the distance to the nearest strikes, it might be that weatherflow takes the one minute average of those. So it might be correct anyway.
When using the websockets API, this is what I get for evt_strike (evt)
“evt”: [1658169253, 14, 3994, 1]
Anyone know what the additional “1” is at the end? It is not documented in the API documentation.
There also is a “source : enhanced” field which is not documented. I assume that since the data is coming from the weatherflow server and not directly from the Tempest (as in the UDP feed), this indicates that the data is QC’d (validated against other stations in the area). Can anyone confirm this?