deltas and accumulators

219 views
Skip to first unread message

Patrick Sifford

unread,
Aug 1, 2026, 5:13:17 PMAug 1
to weewx-user
Is there any where a definitive and correct set of documents that discuss how to use deltas and accumulators and their formats?

I am trying to work on Acurite Atlas Rain and Lightning sensors and get confused when I read different discussions on the topics.  I think the rain is taken care of (somewhere various rain items are calculated (rainToday, rain24, ... ) that I am able to take advantage of.  However, I do not seem to find similar items for Lightning.

I have also found multiple solutions which do not seem to be solutions...   and they all seem to be using different formats of how deltas and accumulator's work.   

Not looking for the solution ...    looking for good reasonable documentation of how these things work to include extractors...

Thanks
Patrick


Tom Keffer

unread,
Aug 1, 2026, 5:45:37 PMAug 1
to weewx...@googlegroups.com
Accumulators are documented here.

Unfortunately, there is no documentation for deltas, but they are pretty simple. If you have some extensive quantity, say "tide", and you want to calculate "delta_tide" as the difference in tide between archive records, it would look like this:

[StdWXCalculate]
  [[Delta]]
    [[[delta_tide]]]
      input = tide






--
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 weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/de622fde-796f-43ad-b087-5cc28edaf347n%40googlegroups.com.

Patrick Sifford

unread,
Aug 2, 2026, 12:33:43 PMAug 2
to weewx-user
Tom  

Thanks...    I think that will help

I have seen other structures to the Delta functions...   Ill give this a try

Patrick Sifford

unread,
Aug 5, 2026, 8:00:14 AMAug 5
to weewx-user
Tom,

Your information was very useful.   I think I have a handle on most things that I am trying to get through.  What I am trying to do is to have values for daily lightning strikes, nearest strike (and its time), and latest strike (and its time) available to send to Hubitat (That is the easy part for me).

One thing that i did not see (may of skipped over it) in the wiki page is the time period of a accumulator.  It was looking like it was a loop/archive interval, but i found out that happenned to be my data.  From reading around it seems that accumulators reset to 0 at midnight.  Once I got over that I was able (I think... still waiting on a thunderstorm to check it out) to get a lightning count for the day:

lightning_count_start = the min value of strike_count (choose the min versus first incase acurite atlas resets the value during the day for any reason)
lightning_count_now = the last value of strike_count
lightning_count = lightning_count_now - lightning_count_start

then put lightning_count into an accumulator for the last.

finding the min and last lightning distance is easy also....      What I can not find any reference on is :

Once I have the min lightning distance (or the last)  how do I determine the time of that strike?

Thanks
Patrick

bell...@gmail.com

unread,
Aug 5, 2026, 9:56:06 AMAug 5
to weewx-user
Patrick,
I'm looking forward to what you come up with. I did some work and you can find it here, https://github.com/bellrichm/WeeWX-Extras/blob/master/bin/user/observationtime.py
Basically I store the first/last/min/max of an observation for the archive period. A bit more information is here, https://groups.google.com/g/weewx-user/c/oQPj0cuYMZw/m/EJvMn6ggAQAJ
It is totally an experiment, so it no install and real documentation; but maybe something in it will be useful to you.
rich

Patrick Sifford

unread,
Aug 5, 2026, 10:51:29 AMAug 5
to weewx-user
Thanks...   very interesting read!!!

we are going two different directions on how to make this work.   You have a much more elegant process that I want to get into to and play with sometime.  Because of my lack of knowledge I was looking at a more brute force (which normally means wrong) way of doing this.  

My thought on time was to set the nearest time = present time when present strike distance is equal to or closer to nearest strike...  
and setting present time = present time when there is a strike.

not really databasing it but getting the value available for hubitat...    

However, looking at your solution it looks really tasty...   If I get mine working...   or run into a brick wall that is there  I will look at what you got...   tempting as it means there are somethings I can learn from it!

Thanks.

P.S.  

it was suppose to rain this morning so I was hoping that we would get some lightning....   neither of rain or lightning.  So I am going to make it look good and then will post for you to look at.  Would love to have a test that runs with lightning and switch over at mid night.

THanks 

Patrick Sifford

unread,
Aug 5, 2026, 12:15:26 PMAug 5
to weewx-user
Here is the code that I am working on...

[StdCalibrate]

    [[Corrections]]
        # For each type, an arbitrary calibration expression can be given.
        # It should be in the units defined in the StdConvert section.
        # Example:
        foo = foo + 0.2

        # lightning_strike_count is a internal variable that is used by weewx in reports.  It shows the numer of lightning strikes that occured within a loop/archive interval
        # obtain information about lightning strikes for reporting to hubitat
        # lightning_strike_count_start is the number of strikes that the day started with (strike_count)
        # lightning_strike_count_last is the present number of strikes today
        # lightning_count is the total count of lightning strikes that have occurred today
        #
        # lightning_strike_last_distance = distance of the last lightning strike
        # lightning_strike_min_distance = distance of the closest lightning strike
        #
        # still have work to do to obtain the time of the two lightning strikes
        # still have testing to do on what is presently done
        #
        lightning_strike_count_start = strike_count
        lightning_strike_count_last = strike_count
        lightning_count = lightning_count + lightning_strike_count if lightning_strike_count > 0 else None
        lightning_distance = strike_distance if lightning_strike_count > 0 else None
        lightning_strike_last_distance = strike_distance if lightning_strike_count > 0 else None
        lighting_strike_min_distance = strike_distance if lightning_strike_count > 0 else None

and

    [[Delta]]

        [[[lightning_strike_count]]]
            input =  strike_count

        [[[rain]]]
            input = rain_total

        [[[lightning_strike_distance]]]
            input = strike_distance

[Accumulator]
    [[lightning_count]]
        extractor = last

    [[lightning_strike_last_distance]]
        extractor = last
#        merger = minmax

    [[lighting_strike_min_distance]]
        extractor = min
#        merger = minmax

    [[lightning_strike_count_start]]
        extractor = min
    [[lightning_strike_count_last]]
        extractor = last

If these work then I will start pulling the datetime information.    I believe that the SDR has a datatime available that I plan to then:

lightning_strike_last_time = datetime if lightning_strike_count>0 else None

if lightning_strike_last_distance is <= lightning_strike_min_dstance then lightning_strike_min_time = lighting_strike_last_time

and accumulate with
    [[lightning_strike_min_time]]
        extractor = last

    [[lightning_strike_last_time]]
        extractor = last

random thought of an amature

So far on my testing i have been able to show that the data flows over to hubitat..

My strike counter this morning was (and still is) 78.  that value is going over to hubitat in both the lightning_strike_count_start and lighning_strike_count_last records!!!!

what I now need is some bad weather so that I can see if the count_start does not increment untill the new day (or acurite atlas reset) and that strike_count_last value increments correctly.
then the next day I expect count_start to be set to the new value which was the last count of the previous day.  Or if atlas reset the value to zero (roll over of power reset) that it is set to zero and count_last is operating as expected.

After that I will be testing if the distance values are working correctly...

then I will be testing the time values to see if they are working correctly.

All will be compared to the data being sent to MyAcurite by the acurite hubs.

Any thoughts would be very much appreciated!

THanks

Patrick Sifford

unread,
Aug 7, 2026, 8:07:49 PMAug 7
to weewx-user
Found a couple of articles that may be of interest....



I think the accumulator time is going to be more useful...  I was hoping that the accumulators without deltas would be nice but I think it only works with extractor last or firstlast...   I have not been able to get it to run with min max or sum (but that maybe me).

Patrick Sifford

unread,
Aug 8, 2026, 6:09:06 PMAug 8
to weewx-user
So after trying several things and failing, I did some more reading.   A couple of things that I tried and was disappointed in that I could not get them to work were the accumulators without deltas and the weewx accumulator time page (both that I posted in the previous notice.

In particular, the accumulator page where they define mintime, maxtime, lastime as extractors within the accumulator looked so promising but everything I tried created errors within the accum.py program.

I also kept running into issues where it seemed that the accumulators were reseting at the end of each archive (REC) loop!

So here is my present solution (not yet tested cause I am waiting for thunderstorms to come through!!!) .

There are three sections to this.    

The first section is the [STDCalibrate] in weewx.conf

the lightning_distance and lightning_strike_count come from the Deltas defined in the SDR.py


[StdCalibrate]

    [[Corrections]]
        # For each type, an arbitrary calibration expression can be given.
        # It should be in the units defined in the StdConvert section.
        # Example:
        foo = foo + 0.2

        # lightning_strike_count is a internal variable that is used by weewx in reports.  It shows the numer of lightning strikes that occured within a loop/archive interval
        # obtain information about lightning strikes for reporting to hubitat


        # lightning_count_sum is the sum of lightning_strike_count for the day

        # lightning_strike_last_distance = distance of the last lightning strike
        # lightning_strike_min_distance = distance of the closest lightning strike
        #
        # still have work to do to obtain the time of the two lightning strikes
        # still have testing to do on what is presently done

        lightning_count_sum = lightning_strike_count
        lightning_strike_min_distance = lightning_distance
        lightning_strike_last_distance = lightning_distance
        lightning_strike_last_time = lightning_distance
        lightning_strike_min_time = lightning_distance


The second is the [Accumulator} section
[Accumulator]
#
# Set up accumulators for monitoring the lightning strikes
#
# Set them all for daily accumulation (period = daily)
#
    [[lightning_count_sum]]
        period = daily
        extractor = sum

    [[lightning_strike_last_distance]]
        period = daily
        extractor = last

    [[lightning_strike_min_distance]]
        period = daily
        extractor = min

    [[lightning_strike_last_time]]
        period = daily
        lastime = user.accumulators.LastTimeAccumulator


    [[lightning_strike_min_time]]
        period = daily
        mintime  = user.accumulatos.MinTimeAccumulator


##############################################################################

you will see to custom accumulators in the Accumulators...   they are stored in a file /etc/weewx/bin/user/accumulators.py

# user/accumulators.py
import weewx.accum

class MinTimeAccumulator(weewx.accum.Accumulator):
    """Custom accumulator to track the timestamp of the minimum value."""

    def __init__(self, obs_type):
        super(MinTimeAccumulator, self).__init__(obs_type)
        self.min_val = None
        self.min_time = None

    def accumulate(self, record):
        """Process each record from the archive."""
        value = record.get(self.obs_type)
        if value is None:
            return

        ts = record.get('dateTime')
        if self.min_val is None or value < self.min_val:
            self.min_val = value
            self.min_time = ts

    def get_result(self):
        """Return the timestamp of the minimum value."""
        return self.min_time

class LastTimeAccumulator(weewx.accum.Accumulator):
   """Custom accumulator to track the timestamp of the last value."""

   def __init__(self, obs_type):
        super(LastTimeAccumulator, self).__init__(obs_type)
        self.last_val = None
        self.last_time = None

    def accumulate(self, record):
        """Process each record from the archive."""
        value = record.get(self.obs_type)
        if value is None:
            return

        ts = record.get('dateTime')
        if self.last_val is None or value < self.min_val:
            self.last_val = value
            self.last_time = ts

    def get_result(self):
        """Return the timestamp of the minimum value."""
       
return self.last_time

Again...   these have not been tested yet (waiting on a thunderstorm) and I am expecting some level of disappointment when it gets here!!!!  However, watching the records in the database they are being written and all the values are 0/Null at this point (which is what they should be).  I am thinking that I might need to put a qualifier on the STDCalibration section about only doing anything unless lightning_strike_count is none 0 (a lightning strike occured within the loop interval.  I am also expecting that the mintime and lasttime accumulators that i wrote may not be 100% correct or may be able to be done more eloquently.

If you have any thoughts let me know.

THanks
Patrick

Patrick Sifford

unread,
Sep 16, 2026, 12:28:34 PMSep 16
to weewx-user
Rich,

I think that I have something that does everything I originally wanted!  I havent been on line about it cause I have been tweeking somethings and need a lightning storm to occur.   THey have been rare lately!!!!

I still need a little more testing.  However,  I let you know what I got...

I worked with GROK to get this going.

We created a service Lightning_first.py that has a few inputs.

     1) a internal variable set to 512 -  this is the modulo of my lightning detector. 
     2) Lightning counter - this is directly from the SDR and the acurite atlas system.  This number counts the lightning strikes to 512 then resets to 0 and keeps counting
     3) lightning distance - this is a estimated distance of the distance of lighting from the last report from the SDR.  At present I am trying to figure out if this is miles or Kilometers.

with those three items the following is a description of what the service does:

     1) create a count of lightning strikes for the day (corrected for the modulo effect)
     2) account for false lightning distances (distance of 0 or distance with no change to the lightning count)
     3) record the closest lightning strike distance
     4) record the time of the closest lightning strike distance
     5) record the distance of the latest lightning strike
     6) record the time of the latest lightning strike
     7) reset the daily lightning count at midnight

Presently, the testing that i have done has been comparing it to the data from the MyAcurite data.  I have the times and the count matching up but the last time I was able to check the distances looked different.  so when I get another storm I will hopefully confirm everything.

Patrick Sifford


On Wednesday, August 5, 2026 at 9:56:06 AM UTC-4 bell...@gmail.com wrote:
Reply all
Reply to author
Forward
0 new messages