[weewx-user] weewx utilities location pip install ver5.

[lecoqacr...@gmail.com]

Hello, were may I find wee_configure and some of the other utilities in the 
pip version 5?
Thank you for weewx

-- 
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/6dff618a-eb20-4a3e-9d49-cc599cdaeb26n%40googlegroups.com.

[weewx-user] Lightsail AWS

[lecoqacr...@gmail.com]

Hello weewx users
Has anyone created a synopsis of creating a weewx site on Amazon Lightsail 
for my Vantage pro 2. I have been trying to get a direction for several 
days but am too unsure of all the variables. Mike Revitt posted a synopsis 
on AWS S3 located at
 
https://www.cougar.eu.com/useful-guides/weewx-guides/publish-weewx-to-s3/index.html
Is this what I need to do or is that different from Lightsail? I was told 
that Lightsail is best option.
There is also this discussion of cloudflare by Doug Jenkins using tunnels 
but Vince and others may question it's security :
https://groups.google.com/g/weewx-user/c/hfo4UgRnWAQ/m/VthxrFJvBAAJ
I have built a network across a sugar cane field from my brothers house to 
our old unoccupied farm house (where the Vantage station is)  but am unsure 
of where to start with creating a web page so that I can see daily data.  I 
seem to have reached my limit at present. Presently using a pi4 with 
weewx.Your help is always appreciated.
Thank you

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c3b8dcec-88fa-44d9-bdfc-1dc463d3d11dn%40googlegroups.com.

[weewx-user] Nginx with weewx on Raspberry pi 4

[lecoqacr...@gmail.com]

Adding the web server states to add the following under the Nginx server :
  server {
   ...
  location /weewx {
  alias /home/weewx/public_html;
   }
 }
This is to be added in /etc/nginx/sites-enabled
May this be placed anywhere in the file or should it be at the end of the 
file?

Is there no changing of the root path from the the original to the setup.py 
install of /home/weewx/public_html or is that unnecessary? 

Are there any other changes to be made in order to get access to the 
Raspberry Pi from without the local network to see the weewx page?
If I can be pointed in the right direction it would be appreciated. 
thank you

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/57fe10d7-414a-4f9a-a76c-59e77293bb6en%40googlegroups.com.

[weewx-user] Re: Battery Status for TE923

[lecoqacr...@gmail.com]

Did the attached file get removed by the google groups filters? or did you 
not attach? Thanks

On Sunday, January 3, 2021 at 1:10:18 PM UTC-6 stelli...@gmail.com wrote:

> Solved it on my own. If others are interested, here is what I did:
>
>1. Copying the sensors.inc file from the Seasons skin to the root 
>folder of the Belchertown skin
>2. Modified the file to change from table to list style
>3. Removed sevction headings of the file
>4. included the sensors.inc via *#include "sensors.inc"*
>5. Adding the information to the Belchertown style.css file to show OK 
>in green and LOW in red
>
> The modified sensors.inc file is attached. The result can be seen on my 
> about site .
>
> Hope that this can be helpful if others want to to adjust this...
>

-- 
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/1d4dba7a-754f-4106-9b00-eeac3d754ee1n%40googlegroups.com.

[weewx-user] Sample site showing use of Highcharts

[lecoqacr...@gmail.com]

Is there a site using the seasons skin with the highcharts extension in use 
that I can see to
determine the differences between the regular seasons skin and the 
highcharts added seasons skin? thank you 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ed67bd33-1346-42b9-9808-80f22fbaf3c7n%40googlegroups.com.

Re: [weewx-user] Re: Belchertown Graphs, Reports, Records only show Index with parent directory in text.

[lecoqacr...@gmail.com]

Still haven't been able to get the Belchertown skin to show graphs page or 
the reports page. I can be sure that the error is due to something I have 
done or not done correctly.
The following shows up with the developer console (ctrl shift j ) when 
opening a graphs page from the home Belchertown screen. Maybe this can show 
something to someone of more understanding than myself.
Maybe I should stick with the seasons skin. It seems to work just as it 
should. thanks

