Belchertown error in log about lightning

[Tim Tuck]

Hi all,

I've just upgraded my weewx instance to the latest Belchertown skin v
1.31 and I have this error in syslog...

May 18 20:55:24 metoffice weewx[7013] INFO user.belchertown: Observation
lightning_strike_count is using unit count that returns %d for
StringFormat, rather than float point decimal format value - using 0 as
rounding
May 18 20:55:24 metoffice weewx[7013] message repeated 2 times: [ INFO
user.belchertown: Observation lightning_strike_count is using unit count
that returns %d for StringFormat, rather than float point decimal format
value - using 0 as rounding]

any help appreciated.

thanks

Tim

[ti...@skybase.net]

Further to this my chart section looks like this...

    [[chart8]]
            title = Lightning
            time_length = today
            aggregate_type = max
            aggregate_interval = 3600 # 1 hour
            gapsize = 3600
            type = column

                [[[lightning_strike_count]]]
                        name = Lightning
                        stacking = normal

                [[[lightning_distance]]]
                        name = Average Distance
                        stacking = normal

Running the gw1000 drive is see that its returning 'lightning_strike_count': 'None' rather than a zero, so that's what the error is about.

I have vague memories of there being some option or flag to set if this kind of thing happened but I cant find it !

So... is there an incantation to change the "none" to 0

thanks

Tim

[gjr80]

I can't help with Belchertown skin specific problems, but can offer some insight of the lightning_strike_count/None issue. Within WeeWX there is a subtle difference in meaning between an observation being 0 and None. Within loop packets and archive records the existence of a given field (irrespective of value) generally means that the relevant sensor is present and detected by the driver. If the value is None that is an indication that no data/invalid data was received from the sensor. If the value is 0 then data was received from the sensor and the value of that data is, well, 0. If a driver does not detect a given sensor the obs should be omitted from loop packets/archive records. In terms of the Ecowitt gateway driver the driver considers the lightning sensor to be present if the driver sees the lightning count address is the data received from the Ecowitt gateway device, so in your case the lightning sensor is being detected. The fact that the data is None indicates the driver could not decode the corresponding lightning count data. That should not occur. 

So, troubleshooting. The fact you are plotting lightning data leads me to assume you do indeed have a WH57 lightning sensor linked to your Ecowitt gateway device? Do you see lightning data in the Ecowitt WSView Plus or WS View apps? Stop then restart WeeWX, let WeeWX run for at least two full archive periods and then post a log extract showing the full WeeWX startup and the reporting cycle for each archive period. Run WeeWX directly, this will show loop packet (LOOP:) and archive record (REC:) data on the console. Does lightning_strike_count appear in the loop packets and archive records, and what value do they show? Paste the console output here (text based post please, no an image based screen capture).

Gary

[Tim Tuck]

Hi Gary,

Thanks for your assistance, see comments below...

On 20/5/23 07:42, gjr80 wrote:

[snip]

So, troubleshooting. The fact you are plotting lightning data leads me to assume you do indeed have a WH57 lightning sensor linked to your Ecowitt gateway device?

Yes

Do you see lightning data in the Ecowitt WSView Plus or WS View apps?

Yes

Stop then restart WeeWX, let WeeWX run for at least two full archive periods and then post a log extract showing the full WeeWX startup and the reporting cycle for each archive period. Run WeeWX directly, this will show loop packet (LOOP:) and archive record (REC:) data on the console. Does lightning_strike_count appear in the loop packets and archive records, and what value do they show?

weewx log output attached and in there I see 'lightning_strike_count': '0', in LOOP and 'lightning_strike_count': '0.0', in REC

But running the gw1000 driver via PYTHONPATH=/usr/share/weewx/ python3 -m user.gw1000 --test-driver shows...

 'lightning_strike_count': 'None'

See logs attached for both.

thanks

Tim

[gjr80]

From what you provide the Ecowitt gateway driver is performing as expected and I don't believe lightning_strike_count being None has anything to do with your Belchertown problem.

The Ecowitt gateway API provides lightning count as a cumulative value (and since WeeWX requires a per-period value), the driver calculates WeeWX field lightning_strike_count by taking the difference between successive cumulative lightning count values. When the driver is first started there is no previous value, and consequently the driver cannot calculate lightning_strike_count, so it returns the value None and that is what appears in the first loop packet (remember None means a sensor exists but WeeWX could not get valid data). This behaviour is identical to that for WeeWX field rain in almost all drivers. Subsequent loop packets include a numeric value, in your case 0, when the driver is run directly and again when WeeWX is run directly. In the archive records generated by WeeWX the initial loop packet None value has no effect and the archive record lightning_strike_count value is calculated (by WeeWX) as the sum of the loop packet values seen during the archive period (None values are effectively ignored). 

Whilst I don't use the Belchertown skin, as far as I can tell the Belchertown skin does not update plots with loop packet data, rather it updates plots with archive record data. Also, if you look at the error message in your first post, the error is generated when the Belchertown skin is obtaining archive record data; nothing to do (directly) with loop packet data. Both of these point to the issue being a mis-configuration in the Belchertown skin config file or the [StdReport] [[Belchertown]] stanza in weewx.conf. 

Gary

[Tim Tuck]

Hi Gary,

Thanks for your detailed analysis, I will delve further into the
Belchertown configuration.

regards

Tim