[weewx-user] Re: reports = local time & PC = UTC

[William Burton]

Hello,

Based on your question, I'm assuming the desired timezone you want to run 
WeeWX under is US/Eastern. If this is incorrect, substitute as appropriate 
below.

Try this experiment on your shell (assumes bash):
$ date
# displays date in UTC time (default on your machine)
$ TZ=US/Eastern date
# displays date in the US Eastern timezone

This works as it's possible to set and export any environment variable by 
specifying it on the command line before the command to be executed. The 
assignment only applies to the following command and would not affect any 
subsequent commands.

The following solution is completely untested with WeewX so YMMV.

>From what I read, it appears possible to define environment variables in a 
.service file like weewx.service (see the systemd.exec man page):

[Service]
*Environment="TZ=US/Eastern" *
ExecStart=/home/weewx/bin/weewxd --daemon --pidfile=/var/run/weewx.pid 
/home/weewx/weewx.conf

WARNING: Don't do this with an existing database unless you have already 
reprocessed the data appropriately before restarting WeewX. Otherwise, 
start with a fresh archive database.

Also, since you may need to run the WeeWX utilites from time to time, you 
should edit your .profile or .bash_profile in your weewx account adding:
export TZ=US/Eastern

Also make sure when you run sudo from the weewx account, that TZ is set 
correctly. If not, you may have to edit your .bashrc or sudo config in /etc.

In general, you have to be really careful when running any WeeWX commands 
that the TZ environment variable is set correctly.

Hope this helps,
-Bill

On Friday, March 20, 2020 at 10:33:04 PM UTC-4, GCC Observatory wrote:
>
> Hello,
>
> Been using weewx for a while now and have always wondered if there's a way 
> to configure it to generate reports that use local time (UTC-5 for me) when 
> the PC clock is set to UTC.  I'm asking because my weewx runs on the same 
> PC as my observatory control software - I'd prefer to set the computer 
> clock to UTC, but the last time I did that, it messed up the weewx 
> reports.  Can anyone tell me if it's possible to "trick" weewx into 
> generating local time reports while keeping the computer clock set to UTC?
>
> Thanks
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f4b08a19-9f72-452c-8f5a-8b017ad05f6e%40googlegroups.com.

Re: [weewx-user] Re: how to insert additional data (cpu temp) into skins?

[gjr80]

Hi,

Most likely cause is that you have entered some code in the wrong place. Can 
you post the entire contents of your /usr/share/weewx/user/cputemp.py ?

Gary

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/cdb61bd1-6791-4c37-8383-4990944d669c%40googlegroups.com.

Re: [weewx-user] Re: how to insert additional data (cpu temp) into skins?

[Vetti52]

Thanks a lot for your idea!
Works perfect!
BTW, after modification with the if .. then ... else part, I get an error: 

Mar 24 21:04:59 raspbee weewx[618]: File 
"/usr/share/weewx/user/cputemp.py", line 19, in AddCpuTemp
Mar 24 21:04:59 raspbee weewx[618]:   if 
event.record['usUnits'] == weewx.US:
Mar 24 21:04:59 raspbee weewx[618]:   NameError: name 'event' is 
not defined
Mar 24 21:04:59 raspbee weewx[618]:   Exiting.

Maybe, my copy/paste went messy with the identation?

Sorry for my poor python skills, please.

Am Mittwoch, 18. März 2020 19:48:21 UTC+1 schrieb Mike Revitt:
>
> Thanks Thomas, easy when you know how
>
> On Wednesday, March 18, 2020 at 6:27:59 PM UTC, Thomas Keffer wrote:
>>
>> import weewx
>>
>> if event.record['usUnits'] == weewx.US:
>> event.record['extraTemp1'] = ( cpu.temperature * 1.8 ) + 32
>> else:
>> event.record['extraTemp1'] = cpu.temperature
>>
>> -tk
>>
>>
>> On Wed, Mar 18, 2020 at 8:38 AM Mike Revitt  wrote:
>>
>>> Thanks Thomas,
>>>
>>> Was looking at that but didn't know how, my Raspberry Pi reports the 
>>> temperature in Celsius and the database is in Fahrenheit and obviously a 
>>> check would be best. 
>>>
>>> But how to do that easily?
>>>
>>>
>>> On Wednesday, March 18, 2020 at 2:14:32 PM UTC, Thomas Keffer wrote:

 Well done!

 However, your extension makes the assumption that the archive record is 
 always in US Customary. Best to put a check in there before doing the 
 conversion.

 -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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/0cd4a4b2-bf30-4f34-a567-4bff9120903f%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a61bff93-2d68-45c6-9473-e716cf332e9d%40googlegroups.com.

