meteohub.de

I would like to report a problem with the data acquisition by the meteobridge of the Ecowitt wh57 / Froggit DP60 lightning sensor.
I believe that the total number of strikes is recorded on the variable for energy. It is possible to fix this bug !.
Also, why on "history" the sensor does not present the data on the time slot but only as a graph?

Hi
it's a known issue - Boris told me recently that he has other priorities right now, but it is somewhere on his "snag list".
I am behind that for a couple of months already - in fact ever since I got my WH57

The issues which I have noticed are:

a) proper naming ("energy" is a mis-translation from the original Chinese API description by the Chinese, but that's just a beauty thing)
b) the data recording is not consistent e.g. in the live data the lightning sensor shows while in the min/max history it gets fast lost
c) there must be a bug in the storage of the lightning data themselves - the lightning sensors are only selectable (I think) within a period of two days - that's while they are in the RAM database - afterwards the seem to get lost
d) and this may be a side-effect of c) - there are no records in my database since September 2020 even though there were more lightning events since then. No records means - not only not visible in the history but on the database level itself - no entries in the respective tables.

I guess the more people complain, the bigger the chance for the issue to climb up in the priority list.
You are number three or four that I am aware of.

Hello, I just purchased an Ecowitt station with a WH57 ray sensor, I have similar problems.

It does not detect the sensor until there is no beam and gives an estimate of distance but loses some numbers of beams.

Thank you.

Josep.

Platform: TL-MR3020 (no USB hub)
RAM: 29364 kB total, 3252 kB free (88% used)
SW Version: Meteobridge 5.1 (Jan 28 2021, build 14301), FW 1.4
Uptime: 0 hours, 23 minutes Buffer: 1 items (0%)

Hello again, once I have observed that it only refreshes the information when it detects lightning.

Thank you.

Currently, lightning strokes are only presented when there is a lightning stroke. Sounds reasonable, or not? If you insist on having data for non-events you can get around this by defaulting sensor evaluation to a value you like, when no stroke occurred. Not much of a drama, isn't it?

Thank you.
I do not have much practice in this type of sensors, I will have to get used to it.

But I continue to believe that the energy and strikes values ​​are reversed.

jmontamat wrote: ↑Sun Jan 31, 2021 10:46 am But I continue to believe that the energy and strikes values ​​are reversed.

Yes, that can be. The documentation was very inconsistent on this. I might have a look at the latest version.

Thanks Great job

The story is a bit more complex than that I fear.
Today I had three (3) lightning events. This is properly shown in the live data (assuming that energy means the number of strikes [per what time unit ?]) - of course, because this is what the GW1000 provides. Meteobridge hasn't done anything yet but pulling the data from the console. It will now remain in the live data for some time - but in the min/max, this is already a MB process result, they are going to disappear next day unless there's a new event until then.

BUT

in the data history there is nothing or strange entries (or only crosses in the mini graph) visible:
(in the database [not in the history view, in the table light0energy_hour] only one entry, value 1000 (probably because the field unit is strangely mm, and 1 x 0.001 = 1 - but only 1, not 3) even though the events were in the same hour; there are no more DB entries either; in the light0energy_minute table there is also only one entry, value 1000)
In the light0total day table: no entry, light0total_hour one entry value 0 (they were 3 though), in the light0total_min table, one entry, value 1000


in the exported minute data, the lightning there are values - see below
but either there are entries for 6 consecutive minutes - no idea where they are from - as they don't appear in the persistent database
(maybe [speculation] the values come from the RAM DB and these values are somehow not not properly calculated and written to the persistent database)

