meteohub.de

Hi Boris,
this is the umpteenth (and hopefully final) request from many forum users for straightening out the naming of the three sensor values provided by a Ecowitt WH57 lightning sensor.
(By the way - that's not meant as criticism, but as a proposal for a constructive solution of the issue. )

There are many posts in the forum which have this imo wrong naming and assignment for reason.

I am aware of the fact that the API documentation has been in a bad shape with English/Chinese mix-ups etc. - but it should be meanwhile clear what each sensor value means - and I find this should now also be updated in Meteobridge.
(by the way: other programs like weewx and CumulusMX have come to a proper and reasonable naming).

I suggest the renaming in the min/max history as shown in the picture attached. If "number of days w/ lightning strikes" is too long,
it could also be "days with lightning strikes"

Also your naming is wrong regarding the content
- what you call "number of lightning strikes" is the "number of lightning strikes per day" i.e. on that day when the strikes occurred
so calling it total (lgt0total), is misleading; total,yes, but only total at that day
having the sensor name lgt0total is in my opinion wrong - it would be your lgt0energy but imo better named lgt0day.

- what you call "lightning energy" is the number of strikes per period (day, month, year, all time); that would deserve the sensor name lgt0total

simply speaking in a nutshell: you have to switch lgt0energy and lgt0total ! - And use fitting text - proposal in the picture

The version 1.6 documentation for the GW1000 states: I just tried a google translate of 0x62 "当天雷电次数" and this translates to "the number of lightning". Ok, now I understand that this documentation is meant to be read in Chinese as the English version seems to be random in parts

Please give just released version a try. It is expected to report distance and lightning count. As before data is only logged, when a lightning occurs.

Mmmh - the test of RPi2230 is not very encouraging (yet) ... see below from the min/max table 1. # of lightning today was 3, shown is zero (today), the counts haven't been updated (see earlier picture)
2. distance is correct (has always been correct)
3. total number of strikes is completely missing now (your sensor lgt0!0total, lgt0total is the # of days with strikes per period)

the numbers allow only one interpretation, as there cannot be 53 strikes in total but on 499 days =>
it has to be 499 strikes in total on 53 days (before the event)
(unless my strike number has been messed up in the past in the database, but I didn't touch it)

expectation (and imo correct display) would be


number of lightning strikes (today): 3, month 4 (1+3), year 22 (19 + 3), all time 502 (499 + 3)
distance is correct anyway
number of days with lightning (today): 1, month 3 (2 + 1), year 20 (19 + 1), all time 54 (53 + 1)

But it doesn't show that.

What confuses me in addition is lightning distance and the total count (earlier picture), where in the year it say 8 km / 1 (one above the other) and 37 km / 12 - should this be the number of strikes of the extreme values ? out of the yearly strikes 1 was at 8 km distance and 12 were at 37 km distance ? That would explain the strange numbers. (the same with the all time numbers, one event at 1 km distance and 499 events at 40 km distance - but how does this relate to the number 53 ??) - but I'm not sure if and how the numbers of the two lines are supposed to be interrelated.

EDIT: 17-Apr-2021-18:52
After some time, at least one hour, the min/max table now shows the strikes of today, even though one too few:

no more attachment per post accepted ...
the not updated MB Pro shows: if we go by the picture above,
- the first line should show "1", not "2" - it can only show 1 or 0, no other number (as it is days with strikes, 1 or 0)
- the distance is clear and ok
- the "energy", the occurrence per day, strikes per day is correct - there have been 3 strikes today

about the month and year column I am doubtful - it looks to me as if the "energy" line shows the min/max distance and its total occurrence in the period considered (where the all time value doesn't seem to make sense - looks as if two different things have been packed into one line)

If we want to show these min/max occurrences of the distance, we should add one more line - so altogether 4 lines:
(1) number of days with strikes in the respective period (today, month, year, all time)
(2) distance - min/max
(3) number of strikes of the min/max distance in the respective period
(4) total number of strikes in the respective period (today, month, year, all time)

in the above case this should be:

now        today      month        year          all
(1) --          1             2             20            54
(2) --      17/20km   17/24km    8/37km    1/40km
(3) --        2/1            2/3          1/12        1/499
(4) --        1/3            1/5          1/??         1/502 (or more, depending on the real all time total; 499 may only be the 40km #)

in my opinion (3) would be sort of luxury information (but would make it different from other software !), whereas (1), (2) and (4) should be there in any case, because they give important information.

(the ?? would need to be looked up and probably summed up from the database)
of course, depending on the time of looking at the table, let's say within the last 30 minutes, the now column would also have a value

I think that apart from a to-be-corrected counting of the days with strikes, (3) and (4) have been packed into one line and that's pretty much of a mess.

Maybe I don't understand the full logic myself - I'm open to a better explanation - and its proper depiction

Now, one day later, MB has made some adjustments to the numbers - looks like the table update occurs delayed (after midnight ?) Still, the numbers are not consistent (count of 2 instead of 3 or 2 instead of 1, depending on the meaning).
Even if that line (# of strikes) is supposed to be the total # of strikes.

Imo there have to be (at least) 3 lines - (1), (2), (4) from the suggestion above (earlier post) - even though four (i.e. plus (3)) would make it all clear and give additional high/low information (with the proper labeling).

So, if
- today's (= FW 14363) "number of lightning strikes" is the number of days with strikes (and counts only up 1 per day) - days with strikes is important information
- lightning distance remains, showing the distance of the last strike but adds to the min/max for month, year, all
- lightning "energy" is the total number of strikes per period (that's important information) - and "energy" is relabeled to "total"
we are already set.

If we want to be completely correct, also with min/max info, we can add one more line without a label (i.e. belonging to the line above = distance) under the distance there showing the occurrences of the distance min/max, we would imo be perfect.

The way it is now set up with update RPi 2230, 17-Apr-2021, at least the monthly counting is incorrect.

(# = number)

Summary (to-do list):
- we have to be clear on the meaning (and proper labeling) of the lines (and which sensor they represent)
- the content shown should be
(a) number of days with strikes (per period),
(b) distance of strike, shown should be only the last one at the day of occurrence, later on the min/max of period (month, year, all), [showing the occurrence per period of the min/max distance values under them or in parentheses in the same line would be nice]
(c) total number of strikes (today, month, year, all)
(d) showing the full time stamp of the last occurrence with distance (similar to what is seen in the raw live data)
if the raw live data showed the exact information = time stamp permanently (the hours since shown there today are cumbersome, and the info disappears after some time), it could be only there and would then not be needed in the min/max info - but some little redundancy here and there make it better readable

By changing the meaning of 0x62 tagged information the data for number of strikes of the past is rendered garbage. I would recommend to delete that and start with a fresh reporting.

Regarding the additional ideas.
a) "number of days with strikes" is not computed by Meteobridge and this is also not provided from the GW1000. Therefore, this data is not available.
b) distance is handled as every other scalar value in Meteobridge. "lgt0distance-lastval" might work in templates.
c) number of strikes should be handled correctly now (for fresh data). If not, I have to further inspect on that point.
d) should be there as "lgt0distance-nonzerotime" in templates.

I am aware that lightning data is different from temperature etc and that it might be nice to have a slightly different view on this and other kinds of requests. But I am reluctant to redesign how to handle data in Meteobridge and go though all the cycles of debugging just to please this rather special edge case.

admin wrote: ↑Sun Apr 18, 2021 11:46 am By changing the meaning of 0x62 tagged information the data for number of strikes of the past is rendered garbage. I would recommend to delete that and start with a fresh reporting.

Regarding the additional ideas.
a) "number of days with strikes" is not computed by Meteobridge and this is also not provided from the GW1000. Therefore, this data is not available.
b) distance is handled as every other scalar value in Meteobridge. "lgt0distance-lastval" might work in templates.
c) number of strikes should be handled correctly now (for fresh data). If not, I have to further inspect on that point.
d) should be there as "lgt0distance-nonzerotime" in templates.