GET file://fonts.googleapis.com/css?family=Roboto%3A300%2C400%2C700&ver=1.0 
net::ERR_INVALID_URL
index.html:28 GET 
file://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css 
net::ERR_INVALID_URL
index.html:29 GET 
file://cdnjs.cloudflare.com/ajax/libs/weather-icons/2.0.9/css/weather-icons.min.css?ver=4.7.4
 
net::ERR_INVALID_URL
index.html:30 GET 
file://ajax.googleapis.com/ajax/libs/jqueryui/1.12.1/themes/smoothness/jquery-ui.css
 
net::ERR_INVALID_URL
index.html:31 GET 
file://stackpath.bootstrapcdn.com/bootstrap/3.4.1/css/bootstrap.min.css 
net::ERR_INVALID_URL
index.html:47 GET 
file://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js 
net::ERR_INVALID_URL
index.html:48 GET 
file://ajax.googleapis.com/ajax/libs/jqueryui/1.12.1/jquery-ui.min.js 
net::ERR_INVALID_URL
index.html:49 GET 
file://cdnjs.cloudflare.com/ajax/libs/moment.js/2.24.0/moment-with-locales.min.js
 
net::ERR_INVALID_URL
index.html:50 GET file://code.highcharts.com/stock/highstock.js 
net::ERR_INVALID_URL
index.html:51 GET file://code.highcharts.com/highcharts-more.js 
net::ERR_INVALID_URL
index.html:52 GET file://code.highcharts.com/modules/exporting.js 
net::ERR_INVALID_URL
index.html:53 GET 
file://stackpath.bootstrapcdn.com/bootstrap/3.4.1/js/bootstrap.min.js 
net::ERR_INVALID_URL
belchertown.js?1607307639:37 Debug: skin.conf belchertown_debug enabled
belchertown.js?1607307639:29 Uncaught ReferenceError: moment is not defined
at belchertown.js?1607307639:29
(anonymous) @ belchertown.js?1607307639:29
index.html:108 Uncaught ReferenceError: moment is not defined
at index.html:108
(anonymous) @ index.html:108
responsive-menu.js:1 Uncaught ReferenceError: jQuery is not defined
at responsive-menu.js:1
(anonymous) @ responsive-menu.js:1
radar.js:8 The AudioContext was not allowed to start. It must be resumed 
(or created) after a user gesture on the page. https://goo.gl/7K7WLu
l @ radar.js:8


On Thursday, December 3, 2020 at 9:26:21 AM UTC-6 lecoqacr...@gmail.com 
wrote:

> Thank you for your replies, Ian and Vince. Was out of town for the holiday 
> and will investigate according to your answers. I appreciate  your help.
>
> On Fri, Nov 27, 2020, 8:42 AM ian...@kinnon.org  wrote:
>
>> I am no expert, but sounds like it might be a web server issue rather 
>> than weewx/belchertown
>>
>> Are you see anything in your web server logs?
>> I am running weewx with belchertown on a raspberry pi Debian 10.6 and my 
>> apache logs are in
>> /var/log/apache2 
>> check for access.log and error.log
>>
>> Ian
>>
>> On Tuesday, 24 November 2020 at 15:06:36 UTC lecoqacr...@gmail.com wrote:
>>
>>> Is there no answer to this issue? Pretty sure that it should be a simple 
>>> fix if someone can point me in the right direction.
>>> the seasons skin shows all graphs but the belchertown only has the 
>>> output above of the " Parent directory etc." for graphs, records, reports.
>>> Tried on weewx 3.9 with same results using debian install.
>>> On Saturday, November 21, 2020 at 12:10:58 AM UTC-6 
>>> lecoqacr...@gmail.com wrote:
>>>
>>>> Have weewx installed on Raspberry pi as a new install using the 
>>>> setup.py method.
>>>> Was trying to test the Belchertown skin after an install according to 
>>>> instructions.
>>>> The home screen of Belchertown looks normal but the Reports, Graphs and 
>>>> Records tabs only bring up the following :
>>>> Index of /home/weewx/public_html/graphs/
>>>> NameSizeDate Modified
>>>> index.html <http:///home/weewx/public_html/graphs/index.html>
>>>> 13.5 kB
>>>> 11/20/20, 10:45:19 PM
>>>>
>>>> Weewx.conf is as follows for the StdReport section
>>>> [StdReport]
>>>> 
>>>> # Where the skins reside, relative to WEEWX_ROOT
>>>> SKIN_ROOT = /home/weewx/skins/
>>>> 
>>>> # Where the generated reports should go, relative to WEEWX_ROOT
>>>> HTML_ROOT = /home/weewx/public_html/
>>>> 
>>>> # The database binding indicates which data should be used in 
>>>> reports.
>>>> data_binding = wx_binding
>>>> 
>&