[weewx-user] 2 question to FileParse

[Astrid]

Hello!

I am using 3.9.2 and want to use FileParser.py as driver.

I choose manuly installation.

In the ReadMe is written, to put in in
.../weex/bin/user
but my installation has only
.../weex/user
It does not have any
.../weex/bin

So is it ok, to put it in 
.../weex/user

And the other question is how to get the timestamp
into the file?
Which keyword must it have?

Would for the datafile ok something this:

time = 1585060980
outTemp = 56.3
outHumidity = 26

Or another keyword for the timestamp?
I do not find something about timestemp in readme.

Regards, Astrid

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/11ac0d8c-89ef-4ada-9e39-9258d58346f9%40googlegroups.com.

Re: [weewx-user] Re: Belchertown skin 1.0 released!

[Meteo Oberwallis]

Hi there.

It should look like the first (1.JPG) graphic. The second does not represent 
the months, but the days (2.JPG).



Am Dienstag, 24. März 2020 08:30:57 UTC+1 schrieb Gert Andersen:
>
> Hi
>
> Please explain what you think is wrong?
>
> Gert
>
> On Tuesday, March 24, 2020 at 7:30:31 AM UTC+1, Meteo Oberwallis wrote:
>>
>>
>> Hello Pat.
>>
>> Thank you very much. But now it looks like this to me. Why is that?
>>
>> Thanks for you Help!
>>
>>
>> Am Montag, 23. März 2020 17:58:24 UTC+1 schrieb Pat:
>>>
>>> Place the code I've pasted to you beneath the Solarstrahlung chart 
>>> you've created. 
>>>
>>>[[avgclimatethisyear]]
>>> title = "Average Climatological Values for This Year"
>>> type = spline
>>> time_length = year
>>> aggregate_type = max
>>> aggregate_interval = 86400 # 1 day
>>> gapsize = 8640
>>> xAxis_groupby = month
>>> xAxis_categories = 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 
>>> 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'
>>> [[[outTemp]]]
>>> zIndex = 2
>>> name = Max Temperature
>>> color = red
>>> [[[outTemp_min]]]
>>> name = Min Temperature
>>> observation_type = outTemp
>>> aggregate_type = min
>>> zIndex = 2
>>> [[[rainTotal]]]
>>> name = Rain Total
>>> type = column
>>> yAxis = 1
>>> zIndex = 0
>>> color = "#268bd2"
>>>
>>>
>>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ceaccbea-8663-46a2-a72c-97d8606636a3%40googlegroups.com.

[weewx-user] Re: ftp does not work

[Astrid]

Hello!

Thanx. Yes, I read the documentation.
But I do not understand it in all detail, sorry.

But now with your explanation I understand. :)

Thanx. :)

Regards, Astrid

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/79112057-e639-4635-847a-c2496b361c85%40googlegroups.com.

Re: [weewx-user] Re: Belchertown skin 1.0 released!

[Pat]

Are you running the development 1.1 beta version of the skin?  You can 
download it here 
.  
Install it just like you did the first time then restart weewx. Also save 
your graphs.conf.example and move them to graphs.conf since the upgrade 
will erase graphs.conf.example

On Tuesday, March 24, 2020 at 2:30:31 AM UTC-4, Meteo Oberwallis wrote:
>
>
> Hello Pat.
>
> Thank you very much. But now it looks like this to me. Why is that?
>
> Thanks for you Help!
>
>
> Am Montag, 23. März 2020 17:58:24 UTC+1 schrieb Pat:
>>
>> Place the code I've pasted to you beneath the Solarstrahlung chart you've 
>> created. 
>>
>>[[avgclimatethisyear]]
>> title = "Average Climatological Values for This Year"
>> type = spline
>> time_length = year
>> aggregate_type = max
>> aggregate_interval = 86400 # 1 day
>> gapsize = 8640
>> xAxis_groupby = month
>> xAxis_categories = 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 
>> 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'
>> [[[outTemp]]]
>> zIndex = 2
>> name = Max Temperature
>> color = red
>> [[[outTemp_min]]]
>> name = Min Temperature
>> observation_type = outTemp
>> aggregate_type = min
>> zIndex = 2
>> [[[rainTotal]]]
>> name = Rain Total
>> type = column
>> yAxis = 1
>> zIndex = 0
>> color = "#268bd2"
>>
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/67d1c4b0-758e-4c07-b1c1-6757ca365e6e%40googlegroups.com.

Re: [weewx-user] Re: ftp does not work

