[weewx-user] Re: Including dynamic link in skin

[Jonathan Zitelman]

Thank you so much, works great!  I've been googling all afternoon and 
trying different scenarios, but couldn't find anything that worked.

Also happened to come across your recent skin and will have to try that out 
soon as well.

Thanks again!

-JZ


On Sunday, September 16, 2018 at 8:46:43 PM UTC-5, Pat wrote:
>
> Give this a try. Admittedly, this took a bit of trial and error with some 
> help from Google. Worked for me to get yesterday's date without having to 
> import anything. 
>
>
> #echo time.strftime('%Y%m%d', time.localtime( int( time.time() ) - 86400 ) 
> ) #
>
>
>
> On Sunday, September 16, 2018 at 9:17:39 PM UTC-4, Jonathan Zitelman wrote:
>>
>> From researching cheetah generator it looks like most of the python 
>> syntax carries over when outputting complex expressions using #echo.  So I 
>> have tried a few python options, primarily variants of datetime or 
>> time.localtime() - timedelta(1) but they're not defined.  I am not sure 
>> where I can import a module that will not be overwritten in upgrades.  I 
>> tried adding the import to /usr/share/weewx/user/extensions.py but it 
>> doesn't seem to carry over.  I have seen a few examples using time-86400, 
>> but I would have to define time in epoch values somewhere as well.
>>
>> I've learned more python than when I first installed WeeWX, and I'm 
>> trying to bridge the gaps, but I'm just not there.  Cheetah throws another 
>> kink in... and the user guide is less thorough than I would have hoped.
>>
>> Thank you in advance to any more suggestions on how to specify 
>> yesterday's date in the link either in skin.conf or index.html.tmpl!
>>
>> -Jonathan †
>>
>>
>> On Sunday, September 16, 2018 at 2:30:20 PM UTC-5, Jonathan Zitelman 
>> wrote:
>>>
>>> Thanks!  That generated the output I needed.  I also figured out why you 
>>> got the 404 (aside from an extra slash)... the day is always 'yesterday'.  
>>> I tried to define yesterday with a timedelta, but can't figure out where I 
>>> would put that.  I tried searching for a guide on cheetah on how I could 
>>> format strftime directly, but haven't been successful.  Any other advice 
>>> would be very helpful!
>>>
>>> -JZ
>>>
>>>
>>> On Sunday, September 16, 2018 at 1:11:09 PM UTC-5, Pat wrote:
>>>>
>>>> The Cheetah generator can use #echo to print 
>>>> <http://cheetahtemplate.sourceforge.net/docs/users_guide_html/users_guide.html#SECTION00081>
>>>>  the 
>>>> date (and other things)... So you can try this in index.html.tmpl:
>>>>
>>>>
>>>> #echo time.strftime('%Y%m%d')#
>>>>
>>>> So the full line would be:
>>>>
>>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/#echo 
>>>> time.strftime('%Y%m%d')#.png">
>>>>
>>>>
>>>> Which gives me this output:
>>>>
>>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/20180916.png;>
>>>>
>>>> But that img returns a 404 for me, so I think you're missing something. 
>>>> Either way, hopefully this is enough to get you started. 
>>>>
>>>>
>>>> On Sunday, September 16, 2018 at 1:50:18 PM UTC-4, Jonathan Zitelman 
>>>> wrote:
>>>>>
>>>>> I am using the standard skin on WeeWX 3.8.0.  I am trying to include a 
>>>>> link to a remote image, but the filename changes each day.  I have 
>>>>> attempted adding it directly to index.html.tmpl using PHP (I know, not 
>>>>> the 
>>>>> correct location):
>>>>>
>>>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst>>>> date(Ymd); ?>.png
>>>>>
>>>>>
>>>>> But it does not look like there is a PHP parser.  Next I added it into 
>>>>> the Extras section on skin.conf using direct python replacement, but it 
>>>>> does not parse correctly and spits out the actual code in the final HTML 
>>>>> document:
>>>>>
>>>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst' + 
>>>>> datetime.strftime.today().strftime('%Y%m%d') + '.png
>>>>>
>>>>>
>>>>> Lastly I tried python using string replacement, and this seems to 
>>>>> break the skin.conf file:
>>>>>
>>>>> skin.conf Code:
>>>>>
>>>>> fire_date = datetime.strftime.today().strftime('%Y%m%d')
>>>>> fire_img = "
>>>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst%s.png; % 
>>>>> (fire_date)
>>>>>
>>>>>
>>>>> Error:
>>>>>
>>>>> reportengine: Failed to read skin configuration file 
>>>>> /etc/weewx/skins/Standard/skin.conf for report StandardReport: Parse 
>>>>> error 
>>>>> in value at line 17.
>>>>>
>>>>>
>>>>> Does anyone have suggestions on what code to use?  Or if I should be 
>>>>> adding this in a different file?  The file on the other site is always 
>>>>> "rawsfcstMMDD.png" and I just need to parse out the date in the 
>>>>> report.
>>>>>
>>>>> -Jonathan †
>>>>>
>>>>>

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

[weewx-user] Re: Weewx doesn't update the files

[Andrew Milner]

You will have to refresh the page in the browser - you cannot just leave 
the page open and expect it to automatically update/change.

The log shows that files are being ftp'd to the remote server.  Have you 
checked the dates/times of the files on the server??  



On Monday, 17 September 2018 02:41:39 UTC+3, vince wrote:
>
> On Sunday, September 16, 2018 at 2:57:23 PM UTC-7, Jose Gomez wrote:
>>
>>
>>> Sep 16 21:50:19 raspberrypi weewx[1506]: cheetahgenerator: Generated 14 
>>> files for report StandardReport in 4.32 seconds
>>> Sep 16 21:50:23 raspberrypi weewx[1506]: imagegenerator: Generated 24 
>>> images for StandardReport in 3.58 seconds
>>> Sep 16 21:50:23 raspberrypi weewx[1506]: *copygenerator: copied 9 files 
>>> to /var/www/html/weewx*
>>> Sep 16 21:50:50 raspberrypi weewx[1506]: ftpgenerator: ftp'd 47 files in 
>>> 27.14 seconds
>>> Sep 16 21:55:14 raspberrypi weewx[1506]: manager: Added record 
>>> 2018-09-16 21:55:00 UTC (1537134900) to database 'weewx.sdb'
>>> Sep 16 21:55:14 raspberrypi weewx[1506]: manager: Added record 
>>> 2018-09-16 21:55:00 UTC (1537134900) to daily summary in 'weewx.sdb'
>>> Sep 16 21:55:16 raspberrypi weewx[1506]: wmr300: No data in heartbeat 
>>> interval,  restarting
>>> Sep 16 21:55:17 raspberrypi weewx[1506]: cheetahgenerator: Generated 14 
>>> files for report StandardReport in 1.21 seconds
>>> Sep 16 21:55:19 raspberrypi weewx[1506]: imagegenerator: Generated 24 
>>> images for StandardReport in 2.39 seconds
>>> Sep 16 21:55:19 raspberrypi weewx[1506]: *copygenerator: copied 0 files 
>>> to /var/www/html/weewx*
>>> Sep 16 21:55:40 raspberrypi weewx[1506]: ftpgenerator: ftp'd 38 files in 
>>> 21.08 seconds
>>>
>>>  
>>
>
> The copygenerator copied 0 files is normal.  That only does something once 
> when your weewx service starts up.
>
> The cheetagenerator and imagegenerator lines show that weewx is running 
> and updating the html and image files normally into wherever your 
> weewx.conf file sets them to install to.   That would be 
> /home/weewx/public_html if you installed via setup.py or alternately at 
> /var/www/html/weewx if you used the .deb or apt methods of installing.
>  
>

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

[weewx-user] Re: Including dynamic link in skin

[Pat]

Give this a try. Admittedly, this took a bit of trial and error with some 
help from Google. Worked for me to get yesterday's date without having to 
import anything. 


#echo time.strftime('%Y%m%d', time.localtime( int( time.time() ) - 86400 ) 
) #