[weewx-user] Re: Belchertown Graphs, Reports, Records only show Index with parent directory in text.

[lecoqacr...@gmail.com]

Is there no answer to this issue? Pretty sure that it should be a simple 
fix if someone can point me in the right direction.
the seasons skin shows all graphs but the belchertown only has the output 
above of the " Parent directory etc." for graphs, records, reports.
Tried on weewx 3.9 with same results using debian install.
On Saturday, November 21, 2020 at 12:10:58 AM UTC-6 lecoqacr...@gmail.com 
wrote:

> Have weewx installed on Raspberry pi as a new install using the setup.py 
> method.
> Was trying to test the Belchertown skin after an install according to 
> instructions.
> The home screen of Belchertown looks normal but the Reports, Graphs and 
> Records tabs only bring up the following :
> Index of /home/weewx/public_html/graphs/
> NameSizeDate Modified
> index.html <http:///home/weewx/public_html/graphs/index.html>
> 13.5 kB
> 11/20/20, 10:45:19 PM
>
> Weewx.conf is as follows for the StdReport section
> [StdReport]
> 
> # Where the skins reside, relative to WEEWX_ROOT
> SKIN_ROOT = /home/weewx/skins/
> 
> # Where the generated reports should go, relative to WEEWX_ROOT
> HTML_ROOT = /home/weewx/public_html/
> 
> # The database binding indicates which data should be used in reports.
> data_binding = wx_binding
> 
> # Whether to log a successful operation
> log_success = True
> 
> # Whether to log an unsuccessful operation
> log_failure = False
> 
> # Each of the following subsections defines a report that will be run.
> # See the customizing guide to change the units, plot types and line
> # colors, modify the fonts, display additional sensor data, and other
> # customizations. Many of those changes can be made here by overriding
> # parameters, or by modifying templates within the skin itself.
> 
> [[SeasonsReport]]
> # The SeasonsReport uses the 'Seasons' skin, which contains the
> # images, templates and plots for the report.
> skin = Seasons
> enable = false
> 
> [[SmartphoneReport]]
> # The SmartphoneReport uses the 'Smartphone' skin, and the images 
> and
> # files are placed in a dedicated subdirectory.
> skin = Smartphone
> enable = false
> HTML_ROOT = public_html/smartphone
> 
> [[MobileReport]]
> # The MobileReport uses the 'Mobile' skin, and the images and files
> # are placed in a dedicated subdirectory.
> skin = Mobile
> enable = false
> HTML_ROOT = public_html/mobile
> 
> [[StandardReport]]
> # This is the old "Standard" skin. By default, it is not enabled.
> skin = Standard
> enable = false
> [[Belchertown]]
> skin = Belchertown
> HTML_ROOT = /home/weewx/public_html/Belchertown
> enable = true
> 
> [[FTP]]
> # FTP'ing the results to a webserver is treated as just another 
> report,
> # albeit one with an unusual report generator!
> skin = Ftp
> 
> # If you wish to use FTP, set "enable" to "true", then
> # fill out the next four lines.
> # Use quotes around passwords to guard against parsing errors.
> enable = false
> user = replace_me
> password = replace_me
> server = replace_me# The ftp server name, e.g, 
> www.myserver.org
> path = replace_me# The destination directory, e.g., /weather
> 
> # Set to True for an FTP over TLS (FTPS) connection. Not all 
> servers
> # support this.
> secure_ftp = False
> 
> # To upload files from something other than what HTML_ROOT is set
> # to above, specify a different HTML_ROOT here.
> #HTML_ROOT = public_html
> 
> # Most FTP servers use port 21
> port = 21
> 
> # Set to 1 to use passive mode, zero for active mode
> passive = 1
> 
> [[RSYNC]]
> # rsync'ing to a webserver is treated as just another report
> skin = Rsync
> 
> # If you wish to use rsync, you must configure passwordless ssh 
> using
> # public/private key authentication from the user account that 
> weewx
> # runs to the user account on the remote machine where the files
> # will be copied.
> #
> # If you wish to use rsync, set "enable" to "true", then
> # fill out server, user, and path.
> # The server should appear in your .ssh/config file.
> # 