[Thomas Keffer]

The FTP "skin" is not a regular "skin". Unlike other skins, such as
Standard, it does not produce graphs and HTML pages. Instead, it uses the
reportgenerator machinery to move files via FTP.

The option "skin" under [[FTP]] is there so reportgenerator can find what
it needs to run FTP. It does NOT specify the skin that will be the source.
That is specified by HTML_ROOT.

Again, this is all in the documentation. It pays to read it.

-tk



On Tue, Mar 24, 2020 at 5:33 AM Astrid  wrote:

> Hello!
>
> Thanx a lot, now it works. :)
>
> But I do not understand.
> There is standing in FTP-section: skin=Ftp
> But it takes the Standard-Skin.
> But no matter, that I do not understand.
> This it, what I want, the Standard-Skin. ;)
> (In the moment, perhaps changing someone
> to another.)
>
> Regards, Astrid
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/bc5a5529-0836-45f9-9f35-24dbfe949627%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zECgDMjmHTWtEG-P_XrkGZYcjz2NLWupyRjfAAGuiW%2BEtw%40mail.gmail.com.

[weewx-user] Re: ftp does not work

[Astrid]

Hello!

Thanx a lot, now it works. :)

But I do not understand.
There is standing in FTP-section: skin=Ftp
But it takes the Standard-Skin.
But no matter, that I do not understand.
This it, what I want, the Standard-Skin. ;)
(In the moment, perhaps changing someone
to another.)

Regards, Astrid

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/bc5a5529-0836-45f9-9f35-24dbfe949627%40googlegroups.com.

[weewx-user] Re: wee_import csv problem "csv.Error: line contains NULL byte"

[gjr80]

Don't get too wrapped around the axles about what happens with the output 
from genArchiveRecords(), WeeWX will take care of it. Just like a driver 
emits loop packets and WeeWX accumulates the data from these loop packets 
and (if necessary) emits an archive record, WeeWX will take care of the 
archive records emitted from genArchiveRecords(). By the sounds of it the 
need to reset the history via a button on the console may be the real 
problem, guess it will come down to exactly how the station works and what 
it can/can't do. Sounds like some experimentation will be required.

Gary

On Tuesday, 24 March 2020 05:12:14 UTC+10, Bob Atchley wrote:
>
> Hi Janne,
>
> I think it is possible.  The driver  includes a function 
> "genArchiveRecords" which I have not yet implemented for the ws6in1 driver 
> (yet ... getting it working was the important thing first), but I think the 
> purpose would be to do precisely what you want.  I'm not sure how it is 
> invoked or what it does with the archive records, but I think I have the 
> required information to implement the function.
> Be warned though that the manual for my Youshiko YC9388 (so the same for 
> your Ventus) says that the history can only be reset at the console, and 
> once the buffer is full it will not keep any more history, so once you have 
> successfully imported the data you need to clear the history at the console 
> (step 7 in your sequence should be to reset the buffer ... maybe after you 
> have taken a backup of the database)
>
> Regards
>
> Bob
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7becdc23-6f84-492e-bf2e-f4bd48d591aa%40googlegroups.com.

[weewx-user] Re: wee_import csv problem "csv.Error: line contains NULL byte"

[gjr80]

On Tuesday, 24 March 2020 00:57:57 UTC+10, Janne Prokkola wrote:
>
> hi
>
> thanks for a good answer. Yesterday after my posting I thought also the 
> reason might be in csv. I tried several different programs like Gedit and 
> Libreoffice and in the end I managed to import my csv to weewx. 
> Unfortunately I did not understand why. 
>

As I said, the issue was some non-displaying characters/bytes at the start 
of the file, specifically the UTF-8 BOM 
. Most likely inserted 
by the program that created the file or an editor used to edit the file. At 
present wee_import cannot handle those characters so the only way to import 
such a file is to delete the characters.
 

> Now I have to find a reasonable workaround to get csv imported to weewx. 
> You might ask why I need this? I'm going to install my Ventus to our 
> cottage without PC connection. When I visit my cottage I'd like to read the 
> history data from my Ventus W835. The manufacturer of Ventus provide a 
> Windows program (Weather Tool v1.exe) to do this, and the output is csv. 
>
> My steps are following
> 1) download history-data from weather station (Windows)
> 2) open file in Linux
> 3) change wind directions (N, E, etc) to degrees
> 4) merge date and time to one column (maybe not necessary to convert it to 
> timestamp?)
> 5) get rid of BOM
> 6) import to weewx
>

Date and time needs to be in a single field/column but can be in any format 
that can be represented by Python strptime() format codes 
.
 