I am aware that lightning data is different from temperature[/color] etc and that it might be nice to have a slightly different view on this and other kinds of requests. But I am reluctant to redesign how to handle data in Meteobridge and go though all the cycles of debugging just to please this rather special edge case.

regarding 0x62: when I look at the lightning data in my databases (3 DBs), its all a mess and therefore garbage anyway. I tried to make sense of the table entry values - but there isn't - at least not consistently - for some short period it seems to be, but then it changes again, 4-5 such leaps within the past year... - so I will probably delete all these entries and start from new, hoping it'll be more consistent from now on


regarding a) - that would cost a few lines of code with 1 or 2 SQL statements, true (tried it out) - but it's very useful information to know on how many days of a period there were thunderstorms - even in a way more interesting than knowing the total number of strikes per period

regarding d) - sure that this is possible, but cumbersome to look up each time - but to see it in dashboard view is something different - and the time stamp is permanently provided by the GW1000 until its reboot - just replace the hours by the time stamp (or add the time stamp to the line text - replace the text "energy 0" by the timestamp) wouldn't be much effort but generate added value.
If it doesn't provide a time stamp because of a reboot, write "unknown".

Of course, if the info appeared in the linked W34 dashboard, this discussion would not be needed - but it doesn't - so the only thing sensibly serving as a dashboard is the live data page

lightning data (in the min/max view) in its most trivial form is just like rain, totals per period - but rain is also visible where/when there is no rain and doesn't disappear from view - so why would lightning data only be visible the day of occurrence and maybe 1-2 more days after the last strike occurred and then disappear ?

And regarding the "special edge case" - don't underestimate the number of GW1000/WH2650 users who are going for a WH57; they are growing day by day - much faster than Davis owners. The low cost of a GW1000 is an incentive for getting a WH57 which otherwise with other non-FO brands would be pretty expensive.

Heck I’d like it just so I can see my lightning sensor.
And I totally agree these sensors are very interesting and with MB feeding data it makes data collection and or upload to our websites an important feature.