[weewx-user] Belchertown Graphs, Reports, Records only show Index with parent directory in text.

[lecoqacr...@gmail.com]

Have weewx installed on Raspberry pi as a new install using the setup.py 
method.
Was trying to test the Belchertown skin after an install according to 
instructions.
The home screen of Belchertown looks normal but the Reports, Graphs and 
Records tabs only bring up the following :
Index of /home/weewx/public_html/graphs/
NameSizeDate Modified
index.html 
13.5 kB
11/20/20, 10:45:19 PM

Weewx.conf is as follows for the StdReport section
[StdReport]

# Where the skins reside, relative to WEEWX_ROOT
SKIN_ROOT = /home/weewx/skins/

# Where the generated reports should go, relative to WEEWX_ROOT
HTML_ROOT = /home/weewx/public_html/

# The database binding indicates which data should be used in reports.
data_binding = wx_binding

# Whether to log a successful operation
log_success = True

# Whether to log an unsuccessful operation
log_failure = False

# Each of the following subsections defines a report that will be run.
# See the customizing guide to change the units, plot types and line
# colors, modify the fonts, display additional sensor data, and other
# customizations. Many of those changes can be made here by overriding
# parameters, or by modifying templates within the skin itself.

[[SeasonsReport]]
# The SeasonsReport uses the 'Seasons' skin, which contains the
# images, templates and plots for the report.
skin = Seasons
enable = false

[[SmartphoneReport]]
# The SmartphoneReport uses the 'Smartphone' skin, and the images 
and
# files are placed in a dedicated subdirectory.
skin = Smartphone
enable = false
HTML_ROOT = public_html/smartphone

[[MobileReport]]
# The MobileReport uses the 'Mobile' skin, and the images and files
# are placed in a dedicated subdirectory.
skin = Mobile
enable = false
HTML_ROOT = public_html/mobile

[[StandardReport]]
# This is the old "Standard" skin. By default, it is not enabled.
skin = Standard
enable = false
[[Belchertown]]
skin = Belchertown
HTML_ROOT = /home/weewx/public_html/Belchertown
enable = true

[[FTP]]
# FTP'ing the results to a webserver is treated as just another 
report,
# albeit one with an unusual report generator!
skin = Ftp

# If you wish to use FTP, set "enable" to "true", then
# fill out the next four lines.
# Use quotes around passwords to guard against parsing errors.
enable = false
user = replace_me
password = replace_me
server = replace_me# The ftp server name, e.g, www.myserver.org
path = replace_me# The destination directory, e.g., /weather

# Set to True for an FTP over TLS (FTPS) connection. Not all servers
# support this.
secure_ftp = False

# To upload files from something other than what HTML_ROOT is set
# to above, specify a different HTML_ROOT here.
#HTML_ROOT = public_html

# Most FTP servers use port 21
port = 21

# Set to 1 to use passive mode, zero for active mode
passive = 1