On Sunday, September 16, 2018 at 9:17:39 PM UTC-4, Jonathan Zitelman wrote:
>
> From researching cheetah generator it looks like most of the python syntax 
> carries over when outputting complex expressions using #echo.  So I have 
> tried a few python options, primarily variants of datetime or 
> time.localtime() - timedelta(1) but they're not defined.  I am not sure 
> where I can import a module that will not be overwritten in upgrades.  I 
> tried adding the import to /usr/share/weewx/user/extensions.py but it 
> doesn't seem to carry over.  I have seen a few examples using time-86400, 
> but I would have to define time in epoch values somewhere as well.
>
> I've learned more python than when I first installed WeeWX, and I'm trying 
> to bridge the gaps, but I'm just not there.  Cheetah throws another kink 
> in... and the user guide is less thorough than I would have hoped.
>
> Thank you in advance to any more suggestions on how to specify yesterday's 
> date in the link either in skin.conf or index.html.tmpl!
>
> -Jonathan †
>
>
> On Sunday, September 16, 2018 at 2:30:20 PM UTC-5, Jonathan Zitelman wrote:
>>
>> Thanks!  That generated the output I needed.  I also figured out why you 
>> got the 404 (aside from an extra slash)... the day is always 'yesterday'.  
>> I tried to define yesterday with a timedelta, but can't figure out where I 
>> would put that.  I tried searching for a guide on cheetah on how I could 
>> format strftime directly, but haven't been successful.  Any other advice 
>> would be very helpful!
>>
>> -JZ
>>
>>
>> On Sunday, September 16, 2018 at 1:11:09 PM UTC-5, Pat wrote:
>>>
>>> The Cheetah generator can use #echo to print 
>>> <http://cheetahtemplate.sourceforge.net/docs/users_guide_html/users_guide.html#SECTION00081>
>>>  the 
>>> date (and other things)... So you can try this in index.html.tmpl:
>>>
>>>
>>> #echo time.strftime('%Y%m%d')#
>>>
>>> So the full line would be:
>>>
>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/#echo 
>>> time.strftime('%Y%m%d')#.png">
>>>
>>>
>>> Which gives me this output:
>>>
>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/20180916.png;>
>>>
>>> But that img returns a 404 for me, so I think you're missing something. 
>>> Either way, hopefully this is enough to get you started. 
>>>
>>>
>>> On Sunday, September 16, 2018 at 1:50:18 PM UTC-4, Jonathan Zitelman 
>>> wrote:
>>>>
>>>> I am using the standard skin on WeeWX 3.8.0.  I am trying to include a 
>>>> link to a remote image, but the filename changes each day.  I have 
>>>> attempted adding it directly to index.html.tmpl using PHP (I know, not the 
>>>> correct location):
>>>>
>>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst>>> date(Ymd); ?>.png
>>>>
>>>>
>>>> But it does not look like there is a PHP parser.  Next I added it into 
>>>> the Extras section on skin.conf using direct python replacement, but it 
>>>> does not parse correctly and spits out the actual code in the final HTML 
>>>> document:
>>>>
>>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst' + 
>>>> datetime.strftime.today().strftime('%Y%m%d') + '.png
>>>>
>>>>
>>>> Lastly I tried python using string replacement, and this seems to break 
>>>> the skin.conf file:
>>>>
>>>> skin.conf Code:
>>>>
>>>> fire_date = datetime.strftime.today().strftime('%Y%m%d')
>>>> fire_img = "https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst%s.png; 
>>>> % (fire_date)
>>>>
>>>>
>>>> Error:
>>>>
>>>> reportengine: Failed to read skin configuration file 
>>>> /etc/weewx/skins/Standard/skin.conf for report StandardReport: Parse error 
>>>> in value at line 17.
>>>>
>>>>
>>>> Does anyone have suggestions on what code to use?  Or if I should be 
>>>> adding this in a different file?  The file on the other site is always 
>>>> "rawsfcstMMDD.png" and I just need to parse out the date in the report.
>>>>
>>>> -Jonathan †
>>>>
>>>>

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

Re: [weewx-user] weewx 3.8.2, Raspberry Pi3B+, Vantage driver seems to be bouncing

[jfk]

Hello there,

To close this out, turns out the RaspberryPi POE hat has some problems, 
which was bouncing the USB ports

https://www.raspberrypi.org/forums/viewtopic.php?f=45=220984=8ffc99c87087908a51116019fa00d2fb=125

Using USB power, and 3.8.2 is running fine.

Jim


On Thursday, September 6, 2018 at 7:57:48 PM UTC-7, jfk wrote:
>
> Hello there,
>
> I was coming form 3.8.0. I'm pretty sure the problem is the Raspberry pi 
> 4.14 kernel update. I did another
>
> sudo rpi-update
>
> And it seems much happier talking to the vantage. I did see a couple
>
> Sep  6 19:49:30 dcrwx weewx[472]: vantage: DMPAFT try #1; error: Timeout 
> in get_data_with_crc16
>
> But it added records, and is generating pages
>
> | You are using the port /dev/vantage. Make sure it points to the port you 
> think it points to. 
>
> Yea, I had to mess with my udev entry to make it happy with the 4.14 
> updates, but this seems to work well:
>
> ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", 
> ATTRS{idProduct}=="ea60", SYMLINK+="vantage", TAG+="systemd", 
> ENV{SYSTEMD_WANTS}="weewx.service", GROUP = "drycreekwxuser", MODE = "664"
>
> Jim
>
>
> On Friday, August 31, 2018 at 4:28:35 PM UTC-7, Thomas Keffer wrote:
>>
>> What version did you update from? There have been no significant changes 
>> to the Vantage runtime in years --- just configuration changes.
>>
>> You are using the port /dev/vantage. Make sure it points to the port you 
>> think it points to. As an experiment, try using the real port name (usually 
>> /dev/ttyUSB0). If that works, you know you have a udev problem. 
>>
>> -tk
>>
>>
>>
>> On Fri, Aug 31, 2018 at 3:07 PM jfk  wrote:
>>
>>> Hello there,
>>>
>>> Did a full update to the latest Raspberry PI 3B+, Weewx 3.8.2 it seems 
>>> either the vantage tty is bouncing, or weewx has some issue with it:
>>>
>>> Aug 31 14:56:17 dcrwx weewx[12677]: engine: Initializing weewx version 
>>> 3.8.2
>>>
>>> Aug 31 14:56:17 dcrwx weewx[12677]: engine: Using Python 2.7.13 
>>> (default, Nov 24 2017, 17:33:09) #012[GCC 6.3.0 20170516]
>>>
>>> Aug 31 14:56:17 dcrwx weewx[12677]: engine: Platform 
>>> Linux-4.14.66-v7+-armv7l-with-debian-9.4
>>>
>>> Aug 31 14:56:17 dcrwx weewx[12677]: engine: Locale is 'en_US.UTF-8'
>>>
>>> Aug 31 14:56:17 dcrwx weewx[12677]: engine: pid file is 
>>> /var/weewx/run/weewx.pid
>>>
>>> Aug 31 14:56:17 dcrwx weewx[12683]: engine: Using configuration file 
>>> /home/drycreekwxuser/weewx/weewx.conf
>>>
>>> Aug 31 14:56:17 dcrwx weewx[12683]: engine: Loading station type Vantage 
>>> (weewx.drivers.vantage)
>>>
>>> Aug 31 14:56:17 dcrwx weewx[12651]: .
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: engine: StdConvert target unit is 0x1
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: wxcalculate: The following values 
>>> will be calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
>>> dewpoint=prefer_hardware, appTemp=prefer_hardware, 
>>> rainRate=prefer_hardware, windrun=prefer_hardware, 
>>> heatindex=prefer_hardware, maxSolarRad=prefer_hardware, 
>>> humidex=prefer_hardware, pressure=prefer_hardware, 
>>> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
>>> cloudbase=prefer_hardware
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: wxcalculate: The following 
>>> algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: engine: Archive will use data 
>>> binding wx_binding
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: engine: Record generation will be 
>>> attempted in 'hardware'
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: engine: Using archive interval of 
>>> 300 seconds (specified by hardware)
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: engine: Using binding 'wx_binding' 
>>> to database 'weewx.sdb'
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: manager: Starting backfill of daily 
>>> summaries
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: restx: StationRegistry: Registration 
>>> not requested.
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: restx: Wunderground: Posting not 
>>> enabled.
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: restx: PWSweather: Posting not 
>>> enabled.
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: restx: CWOP: Posting not enabled.
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: restx: WOW: Posting not enabled.
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: restx: AWEKAS: Posting not enabled.
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: engine: Starting up weewx version 
>>> 3.8.2
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: engine: Clock error is -0.10 seconds 
>>> (positive is fast)
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: manager: Added record 2018-08-31 
>>> 14:25:00 PDT (1535750700) to database 'weewx.sdb'
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: manager: Added record 2018-08-31 
>>> 14:25:00 PDT (1535750700) to daily summary in 'weewx.sdb'
>>>
>>> Aug 31 14:56:18 dcrwx weewx[12683]: manager: Added record 2018-08-31 
>>> 14:30:00 PDT (1535751000) to database 'weewx.sdb'
>>>
>>> Aug 31 

Re: [weewx-user] Error in Main Loop after Gentle wake up

[Thomas Keffer]

Committed in b989eab

