Add a graph to the rain intensity

[Pookmia Romero]

Hello, I am a French user Weewx 3.4.
great program, but I was missing a graph of the rain rate.

In index.html.tmpl file at <div id = "plots"> I added <img src = "dayrainrate.png" alt = "rainrate" />

skin.conf in the file I added in [ImageGenerator] and [[day_images]]

 [[[Dayrainrate]]]
            # Make sour the y-axis increment is at least 0.02 for the rain plot
            yscale = None, None, 0.02
            plot_type = bar
            [[[[RainRate]]]]
                aggregate_type = sum
                aggregate_interval = 3600
                label = Intensity

I get a pretty good graphics, but after I added in week.html.tmpl

<Img src = "dayrainrate.png" alt = "rainrate" />

then in skin.conf at [[week_images]] I added

        [[[Weekrainrate]]]
            yscale = None, None, 0.02
            plot_type = bar
            [[[[RainRate]]]]
           aggregate_type = max
                label = Intensity

I get a graph but not the maximum intensity, but still average.

I saw:

    [[Week_images]]
        x_label_format =% d
        bottom_label_format =% x% X
        TIME_LENGTH = 604800 # == 7 days
        aggregate_type avg =
        aggregate_interval = 3600

but putting aggregate_type = MAX is the same.

Would you have a solution?

thank you in advance

[Thomas Keffer]

You want "rainRate", not "RainRate"

You also have a typo in your [[Week_images]]. It should be

aggregate_type = avg

not

aggregate_type avg =

-tk

--
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.
For more options, visit https://groups.google.com/d/optout.

[Pookmia Romero]

Hello, thank you for your answer
in fact I wrote a little fast just now, it's copying errors in the skin.conf file is correct, but the graphics still use an average value and not max.

[Thomas Keffer]

Rather than typing in what you think is in skin.conf, how about cutting and pasting? There is no point in chasing errors introduced by transcription.

-tk

[Pookmia Romero]

    [[week_images]]
        x_label_format = %d
        bottom_label_format = %x %X
        time_length = 604800    # == 7 days
        aggregate_type = max
        aggregate_interval = 3600

    

    [[[weekrainrate]]]

            yscale = None, None, 0.02
            plot_type =

bar
            [[[[rainRate]]]]
           aggregate_type = avg
                label = Intensite

I tried

        [[[weekrainrate]]]

            yscale = None, None, 0.02
            plot_type =

bar
            [[[[rainRate]]]]
           aggregate_type = max
                label = Intensite

[Thomas Keffer]

OK. And what did you get?

If all the events are of the same intensity, the max will be the same as the average. 

Perhaps you have a plot of rainRate, without an aggregation?

-tk

[Pookmia Romero]

Max reached the 21.8 mm / h, the graph shows 3mm / h.

I test without aggregate

[Pookmia Romero]

I tried without aggregate

 

 

I have not the max

[Thomas Keffer]

Mr. Romero

You are not giving much information to go on. You're not including any graphs (or supplying URLs to graphs), and you're only giving little snippets of your skin.conf file. It is very hard to debug with so little information.

Rest assured, if you have rainRate in your database, it will work. It's just a matter of getting skin.conf right.

How about if you mail your skin.conf file to me (tke...@gmail.com). I will try it on my machine.

-tk

On Tue, May 24, 2016 at 7:56 AM, Pookmia Romero <pooki...@gmail.com> wrote:

I tried without aggregate

 

 

I have not the max

[Pookmia Romero]

http://78.218.239.214

[Andrew Milner]

If I understand this correctly - you want to plot the max values from the stats (which probably came from a LOOP record) rather than the max averaged values from the archive?  I don't know if you can do that ... I am sure Tom will advise.....

[Thomas Keffer]

From your skin.conf file (sent under separate cover) you modified the parameters for the weekly plots. So, in the file you sent me, they now read

    [[week_images]]

        x_label_format = %d

        bottom_label_format = %x %X

        time_length = 604800    # == 7 days

        aggregate_type = avg

        aggregate_interval = 300

        

        [[[weekrainrate]]]

            yscale = None, None, 0.02

            plot_type = bar

            [[[[rainRate]]]]

                label = Intensite