[[RSYNC]]
# rsync'ing to a webserver is treated as just another report
skin = Rsync

# If you wish to use rsync, you must configure passwordless ssh 
using
# public/private key authentication from the user account that weewx
# runs to the user account on the remote machine where the files
# will be copied.
#
# If you wish to use rsync, set "enable" to "true", then
# fill out server, user, and path.
# The server should appear in your .ssh/config file.
# The user is the username used in the identity file.
# The path is the destination directory, such as 
/var/www/html/weather.
# Be sure that the user has write permissions on the destination!
enable = false
server = replace_me
user = replace_me
path = replace_me

# To upload files from something other than what HTML_ROOT is set
# to above, specify a different HTML_ROOT here.
#HTML_ROOT = public_html

# Rsync can be configured to remove files from the remote server if
# they don't exist under HTML_ROOT locally. USE WITH CAUTION: if you
# make a mistake in the remote path, you could could unintentionally
# cause unrelated files to be deleted. Set to 1 to enable remote 
file
# deletion, zero to allow files to accumulate remotely.
delete = 0
What am I missing in my setup to not get the graphs or record plots to 
show?
Thank you
 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving email

Re: [weewx-user] Davis VP2 can't open ttyUSB0

[lecoqacr...@gmail.com]

What is a good way to test the symlink rule to verify that it was created 
correctly? There is the new file in /dev/weather but is there a more 
complete way to test? thank you

On Tuesday, November 17, 2020 at 7:29:08 PM UTC-6 Greg from Oz wrote:

> I set my fineoffset rule to:
>
> SUBSYSTEM=="usb", ATTRS{idVendor}=="1941", ATTRS{idProduct}=="8021", 
> MODE="0666", GROUP="plugdev", SYMLINK+="weather"
>
> That way it is always /dev/weather regardless of the ttyUsb it is attached 
> to.
>
> ll /dev/weather 
> lrwxrwxrwx 1 root root 15 Nov 17 09:26 /dev/weather -> bus/usb/002/002
>
> On Wednesday, 18 November 2020 at 12:14:53 UTC+11 tke...@gmail.com wrote:
>
>> Are you sure? Depending on what permissions the usb port has, you may 
>> need to use sudo to run lsof:
>>
>> *sudo lsof /dev/ttyUSB0*
>>
>> Come to think of it, you may have to do that with minicom, too.
>>
>> Personally, I change the udev rule that governs permissions for usb 
>> devices to give everyone access to the port. The rule that governs this is 
>> most likely in the directory /lib/udev/rules.d, but which file it is in 
>> depends on the operating system. I believe on Raspbian, it's in file 
>> 91-permissions.rules, but it may be in 50-udev-default.rules.  Wherever 
>> you find it, you want to change this
>>
>> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664"
>>
>> to this
>>
>> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0666"
>>
>>
>> -tk
>>
>> On Tue, Nov 17, 2020 at 3:07 PM bgra...@umw.edu  wrote:
>>
>>>
>>> Thanks everyone, I think I have a bad logger (6540).
>>> On Tuesday, November 17, 2020 at 9:41:56 AM UTC-5 bgra...@umw.edu wrote:
>>>
 root@raspberrypi:/home/pi# ll /dev/ttyUSB0
 crw-rw 1 root dialout 188, 0 Nov 16 17:48 /dev/ttyUSB0


 root@raspberrypi:/home/pi# lsof /dev/ttyUSB0
 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system 
 /run/user/1000/gvfs
   Output information may be incomplete.

 On Monday, November 16, 2020 at 8:43:34 PM UTC-5 tke...@gmail.com 
 wrote:

> If it were a permissions problem, it would have said so. Same if 
> modemmanager controlled the port. Still, it doesn't hurt to try lsof and 
> see if anything else is using the port.
>
> *lsof /dev/ttyUSB0*
>
>
>
>
> On Mon, Nov 16, 2020 at 5:36 PM Greg from Oz  
> wrote:
>
>> Is the user running this in the dialout group? 
>>
>> On Tuesday, 17 November 2020 at 12:30:14 UTC+11 tke...@gmail.com 
>> wrote:
>>
>>> The only thing I can think of to try is to reseat the logger. 
>>>
>>> Unless, you actually have the serial version of the VantagePro and 
>>> are using a serial-to-usb converter. They are notoriously flakey. If 
>>> you 
>>> have a spare one, try that.
>>>
>>> If none of that works, call Davis.
>>>
>>> On Mon, Nov 16, 2020 at 5:04 PM bgra...@umw.edu  
>>> wrote:
>>>
 Yes, I did hit enter many times. Since dmesg said that the usb had 
 attached to ttyUSB0 then I assumed (maybe incorrectly) the rpi had 
 connected. I’m at a loss because everything was working...  Thanks.

 On Monday, November 16, 2020 at 7:59:54 PM UTC-5 tke...@gmail.com 
 wrote:

> OK, but did you hit  a few times before typing "TEST"? If 
> so, you have a connectivity problem, not a WeeWX problem.
>
> But, you probably already knew that!
>
> -tk
>
> On Mon, Nov 16, 2020 at 4:57 PM bgra...@umw.edu  
> wrote:
>
>>
>> I don’t remember the minicom string but it was the one posted to 
>> test TEST. When I opened minicom it just sat there no echo on TEST 
>> or VER. 
>> No reply. Several reboots no results. /dev/ttyUSB0 is there but does 
>> not 
>> respond. Dmesg Seems to have found it.
>> I checked all plugs and connections. Removed batteries from 
>> console to reboot. Even tried new RS232/USB dongle. I have a main 
>> ubuntu 
>> linux pc running from the ISS so I know that’s working and sending 
>> data. 
>> The rpi is setup as a second console which was running weather34. 
>> Thanks 
>> Tom and Graham (you helped me in the days of wview).
>> Bob
>> Main setup: grattans.org/wx
>> On Monday, November 16, 2020 at 6:43:17 PM UTC-5 tke...@gmail.com 
>> wrote:
>>
>>> When you say  you "tried listening to the console with minicom 
>>> but got no data" what do you mean?
>>>
>>> In particular, did you set the baudrate? And, did you type 
>>>  a few types before trying to type TEST?
>>>
>>> -tk
>>>
>>> On Mon, Nov 16, 2020 at 2:55 PM bgra...@umw.edu  
>>> wrote:
>>>
 I have a VP2 console that I am connecting to an RPI OS 

[weewx-user] Re: Computer offline for 3 days --Davis weather logger did not upload data stored during this time.

[lecoqacr...@gmail.com]

Thank you again for your reply. Found the below error in the 
/var/log/syslog file  for the dump command output that covered parts of 
10/06/2020 to 10/14/2020

raspverrypi wee_device [1263] ERROR weewx.manager: Unable to add record 
2020-10-07 14:45:00 CDT (1602099900) to database 'weewx.sdb': attempt to 
write a readonly database

Used the "--dump" command today to recheck after clearing the memory 
"--clear memory" and received the same above error as yesterday. Weewx was 
stopped prior to the dump command. This error occurs  every 5 minutes for 
the periods stated above and for today as well. 
Could this be corrupted memory and the reason for the catchup problem? 
Should the vantage console be powered down and reset or is there an easier 
way to solve this error? Thank you
On Thursday, October 15, 2020 at 3:43:31 AM UTC-5 gjr80 wrote:

> On Thursday, 15 October 2020 at 13:58:25 UTC+10 lecoqacr...@gmail.com 
> wrote:
>
>> Thank you for the replies. Yes, as stated the"no_catchup" setting does 
>> not exist in my /home/weewx/weewx.conf file. Used the setup.py method of 
>> installation using latest weewx as of 10/5/2020. Therefore based on the 
>> replies no_catchup is already set to false by default somewhere in the 
>> weewx program and therefore should attempt to catch up when offline for 
>> several days. 
>
>
> Correct. 
>
> That would only leave the second reason stated in the first reply--that 
>> there is a time stamp already newer in my database that has prevented the 
>> catchup from reaching further back than this this newer time stamp. How 
>> could that be possible since the machine was started after 3 days without 
>> an ability to receive data that would include the newer time stamped data?
>
>
> Hard to say. RPis are prone to time issues, particularly on startup and 
> after power outages, and it’s not unknown for a future dated record to be 
> created. Or it could some other cause/issue.
>
> I did stop weewx and invoke the wee_device --dump command but received the 
>> response of  bash : wee_device command not found. I then tried the 
>> following command that did work: /home/weewx/util/scripts/wee_device 
>> /home/weewx/weewx.conf --dump. I was then prompted for for a yes or no 
>> which proceeded with a yes it and it dumped data through 10/07/2020  which 
>> should include data through the offline time. This data is to be placed 
>> automatically into the database file according to the documentation when 
>> using the dump command. How long does it take to show on the plot graphs 
>> (/home/weewx/public_html/index.html) which would remove the blank data line 
>> of temp, humidity etc.?
>>
>
> Short answer is it depends. Data in reports should be updated on the next 
> report cycle. Data in plots depends on the plot aggregate interval used in 
> the plot, plots that include aggregates are only generated every ‘aggregate 
> interval’; current plots re-generate every report cycle, week plots every 
> hour, month every three hours and year every 24 hours. NOAA format reports 
> are a little different, the current month and year reports are updated 
> every report cycle. Historical NOAA format month and year reports are never 
> re-generated. The easiest way to force and update of the NOAA format 
> reports is to delete all of the generated reports, this will cause all NOAA 
> format reports to be re-generated on the next report cycle. A similar 
> approach can be taken with the plots by deleting the generated plot files 
> to force all plots to be re-generated on the next report cycle.
>  
>
>> Does dumping the data clear the memory of the data logger or is it still 
>> there as well as now on my dump file?  
>>
>
> No, —dump just reads all of the stored archive records and attempts to 
> save them to archive. —clear-memory will clear the logger memory.
>  
>
>> Incidentally, should the full paths have been needed to  invoke the 
>> wee_device command.
>>
>
> setup.py installs typically require you to be in the directory containing 
> the executable (in this case wee_device) or to use an appropriate path to 
> the executable. Package installs usually don’t require the path as the 
> appropriate directory is added to the PATH environment variable on 
> installation. And we probably don’t help too much as we tend not to mention 
> adding the path when listing commands, probably a bit of assumed knowledge 
> there as well.
>  
>
>> Thank you and my apologies for so many questions.
>>
>
> No problems, we’ve all been in your shoes at some time or other.
>
> 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/42c6b0f7-b41d-435c-90a9-01680a055a6dn%40googlegroups.com.

[weewx-user] Re: Computer offline for 3 days --Davis weather logger did not upload data stored during this time.

[lecoqacr...@gmail.com]

Thank you for the replies. Yes, as stated the"no_catchup" setting does not 
exist in my /home/weewx/weewx.conf file. Used the setup.py method of 
installation using latest weewx as of 10/5/2020. Therefore based on the 
replies no_catchup is already set to false by default somewhere in the 
weewx program and therefore should attempt to catch up when offline for 
several days. That would only leave the second reason stated in the first 
reply--that there is a time stamp already newer in my database that has 
prevented the catchup from reaching further back than this this newer time 
stamp. How could that be possible since the machine was started after 3 
days without an ability to receive data that would include the newer time 
stamped data?
I did stop weewx and invoke the wee_device --dump command but received the 
response of  bash : wee_device command not found. I then tried the 
following command that did work: /home/weewx/util/scripts/wee_device 
/home/weewx/weewx.conf --dump
I was then prompted for for a yes or no which proceeded with a yes it and 
it dumped data through 10/07/2020  which should include data through the 
offline time. This data is to be placed automatically into the database 
file according to the documentation when using the dump command. How long 
does it take to show on the plot graphs 
(/home/weewx/public_html/index.html) which would remove the blank data line 
of temp, humidity etc.? Does dumping the data clear the memory of the data 
logger or is it still there as well as now on my dump file?  Incidentally, 
should the full paths have been needed to  invoke the wee_device command. 
Thank you and my apologies for so many questions.




