That screenshot is misleading - as the lightning occurrence is from yesterday - and one day after the lightning event(s) only the date/time of the last occurrence is shown. "0" is correct here but it's "0" for the current day and not for the day of the lightning event. On Ecowitt.net (and in the GW1000) the past counts are not maintained in the current view. Only the distance and time/date of the last occurrence. The real values of the day in question you can see in the history of that day in Ecowitt.net (graph or table).
But MB showing a "0" count on the day of a lightning event when only one strike occurs - or at least until another is recorded that day is not correct. When 2 strikes have occurred, the MB count in the min/max history is "1" instead of "2" etc. From there I guess the lost strike
(real count - 1) comes. MB sees, reports the 1st strike correct with distance and time since occurrence in the raw live data, but as count "0" in min/max history. Therefore the numbers differ from ecowitt.net or from a HP2551 console (or a template which is fed by a GW1000 or a HP2551 console) by one (1).
This has been my observation since long ...
(and has been reported here in the forum since long).
All other "complaints" have meanwhile finally been removed (software corrected), but the wrong counting and depicting of the last occurrence still remains.
One has to properly understand the meaning of the observations/sensor values and the behaviour of the GW1000 console.
Three values are important: strike count of the day, distance for each strike, and the date/time and distance of the last occurrence (at the day of occurrence and continuing until the next strike occurs, even after one month or later). And of course summary values and min/max of distance.
The raw live data should simply show the time stamp (showing time since in minutes/hours is not helpful and not what the user expects) and the distance of the last occurrence until the next strike (whenever) occurs.
Until now, the live data disappear after some time (haven't figured out the time yet).
It would be good to save this last occurrence - either separately or retrieve it from the database - locally as the GW1000, which usually keeps on sending this data, "forgets" them after a reset or a firmware update, which is a bit of an annoyance.
@Boris: I have been offering my infrastructure for testing already earlier. I can provide a "spare" MB Pro and a "spare" GW1000 and device access for testing. And of course a WH57/DP60 lightning sensor where we can create fake strikes with. I can deactivate the WH57 sensor receptions in/from the other GW1000/HP2551 to avoid false data entering the database.
The offer is still valid.
(in English the use of present perfect tense means that something has started in the past and hasn't ended yet in the present
)
