Ecowitt GW1000 + WH57 lightning detector still not properly handled by MB Pro/RPi - nonzerotime keeps disappearing

[Gyvate]

Never ending story ... (??)
There is still an issue with the WH57 lightning count and last strike time stamp.
There seem to be several events which trigger MB to forget the lightning data on RPi - I keep on reporting to Boris about the issue, but until now he doesn't seem to have figured out the reason.

1. one reason is a reboot - after a reboot the data disappears from min/max and the variable/selector [nonzerotime] provides an empty string even though
the data is still in the database
2. if only one strike occurs after the reboot, the strike count reappears, the last time stamp from before the reboot becomes available again, but the time stamp is still the time stamp of the last strike before that i.e. the time stamp which disappeared after the reboot.
MB records a strike count 0 (zero). The database records "--" ever since the new lightning occurred, before the history shows just an empty field. Only if a 2nd strike occurs, then the count will be one and the correct time stamp of that 2nd one becomes available as [nonzerotime] (e.g. [lgt0total-nonzerotime=epoch]) - but the total count is 1 and not 2 as it should be.
3. there seems to be also a time related cause for the disappearance - I'm still observing that
It happens with the RPi and the MB Pro.
It is interesting that in the non-database versions (repurposed routers - that what TP-Link refers to I assume) this doesn't or didn't appear. That may be a hint pointing at the database/software communication.

[jmontamat]

I confirm the Problem with RPI.

[Gyvate]

after ~20 days MB decided to forget nonzerotime again ....
I got it reawakened by a (one !) fake strike recorded as 0 (zero).
This time the time stamp was the one of the most recent one...
mystery over mystery ...
but two things are consistent
1. the 1st strike on a day is recorded as zero amount (which is wrong !, it should be 1)
2. once the strike line disappears from the Min/Max overview
a) nonzerotime provides only an empty string
b) it (nonzerotime and being shown in the Min/Max overview) needs to be (and gets) reactivated by a new strike

two things make the Min/Max lightning line disappear and nonzerotime to be forgotten (the data is still in the database !)
1. a reboot
2. a constant running period of ~20 days

[Gyvate]

The documentation of this last event - from my Meteotemplate database where MB posts (not only) the lightning data to.
Even though there was only one lightning strike, two different timestamps (nonzerotime) show up (5 minute window in the database).
The so far reported: 08-12-2021, the meanwhile occurred but ignored with count 0 from 30-12-2022 which reset nonzerotime to the earlier nonzerotime (as there was only one strike) and the new, latest one from 22-Jan-2022.

lgt0total provides a count of zero
lgt1!0total provides the right values - from a 2nd GW1000. There it seems to work and the data send to MT bring the proper value (which also disappears after a reboot or 20+ days), but with the strange two timestamps when nonzerotime gets "re-awakened".
The string used is L=[lgt1!0total-dmax.0:]&LD=[lgt1!0dist-lastval.0:77]&LT=[lgt1!0total-nonzerotime=epoch:].
But, obviously, the strike from the primary station is detected - the entry in the database switches from "--" to "0" ....
Something still fishy here ....
The count of zero for lgt0total was maintained in the database from 30-12-2022 until 18-01-2022, then "0" was replaced again by "--".
What is even more amazing is that the count for lgt0!1total switches from "--" to "0" in parallel when lgt0total switches from "0" to "--".
These data are from my RPi with two stations.
In parallel, one of my MBPros, with a different station/console, shows the same zero count.

MB-lightning-count-timestamp-nonzerotime6(GW2000)_20220122.jpg (16.23 KiB) Viewed 1600 times

This should now be sufficient information to make a deep dive into the program behaviour.
Access to my systems is available for Boris.

[Gyvate]

02-Feb-2022 between 04:30 and 04:35, the nonzerotime timestamp disappeared again - was no longer posted by MB to my Meteotemplate database.

lgt0total was already reset from count "0" on 28-Jan-2022 05:03 CET to "--".
Meaning: nonzerotime (which dated from 22-01-2022 22:04 CET*) was still available for almost five more days after the change in the database and then also disappeared. No reboot or any change of configuration in this time. MB now up for 35 days 15 hours ...

And this behaviour shows for both stations connected to the MB.
Could it be that the two GW1000 "forgot" the last strike after a mini-power outage and now MB also forgets ???
I have realized that in order to maintain the count, MB shows/queries the last strike continuously and it shows in the RAW realtime data ...
It looks to me that when it disappears, from the realtime data, nonzerotime** also disappears. That shouldn't be the case.
Something in the programming here has not been fully throught through to the end ....

(*That's when the lgt0total counter was set from "--" to "0" and my consoles recorded a proper lightning strike)
(**nonzerotime stands here short for [lgt0total-nonzerotime=epoch:])

My MBPro black which hasn't been rebooted either ever since the last lightning event, still shows the time stamp. The only difference between the two setups is that the GW2000 it is connected to still keeps its time stamp from the last strike.

[Gyvate]

one more strike today: same effect - count = 0 recorded; lgt0total-nonzerotime = time stamp of previous (NOT this !) event "re-instated"....
stop watch running again until the time stamp disappears again ... :