There is no need to convert to Unix epoch timestamps. I have a long 
outstanding task  to allow 
compass point directions to be used in CSV imports. Seems I might have some 
spare time on my hands now so I will see if I can get that implemented in 
the not too distant future. The BOM issue is being worked on and should be 
solved in WeeWX 4.0. So if you have a lot of data to import if you wait a 
for short while it should make your task of importing your data somewhat 
easier. 

>
> Just too many steps to do it regularly. A nice script would help. Maybe I 
> have to try to write one.
>

A script or a decent (code) editor with some well thought out 
regexs/searches/replaces will make life easier.

Or will there be in the future an option to download the history data 
> stored in weather station directly to weewx?
>

Downloading history stored in the station is a driver issue not a '
wee_import' issue. Some station hardware supports it, some does not. Of the 
stations that do support it some drivers implement it and some do not (for 
a variety of reasons). By the sounds of it your station may support 
downloading the history but the driver is yet to implement the feature.

Gary

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ac09c409-25ce-461c-a099-afaca13e13ce%40googlegroups.com.

Re: [weewx-user] Re: Original Dallas Semiconductor 8 reed switch wind vane with DS2407 and DS2401 1-wire chips

[Glenn McKechnie]

Further to this, and referencing the following article...
https://www.element14.com/community/groups/internet-of-things/blog/2015/01/07/old-meets-new-the-1-wire-weather-station-on-the-spark-core-part-5

You have reed switches that are normally open (off).
They are connected to identifiable locations (unique DS2401 id code
corresponding to a compass direction.)
Depending on the position of the wind vane, the magnet will close the
reed switch and power up the DS2401 when the DS2407 is turned on.

So, If the DS2407 is queried , by turning it on (and immediately
afterwards it must be turned off ) then the ID of the DS2401 can be
read by the bus, that value can then be passed to the software where
its cardinal value can be returned. It can easily return 8 points,
with a little more interpretation it can return up to 16 points (if it
reads 2 DS2401 ids).

Seems reasonably simple. :-) Don't think I missed any show stoppers!