.

I guess in nearly 10 years and thousands of users, your VP2 is the first
with an older "Type A" firmware!

-tk

On Sun, Sep 16, 2018 at 12:14 PM Michael Loconte  wrote:

> Thanks for your help! I have had this new version of vantage.py running
> for a few hours now and it all seems to be going well!
>
> Also, BTW I like that you have a mobile site included, I had to roll my
> own on wview!
>
> Thanks again,
> Mike
>
> On Saturday, September 15, 2018 at 5:30:46 PM UTC-7, Thomas Keffer wrote:
>>
>> No, I don't think it's necessary to update the firmware. We can make it
>> work.
>>
>> The problem is a bug in the driver that sets the value of the raw loop
>> data to None for older, "Type A" firmware, then tries to decode it.
>>
>> Try this version of vantage.py.
>>
>> -tk
>>
>> On Sat, Sep 15, 2018 at 5:16 PM Michael Loconte 
>> wrote:
>>
>>> Hi Thomas,
>>>
>>> Ah! My console is displaying a low battery message now, but wasn't
>>> earlier. Related perhaps?  wee_device (very cool BTW) reports that it is
>>> Vantage driver version 3.0.11 (from 2001), so I guess I should consider
>>> upgrading the firmware!
>>>
>>> Mike
>>>
>>> On Saturday, September 15, 2018 at 4:06:41 PM UTC-7, Thomas Keffer wrote:

 Hello, Michael and welcome to the WeeWX user's group

 The function _null_int() is only used to decode the battery status and
 the barometric trend icon, so your change is probably innocuous enough.
 However, I wonder why it is happening. Could you please check for the
 firmware version of your station?

 *wee_device --info*

 -tk

 On Sat, Sep 15, 2018 at 3:37 PM Michael Loconte 
 wrote:

> Hello,
>
> First off here are my details:
>
>- Raspberry Pi 3, Raspian 9 (Jessie)
>- Davis Vantage Pro (model 6160)
>- Serial to USB, connected at /dev/ttyUSB0
>- Python 2.7.9
>- weewx 3.8.2 (according to my weewx.conf)
>
>
> I am a long time (since 2008ish) user of wview and made the switch a
> few weeks ago to weewx. The install went smooth, moved my sdb files over,
> but I couldn't see any pages being generated in the html folder.  I have
> lurked a bit here and read about how to set the debug level in the
> weewx.conf and I have been watching the logs. I also haven't had a ton of
> time to sit down and think things through until today. What I have been
> observing is, I believe, weewx can connect to my data logger and download
> data, parse it, and insert into the sdb.  There is a odd thing happening
> though, the date time stamp is in UTC but the time zone designation is
> Pacific Daylight Time (which is my time zone).  After weewx downloads from
> the data logger it tries to connect to the console, and start the "main
> loop." It's here that the program crashes and exits. I have attached the
> log (mainLoopError_NoneType.txt), if you take a look you will see that
> weewx acknowledges that my raspberry pi's clock (PDT) is less than the UTC
> time coming that the record has (my vantage console has the PDT time
> displayed). Also you will see in the log file that at line 1677 in the
> vantage.py file is where the program crashes. It looks like the value
> passed into the _null_int() function is null and the function cant return
> the integer of a null value. So, here is where I decided to try and handle
> the error. I edited vantage.py and added an if statement to only return 
> the
> integer if the value is not None. I don't really know the repercussions of
> doing this because I haven't dug through the entire program to trace out
> what this value is.
>
>> # Try to handle NoneType error
>>
>> def _null_int(v):
>>
>> if v is not None:
>>
>> return int(v)
>>
>>
>
> After saving and restarting weewx the program doesn't error out and my
> html pages are finally generated! Very exciting but I am wondering if
> anyone here has the experience to know why my console was sending a null
> value and whether my error handling will have any negative effects. I am
> attaching the log file after my little fix for your review too
> (afterEditVantagePy.txt).
>
> Thanks, I am excited to get this up and running!
>
> Mike
>
> --
> 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.
>
 --
>>> 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 

[weewx-user] Re: Including dynamic link in skin

[Jonathan Zitelman]

>From researching cheetah generator it looks like most of the python syntax 
carries over when outputting complex expressions using #echo.  So I have 
tried a few python options, primarily variants of datetime or 
time.localtime() - timedelta(1) but they're not defined.  I am not sure 
where I can import a module that will not be overwritten in upgrades.  I 
tried adding the import to /usr/share/weewx/user/extensions.py but it 
doesn't seem to carry over.  I have seen a few examples using time-86400, 
but I would have to define time in epoch values somewhere as well.

I've learned more python than when I first installed WeeWX, and I'm trying 
to bridge the gaps, but I'm just not there.  Cheetah throws another kink 
in... and the user guide is less thorough than I would have hoped.

Thank you in advance to any more suggestions on how to specify yesterday's 
date in the link either in skin.conf or index.html.tmpl!

-Jonathan †


On Sunday, September 16, 2018 at 2:30:20 PM UTC-5, Jonathan Zitelman wrote:
>
> Thanks!  That generated the output I needed.  I also figured out why you 
> got the 404 (aside from an extra slash)... the day is always 'yesterday'.  
> I tried to define yesterday with a timedelta, but can't figure out where I 
> would put that.  I tried searching for a guide on cheetah on how I could 
> format strftime directly, but haven't been successful.  Any other advice 
> would be very helpful!
>
> -JZ
>
>
> On Sunday, September 16, 2018 at 1:11:09 PM UTC-5, Pat wrote:
>>
>> The Cheetah generator can use #echo to print 
>> <http://cheetahtemplate.sourceforge.net/docs/users_guide_html/users_guide.html#SECTION00081>
>>  the 
>> date (and other things)... So you can try this in index.html.tmpl:
>>
>>
>> #echo time.strftime('%Y%m%d')#
>>
>> So the full line would be:
>>
>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/#echo 
>> time.strftime('%Y%m%d')#.png">
>>
>>
>> Which gives me this output:
>>
>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/20180916.png;>
>>
>> But that img returns a 404 for me, so I think you're missing something. 
>> Either way, hopefully this is enough to get you started. 
>>
>>
>> On Sunday, September 16, 2018 at 1:50:18 PM UTC-4, Jonathan Zitelman 
>> wrote:
>>>
>>> I am using the standard skin on WeeWX 3.8.0.  I am trying to include a 
>>> link to a remote image, but the filename changes each day.  I have 
>>> attempted adding it directly to index.html.tmpl using PHP (I know, not the 
>>> correct location):
>>>
>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst>> date(Ymd); ?>.png
>>>
>>>
>>> But it does not look like there is a PHP parser.  Next I added it into 
>>> the Extras section on skin.conf using direct python replacement, but it 
>>> does not parse correctly and spits out the actual code in the final HTML 
>>> document:
>>>
>>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst' + 
>>> datetime.strftime.today().strftime('%Y%m%d') + '.png
>>>
>>>
>>> Lastly I tried python using string replacement, and this seems to break 
>>> the skin.conf file:
>>>
>>> skin.conf Code:
>>>
>>> fire_date = datetime.strftime.today().strftime('%Y%m%d')
>>> fire_img = "https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst%s.png; 
>>> % (fire_date)
>>>
>>>
>>> Error:
>>>
>>> reportengine: Failed to read skin configuration file 
>>> /etc/weewx/skins/Standard/skin.conf for report StandardReport: Parse error 
>>> in value at line 17.
>>>
>>>
>>> Does anyone have suggestions on what code to use?  Or if I should be 
>>> adding this in a different file?  The file on the other site is always 
>>> "rawsfcstMMDD.png" and I just need to parse out the date in the report.
>>>
>>> -Jonathan †
>>>
>>>

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

[weewx-user] Re: Weewx doesn't update the files

[vince]