Your aggregate interval is only 300 seconds (5 minutes), instead of the default one hour. If your archive interval is also 5 minutes, there will be effectively no aggregation at all. You'll just be getting the value for each archive interval.

You also have not specified aggregate_type = max under [[[weekrainrate]]]. So, you will get the value supplied for the weekly images, which is "avg". 

Put this all together, and you want

    [[week_images]]

        x_label_format = %d

        bottom_label_format = %x %X

        time_length = 604800    # == 7 days

        aggregate_type = avg

        aggregate_interval = 3600

        

        [[[weekrainrate]]]

            yscale = None, None, 0.02

            plot_type = bar

            [[[[rainRate]]]]

                aggregate_type = max

                label = Intensite

-tk

[Pookmia Romero]

Ok, but that's exactly the parameters I had set, before I modified this afternoon.

I send you the skin.conf.

[Pookmia Romero]

May 22, max intensity 22:00 to 21 mm / h on the graph it is far off.

[gjr80]

Hi,

I think Andrew has it right. Weewx records the max/mins (or highs/lows) from archive records and loop packets in the daily summaries and saves archive records (only) in the archive table. Archive records are generated every archive period minutes and loop packets are generated somewhat more often, how often depends in your station. The max/min values appearing on a page will normally come from the daily summaries; so if a max/min was picked up in a loop packet it would be recorded in the daily summaries and displayed in a table on your page through use of the appropriate tag eg $week.rainRate.max for max rainRate in the last week. The max/min value concerned will not appear in the archive table unless the max/min was detected in an archive record. Now when you create a plot, weewx pulls the data from the archive table only so any min/max value picked up in a loop packet will not appear in the plot.

This is what you are seeing, the time of your max, 22:01:22, tells us that it was a max picked up in a loop packet (remember archive records are time stamped every 'archive period' and hence would appear on a '5 minute' boundary if you have a 5 minute archive period). So since it was a loop packet where the max value occurred the max value will not appear in a plot. There is nothing you can do about it, without fundamental (and complex) changes to how weewx and/or the plot engine works.

Gary

[Andrew Milner]

It actually shouldn't be that difficult to implement since a stats table contains max, min and average (sum/count) for a day so for weekly, monthly and yearly these plots could be specifiable as being sourced from stats data if required.  Maybe it could be added to a wish list - specify to be able to define a table and database as a source to a plot or something similar!!

[Thomas Keffer]

Feel free to offer a pull request.

-tk

--

[Andrew Milner]

By which I assume it would actually be much harder than I theorised!!  Guess that's the problem with evolving to an ideas man rather than implementor over the years!!

[Thomas Keffer]

One thing I've learned about open source development: other people are very free with my time! :-)

-tk

[Andrew Milner]

I think my development team always had other thoughts (unprintable) about their manager's "I was thinking last night ....." 'good' ideas!!!

[Pookmia Romero]

ok I see. I know nothing about programming.
by cons I can get a little php.
The data it uses you default a database sql kind or another?

[gjr80]

A plain vanilla weewx install will use SQLite, but weewx also has inbuilt support for MySQL. It is a fairly easy process to change over to MySQL, it's covered in the docs and the wiki.

Gary

[Pookmia Romero]

I looked everywhere, but I have not found much information on migrating to MySQL.
I do not want to make a mistake, then I ask you a link?
thank you


quick question, is there a directory of available extensions?

[Andrew Milner]

Why exactly are you wanting to change from SQLite to MySQL??  Weewx uses as standard SQLite, and this is adequate for most uses unless you have a very specific reason for wanting to change to MySQL. 

SQLite uses pretty standard sql for queries etc. 

Do you already have a lot of data in an SQLite database that you need to move to a MySQL database, or can you just start afresh using MySQL and not have to migrate anything from one to the other?

[gjr80]

I suspect you did not look everywhere, the Users Guide has some info:
http://weewx.com/docs/usersguide.htm#configuring_mysql

Also, the weewx wiki has an entry re converting from SQLite to MySQL:
http://weewx.com/docs/usersguide.htm#configuring_mysql