# date, time, temperature[C], humidity[%], dew point[C], sealevel pressure[hPa], avg wind speed[m/s], gust speed[m/s], winddir, rainfall00, Solar [W/m2], PM25(1) [ug/m3], PM25(2), extra-temp1 [°C], extra-hum1 [%], extra-temp2 [°C], extra-hum2 [%], extra-temp3 [°C], extra-hum3 [%], extra-temp4 [°C], extra-hum4 [%],soil moisture (1) [%], soil moisture (2) [%], soil moisture (3) [%], soil moisture (4) [%], soil moisture (5) [%], lightning total, lightning distance, lightning energy, WH45-temp-in, WH45-hum-in, WH45-CO2, WH45-PM25. WH45-PM10
2021-01-31,11:32,0.8,95,0.1,999.8,2.4,3.4,264,0.0, 61.50, 9.0, 30.0, 0.8, 94.0, 2.5, 99.0, 0.3, 97.0, 0.8, 99.0,41, 50, 69, 56, 68, , , ,20.9, 49.0,730,5.6, 5.6
2021-01-31,11:33,0.8,95,0.1,999.9,1.6,3.4,248,0.0, 64.25, 9.0, 30.0, 0.8, 94.0, 2.5, 99.0, 0.3, 97.0, 0.8, 99.0,41, 50, 69, 56, 68, , , ,20.9, 48.5,743,4.5, 4.2
2021-01-31,11:34,0.8,95,0.1,999.9,2.1,3.7,264,0.0, 67.25, 9.0, 30.0, 0.8, 94.0, 2.5, 99.0, 0.3, 97.0, 0.8, 99.0,41, 50, 69, 56, 68, 1, 27, 1,20.9, 48.0,738,4.2, 3.5
2021-01-31,11:35,0.8,95,0.1,999.9,2.3,4.9,279,0.0, 66.00, 9.0, 30.0, 0.8, 94.0, 2.5, 99.0, 0.2, 97.0, 0.8, 99.0,41, 50, 69, 56, 68, 1, 27, 1,20.9, 48.0,727,4.0, 3.2
2021-01-31,11:36,0.9,95,0.2,999.9,1.3,3.9,267,0.0, 67.50, 9.0, 30.0, 0.8, 93.0, 2.5, 99.0, 0.2, 97.0, 0.8, 99.0,41, 50, 69, 56, 68, 1, 27, 1,20.9, 48.0,699,4.1, 4.0
2021-01-31,11:37,0.9,95,0.2,999.5,1.9,4.6,242,0.0, 73.80, 9.0, 25.0, 0.8, 93.0, 2.6, 99.0, 0.2, 97.0, 0.7, 99.0,41, 50, 69, 74, 68, 1, 27, 1,20.9, 48.0,713,6.1, 5.2
2021-01-31,11:38,0.9,95,0.2,999.9,1.0,4.5,276,0.0, 80.80, 9.0, 25.0, 0.8, 93.0, 2.6, 99.0, 0.2, 97.0, 0.8, 99.0,41, 50, 69, 87, 68, 1, 27, 1,20.9, 48.0,725,6.2, 5.5
2021-01-31,11:39,0.8,95,0.1,999.8,1.7,2.7,248,0.0, 93.50, 9.0, 25.0, 0.8, 94.0, 2.6, 99.0, 0.2, 97.5, 0.8, 99.0,41, 50, 69, 86, 68, 1, 27, 1,20.9, 47.5,640,5.3, 4.5
2021-01-31,11:40,0.8,95,0.1,999.9,1.4,3.0,232,0.0, 102.00, 9.0, 25.0, 0.8, 94.0, 2.6, 99.0, 0.2, 98.0, 0.8, 99.0,41, 50, 69, 85, 68, , , ,20.9, 47.0,649,4.5, 4.1
2021-01-31,11:41,0.8,96,0.2,999.9,0.9,2.3,261,0.0, 104.50, 9.0, 25.0, 0.8, 94.0, 2.6, 99.0, 0.3, 98.0, 0.8, 99.0,41, 50, 69, 85, 68, , , ,20.8, 47.0,607,10.3, 8.2
whichever of the three lightning sensor descriptor values is what (this, i.e. the name, can be sorted out easily I guess), but when the values are not, not completely or/and not properly recorded in the database, they cannot be properly retrieved either.

For my three lightning events, there should be (reasonable) entries in the _day, _hour, _min tables of each, which correspond to:
# of strikes per day
# distance of strike (accuracy in the minute time windows)
# record of last and closest strike
as the events are shown in Ecowitt.net Now, after one day the data have disappeared from the min/min history where in my opinion that should remain.
Also, later on, nothing in the database (history).

@Boris: you want to have a copy of the database or access the system ? Let me know.

Hello again.
By not updating the sensor, it does not update the data of day month year total ???

I could change the number of lightning strikes in my template to lightning energy, but not updating the data on the day is not enough.

At the moment it remains like this, waiting for events .....

https://meteosantgenis.org/pws/

4 events today - an example of what the GW1000/WH2650 sends to Ecowitt.net:

a:77:{s:11:"stationtype";s:14:"WH2650A_V1.6.3";s:7:"dateutc";s:19:"2021-02-10 10:13:24";s:7:"tempinf";s:4:"64.6";s:10:"humidityin";s:2:"51";s:10:"baromrelin";s:6:"29.701";s:10:"baromabsin";s:6:"28.842";s:5:"tempf";s:4:"19.9";s:8:"humidity";s:2:"78";s:7:"winddir";s:3:"129";s:12:"windspeedmph";s:4:"3.80";s:11:"windgustmph";s:4:"4.70";s:12:"maxdailygust";s:5:"22.37";s:14:"solarradiation";s:5:"86.82";s:2:"uv";s:1:"0";s:10:"rainratein";s:5:"0.000";s:11:"eventrainin";s:5:"0.000";s:12:"hourlyrainin";s:5:"0.000";s:11:"dailyrainin";s:5:"0.000";s:12:"weeklyrainin";s:5:"0.429";s:13:"monthlyrainin";s:5:"4.094";s:12:"yearlyrainin";s:6:"10.161";s:11:"totalrainin";s:6:"10.161";s:6:"temp1f";s:5:"19.58";s:9:"humidity1";s:2:"77";s:6:"temp2f";s:5:"33.44";s:9:"humidity2";s:2:"75";s:6:"temp3f";s:5:"18.50";s:9:"humidity3";s:2:"81";s:6:"temp4f";s:5:"21.74";s:9:"humidity4";s:2:"86";s:6:"temp5f";s:5:"-0.76";s:6:"temp6f";s:5:"30.38";s:9:"humidity6";s:2:"65";s:6:"temp7f";s:5:"43.16";s:9:"humidity7";s:2:"67";s:13:"soilmoisture1";s:2:"41";s:13:"soilmoisture2";s:2:"56";s:13:"soilmoisture3";s:2:"61";s:13:"soilmoisture4";s:2:"79";s:13:"soilmoisture5";s:2:"66";s:8:"pm25_ch1";s:4:"22.0";s:16:"pm25_avg_24h_ch1";s:4:"14.5";s:8:"pm25_ch2";s:4:"31.0";s:16:"pm25_avg_24h_ch2";s:4:"30.1";s:6:"tf_co2";s:4:"67.8";s:8:"humi_co2";s:2:"43";s:8:"pm25_co2";s:4:"19.3";s:12:"pm25_24h_co2";s:4:"15.4";s:8:"pm10_co2";s:4:"20.6";s:12:"pm10_24h_co2";s:4:"16.2";s:3:"co2";s:3:"647";s:7:"co2_24h";s:3:"789";s:14:"lightning_time";s:10:"1612948164";s:13:"lightning_num";s:1:"4";s:9:"lightning";s:2:"24";s:8:"wh65batt";s:1:"0";s:8:"wh80batt";s:4:"2.98";s:8:"wh25batt";s:1:"0";s:8:"wh26batt";s:1:"0";s:5:"batt1";s:1:"0";s:5:"batt2";s:1:"0";s:5:"batt3";s:1:"0";s:5:"batt4";s:1:"0";s:5:"batt5";s:1:"0";s:5:"batt6";s:1:"0";s:5:"batt7";s:1:"0";s:9:"soilbatt1";s:3:"1.6";s:9:"soilbatt2";s:3:"1.5";s:9:"soilbatt3";s:3:"1.6";s:9:"soilbatt4";s:3:"1.6";s:9:"soilbatt5";s:3:"1.4";s:9:"pm25batt1";s:1:"4";s:9:"pm25batt2";s:1:"4";s:8:"wh57batt";s:1:"4";s:8:"co2_batt";s:1:"6";s:4:"freq";s:4:"868M";s:5:"model";s:6:"WH2650";}

lightning_time is the actual (at the same time last) occurrence of a strike
lightning_num is the so-far occurred number of strikes at that day (including the last one)
lightning is the distance of the last occurrence

the number of strikes per day needs to be totaled with the number of strikes per month, year, ever already which occurred earlier
this should permanently appear in the min/max history, even if there is no last strike reported anymore (e.g. reboot of the GW1000)

date, time and distance of the last strike need to be recorded / displayed in the current data ("live data") - the GW1000 provides this info regularly

only then we have a proper representation of the lightning events the first line in the totaling only makes sense if 37 is the max number which once occurred in one day - then the name should be adapted:
like "number of lightning strikes daily", and for month, year, ever there should be a minimum and a maximum value.
2nd and third lines look ok - IF they remain all the time in the min/max history visible and not only on the day when strikes occur.