On Sunday, September 16, 2018 at 2:57:23 PM UTC-7, Jose Gomez wrote:
>
>
>> Sep 16 21:50:19 raspberrypi weewx[1506]: cheetahgenerator: Generated 14 
>> files for report StandardReport in 4.32 seconds
>> Sep 16 21:50:23 raspberrypi weewx[1506]: imagegenerator: Generated 24 
>> images for StandardReport in 3.58 seconds
>> Sep 16 21:50:23 raspberrypi weewx[1506]: *copygenerator: copied 9 files 
>> to /var/www/html/weewx*
>> Sep 16 21:50:50 raspberrypi weewx[1506]: ftpgenerator: ftp'd 47 files in 
>> 27.14 seconds
>> Sep 16 21:55:14 raspberrypi weewx[1506]: manager: Added record 2018-09-16 
>> 21:55:00 UTC (1537134900) to database 'weewx.sdb'
>> Sep 16 21:55:14 raspberrypi weewx[1506]: manager: Added record 2018-09-16 
>> 21:55:00 UTC (1537134900) to daily summary in 'weewx.sdb'
>> Sep 16 21:55:16 raspberrypi weewx[1506]: wmr300: No data in heartbeat 
>> interval,  restarting
>> Sep 16 21:55:17 raspberrypi weewx[1506]: cheetahgenerator: Generated 14 
>> files for report StandardReport in 1.21 seconds
>> Sep 16 21:55:19 raspberrypi weewx[1506]: imagegenerator: Generated 24 
>> images for StandardReport in 2.39 seconds
>> Sep 16 21:55:19 raspberrypi weewx[1506]: *copygenerator: copied 0 files 
>> to /var/www/html/weewx*
>> Sep 16 21:55:40 raspberrypi weewx[1506]: ftpgenerator: ftp'd 38 files in 
>> 21.08 seconds
>>
>>  
>

The copygenerator copied 0 files is normal.  That only does something once 
when your weewx service starts up.

The cheetagenerator and imagegenerator lines show that weewx is running and 
updating the html and image files normally into wherever your weewx.conf 
file sets them to install to.   That would be /home/weewx/public_html if 
you installed via setup.py or alternately at /var/www/html/weewx if you 
used the .deb or apt methods of installing.
 

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

[weewx-user] Re: Weewx doesn't update the files

[Jose Gomez]

I can't find the problem

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

[weewx-user] Re: Weewx doesn't update the files

[gjr80]

Yes

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

[weewx-user] Re: Weewx doesn't update the files

[Jose Gomez]

This?
 

> [CopyGenerator]
>
> # This section is used by the generator CopyGenerator
>
> # List of files to be copied only the first time the generator runs
> copy_once = backgrounds/*, weewx.css, mobile.css, favicon.ico, 
> smartphone/icons/*, smartphone/custom.js
>
> # List of files to be copied each time the generator runs
> # copy_always =
>


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

[weewx-user] Weewx doesn't update the files

[gjr80]

Hi,

I 'm not sure what the problem is that you are experiencing. If your concern is 
that copygenerator is only copying files once on startup then this is expected 
behaviour. Copygenerator has a 'copy_once' setting that copies static files (eg 
CSS files) once only on startup - the reason they are only copied once is that 
they do not change so there is no need to copy them every time. 

Your log indicates that archive records are being saved to database, reports 
are being generated and the results successfully ftp'd. Does the date/tine on 
your web page update over time or does it stay the same when you refresh the 
page?

The log entry about no data in the heartbeat interval may or may not be of 
consequence, unfortunately I am not familiar with the WMR300.

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

Re: [weewx-user] Re: FTP oddity

[gjr80]

The log and the config files will tell you exactly what is/isn't going on. I 
suggest you set debug=1 in weewx.conf, save weewx.conf then restart WeeWX. Let 
WeeWX run for a couple of archive intervals then post the log from startup. It 
should be clear from the log what files are being ftp'd.

Posting the [StdReport] section of weewx.conf and the highcharts skin.conf will 
reveal where the files concerned are being saved by WeeWX upon generation and 
the source directory from which the ftp generator is uploading.

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

[weewx-user] Re: Weewx doesn't update the files

[Jose Gomez]

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

[weewx-user] Weewx doesn't update the files

[Jose Gomez]

Hello. I installed the Weewx on my Raspberry Pi, but only update the files 
when start.

For example, I started the Weewx at 23:46 and the Weewx update the files to 
../weewx/ and FTP at 23:50. The update in the html says "16/09/18 23:50:00".

The station is Oregon WMR300 and I think that is working fine without 
problems.

Log:

Sep 16 21:46:38 raspberrypi weewx[1506]: wmr300: get history complete: 
> count=13 last_index=79 history_end_index=80
> Sep 16 21:46:39 raspberrypi weewx[1506]: engine: Starting main packet loop.
> Sep 16 21:47:12 raspberrypi weewx[1506]: wmr300: history buffer at 0.15% 
> (81)
> Sep 16 21:50:14 raspberrypi weewx[1506]: manager: Added record 2018-09-16 
> 21:50:00 UTC (1537134600) to database 'weewx.sdb'
> Sep 16 21:50:14 raspberrypi weewx[1506]: manager: Added record 2018-09-16 
> 21:50:00 UTC (1537134600) to daily summary in 'weewx.sdb'
> Sep 16 21:50:19 raspberrypi weewx[1506]: cheetahgenerator: Generated 14 
> files for report StandardReport in 4.32 seconds
> Sep 16 21:50:23 raspberrypi weewx[1506]: imagegenerator: Generated 24 
> images for StandardReport in 3.58 seconds
> Sep 16 21:50:23 raspberrypi weewx[1506]: *copygenerator: copied 9 files 
> to /var/www/html/weewx*
> Sep 16 21:50:50 raspberrypi weewx[1506]: ftpgenerator: ftp'd 47 files in 
> 27.14 seconds
> Sep 16 21:55:14 raspberrypi weewx[1506]: manager: Added record 2018-09-16 
> 21:55:00 UTC (1537134900) to database 'weewx.sdb'
> Sep 16 21:55:14 raspberrypi weewx[1506]: manager: Added record 2018-09-16 
> 21:55:00 UTC (1537134900) to daily summary in 'weewx.sdb'
> Sep 16 21:55:16 raspberrypi weewx[1506]: wmr300: No data in heartbeat 
> interval,  restarting
> Sep 16 21:55:17 raspberrypi weewx[1506]: cheetahgenerator: Generated 14 
> files for report StandardReport in 1.21 seconds
> Sep 16 21:55:19 raspberrypi weewx[1506]: imagegenerator: Generated 24 
> images for StandardReport in 2.39 seconds
> Sep 16 21:55:19 raspberrypi weewx[1506]: *copygenerator: copied 0 files 
> to /var/www/html/weewx*
> Sep 16 21:55:40 raspberrypi weewx[1506]: ftpgenerator: ftp'd 38 files in 
> 21.08 seconds
>
>  

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

Re: [weewx-user] Re: FTP oddity

[John Clark]

/*OK. *//*
*/

/*skin=Belchertown*//*
*/

/*http://weather.w0avq.org/json/day.json  does not exist, nor do I see 
an instance of it being uploaded in the syslog*//*

*//*
*//*public_html on your weewx system:  does not exist as a file or 
directory locally or remotely, nor can I find it in weewx.conf or skin.conf


As I said, everything was working until 0.7. My install is not the 
py_install and I.m thinking when I deleted all instances of 
"Belchertown" as I thought I saw in the instructions, I might have 
gotten something important. Might do a reinstall tonight when I get back 
home. BTW, I renamed the remote weather directory and now there are no 
graphs at all. gotta go.

*/
On 9/16/2018 9:29 AM, Pat wrote:
The file that needs to be updated is this one 
http://weather.w0avq.org/json/day.json -- what are the timestamps on 
that? And is it in your public_html on your weewx system for it to be 
copied?


In weewx.conf under [StdReport] and     [[StandardReport]], what do 
you have for skin = ?


because i see that http://weather.w0avq.org/belchertown also works, 
but I don't know why. I wouldn't think there'd be duplicate data, 
unless that's old (and maybe the problem)?


What if you delete (or backup and rename) your web server's 
public_html section and let weewx do a fresh FTP copy?


On Saturday, September 15, 2018 at 9:27:33 PM UTC-4, John Clark wrote:

john@OptiPlex /var/www/html/weewx/belchertown/json $ dir -l
total 680
-rw-r--r-- 1 root root  28689 Sep 15 19:20 darksky_forecast.json
-rw-r--r-- 1 root root  74741 Sep 15 19:50 day.json
-rw-r--r-- 1 root root   1061 Sep 15 18:50 earthquake.json
-rw-rw-r-- 1 root root 14 Sep 15 19:30 index.html
-rw-r--r-- 1 root root 270979 Sep 15 19:50 month.json
-rw-r--r-- 1 root root 151761 Sep 15 19:50 week.json
-rw-r--r-- 1 root root   8058 Sep 15 19:50 weewx_data.json
-rw-r--r-- 1 root root 137581 Sep 15 19:50 year.json

/*and the files on the server concur. as to weewx.conf*/

[[forecast]]
    HTML_ROOT = /var/www/html/weewx/forecast
    skin = forecast
    [[Highcharts_Belchertown]]
    HTML_ROOT = /var/www/html/weewx/belchertown
    skin = Highcharts_Belchertown
    [[Belchertown]]
    HTML_ROOT = /var/www/html/weewx/belchertown
    skin = Belchertown
    [[[Extras]]]


