Ligtning sensor output mapped to non-existent in extended database schema

[steepleian]

Gary,

I have noticed that 'lightningdettime' is mapped to a field that does not exist in the default WeeWX extended database.

'lightning_last_det_time': 'lightningdettime',

I had not noticed this before as I manually updated my own database. However one of my users was having problems. He has now overcome this by using extended mapping in weewx.conf to map to an existing unused field.

Is this a bug, or should the field 'lightning_last_det_time' have been in the extended database schema but got missed in the WeeWX release?

Ian

[gjr80]

Ian, apologies for not addressing this earlier.

I don't know what thought process was used when the extended schema was added to WeeWX. I surmise that for 'lightning' related fields the commonly used (at the time) fields of distance, energy and various counts were adopted.

Also, in terms of 'times', WeeWX has tended not to record 'times' in the archive, rather relying on aggregate times in the daily summaries or a suitable report tag/search list extension for deriving the time required. Consider, for example, 'the time of last rainfall', this can be determined by finding the time of the last non-zero rain value in the archive and so could easily be put into an SLE. Admittedly, such an approach only has the resolution of the archive period; it will not give the precise second that rainfall last occurred. A similar approach can be used for time of last lightning detection.

I don't believe this is a bug (in the GW1000 driver or WeeWX). If a user wanted to save such data to the database my (untried) advice would be to:

1. use wee_database to add a suitably named field of type integer to the database
2. add an entry to the [Accumulator] stanza of weewx.conf to extract the last (rather than the average) loop packet value of the field from the accumulator when synthesising an archive record from the loop packet data, eg:

   [Accumulator]
   [[my_lightning_time_field_name]]
       extractor = last

3. add a suitable field map extension to the [GW1000] stanza in weewx.conf to map the GW1000 driver lightningdettime field to your new WeeWX lightning time field, eg:

   [GW1000]
   ....
   [[field_map_extensions]]
       my_lightning_time_field_name = lightningdettime

Gary

[steepleian]

Hi Gary, No need to apologise for the delay. Thank you for your very clear response. I had already made the changes you suggested. I never upgraded to the extended database, but just add fields as and when required. It was only when one of the users of my weather34 skin ran into trouble that I realised what had happened. I have now directed him to this explanation and all is working fine. Thank you Ian

[gjr80]

Actually Ian, one more thing that came to mind just now. Depending on how you intend to use the lightningdettime data you could get away with doing nothing (well actually adding the extractor definition would be required but no need to add to the database). For some time now WeeWX includes all fields that were seen in loop packets during a particular archive period in the archive record that is produced at the end of the archive period. Only those fields that exist in the archive record and the database archive table are actually saved to database. However, all fields (whether saved or not) in the current archive record are available in any report template via the $current.xxxxx tag. So any user, with no change to the WeeWX database, could access $current.lightning_last_det_time in a report template. Haven't tried it but you should also be able to do the same through a SLE.

Saving things to database become important when you want historical data, aggregates or need to plot the data. I'm not sure of the need to know the time of last lightning strike at 9am on 1 March, nor do I see much value in any aggregates or plotting.

Maybe something to keep in mind.

[Millardiang]

Hi Gary, You would be surprised how many people need that level of granuality in their lightning data, particularly in those locations where it is a significant feature of the climate. Fortunately not an issue here in the UK.

I gave your last suggestion a go but all I got was a resounding '0'. Not surprising. However, I came up with this which appears to work as it picked the date of the last strike in my database. (1645056000 which converts to 17 Febuary 2022) which was confirmed by a manual inspection.

                             $alltime.lightning_last_det_time.lastnonzero.raw

lastnonzero is an X-type which TK knocked up for me a while ago for another un-related requirement.

Regards, Ian