On Wednesday, October 14, 2020 at 3:43:26 PM UTC-5 gjr80 wrote:

> No. no_catchup was implemented to give users the ability to turn off the 
> automatic catch-up/backfill that occurs on WeeWX startup. To *disable* 
> automatic 
> catch-up/backfill on WeeWX startup you need to set no_catchup = True; 
> if no_catchup is omitted or no_catchup = False (the default) automatic 
> catch-up/backfill on WeeWX startup will be enabled. A fresh WeeWX install 
> will not include the no_catchup setting in weewx.conf but automatic 
> catch-up/backfill on WeeWX startup will still occur due to the default 
> being False.
>
> I would expect not many folks would use no_catch to disable automatic 
> catch-up/backfill on WeeWX startup.
>
> Gary
>
> On Thursday, 15 October 2020 at 04:44:20 UTC+10 gsn...@gmail.com wrote:
>
>> So to do the backfill,
>> [StdArchive] 
>>   no_catchup = True
>>
>> Thanks
>> Greg
>>
>> On Wednesday, October 14, 2020 at 6:17:53 AM UTC-5 gjr80 wrote:
>>
>>> Hi,
>>>
>>> Whilst it's true the vantage driver will backfill records generated 
>>> during a WeeWX outage there are some conditions/limitations. Firstly, in 
>>> weewx.conf under [StdArchive] option no_catchup must either not exist 
>>> or must be set to False otherwise the hardware record catchup will not be 
>>> attempted (the no_catchup option is not included in weewx.conf for a 
>>> default install so likely it will not exist on your system). Secondly, and 
>>> what probably prevents most catchups occurring, is that the catchup only 
>>> downloads those records that are newer/younger/more recent than the 
>>> timestamp of the last good archive record in your database. Whilst your 
>>> missing data may well be in the data logger it could be the you have a 
>>> record in your archive that is timestamped after the logger data of 
>>> interest. In this case the easiest solution is to stop WeeWX and use the 
>>> wee_device utility with --dump 
>>> <http://weewx.com/docs/hardware.htm#vantage_dumping_the_logger_memory> 
>>> to dump all of the archive records stored in the logger to WeeWX. You can 
>>> check the WeeWX log to see what records were downloaded during the dump. 
>>> --dump will download all stored archive records but only those not 
>>> already saved in the WeeWX archive will be saved, those already in the 
>>> archive will generate a duplicate key error which can be ignored.
>>>
>>> Just for completeness there is one other situation where backfill of 
>>> logged data did not occur. WeeWX v3.9.0 introduced a change whereby 
>>> backfill was only attempted on startup if hardware record generation was in 
>>> use. This behaviour was changed as of v3.9.1 and backfill is now attempted 
>>> irrespective of whether hardware or software archive record generation is 
>>> used.
>>>
>>> Gary
>>>
>>> On Wednesday, 14 October 2020 12:39:48 UTC+10, lecoqacr...@gmail.com 
>>> wro

[weewx-user] Computer offline for 3 days --Davis weather logger did not upload data stored during this time.

[lecoqacr...@gmail.com]

Have a raspberry pi 3b running weewx 4.1 (thank you for a great program and 
so much hard work and the online support), but am curious as to why the 
data which should be up to 8 days for the data logger was not uploaded 
automatically when restarting the raspberry pi. There is a gap of 3 days 
that I don't understand if the logger keeps 8 days in memory. Apparently 
there is a setting that needs to be changed but am unsure of this setting. 
thank you for your time.

-- 
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/ce6cfc79-3938-4864-9e87-83a892bd13dcn%40googlegroups.com.