/*and just for fun, I tried localhost/weewx and got * /


404 Not Found
nginx/1.4.6 (Ubuntu)

/*(yes I did a restart, just in case) I only include this as
information since I nearly never look at it locally, always from
the web site. Also, as a note, the "earthquake fix" was 24 hours
later so I can't see how it could have an effect. I can always
look on CWOP or PWS for historical data (they are updating just
fine) so there is no overpowering rush. Just an
observation/[personal]bug report*/


On 9/15/2018 7:06 PM, Pat wrote:

Check the public_html/belchertown/json folder to make sure the
day.json, week.json, month.json and year.json files are being
updated correctly.

Also, make sure that the [[Highcharts_Belchertown]] skin's
HTML_DIR is the same as the [[Belchertown]] HTML_DIR in weewx.conf

On Saturday, September 15, 2018 at 7:34:34 PM UTC-4, John Clark
wrote:

I'm beginning to feel like the guys on Hee Haw, "If it
weren't for bad luck" When I upgraded to 0.7 (I checked
timestamps on new files) everything on the upload side seems
to be the same as before, only now there are no new graphs
after that time up til now (it just dawned on me today).
Using filezilla and looking on the web server, all files are
there with proper date and file stamp, so it seems to be a
display problem on my end. Any ideas on how and where to look?


http://weather.w0avq.org

