FWIW the strike_last_epoch value decodes to a reasonable value…
pi@pi4:~$ date -d @1725496830
Wed 04 Sep 2024 05:40:30 PM PDT
1 Like
On WeatherFlowPiConsole, the Epoch values are only 7 digits long.
On Weather Display, the Epoch full value (10 digits long) is received…
UDP Events As Received by WeatherFlowPiConsole:
{‘serial_number’: ‘ST-00152207’, ‘type’: ‘evt_strike’, ‘hub_sn’: ‘HB-00158637’, ‘evt’: [1725653, 17, 570]}
{‘serial_number’: ‘ST-00152207’, ‘type’: ‘evt_strike’, ‘hub_sn’: ‘HB-00158637’, ‘evt’: [1725653, 17, 570]}
{‘serial_number’: ‘ST-00152207’, ‘type’: ‘evt_strike’, ‘hub_sn’: ‘HB-00158637’, ‘evt’: [1725653, 17, 570]}
UDP Events As Received by Weather Display:
{“serial_number”: “ST-00152207”, “type”: “evt_strike”, “hub_sn”: “HB-00158637”, “evt”: [1725653632, 35, -138, 1], “source”: “enhanced”, “device_id”: 357406}
{“serial_number”: “ST-00152207”, “type”: “evt_strike”, “hub_sn”: “HB-00158637”, “evt”: [1725653698, 38, -175, 1], “source”: “enhanced”, “device_id”: 357406}
{“serial_number”: “ST-00152207”, “type”: “evt_strike”, “hub_sn”: “HB-00158637”, “evt”: [1725653856, 41, -151, 1], “source”: “enhanced”, “device_id”: 357406}
Looks like we are getting somewhere! The truncated numbers are definitely the cause of the issue.
It’s worth noting that the ‘UDP’ messages you shared from Weather Display are not UDP messages. You can tell because they contain the device_id and the source is given as enhanced, which I’ve always read to mean that the event has originated from the lightning algorithms run on the Tempest servers. These messages must be originating from a websocket connection.
With this is mind, the issue must be related to a bug in the hub that is truncating the epoch value, rather than a bug in the console (which just reacts to whatever it is receiving). I think you need to raise a ticket with WF support to share the bug. I’ll also tag @eric here who may be able to help escalate to the right team
1 Like
I am going to see what @eric can do first.
I have not had much success with Tempest Support.
Past experience - I seem to get someone elsewhere in the world
that triages me with obvious basics - does not understand what I am explaining - and then never resolves the issue…
I gave up on my other older air/sky station and just started over with a new Tempest
Hoping things would be better.
Thank You @peter and @vinceskahan for helping find what is happening here.
trying to understand before calling Corrine in.
please tell me if wrong, this is related to lightning strike data
- UDP messages from the UDP only have 7 digits in the epoch
- Messages coming from the server are 10 digits in the epoch
Is this what you see ?
Yes, that sums it up perfectly.
I just grabbed on one of my devices (purple hub with a normal Tempest) and got the raw data via node-red
I have only 1 epoch part for the full set of data each time and it is 10 digits long.
@peter : the line I see above from your code is the one after you split the data ?
Can’t test more regarding lightning since there is none around in reach of the Tempest sensor
Hi @eric, the data @lenny shared is the raw UDP packets before they are split by the console. The issue is likely restricted to only evt_strike packets. There is no evidence that it affects other types of packet (as you have seen). I suspect there is some bug in the hub that is truncating the epoch for just evt_strike packets
right, since it is hub related let’s first call @rderr since that is his playground.
I can’t test since there are no strikes nearby 
2 Likes