It would be within the scope of owfs.py, once a mechanism of cleanly
querying the DS2407 is worked out.
owfs.py can certainly read an id, and the comparison function might be
a little unwieldy but its not a unique problem. (The example above
already has the getValues() {[...]} code which translates to a series
of python elif 's)

If the unit still works (testing the unit as per my previous post with
OWW) then it would be worth pursuing (nothing worse than a dead unit
when writing code! Been there done that.)



On 24/03/2020, Glenn McKechnie  wrote:
> I don't have one of these, so what follows is only building on what
> you've reported.
>
> As you say, the weewx-owfs driver appears to be focused on voltage
> sensing/conversion.
> As I recall the AAG windvane (at least the one I had and can't find)
> used reed switches so its logic started from simple switching and that
> worked with the OWW software. The very early AAG windvane was a direct
> copy of the original Dallas windvane so perhaps there is code in OWW
> for it?
>
> Viewing the src/weather.c from OWW it mentions a DS2407 in association
> with 8 DS2401's and while that references Dallas's original Win32
> software there is another reference. Later in the file it suggests OWW
> does a search for a DS2407 Vane switch and is happy if it finds one...
>
> line number 3281 of weather.c
>
> ReadWindDirection ( /*uchar SwitchID[8] */ int vane)
> {
>   int dira = -1, dirb = -1, i, found = 0;
>   uchar DirSN[MAX_DEVS_SEARCH][8];
>   int p ;
>   p = devices_portnum(vane) ;
>
>   memset ((void *) DirSN, 0, MAX_DEVS_SEARCH * 8 * sizeof (uchar));
>
>   /* Access the Vane Switch - Vane IDs are behind this */
>
>   if (!devices_access (vane))
>   {
> werr (WERR_AUTOCLOSE, _("Could not access Vane Switch"));
> return -1;
>   }
>
>   /* connect channel B of DS2407 */
>   /* There shouldn't be any trouble here, but may as well
>* use the robust function */
>   if (!set_switch_robust (vane, SWITCH_AOFF_BON, SWITCH_TRIES))
>   {
> werr (WERR_DEBUG0, "Connect channel B of DS2407 failed");
> return -1;
>   }
>
>   /* delay to allow presence pulse to proceed */
>   msDelay (10);
>
>   /* record all of DS2401's found */
>
> In short, it appears to have some relevant code. (Assuming I'm reading
> it correctly)
>
> Also, looking back in the weewx-user archive I note that you detected
> 2 DS2406s using OWFS.py The DS2407 is the next gen version of that
> semi.
>
> Have you tried running this using OWW?
> https://sourceforge.net/projects/oww/
>
> If that works, well ... ?
>
> As a final note, I just found the following that was linked from a
> 2015 weewx-user post
> https://groups.google.com/forum/#!topic/weewx-user/Nn0P0xzxTaY
> and that points to a very informative document
> https://web.archive.org/web/20061018205111/http://archives.sensorsmag.com/articles/0698/wir0698/
>
> On 24/03/2020, Bret Craytor  wrote:
>> I have searched high and low on this group to look for old threads, seems
>> everyone has the voltage Wind Direction using OWFS.
>> Can someone just point me in the right direction or to the right forum?
>> Looked at OWW too.  Thanks for any and all input.
>>
>> Bret Craytor
>>
>> On Monday, March 23, 2020 at 11:55:52 AM UTC-5, Bret Craytor wrote:
>>>
>>> Hey!
>>>
>>> Which sensor type should I use in my OWFS WEEWX conf file?  I have the
>>> addresses of the DS2401's on the PCB layout:
>>>
>>>
>>>  D E F
>>>  CG
>>>  B A H
>>> II
>>> II  -mount side (viewed from top of PCB
>>>
>>>
>>> A:  01.B5374A04
>>> B:  01.B2374A04
>>> C:  01.BA374A04
>>> D:  01.B7374A04
>>> E:  01.C6374A04
>>> F:  01.C3374A04
>>> G:  01.BD374A04
>>> H:  01.AE374A04
>>>
>>> As you can see, the first two digits after the dot are the only values
>>> that change.  Surely someone out there has already made a sensor type
>>> file
>>>
>>> for this, and can help with my weewx.conf file setup.
>>>
>>> I had some earlier posts and recieved great help, but have had to keep
>>> 

[weewx-user] Possability to add a second "target" archive DB as "data_binding to weewx.engine.StdArchive" Service?

[Rekaf]

Hi,

i have a questing regarding the "target" archive database, where weewx 
stores the weather data.
Is it possible to add a second archive database, so that weewx stores the 
same data during main loop in a second archive database?

I'm currently using one weewx instance running on my RasPi, collecting data 
from my usb connected weather station. Data will be stored in the default 
sqlite database. Thats fine, weewx takes care if units are correct 
converted, if data is already inside the database, ...
HTML Reports are generated and available in the local network, but I want 
to upload the measured data also to a remote mysql server outside of my 
network (not only copy html files to a web-server).


Example behavior:
prep_services = weewx.engine.StdTimeSynch 
data_services = , 
process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate, 
weewx.engine.StdQC, weewx.wxservices.StdWXCalculate 
archive_services = weewx.engine.StdArchive*Sqlite, 
weewx.engine.StdArchiveMysql* 
restful_services = weewx.restx.StdStationRegistry, 
weewx.restx.StdWunderground, weewx.restx.StdPWSweather, 
weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS 
report_services = weewx.engine.StdPrint, weewx.engine.StdReport 

Thanks in advance!

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a9087851-f2a6-4a5b-a6f2-52f72ecf540c%40googlegroups.com.

Re: [weewx-user] Re: Belchertown skin 1.0 released!

[Gert Andersen]

Hi

Please explain what you think is wrong?

Gert

On Tuesday, March 24, 2020 at 7:30:31 AM UTC+1, Meteo Oberwallis wrote:
>
>
> Hello Pat.
>
> Thank you very much. But now it looks like this to me. Why is that?
>
> Thanks for you Help!
>
>
> Am Montag, 23. März 2020 17:58:24 UTC+1 schrieb Pat:
>>
>> Place the code I've pasted to you beneath the Solarstrahlung chart you've 
>> created. 
>>
>>[[avgclimatethisyear]]
>> title = "Average Climatological Values for This Year"
>> type = spline
>> time_length = year
>> aggregate_type = max
>> aggregate_interval = 86400 # 1 day
>> gapsize = 8640
>> xAxis_groupby = month
>> xAxis_categories = 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 
>> 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'
>> [[[outTemp]]]
>> zIndex = 2
>> name = Max Temperature
>> color = red
>> [[[outTemp_min]]]
>> name = Min Temperature
>> observation_type = outTemp
>> aggregate_type = min
>> zIndex = 2
>> [[[rainTotal]]]
>> name = Rain Total
>> type = column
>> yAxis = 1
>> zIndex = 0
>> color = "#268bd2"
>>
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/28beaf05-c515-4ae6-8aae-9d05ce8c84e4%40googlegroups.com.