As for extensions, there is no definitive list; however, the wiki is probably the biggest list of extensions:
https://github.com/weewx/weewx/wiki

I would have to echo Andrew's thoughts why do you want to change to MySQL. I would recommend changing only if there is a good reason to do so. SQLite works straight out of the box and is easier to use/manage with weewx.

Gary

[Pookmia Romero]

Little rain this morning, the chart of the day shows an intensity to 6mm / h while the recorded 2.8mm max / h

to see on http://78.218.239.214

[URL=http://www.hostingpics.net/viewer.php?id=683550dayrainrate.png][IMG]http://img15.hostingpics.net/thumbs/mini_683550dayrainrate.png[/IMG][/URL]

[Andrew Milner]

What values are actually in the database for today

- in archive table

- in archive_day_rainrate

what is actually being plotted - what is in skin.conf for the rainrate graph?

On Sunday, 29 May 2016 10:54:43 UTC+3, Pookmia Romero wrote:

e actually in the database

[Pookmia Romero]

My skin.conf

[[[dayrainrate]]]
# Make sure the y-axis increment is at least 0.02 for the rain plot

yscale = None, None, 0.02
plot_type = bar
[[[[rainRate]]]]

aggregate_type = sum
aggregate_interval = 3600

label = Intensite

[Andrew Milner]

I would imagine that if you sum rainrates you will get strange values - you can sum rain, but not rainrate!!

eg if the rsate for one interval of 5 minutes is 3mm/hr, and for another interval is 4mm/hr - the sum is 7mm/hr, but the average is 3.5mm/hr, the max is 4 and the min is 3.

Maybe that is why your graph and the values are 'different' which is why I asked you what values are actually in the database tables for rain rate.  Remember the 'rate' will only be accurate if the archive interval is also 1 hour so the rainfall is accurate.  Otherwise rainrate is a calculation based on rainfall in an archive period, multiplied up to a rate per hour.

Make sense??  I hope so!!

[Andrew Milner]

so I think you want aggregate type = max and not sum.

[Pookmia Romero]

[[[dayrainrate]]]
# Make sure the y-axis increment is at least 0.02 for the rain plot
yscale = None, None, 0.02
plot_type = bar
[[[[rainRate]]]]

aggregate_type = max
aggregate_interval = 3600
label = intensité


With this parameter I from 6mm/h to 0.30mm/h

[Andrew Milner]

What are the values for rainrate in the archive table?  If the max which you see in the text table came from a loop record, (| not from an archive record), then you will only see it on a graph if you are plotting with aggregate periods of a day or more because it just does not exist in the archive table's data!!

I do not think there is a solution to your problem on the daily graph plots unless you can find a method to change/alter the values for rainrate in the archive table data itself.  The only other 'solution' is to change weewx.conf to NOT use Loop data for low/high - but then you will also lose the high intensity rainrate from the text table on the left hand side.  Another 'solution' is to remove the rain rate graph completely from the current conditions page and instead have it only on the weekly monthly and yearly pages, and display max value on those graphs.

[Pookmia Romero]

I could finally access the tables.
rainrate in archive dates are in datetime format hard to decipher, but I have no example max 0.0699999998572 at 1462744800 (datetime)

[Andrew Milner]

You can convert datetime easily using:

http://www.freeformatter.com/epoch-timestamp-to-date-converter.htmlle the max was .069 cm/hr == .69 mm/hr or thereabouts, as you plotted.

and you can access the tables using either SQLite directly from the command line or via sqlitephpadmin

from the data you had in the archive tab

On Monday, 30 May 2016 09:43:39 UTC+3, Pookmia Romero wrote:

[Pookmia Romero]

I just thought of something , kidney, spleen should be in mm. But in the basis it does not look like a millimeter but to thumb

Phpliteadmin

[Andrew Milner]

I think you are confusing sql max - which will give you max from the whole archive unless you limit the search using dateTime values eg:

select dateTime, max (rainRate) from archive where dateTime > 1464480000 would give you the max rate occurring after midnight 29 May 2016

and the graphing aggregate = max which for daily graph will give you the max rates occurring in an aggregate period, taken from the archive table again - but I think you want to show the max value that has occurred today from the archive day table - not from the archive table.  You can only get the archive day values in plots for more than a day ie weekly, monthly or annually.  In that case the aggregate period will be at least a day.

[Andrew Milner]

These are the archive values since midnight yesterday:

dateTime	rainRate
1464496680	0.0043749999866125
1464496800	0.00482758619212414
1464496920	0.00656249997991875
1464497040	0.00424242422944242
1464497160	0.00777777775397778
1464497280	0.00656249997991875
1464497400	0.00482758619212414
1464497520	0.00656249997991875
1464497640	0.00451612901843871
1464497760	0.00466666665238667
1464497880	0.0068749999789625
1464498000	0.0099999999694
1464498120	0.00758620687333793
1464498240	0.0113793103100069
1464498360	0.01178571424965
1464498480	0.0068749999789625
1464498600	0.0106451612577484
1464498720	0.0068749999789625
1464498840	0.0103124999684437
1464498960	0.00758620687333793
1464499080	0.01178571424965
1464499200	0.00733333331089333
1464499320	0.00733333331089333
1464499440	0.0078571428331
1464499560	0.0113793103100069
1464499680	0.01099999996634
1464499800	0.0068749999789625
1464499920	0.01178571424965
1464500040	0.00407407406160741
1464500160	0.0106451612577484
1464500280	0.008799999973072
1464500400	0.0113793103100069
1464500520	0.00366666665544667
1464500640	0.00970588232324118
1464500760	0.01099999996634
1464500880	0.00709677417183226
1464501000	0.0103124999684437
1464501120	0.0068749999789625
1464501240	0.0103124999684437
1464501360	0.00379310343666896
1464501480	0.0103124999684437
1464501600	0.00709677417183226
1464501720	0.0099999999694
1464501840	0.0103124999684437
1464501960	0.00733333331089333
1464502080	0.0103124999684437
1464502200	0.00733333331089333
1464502320	0.0099999999694
1464502440	0.00758620687333793
1464502560	0.0099999999694
1464502680	0.00709677417183226
1464502800	0.0126923076534692
1464502920	0.00970588232324118
1464503040	0.00733333331089333
1464503160	0.0103124999684437
1464503280	0.00733333331089333
1464503400	0.0103124999684437
1464503520	0.00709677417183226
1464503640	0.00758620687333793
1464503760	0.00709677417183226
1464503880	0.0106451612577484
1464504000	0.01099999996634
1464504120	0.00379310343666896
1464504240	0.0106451612577484
1464504360	0.00354838708591613
1464504480	0.0106451612577484
1464504600	0.00758620687333793
1464504720	0.0113793103100069
1464504840	0.00647058821549412
1464504960	0.01099999996634
1464505080	0.00709677417183226
1464505200	0.00970588232324118
1464505320	0.0106451612577484

rainrate units are in/hr since you are using us units

can you tell me exactly what the problem is now, and exactly what you are trying to achieve, and exactly which graph or graphs are incorrect.

what values are you expecting to plot?

the daily max is attached - approx. 0.3mm/hr from yesterday

[Pookmia Romero]

Exactly a density of 0.3 mm hour max, or I do not know but I think yesterday was 2.8 m per hour or 4.8 mm per hour.

[Andrew Milner]

But yesterday you had 3 times as many readings for some reason - 720 instead of the usual 288 that you had been getting previoiusly!!  So what else did you change yesterday???

what was the polling interval at 4.56 GMT when the high was recorded?  Did you change from use loop for hi/lo to not use (or vice versa)?  It is hard to see what you were actually running?  I see the archive interval is currently set at 2 minutes (which seems very frequent)

I am still unsure what exactly you are trying to do.  You cannot have the daily max rate on a daily graph, but you can select max for the weekly and monthly graphs.  If you select max on the daily graph it will be the max rate from the archive records, not from the daily summary records.  The text max rate comes from the daily summary table.

[Pookmia Romero]

I thought I had selected the right unit, how to switch to mm?

[Andrew Milner]

You probably have the correct units - the dstabase is storing the data in us units because you have said target_unit = us in stdcopnvert, but you can display in whatever units you want by settings in the skin.  So you probably have the correct units.  See the user guide if you want to change the units of the database itself - not recommended unless you have a real reason to change though.

[Pookmia Romero]

I have reviewed the file skin.conf , made ​​several attempts but unfortunately the data still remains inch , no way to move in mm

[gjr80]

Hi,

It is not clear to me what your problem is. The plots on the site whose IP you posted earlier (http://78.218.239.214) all use metric units. Your underlying database my be in US customary units (ie inches for rain and inches/hour for rainRate) but that has no real bearing on the presentation layer. Weewx will automatically do any necessary conversions when generating reports/plots. If you are trying to change the units of your database then this cannot be done from skin.conf, it is more complex than that. If you believe your problem is that values in US customary units are being displayed as metic without conversion then we will need more info oitehr than it does not work.

Since you are using v3.4.0 might I suggest that you use the wee_debug utility (read about it here) and post the output along with a copy of the skin.conf concenred in its entirety. It is important to post the entire output/file, often a small portion only provides part of the picture. When posting wee_debug output check to make sure it has removed all sensitive information (it tries but it isn't necessarily perfect).

Gary

[Andrew Milner]

Best of luck Gary ...... I lost track of the problem some time ago!!  I THINK the problem is still trying to plot a daily max that came from a loop record on a current conditions (daily) rain intensity graph that has now become muddied by units and more!!  As far as I could see the original graph was correct, but the intensity did not match the daily max, and to make matters worse the max is from a loop record.  After that I got lost due to lack of more detailed and precise information from the OP.

[Pookmia Romero]

For example, it has just a storm, 30 mm in total, maximum intensity 134mm/h , the graph is less a 8mm/h.

[Andrew Milner]

WHICH graph showed maximum intensity less than 8? 

What time showed maximum intensity less than 8? 

What time was maximum intensity 134 mm/h?

What are the rainfall and rainrate columns in the archive table for the period surrounding the time of the maximum intensity?

What is in the daily rainrate table for the day with the maximum intensity?

[Andrew Milner]

The maximum intensity occurred at 18:48:11 - in other words it was in a LOOP packet.

The graphs are plotting the data from the Archive data, not the loop data.  The archive data for rain rate is a result of calculating (rainfall in archive period in minutes) * (60 / archive period in minutes).  The max value from a loop packet is the rate in a much smaller time period than the archive interval.

It is not possible to plot the intensity from the max/min daily tables, only from the archive table.

IF it was possible (but it isn't) you would have a graph where you would probably only see the maximum value and the scale would be such that all other plot data would be close to zero on the vertical scale, so the graph as such would be pretty useless and not give much information!! 

[Pookmia Romero]

In database Max has 5.3099999891676 6:48 p.m. .

All graph shows 8. Both weeks that month.

Skin.conf :

http://www.partage-facile.com/JK6GR4R34Z/skin.conf.html

Weewx.conf :

http://www.partage-facile.com/V38MDAYPRY/weewx.conf.html

[gjr80]

Hi,

Might I suggest you post the actual files to this forum rather than providing a link to some sort of hosting site that bombards you (me) with unsolicited ads. I can't speak for others on this forum but I refuse to download and look at such files.

So far I am yet to see anything in this thread or on your site that is anything other than expected behaviour. Posting weewx.conf and the applicable skin.conf will go a long way in helping us understand.

Gary

[Andrew Milner]

I still do not understand EXACTLY what your problem is.

The graph does NOT, repeat NOT plot data from the daily max/min tables.  The graphs are plotted from the data in the ARCHIVE table.

Your archive table has a max rate recorded of .279 inches/hr = 8mm/hr at time 1465318320

The absolute highest value I saw on a quick look was .29

The rain values for the archive periods around that time are .049, .079, .079, .079, .21

[Andrew Milner]

Can I suggest that you 'solve' the problem by changing weewx.conf loop_hilo to false so that the maximum values in the database max/min tables always come from the archived data and not the loop data.  This will mean that you may miss a high windgust or a super high rain rate, but you may get less confused.