Output from a test-service which shows the correct amounts but for some
reason the database shows
LOOP: 2023-04-08 12:55:28 BST (1680954928) 'dateTime': '1680954928',
'dummyTemp': '96.3', 'inHumidity': '44', 'inTemp': '75.38',
'lightning_distance': '7.456454304', 'lightning_last_det_time':
'1680954865', 'lightning_strike_count': 'None', 'lightningcount': '5',
'pressure': '30.132399245', 'relbarometer': '1020.4', 'usUnits': '1',
'wh57_batt': '5', 'wh57_sig': '4'
LOOP: 2023-04-08 12:55:39 BST (1680954939) 'dateTime': '1680954939',
'dummyTemp': '96.3', 'usUnits': '1'
LOOP: 2023-04-08 12:55:49 BST (1680954949) 'dateTime': '1680954949',
'dummyTemp': '96.3', 'inHumidity': '44', 'inTemp': '75.38',
'lightning_distance': '7.456454304', 'lightning_last_det_time':
'1680954865', 'lightning_strike_count': '0', 'lightningcount': '5',
'pressure': '30.132399245', 'relbarometer': '1020.4', 'usUnits': '1',
'wh57_batt': '5', 'wh57_sig': '4'
LOOP: 2023-04-08 12:56:00 BST (1680954960) 'dateTime': '1680954960',
'dummyTemp': '96.3', 'usUnits': '1'
LOOP: 2023-04-08 12:56:10 BST (1680954970) 'dateTime': '1680954970',
'dummyTemp': '96.3', 'inHumidity': '44', 'inTemp': '75.38',
'lightning_distance': '7.456454304', 'lightning_last_det_time':
'1680954865', 'lightning_strike_count': '0', 'lightningcount': '5',
'pressure': '30.132399245', 'relbarometer': '1020.4', 'usUnits': '1',
'wh57_batt': '5', 'wh57_sig': '4'
LOOP: 2023-04-08 12:56:21 BST (1680954981) 'dateTime': '1680954981',
'dummyTemp': '96.3', 'usUnits': '1'
LOOP: 2023-04-08 12:56:31 BST (1680954991) 'dateTime': '1680954991',
'dummyTemp': '96.3', 'inHumidity': '44', 'inTemp': '75.38',
'lightning_distance': '7.456454304', 'lightning_last_det_time':
'1680954865', 'lightning_strike_count': '0', 'lightningcount': '5',
'pressure': '30.1264932475', 'relbarometer': '1020.2', 'usUnits': '1',
'wh57_batt': '5', 'wh57_sig': '4'
LOOP: 2023-04-08 12:56:42 BST (1680955002) 'dateTime': '1680955002',
'dummyTemp': '96.3', 'usUnits': '1'
LOOP: 2023-04-08 12:56:52 BST (1680955012) 'dateTime': '1680955012',
'dummyTemp': '96.3', 'inHumidity': '44', 'inTemp': '75.38',
'lightning_distance': '7.456454304', 'lightning_last_det_time':
'1680955005', 'lightning_strike_count': '1', 'lightningcount': '6',
'pressure': '30.1264932475', 'relbarometer': '1020.2', 'usUnits': '1',
'wh57_batt': '5', 'wh57_sig': '4'
LOOP: 2023-04-08 12:57:03 BST (1680955023) 'dateTime': '1680955023',
'dummyTemp': '96.3', 'usUnits': '1'
LOOP: 2023-04-08 12:57:13 BST (1680955033) 'dateTime': '1680955033',
'dummyTemp': '96.3', 'inHumidity': '44', 'inTemp': '75.38',
'lightning_distance': '0.621371192', 'lightning_last_det_time':
'1680955010', 'lightning_strike_count': '1', 'lightningcount': '7',
'pressure': '30.1264932475', 'relbarometer': '1020.2', 'usUnits': '1',
'wh57_batt': '5', 'wh57_sig': '4'
LOOP: 2023-04-08 12:57:24 BST (1680955044) 'dateTime': '1680955044',
'dummyTemp': '96.3', 'usUnits': '1'
LOOP: 2023-04-08 12:57:34 BST (1680955054) 'dateTime': '1680955054',
'dummyTemp': '96.3', 'inHumidity': '44', 'inTemp': '75.38',
'lightning_distance': '0.621371192', 'lightning_last_det_time':
'1680955010', 'lightning_strike_count': '0', 'lightningcount': '7',
'pressure': '30.1264932475', 'relbarometer': '1020.2', 'usUnits': '1',
'wh57_batt': '5', 'wh57_sig': '4'
LOOP: 2023-04-08 12:57:45 BST (1680955065) 'dateTime': '1680955065',
'dummyTemp': '96.3', 'usUnits': '1'
If I look at the DB in DB Browser for SQLite after the 5 minute archive I
can see a count of 20 under "lightning_strike_count" off the same run, that
is basically 2 strikes x10 checks (every 2 seconds for 20 seconds).
On Saturday, 8 April 2023 at 09:23:09 UTC+1 Mike wrote:
> Hi,
> 1. I have attached the log as a text file as its quite large. Also the
> service stopping at the end is me so I know where the log starts and ends.
> 2. If I put the sensor on top a running microwave and spark a piezo
> lighter I can gernerate a strike count on the ecowitt.
> 3. This is code being used
> "lightning":
> {
>
> "lightning last distance": {"value":
> "$alltime.lightning_distance.lastnonzero.format(add_label=False,
> $localize=False)"},
> "lightning last time": {"at": "$alltime.signal7.lastnonzero.raw"},
> "lightning last hour": {"value":
> "$hour.lightning_strike_count.sum"},
> ## Last value can't end with a comma
> "void_end": null
> },
> 4. The webui on the GW1000 live data screen shows the correct amount,
> example below.
> [image: ecowitt.jpg]
>
> Thanks
> Mike
>
>
>
> On Saturday, 8 April 2023 at 02:28:54 UTC+1 gjr80 wrote:
>
>> I have just run a similar configuration (simulator with 2 sec loop
>> interval and Ecowitt gateway driver as a service with a 20 sec poll
>> interval) and I received the expected results. Not saying there is no
>> issue, but I did not notice it on my test. To look into this further I am
>> going to need some more information:
>>
>> 1. provide a debug startup log - edit weewx.conf, set debug = 1, save
>> weewx.conf and restart WeeWX. Take a log extract showing the full WeeWX
>> startup sequence and post it here without alteration.
>>
>> 2. '*I have found a way to generate test lightning*' - what does this
>> mean and exactly what have you done to generate this test data?
>>
>> 3. '*the numbers recorded in the database*' - what field in the
>> database? are you manually querying the database - if so with what query,
>> or are you using a report - if so with what tags/content?
>>
>> 4. '*the gw1000 interface report*s' - what does this mean?
>>
>> Gary
>> On Saturday, 8 April 2023 at 01:07:09 UTC+10 Mike wrote:
>>
>>> Hi,
>>> I have a davis weather station which is polled roughly every 2 seconds.
>>> I have recently purchased an ecowitt wh57 lightning sensor and gw1000
>>> gateway which I am polling using the user.gw1000 driver found here:
>>> https://github.com/gjr80/weewx-gw1000 as a service in weewx. I have
>>> found a way to generate test lightning and have noticed that the numbers
>>> recorded in the database are higher than the gw1000 interface reports. All
>>> other entries such as distance and time are recorded correctly.
>>>
>>> For example 1 strike would be recorded in the db as 10 strikes.
>>>
>>> After some messing around I noticed that 10 is basically the number of
>>> loops my davis was doing in the 20 second window between the gw1000
>>> polling. To confirm this I have set the gw1000 polling to 1 second and now
>>> 1 strike is counted as 1 in the DB. If I set the polling to 4 seconds 1
>>> strike is counted as 2.
>>>
>>> Is this something that can be resolved in code or is the fix to simply
>>> poll the gw1000 every 1 second?
>>>
>>> Many Thanks
>>> Mike
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/ae9e8b98-cc80-473d-a1ea-4106d32bc836n%40googlegroups.com.