-- 
*/John Clark/*


-- 
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
.


-- 
*/John Clark /*


--
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 
.

For more options, visit https://groups.google.com/d/optout.


--
*/John Clark /*

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

[weewx-user] Re: Including dynamic link in skin

[Jonathan Zitelman]

Thanks!  That generated the output I needed.  I also figured out why you 
got the 404 (aside from an extra slash)... the day is always 'yesterday'.  
I tried to define yesterday with a timedelta, but can't figure out where I 
would put that.  I tried searching for a guide on cheetah on how I could 
format strftime directly, but haven't been successful.  Any other advice 
would be very helpful!

-JZ


On Sunday, September 16, 2018 at 1:11:09 PM UTC-5, Pat wrote:
>
> The Cheetah generator can use #echo to print 
> <http://cheetahtemplate.sourceforge.net/docs/users_guide_html/users_guide.html#SECTION00081>
>  the 
> date (and other things)... So you can try this in index.html.tmpl:
>
>
> #echo time.strftime('%Y%m%d')#
>
> So the full line would be:
>
> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/#echo 
> time.strftime('%Y%m%d')#.png">
>
>
> Which gives me this output:
>
> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/20180916.png;>
>
> But that img returns a 404 for me, so I think you're missing something. 
> Either way, hopefully this is enough to get you started. 
>
>
> On Sunday, September 16, 2018 at 1:50:18 PM UTC-4, Jonathan Zitelman wrote:
>>
>> I am using the standard skin on WeeWX 3.8.0.  I am trying to include a 
>> link to a remote image, but the filename changes each day.  I have 
>> attempted adding it directly to index.html.tmpl using PHP (I know, not the 
>> correct location):
>>
>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst> date(Ymd); ?>.png
>>
>>
>> But it does not look like there is a PHP parser.  Next I added it into 
>> the Extras section on skin.conf using direct python replacement, but it 
>> does not parse correctly and spits out the actual code in the final HTML 
>> document:
>>
>> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst' + 
>> datetime.strftime.today().strftime('%Y%m%d') + '.png
>>
>>
>> Lastly I tried python using string replacement, and this seems to break 
>> the skin.conf file:
>>
>> skin.conf Code:
>>
>> fire_date = datetime.strftime.today().strftime('%Y%m%d')
>> fire_img = "https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst%s.png; 
>> % (fire_date)
>>
>>
>> Error:
>>
>> reportengine: Failed to read skin configuration file 
>> /etc/weewx/skins/Standard/skin.conf for report StandardReport: Parse error 
>> in value at line 17.
>>
>>
>> Does anyone have suggestions on what code to use?  Or if I should be 
>> adding this in a different file?  The file on the other site is always 
>> "rawsfcstMMDD.png" and I just need to parse out the date in the report.
>>
>> -Jonathan †
>>
>>

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

Re: [weewx-user] Error in Main Loop after Gentle wake up

[Michael Loconte]

Thanks for your help! I have had this new version of vantage.py running for 
a few hours now and it all seems to be going well!

Also, BTW I like that you have a mobile site included, I had to roll my own 
on wview!

Thanks again,
Mike

On Saturday, September 15, 2018 at 5:30:46 PM UTC-7, Thomas Keffer wrote:
>
> No, I don't think it's necessary to update the firmware. We can make it 
> work.
>
> The problem is a bug in the driver that sets the value of the raw loop 
> data to None for older, "Type A" firmware, then tries to decode it.
>
> Try this version of vantage.py.
>
> -tk
>
> On Sat, Sep 15, 2018 at 5:16 PM Michael Loconte  > wrote:
>
>> Hi Thomas,
>>
>> Ah! My console is displaying a low battery message now, but wasn't 
>> earlier. Related perhaps?  wee_device (very cool BTW) reports that it is 
>> Vantage driver version 3.0.11 (from 2001), so I guess I should consider 
>> upgrading the firmware!
>>
>> Mike
>>
>> On Saturday, September 15, 2018 at 4:06:41 PM UTC-7, Thomas Keffer wrote:
>>>
>>> Hello, Michael and welcome to the WeeWX user's group
>>>
>>> The function _null_int() is only used to decode the battery status and 
>>> the barometric trend icon, so your change is probably innocuous enough. 
>>> However, I wonder why it is happening. Could you please check for the 
>>> firmware version of your station? 
>>>
>>> *wee_device --info*
>>>
>>> -tk
>>>
>>> On Sat, Sep 15, 2018 at 3:37 PM Michael Loconte  
>>> wrote:
>>>
 Hello, 

 First off here are my details:

- Raspberry Pi 3, Raspian 9 (Jessie)
- Davis Vantage Pro (model 6160)
- Serial to USB, connected at /dev/ttyUSB0
- Python 2.7.9
- weewx 3.8.2 (according to my weewx.conf)


 I am a long time (since 2008ish) user of wview and made the switch a 
 few weeks ago to weewx. The install went smooth, moved my sdb files over, 
 but I couldn't see any pages being generated in the html folder.  I have 
 lurked a bit here and read about how to set the debug level in the 
 weewx.conf and I have been watching the logs. I also haven't had a ton of 
 time to sit down and think things through until today. What I have been 
 observing is, I believe, weewx can connect to my data logger and download 
 data, parse it, and insert into the sdb.  There is a odd thing happening 
 though, the date time stamp is in UTC but the time zone designation is 
 Pacific Daylight Time (which is my time zone).  After weewx downloads from 
 the data logger it tries to connect to the console, and start the "main 
 loop." It's here that the program crashes and exits. I have attached the 
 log (mainLoopError_NoneType.txt), if you take a look you will see that 
 weewx acknowledges that my raspberry pi's clock (PDT) is less than the UTC 
 time coming that the record has (my vantage console has the PDT time 
 displayed). Also you will see in the log file that at line 1677 in the 
 vantage.py file is where the program crashes. It looks like the value 
 passed into the _null_int() function is null and the function cant return 
 the integer of a null value. So, here is where I decided to try and handle 
 the error. I edited vantage.py and added an if statement to only return 
 the 
 integer if the value is not None. I don't really know the repercussions of 
 doing this because I haven't dug through the entire program to trace out 
 what this value is.  

> # Try to handle NoneType error
>
> def _null_int(v):
>
> if v is not None:
>
> return int(v)
>
>
  
 After saving and restarting weewx the program doesn't error out and my 
 html pages are finally generated! Very exciting but I am wondering if 
 anyone here has the experience to know why my console was sending a null 
 value and whether my error handling will have any negative effects. I am 
 attaching the log file after my little fix for your review too 
 (afterEditVantagePy.txt).

 Thanks, I am excited to get this up and running!

 Mike

 -- 
 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.

>>> -- 
>> 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.
>>
>

-- 
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.
For more options, 

[weewx-user] Re: Including dynamic link in skin

[Pat]

The Cheetah generator can use #echo to print 
<http://cheetahtemplate.sourceforge.net/docs/users_guide_html/users_guide.html#SECTION00081>
 the 
date (and other things)... So you can try this in index.html.tmpl:


#echo time.strftime('%Y%m%d')#

So the full line would be:

https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/#echo 
time.strftime('%Y%m%d')#.png">


Which gives me this output:

https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst/20180916.png;>

But that img returns a 404 for me, so I think you're missing something. 
Either way, hopefully this is enough to get you started. 


On Sunday, September 16, 2018 at 1:50:18 PM UTC-4, Jonathan Zitelman wrote:
>
> I am using the standard skin on WeeWX 3.8.0.  I am trying to include a 
> link to a remote image, but the filename changes each day.  I have 
> attempted adding it directly to index.html.tmpl using PHP (I know, not the 
> correct location):
>
> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst date(Ymd); ?>.png
>
>
> But it does not look like there is a PHP parser.  Next I added it into the 
> Extras section on skin.conf using direct python replacement, but it does 
> not parse correctly and spits out the actual code in the final HTML 
> document:
>
> https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst' + 
> datetime.strftime.today().strftime('%Y%m%d') + '.png
>
>
> Lastly I tried python using string replacement, and this seems to break 
> the skin.conf file:
>
> skin.conf Code:
>
> fire_date = datetime.strftime.today().strftime('%Y%m%d')
> fire_img = "https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst%s.png; 
> % (fire_date)
>
>
> Error:
>
> reportengine: Failed to read skin configuration file 
> /etc/weewx/skins/Standard/skin.conf for report StandardReport: Parse error 
> in value at line 17.
>
>
> Does anyone have suggestions on what code to use?  Or if I should be 
> adding this in a different file?  The file on the other site is always 
> "rawsfcstMMDD.png" and I just need to parse out the date in the report.
>
> -Jonathan †
>
>

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

[weewx-user] Including dynamic link in skin

[Jonathan Zitelman]

I am using the standard skin on WeeWX 3.8.0.  I am trying to include a link 
to a remote image, but the filename changes each day.  I have attempted 
adding it directly to index.html.tmpl using PHP (I know, not the correct 
location):

https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst.png


But it does not look like there is a PHP parser.  Next I added it into the 
Extras section on skin.conf using direct python replacement, but it does 
not parse correctly and spits out the actual code in the final HTML 
document:

https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst' + 
datetime.strftime.today().strftime('%Y%m%d') + '.png


Lastly I tried python using string replacement, and this seems to break the 
skin.conf file:

skin.conf Code:

fire_date = datetime.strftime.today().strftime('%Y%m%d')
fire_img = "https://twc.tamu.edu/weather_images/rawsfcst/rawsfcst%s.png; % 
(fire_date)


Error:

reportengine: Failed to read skin configuration file 
/etc/weewx/skins/Standard/skin.conf for report StandardReport: Parse error 
in value at line 17.


Does anyone have suggestions on what code to use?  Or if I should be adding 
this in a different file?  The file on the other site is always 
"rawsfcstMMDD.png" and I just need to parse out the date in the report.

-Jonathan †

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

Re: [weewx-user] Updating Rain graphs

[pbartko5]

Gary,

Thanks for looking into this.  You are correct, that is when I started 
using weewx and it must have also uploaded archive data to WU.  Previously, 
the Weatherlink software was uploading 3 min after the archive intervals.  
That explains the interleaving of the data.  

As a work around, I spent some time today reformating a csv export from 
Weatherlink to be compatible with wee_import.  I was able to convert the 
time stamp to epoch time and reformat the wind cardinal directions to 
degrees.  Then I imported the last 9 years of data from the csv file 
(almost a half million records).  It all worked great, I now have all my 
data going back almost a decade.  Best part is, the data is correct.

Thanks again for everyone's help.

Pete B

On Sunday, September 16, 2018 at 2:31:20 AM UTC-4, gjr80 wrote:
>
> OK, I think I can see what happened here. if you look at the WU data for 
> 21 August (tried to include an extract in a bit more readable format below 
> but with limited success) at 17:10:00 you can see a WeeWX 3.8.2 sourced 
> record and thence every 10 minutes after. The net effect is that there are 
> WeeWX sourced and 'Wunderground v.1.15' sourced interleaved records. I 
> suspect the cause is that when Pete first started WeeWX it downloaded the 
> loggers history and uploaded any archive records to WU, I'll bet at the 
> time the oldest record in the logger was 21 August 2018 17:10:00. Because 
> 21 August was a 'partial' day as far as WeeWX was concerned I imagine it 
> had trouble getting a dayRain value to upload to WU, hence the WeeWX 
> records break the integrity of the WU rain data (column with first entry 
> 5.6). Consequently when wee_import was used to import the WU data it 
> hoovered up everything, and I could see wee_import being easily tricked 
> with the dayRain values going up and down within a day. Interestingly, if 
> you look at subsequent days you still see the interleaved records but this 
> time WeeWX has a full day of data so there is much more consistency in the 
> dayRain data (still the odd error though)
>
> 2018-08-21 16:23:2023.422.91010.4East1001.6
> 3.2971.35.656Wunderground v.1.152018-08-21 20:23:20
> 2018-08-21 16:33:1223.422.91010.4East901.6
> 3.29715.649Wunderground v.1.152018-08-21 20:33:12
> 2018-08-21 16:43:0823.623.11010.4SE1341.6
> 3.29705.672Wunderground v.1.152018-08-21 20:43:08
> 2018-08-21 16:53:0423.723.21010.4SE1323.2
> 4.89705.6148Wunderground v.1.152018-08-21 20:53:04
> 2018-08-21 17:03:2023.823.31010.4SE1323.2
> 3.29705.642Wunderground v.1.152018-08-21 21:03:20
> 2018-08-21 17:10:0023.723.11010.1SE1351.6
> 9.7960054weewx-3.8.22018-08-21 21:10:00
> 2018-08-21 17:13:1223.723.11010East983.23.2
> 9605.637Wunderground v.1.152018-08-21 21:13:12
> 2018-08-21 17:20:0023.723.21010East901.6
> 11.3970043weewx-3.8.22018-08-21 21:20:00
> 2018-08-21 17:23:0823.723.21010East991.61.6
> 9705.637Wunderground v.1.152018-08-21 21:23:08
> 2018-08-21 17:30:0023.723.21010East901.66.4
> 970043weewx-3.8.22018-08-21 21:30:00
> 2018-08-21 17:33:0423.723.21010East1011.6
> 1.69705.626Wunderground v.1.152018-08-21 21:33:04
> 2018-08-21 17:40:0023.723.21009.9East901.68
> 970027weewx-3.8.22018-08-21 21:40:00
> 2018-08-21 17:43:2023.723.21010ESE1041.64.8
> 9705.614Wunderground v.1.152018-08-21 21:43:20
> 2018-08-21 17:50:0023.823.31009.8ESE1123.2
> 11.3970016weewx-3.8.22018-08-21 21:50:00
> 2018-08-21 17:53:1223.823.31009.7ESE1134.8
> 4.89705.625Wunderground v.1.152018-08-21 21:53:12
> 2018-08-21 18:00:0023.923.41009.8ESE1123.2
> 11.3970031weewx-3.8.22018-08-21 22:00:00
> 2018-08-21 18:03:0823.823.21009.7SSE1513.2
> 3.29605.644Wunderground v.1.152018-08-21 22:03:08
> 2018-08-21 18:10:0023.923.21009.8SSE1581.6
> 6.4960.80.836weewx-3.8.22018-08-21 22:10:00
> 2018-08-21 18:13:0423.823.21009.7ESE1161.6
> 1.69643.47.923Wunderground v.1.152018-08-21 22:13:04
>
> No point in trying to re-import the WU data. So the available fixes would 
> be editing the WeeWX archive for 21 August 2018 then rebuilding the daily 
> 

Re: [weewx-user] Re: FTP oddity

[Pat]

The file that needs to be updated is this one 
http://weather.w0avq.org/json/day.json -- what are the timestamps on that? 
And is it in your public_html on your weewx system for it to be copied?

In weewx.conf under [StdReport] and [[StandardReport]], what do you 
have for skin = ?

because i see that http://weather.w0avq.org/belchertown also works, but I 
don't know why. I wouldn't think there'd be duplicate data, unless that's 
old (and maybe the problem)? 

What if you delete (or backup and rename) your web server's public_html 
section and let weewx do a fresh FTP copy? 

On Saturday, September 15, 2018 at 9:27:33 PM UTC-4, John Clark wrote:
>
> john@OptiPlex /var/www/html/weewx/belchertown/json $ dir -l
> total 680
> -rw-r--r-- 1 root root  28689 Sep 15 19:20 darksky_forecast.json
> -rw-r--r-- 1 root root  74741 Sep 15 19:50 day.json
> -rw-r--r-- 1 root root   1061 Sep 15 18:50 earthquake.json
> -rw-rw-r-- 1 root root 14 Sep 15 19:30 index.html
> -rw-r--r-- 1 root root 270979 Sep 15 19:50 month.json
> -rw-r--r-- 1 root root 151761 Sep 15 19:50 week.json
> -rw-r--r-- 1 root root   8058 Sep 15 19:50 weewx_data.json
> -rw-r--r-- 1 root root 137581 Sep 15 19:50 year.json
>
> *and the files on the server concur. as to weewx.conf*
>
> [[forecast]]
> HTML_ROOT = /var/www/html/weewx/forecast
> skin = forecast
> [[Highcharts_Belchertown]]
> HTML_ROOT = /var/www/html/weewx/belchertown
> skin = Highcharts_Belchertown
> [[Belchertown]]
> HTML_ROOT = /var/www/html/weewx/belchertown
> skin = Belchertown
> [[[Extras]]]
>
>
> *and just for fun, I tried localhost/weewx and got*
>
>
> 404 Not Found
> nginx/1.4.6 (Ubuntu)   
>
> *(yes I did a restart, just in case) I only include this as information 
> since I nearly never look at it locally, always from the web site. Also, as 
> a note, the "earthquake fix" was 24 hours later so I can't see how it could 
> have an effect. I can always look on CWOP or PWS for historical data (they 
> are updating just fine) so there is no overpowering rush. Just an 
> observation/[personal]bug report*
>
> On 9/15/2018 7:06 PM, Pat wrote:
>
> Check the public_html/belchertown/json folder to make sure the day.json, 
> week.json, month.json and year.json files are being updated correctly.  
>
> Also, make sure that the [[Highcharts_Belchertown]] skin's HTML_DIR is 
> the same as the [[Belchertown]] HTML_DIR in weewx.conf
>
> On Saturday, September 15, 2018 at 7:34:34 PM UTC-4, John Clark wrote: 
>>
>> I'm beginning to feel like the guys on Hee Haw, "If it weren't for bad 
>> luck" When I upgraded to 0.7 (I checked timestamps on new files) 
>> everything on the upload side seems to be the same as before, only now 
>> there are no new graphs after that time up til now (it just dawned on me 
>> today). Using filezilla and looking on the web server, all files are there 
>> with proper date and file stamp, so it seems to be a display problem on my 
>> end. Any ideas on how and where to look?
>>
>>
>> http://weather.w0avq.org
>> -- 
>> *John Clark*
>>
> -- 
> 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.
>
>
> -- 
> *John Clark *
>

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

Re: [weewx-user] Re: FTP oddity

[Pat]

The good news is that the skin is just a report. Your core data is 
untouched. 

It looks like Belchertown skin and the Highcharts companion are updating 
the files as they show recent timestamps. 

I'm not familiar with the FTP skin, personally, so I don't know why it's 
skipping these files. Maybe someone who's familiar can help?

On Saturday, September 15, 2018 at 9:27:33 PM UTC-4, John Clark wrote:
>
> john@OptiPlex /var/www/html/weewx/belchertown/json $ dir -l
> total 680
> -rw-r--r-- 1 root root  28689 Sep 15 19:20 darksky_forecast.json
> -rw-r--r-- 1 root root  74741 Sep 15 19:50 day.json
> -rw-r--r-- 1 root root   1061 Sep 15 18:50 earthquake.json
> -rw-rw-r-- 1 root root 14 Sep 15 19:30 index.html
> -rw-r--r-- 1 root root 270979 Sep 15 19:50 month.json
> -rw-r--r-- 1 root root 151761 Sep 15 19:50 week.json
> -rw-r--r-- 1 root root   8058 Sep 15 19:50 weewx_data.json
> -rw-r--r-- 1 root root 137581 Sep 15 19:50 year.json
>
> *and the files on the server concur. as to weewx.conf*
>
> [[forecast]]
> HTML_ROOT = /var/www/html/weewx/forecast
> skin = forecast
> [[Highcharts_Belchertown]]
> HTML_ROOT = /var/www/html/weewx/belchertown
> skin = Highcharts_Belchertown
> [[Belchertown]]
> HTML_ROOT = /var/www/html/weewx/belchertown
> skin = Belchertown
> [[[Extras]]]
>
>
> *and just for fun, I tried localhost/weewx and got*
>
>
> 404 Not Found
> nginx/1.4.6 (Ubuntu)   
>
> *(yes I did a restart, just in case) I only include this as information 
> since I nearly never look at it locally, always from the web site. Also, as 
> a note, the "earthquake fix" was 24 hours later so I can't see how it could 
> have an effect. I can always look on CWOP or PWS for historical data (they 
> are updating just fine) so there is no overpowering rush. Just an 
> observation/[personal]bug report*
>
> On 9/15/2018 7:06 PM, Pat wrote:
>
> Check the public_html/belchertown/json folder to make sure the day.json, 
> week.json, month.json and year.json files are being updated correctly.  
>
> Also, make sure that the [[Highcharts_Belchertown]] skin's HTML_DIR is 
> the same as the [[Belchertown]] HTML_DIR in weewx.conf
>
> On Saturday, September 15, 2018 at 7:34:34 PM UTC-4, John Clark wrote: 
>>
>> I'm beginning to feel like the guys on Hee Haw, "If it weren't for bad 
>> luck" When I upgraded to 0.7 (I checked timestamps on new files) 
>> everything on the upload side seems to be the same as before, only now 
>> there are no new graphs after that time up til now (it just dawned on me 
>> today). Using filezilla and looking on the web server, all files are there 
>> with proper date and file stamp, so it seems to be a display problem on my 
>> end. Any ideas on how and where to look?
>>
>>
>> http://weather.w0avq.org
>> -- 
>> *John Clark*
>>
> -- 
> 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.
>
>
> -- 
> *John Clark *
>

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

Re: [weewx-user] Values displayed by WeeWX skins from DarkSky API and moon phase calculations don't seem correct - Anyone else notice this?

[Philip Kutzenco]

Gary,

OK. It's working now! 

Interestingly - "sudo pip uninstall ephem" and "sudo pip uninstall pyephem" 
gave not-installed errors. However, "pip uninstall ephem" and "pip 
uninstall pyephem" both did uninstalls. It appears that installing without 
privileges puts the files in /home/pi/.local/lib/python2.7/site-packages/ .
After uninstalling both, I installed pyephem with sudo, restarted weewx and 
now am showing 46% moon illumination on both the standard skin and the 
belchertown skin.

Thanks for your (and everyone else's) help.

Now if someone can help explain the inconsistency between the DarkSky API 
download and the DarkSky.net forecast for my location I'd be grateful. If I 
see no answer to that, I can move that question to a new topic. 

Best,
Phil

On Sunday, September 16, 2018 at 1:14:28 AM UTC-4, gjr80 wrote:
>
> On Sunday, 16 September 2018 12:39:53 UTC+10, Philip Kutzenco wrote:
>>
>>
>> Plus that doesn't explain why weewx is still indicating 24% on Standard 
>> and Belchertown skins for me.
>>
>>
> Let's deal with the second problem first. It appears that installing ephem 
> and pyephem as an unprivileged causes issues, particularly for WeeWX 
> (well it does on my Debian stretch VM). I would also be using pyephem and 
> not ephem. First off let's uninstall ephem and pyephem:
>
> $ sudo pip uninstall ephem
> $ sudo pip uninstall pyephem
>
> answer y to any y/n prompts
>
> Now install pyephem making sure you have privileges:
>
> $ sudo pip install pyephem
>
> and finally restart WeeWX:
>
> $ sudo systemctl restart weewx
>
> Wait for a report cycle to complete then check you pages again.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Updating Rain graphs

[gjr80]

OK, I think I can see what happened here. if you look at the WU data for 21 
August (tried to include an extract in a bit more readable format below but 
with limited success) at 17:10:00 you can see a WeeWX 3.8.2 sourced record 
and thence every 10 minutes after. The net effect is that there are WeeWX 
sourced and 'Wunderground v.1.15' sourced interleaved records. I suspect 
the cause is that when Pete first started WeeWX it downloaded the loggers 
history and uploaded any archive records to WU, I'll bet at the time the 
oldest record in the logger was 21 August 2018 17:10:00. Because 21 August 
was a 'partial' day as far as WeeWX was concerned I imagine it had trouble 
getting a dayRain value to upload to WU, hence the WeeWX records break the 
integrity of the WU rain data (column with first entry 5.6). Consequently 
when wee_import was used to import the WU data it hoovered up everything, 
and I could see wee_import being easily tricked with the dayRain values 
going up and down within a day. Interestingly, if you look at subsequent 
days you still see the interleaved records but this time WeeWX has a full 
day of data so there is much more consistency in the dayRain data (still 
the odd error though)

2018-08-21 16:23:2023.422.91010.4East1001.6
3.2971.35.656Wunderground v.1.152018-08-21 20:23:20
2018-08-21 16:33:1223.422.91010.4East901.6
3.29715.649Wunderground v.1.152018-08-21 20:33:12
2018-08-21 16:43:0823.623.11010.4SE1341.63.2
9705.672Wunderground v.1.152018-08-21 20:43:08
2018-08-21 16:53:0423.723.21010.4SE1323.24.8
9705.6148Wunderground v.1.152018-08-21 20:53:04
2018-08-21 17:03:2023.823.31010.4SE1323.23.2
9705.642Wunderground v.1.152018-08-21 21:03:20
2018-08-21 17:10:0023.723.11010.1SE1351.69.7
960054weewx-3.8.22018-08-21 21:10:00
2018-08-21 17:13:1223.723.11010East983.23.2
9605.637Wunderground v.1.152018-08-21 21:13:12
2018-08-21 17:20:0023.723.21010East901.611.3
970043weewx-3.8.22018-08-21 21:20:00
2018-08-21 17:23:0823.723.21010East991.61.6
9705.637Wunderground v.1.152018-08-21 21:23:08
2018-08-21 17:30:0023.723.21010East901.66.4
970043weewx-3.8.22018-08-21 21:30:00
2018-08-21 17:33:0423.723.21010East1011.61.6
9705.626Wunderground v.1.152018-08-21 21:33:04
2018-08-21 17:40:0023.723.21009.9East901.68
970027weewx-3.8.22018-08-21 21:40:00
2018-08-21 17:43:2023.723.21010ESE1041.64.8
9705.614Wunderground v.1.152018-08-21 21:43:20
2018-08-21 17:50:0023.823.31009.8ESE1123.2
11.3970016weewx-3.8.22018-08-21 21:50:00
2018-08-21 17:53:1223.823.31009.7ESE1134.8
4.89705.625Wunderground v.1.152018-08-21 21:53:12
2018-08-21 18:00:0023.923.41009.8ESE1123.2
11.3970031weewx-3.8.22018-08-21 22:00:00
2018-08-21 18:03:0823.823.21009.7SSE1513.2
3.29605.644Wunderground v.1.152018-08-21 22:03:08
2018-08-21 18:10:0023.923.21009.8SSE1581.6
6.4960.80.836weewx-3.8.22018-08-21 22:10:00
2018-08-21 18:13:0423.823.21009.7ESE1161.6
1.69643.47.923Wunderground v.1.152018-08-21 22:13:04

No point in trying to re-import the WU data. So the available fixes would 
be editing the WeeWX archive for 21 August 2018 then rebuilding the daily 
summaries for that day or importing the .wlk files via a third party app. 
You could delete the 'WeeWX sourced' records from the archive for 21 August 
(for that matter through until 8 September when WeeWX is the sole source of 
data) or you could delete the 'Wunderground v.1.15' records from 21 August 
2018 17:10:00 to 8 September. I am sure a cunning query could be crafted to 
do it. One word of warning, if you use a graphical app to manipulate your 
data be careful as they can leave null strings in SQLite databases and that 
can causes issues.

I guess hardening wee_import to these sorts of errors would be good, going 
to be pretty complex though and I just see a stack more issues being thrown 
up.

Gary

On Sunday, 16 September 2018 09:57:00 UTC+10, gjr80 wrote:
>
> Will look closely at this later, got to go out.
>
> Gary
>
> On Sunday, 16 September 2018 09:23:58 UTC+10, Thomas Keffer wrote:
>>
>> I think this is Pete's 

Re: [weewx-user] Updating Rain graphs

[gjr80]

OK, I think I can see what happened here. if you look at the WU data for 21 
August (tried to include an extract in a bit more readable format below) at 
17:10:00 you can see a WeeWX 3.8.2 sourced record and thence every 10 
minutes after. The net effect is that there are WeeWX sourced and 
'Wunderground v.1.15' sourced interleaved records. I suspect the cause is 
that when Pete first started WeeWX it downloaded the loggers history and 
uploaded any archive records to WU, I'll bet at the time the oldest record 
in the logger was 21 August 2018 17:10:00. Because 21 August was a 
'partial' day as far as WeeWX was concerned I imagine it had trouble 
getting a dayRain value to upload to WU, hence the WeeWX records break the 
integrity of the WU rain data (column with first entry 5.6). Consequently 
when wee_import was used to import the WU data it hoovered up everything, 
and I could see wee_import being easily tricked with the dayRain values 
going up and down within a day. Interestingly, if you look at subsequent 
days you still see the interleaved records but this time WeeWX has a full 
day of data so there is much more consistency in the dayRain data (still 
the odd error though)












  
2018-08-21 16:23:20 23.4 22.9 1010.4 East 100 1.6 3.2 97 1.3 5.6 56 
Wunderground 
v.1.15 2018-08-21 20:23:20
2018-08-21 16:33:12 23.4 22.9 1010.4 East 90 1.6 3.2 97 1 5.6 49 Wunderground 
v.1.15 2018-08-21 20:33:12
2018-08-21 16:43:08 23.6 23.1 1010.4 SE 134 1.6 3.2 97 0 5.6 72 Wunderground 
v.1.15 2018-08-21 20:43:08
2018-08-21 16:53:04 23.7 23.2 1010.4 SE 132 3.2 4.8 97 0 5.6 148 Wunderground 
v.1.15 2018-08-21 20:53:04
2018-08-21 17:03:20 23.8 23.3 1010.4 SE 132 3.2 3.2 97 0 5.6 42 Wunderground 
v.1.15 2018-08-21 21:03:20
2018-08-21 17:10:00 23.7 23.1 1010.1 SE 135 1.6 9.7 96 0 0 54 weewx-3.8.2 
2018-08-21 
21:10:00
2018-08-21 17:13:12 23.7 23.1 1010 East 98 3.2 3.2 96 0 5.6 37 Wunderground 
v.1.15 2018-08-21 21:13:12
2018-08-21 17:20:00 23.7 23.2 1010 East 90 1.6 11.3 97 0 0 43 weewx-3.8.2 
2018-08-21 
21:20:00
2018-08-21 17:23:08 23.7 23.2 1010 East 99 1.6 1.6 97 0 5.6 37 Wunderground 
v.1.15 2018-08-21 21:23:08
2018-08-21 17:30:00 23.7 23.2 1010 East 90 1.6 6.4 97 0 0 43 weewx-3.8.2 
2018-08-21 
21:30:00
2018-08-21 17:33:04 23.7 23.2 1010 East 101 1.6 1.6 97 0 5.6 26 Wunderground 
v.1.15 2018-08-21 21:33:04
2018-08-21 17:40:00 23.7 23.2 1009.9 East 90 1.6 8 97 0 0 27 weewx-3.8.2 
2018-08-21 
21:40:00
2018-08-21 17:43:20 23.7 23.2 1010 ESE 104 1.6 4.8 97 0 5.6 14 Wunderground 
v.1.15 2018-08-21 21:43:20
2018-08-21 17:50:00 23.8 23.3 1009.8 ESE 112 3.2 11.3 97 0 0 16 weewx-3.8.2 
2018-08-21 
21:50:00
2018-08-21 17:53:12 23.8 23.3 1009.7 ESE 113 4.8 4.8 97 0 5.6 25 Wunderground 
v.1.15 2018-08-21 21:53:12
2018-08-21 18:00:00 23.9 23.4 1009.8 ESE 112 3.2 11.3 97 0 0 31 weewx-3.8.2 
2018-08-21 
22:00:00
2018-08-21 18:03:08 23.8 23.2 1009.7 SSE 151 3.2 3.2 96 0 5.6 44 Wunderground 
v.1.15 2018-08-21 22:03:08
2018-08-21 18:10:00 23.9 23.2 1009.8 SSE 158 1.6 6.4 96 0.8 0.8 36 
weewx-3.8.2 2018-08-21 22:10:00
2018-08-21 18:13:04 23.8 23.2 1009.7 ESE 116 1.6 1.6 96 43.4 7.9 23 
Wunderground 
v.1.15 2018-08-21 22:13:04


































































































































































































































No point in trying to re-import the WU data. So the available fixes would 
be editing the WeeWX archive for 21 August 2018 then rebuilding the daily 
summaries for that day or importing the .wlk files via a third party app. 
You could delete the 'WeeWX sourced' records from the archive for 21 August 
(for that matter through until 8 September when WeeWX is the sole source of 
data) or you could delete the 'Wunderground v.1.15' records from 21 August 
2018 17:10:00 to 8 September. I am sure a cunning query could be crafted to 
do it. One word of warning, if you use a graphical app to manipulate your 
data be careful as they can leave null strings in SQLite databases and that 
can causes issues.

I guess hardening wee_import to these sorts of errors would be good, going 
to be pretty complex though and I just see a stack more issues being thrown 
up.

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