Re: [weewx-user] Aggregation generates empty plots in daily images (customized Seasons skin)

[Thomas Keffer]

You've got me stumped. A few things to check:

1. Make sure the copy of skin.conf that you are editing is the copy of skin.conf that weewx is using. They should both be /etc/weewx/skins/Seasons/skin.conf
2. Make sure something in weewx.conf is not overriding the values you are setting in skin.conf. If you wish, you can obfuscate any passwords in weewx.conf then forward it. (Or use the tool wee_debug to do this).
3. Check the database to make sure there are not unexpected values. this can be done with

sqlite3 /var/lib/weewx/weewx.sdb

sqlite> select dateTime, datetime(dateTime, 'unixepoch','localtime'), outTemp from archive where dateTime> 1562454000;

I know these suggestions are not terribly helpful. If worse comes to worse, I'll send you an instrumented copy of imagegenerator.py which can pin down the problem.

-tk

On Sun, Jul 7, 2019 at 7:33 AM mph <mph.s...@gmail.com> wrote:

Hello,

I am working on my weewx and faced a trouble generating daily images with outTemp aggregation.

The specific part of my Seasons/skin.conf:

[[[daytemphilow]]]
    [[[[low]]]]
        data_type = outTemp
        aggregate_type = min
        aggregate_interval = 3600
        label = Nejnižší
    [[[[hi]]]]
        data_type = outTemp
        aggregate_type = max
        aggregate_interval = 3600
        label = Nejvyšší teplota

generates an empty graph, with no data lines. The same result will generate another types of aggregation (sum, avg).
Another daily images are generated fine.

If I do comment the aggregation lines, the graph is generated fine (but with no aggregation of course).
Even the exact example from weewx User guide ([[[daytemp_with_avg]]]) doesn't work for me.

Please note that the generated graph does have correct units, X and Y scales, title and generation date/time, but no data lines.
My another aggregation graphs (rain-sum, yearly-hilow-outtemp) work fine.

There's no message in the debug log. I've tried almost everything (shorten aggregation time, interval, use another data_types), but nothing helps. Any advice will be appreciated.
Thank you

--
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 on the web visit https://groups.google.com/d/msgid/weewx-user/064a15a2-ffb3-4aa5-9bba-0a0f10380f2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mph]

Hello Thomas,

thank you.

I am pretty sure I am working with right files, and the changes are populated to the result, because I am continuously checking the resulting page (every 5 minutes ;-)
At this time I am able to shorten the graph time_length to 432000 (120 hours, 5 days) and the graph is plotted well.

Shortening the time_length (e.g. to 356400 or 326400) does not have effect - the graph is as plotted as for 5 days - see attachment.
It is still newly generated, because date/time of generation is changing.

When I've set the time_length to 97200 (27h), the graph is empty.

There in my database can be wrong records, because my meteo history is only few days old and sometimes interrupted due to work on my weewx customization (database extension, full SD backup...).
Sadly, I have absolutely no clue how to check and/or repair the database.

Thank you
Pavel


Dne neděle 7. července 2019 17:24:19 UTC+2 Thomas Keffer napsal(a):

You've got me stumped. A few things to check:

1. Make sure the copy of skin.conf that you are editing is the copy of skin.conf that weewx is using. They should both be /etc/weewx/skins/Seasons/skin.conf
2. Make sure something in weewx.conf is not overriding the values you are setting in skin.conf. If you wish, you can obfuscate any passwords in weewx.conf then forward it. (Or use the tool wee_debug to do this).
3. Check the database to make sure there are not unexpected values. this can be done with

sqlite3 /var/lib/weewx/weewx.sdb

sqlite> select dateTime, datetime(dateTime, 'unixepoch','localtime'), outTemp from archive where dateTime> 1562454000;

I know these suggestions are not terribly helpful. If worse comes to worse, I'll send you an instrumented copy of imagegenerator.py which can pin down the problem.

-tk

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

[mph]

I've installed the sqlite3.

Result is in the attachment.

[Thomas Keffer]

That all looks OK.

Do two things for me:

1. Go into skin.conf and try setting the value of line_gap_fraction to something larger, say 0.2. Restart weewx and see if that does anything.

2. If that doesn't help, then replace your copy of manager.py (most likely in /usr/share/weewx/weewx/manager.py) with the attached. Then run the utility wee_reports (no need to stop weewx). Post the output. It will print the results of the min and max aggregations.

-tk

On Sun, Jul 7, 2019 at 9:22 AM mph <mph.s...@gmail.com> wrote:

I've installed the sqlite3.

Result is in the attachment.

--
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 on the web visit https://groups.google.com/d/msgid/weewx-user/a49793f4-703c-4c9f-b01a-7f4229fcd2cd%40googlegroups.com.

[mph]

Thanks for the advice.

Changing line_gap_fraction to 0.2 did the trick. I've tested another values down to 0.03.
The 0.04 is the smallest value, when the graph is plotted right.

I've noticed in this image a small gap at the start and the end of the data lines (left and right side).
None of my other images does have this.

But as a workarround the line_gap_fraction trick is reasonable good for me.
Although the trick helped, I did the manager.py test. Resulting output is in attachment.

Thank you a lot for your help
Pavel

[mph]

About the small gaps at the start and the end of the data lines.

In my opinion this is due to hourly aggregation. May be consider starting aggregation one aggregate_interval in the past before time_length to gain early data.
I'm not sure if it can be done using some similar trick at the end of the data lines. However in general it is not necessary there.

Thank you
Pavel

Dne pondělí 8. července 2019 6:37:10 UTC+2 mph napsal(a):