Re: [weewx-user] Problem for public_html access with Weewx 5 and apache 2

2024-04-27 Thread cric...@pobox.com


In /etc/apache2/apache2.conf

 

Options FollowSymLinks

 

Options Indexes FollowSymLinks

 Might not be the exact one(s), but FollowSymLinks is the thing to set.

 Chris

 
On Saturday, April 27, 2024 at 3:55:01 AM UTC-6 Remy Lavabre wrote:

> Yes thank you it works Vince!
> I've been racking my brains over these Apache directories for a while and 
> I admit I haven't thought about reversing my symbolic links, idiot that I 
> am...! :-(
>
> Perhaps an even simpler solution would have been to put the version 4 path 
> back in weewx.conf...?
>
> However, I would have liked to understand why I was unable to reach my 
> ~/weewx-venv/public_html directory with my initial symbolic links... The 
> rights seemed to have been assigned correctly to the directories.
>
> But in any case it works with your method! So I'm keeping it :-)))
> Thank you Vince and have a good weekend
>
> Le vendredi 26 avril 2024 à 18:44:29 UTC+2, vince a écrit :
>
>> I do it in the opposite direction.   The /var/www/html/weewx path is a 
>> directory.  The /home//weewx-data/public_html path is a symlink 'to' 
>> the webserver directory.
>>
>> For a pip installation:
>> sudo mkdir /var/www/html/weewx
>> sudo chown ${WEEWXUSER}:${WEEWXUSER} /var/www/html/weewx
>> ln -s /var/www/html/weewx /home/${WEEWXUSER}/weewx-data/public_html
>>
>>
>> On Friday, April 26, 2024 at 7:53:03 AM UTC-7 Remy Lavabre wrote:
>>
>>> 1/ if I try xxx.xxx.xxx.xxx/index.html -> Work fine, I've got the 
>>> Apache2 Debian Default Page (which is in /var/www/html/index.html).
>>> 2/ if i try xxx.xxx.xxx.xxx/weewx/index.html -> Forbidden - You don't 
>>> have permission to access this resource. (with my symbolic link)
>>>
>>> I've tried :
>>> A/ sudo chown www-data ~/weewx-data/public_html -Rf
>>> B/ sudo chmod 775 -R ~/weewx-data/public_html
>>> --> Same thing
>>>
>>> C/ sudo nano /etc/apache2/sites-available/000-default.conf and change 
>>> "DocumentRoot /var/www/html" to "DocumentRoot ~/weewx-data/public_html"
>>>  xxx.xxx.xxx.xxx/index.html *and* xxx.xxx.xxx.xxx/weewx/index.html does 
>>> not work...
>>>
>>> Any idear ??
>>> Le vendredi 26 avril 2024 à 15:46:48 UTC+2, p q a écrit :
>>>
 Looks like a rights issue with Apache. Find the apache.conf file and 
 you probably need to enable access to the right directories.

 On Fri, Apr 26, 2024 at 6:26 AM Remy Lavabre  
 wrote:

> Hello,
>
> Good morning,
> I didn't find the answer to my problem in the various discussions on 
> the WeeWX forum...
>
> I installed Weewx 5 in a virtual environment.
> So I have my weewx-data and weewx-venv directories in /home/---/
>
> weewxd seems to "finally" work normally with the 
> ~/weewx-data/public_html directory refreshing.
>
> On version 4, the weewx public_html directory was /var/www/html/weewx 
> ROOT:ROOT and did not pose a problem with the Apache 2 server.
> Since the location of the web server changed in version 5, I put a 
> symbolic link "weewx" in /var/www/html/ pointing to 
> ~/weewx-data/public_html/weewx [sudo ln -s/ ~/ 
> weewx-data/public_htmlweewx 
> /var/www/html/weewx].
>
> The rights of var/www/html remained ROOT:ROOT while the rights of 
> ~/weewx-data/public_html/weewx are those of the creator.
>
> Filezilla navigation works correctly. Clicking on the symbolic link 
> takes you to the new WeeWX 5 public_html directory.
>
> However, when trying to connect through a web browser (
> http://xxx.xxx.xxx.xxx/weewx/index.html), I get the response:
> :
>
>
>
>
> *ForbiddenYou don't have permission to access this 
> resource.Apache/2.4.59 (Debian) Server at xxx.xxx.xxx.xxx Port 80*
>
> I think it must just be a rights issue...?
>
> *What is the recommended solution in Weewx 5 with Apache 2 to redirect 
> Apache from /var/www/html to ~/weewx-data/public_html?*
>
> Thanks a lot for the help! ;-)
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/1deda7f3-fa1e-4ab8-8ef7-a7b561fa9ffen%40googlegroups.com
>  
> 
> .
>


 -- 
 Peter Quinn
 (415)794-2264 <(415)%20794-2264>

>>>

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

[weewx-user] Re: Comparison of method of using WeeWX

2024-03-04 Thread cric...@pobox.com
Since I detest systemd and friends, I wrote a perl script to run as a cron 
job to start weewx as needed.
Suites me just fine.  Since weewx is so stable, it rarely has to be 
restarted.  I use the same basic script
for several other things, and quite happy with it.  Oh, and the cron job is 
OS-agnostic, which is a plus for me.

Chris

On Sunday, March 3, 2024 at 2:34:23 PM UTC-7 Invisible Man wrote:

> To my understanding, the commands are the same in terms of "what they do", 
> i.e start weewx.
> The difference lies in how easy it is to manage weewx.
>
> 1. If you use weewx as a service, you can easily start/stop/restart/mask 
> (etc) your service with the systemctl commands. This includes for example 
> restarting weewx if it has stopped. Also, you can ensure at boot time that 
> weewx only tries to start once your host has network for example.
>
> 2. Crontab. IMHO, a crontab is useful to start periodic tasks, like "do a 
> backup at 5am". If your idea is to use a crontab just to start weewx at 
> boot time, the /etc/rcX.d directories are probably better suited. If you 
> want the crontab to periodically check weewx is running and restart it if 
> it's down, then yes, you can do it with the crontab, but you'll  have to 
> write the script that detects weewx is up or down and restart if necessary. 
> This is automatically handled by the systemctl service configuration, so 
> you are kind of re-inventing the wheel IMHO.
>
> 3. nohup weewxd. This works and it's sometimes handy because it's simple 
> and easy to debug. But if your weewx dies for some reason, you have no way 
> to restart it. Also, it's not that easy to see if you already have a weewxd 
> running (you'll  have to do "ps aex" and grep for example) so you might 
> launch several instances by error. Finally, the logs go where you launched 
> the command, they are not centralized in journalctl like systemctl option, 
> or in /var/log/syslog.
>
> Hope it helps. There might be other differences I am missing.
>
> On Sunday, March 3, 2024 at 8:45:50 PM UTC+1 Remy Lavabre wrote:
>
>> Good morning,
>>
>> Small question(s) for a PIP installation:
>>
>> 1/ Is there a difference between:
>> - the use of the weewx daemon
>> - the weewxd command placed in the contrab at the RPi starting
>> - the manually typed command "nohup weewxd &"?
>>
>> 2/What is the interest/advantage of one method compared to others?
>>
>> THANKS
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/651adf9c-69fe-416e-9888-7da45ea0e895n%40googlegroups.com.


[weewx-user] Re: SOLVED as3935 lightining module not detected by I2c on a Rpi4

2024-02-16 Thread cric...@pobox.com
So... I've recently set up one of these modules from DFRobot.  I started 
with their sample python code
and morphed into something that fits in my set of libraries.  In my case, I 
have it sending events out
via mqtt.  A quick look at the code doesn't give any hints to help you.  
>From the sample code, I set this up:
  #I2C address
  self.config['AS3935_I2C_ADDR1']   = 0x01
  self.config['AS3935_I2C_ADDR2']   = 0x02
  self.config['AS3935_I2C_ADDR3']   = 0x03
I think the hardware module has tiny switches to change it's address.

It's dead of winter here, so no lightning to detect for a few months.  I 
can share some of the code,
but not all.

Chris


On Friday, February 16, 2024 at 4:43:49 PM UTC-7 Pierre-Yves wrote:

> Finally, I succeeded to make the weewx running and capturing AS3935 
> lightning detector data
>
> For that, I had to force the detection of the i2c addresses from 0x03 to 
> 0x77 instead of 0x08 to 0x77 with the command:
> sudo i2cdetect -a -y 1 0x03 0x77
>
> I had also to add gpio to weewx group:
> sudo usermod -a -G gpio weewx
>
> PYB
> Le vendredi 16 février 2024 à 21:30:08 UTC+1, Pierre-Yves a écrit :
>
>> Hello All,
>>
>> Maybe a bit off-topic. But just in case someone would have faced to this 
>> strange behavior of a Raspberry i2c address map.
>>
>>
>> Rpi4-1: usual address map from 0x03 to 7x76.
>> Config.:
>> Weewx 4.10.2,
>> Bresser 7in1,
>> sdr driver,
>> RTC clock (UU),
>> BME280 (0x76) (pressure, temperature, humidity)
>> AS3935 (0x03) (lightning detector)
>>
>> Weewx on Rpi4-1 running without any error.
>>
>> pi@weewx:~ $ sudo i2cdetect -y 1
>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00:  03 -- -- -- -- -- -- -- -- -- -- -- -- 
>> 10: -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- -- 
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
>> 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 
>> 70: -- -- -- -- -- -- 76 -- 
>> pi@weewx:~ $ 
>>
>> Rpi4-2: "abnormal" map with addresses 0x03 to 0x07 non selectable.
>> Config.:
>> Weewx 5.0.2,
>> Bresser 7in1,
>> RTC clock (UU),
>> AS3935 (??)
>>
>> Weewx on Rpi4-2 failing : File "/etc/weewx/bin/user/as3935.py", line 182, 
>> in __init__GPIO.setup(self.pin, GPIO.IN (see log below)
>>
>> pi@raspberrypi:~ $ sudo i2cdetect -y 1
>>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00: -- -- -- -- -- -- -- -- 
>> 10: -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- -- 
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
>> 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 
>> 70: -- -- -- -- -- -- -- -- 
>> pi@raspberrypi:~ $
>>
>> Clearly, the AS3935 is not identified because the 0x03 to 0x07 address 
>> range is not active. This AS3935 module works on the Rpi4-1
>>
>> Any idea on where this problem of misconfiguration could come from, 
>> firmware, kernel ?
>> Is there a way to reset the I2c address map ? 
>>
>> Thanks,
>>
>> Pierre-Yves
>>
>

-- 
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/97354093-f04c-4f9c-915b-4990b0634d2bn%40googlegroups.com.


Re: [weewx-user] Re: monitoring Weewx with Nagios

2024-01-04 Thread cric...@pobox.com
Here's another idea.  I don't know anything about Nagios, but I'm running 
this screwy setup where I made up my own
thermostat(s), and in the living room, the one has a small OLED display for 
set point, current temp, and also outside
temp and wind chill that gets sent from my weather station's weewx via 
MQTT.  I'm sending a few observations along
with the current time from weewx.  The receivers track to make sure the 
values are changing, and I get a text message
when things are askew.  In any case, if Nagios can listen to MQTT messages, 
this is pretty easy to set up.
Chris

On Thursday, January 4, 2024 at 5:37:45 AM UTC-7 matthew wall wrote:

> On Thursday, January 4, 2024 at 4:54:05 AM UTC-5 sali...@gmail.com wrote:
>
> I just looked at your files, I think "tell me if it's true" that your 
> Nagios is on the same machine as "Weewx"; my Nagios is on a server outside 
> the RPi, so I think there must be something missing in the programs to run 
> it remotely, like I have in the other Nagios plugins; for example: -H 
> $HOSTADDRESS$ etc etc;
>
> patrick,
>
> if nagios is on the same machine, then you can run the plugin directly. 
> but if nagios is on a different machine, then you must install the "nagios 
> remote plugin executor" (NRPE) on the machine running weewx.  then NRPE 
> will run the plugin.
>
> if you do not want to install NRPE on the weewx machine, then you must 
> talk to the weewx machine over standard network interfaces. in that case, 
> your nagios plugin might do an http/https request to the weewx machine to 
> see when the weewx report was last updated.  of course, this assumes that 
> you are running a web server on the weewx machine to publish your weewx 
> reports.  you could also run a nagios ssh plugin - in that case, the plugin 
> should execute a command on the weewx machine that returns the information 
> you want in nagios.  that would use the same approach that you see in the 
> nagios_wview plugin (check for existance of weewxd process, check database 
> timestamp, return data from database as performance data), but do it over 
> an ssh connection with shell scripting.
>
> another approach would be to write a weewx service, say weewx-nagios, that 
> listens on a network port then provides the information about weewxd and 
> report status when it is queried.  
>
> or create a weewx-snmp extension that runs on the weewx machine, gathers 
> the weewx and report status, but responds to standard snmp queries. that 
> would be the most generic approach, and would let you monitor weewx using 
> much any tool that can do snmp - nagios, icinga, prtg, zabbix, etc.
>
> m
>

-- 
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/162086cb-b1e1-4fbb-9c4c-6371dbe46292n%40googlegroups.com.


Re: [weewx-user] Pipe errors etc

2023-12-18 Thread cric...@pobox.com
Hi David,

   As for stopping weewx, kill 535 will work, but systemd will likely 
restart it very soon.  I ran into an similar issue
the other day with systemd.  In this case it was for NUT (ups monitoring 
stuff).  The systemctl stop 
didn't stop the daemon (same message you got).  I ended up disabling the 
service unit and killed the processes by hand.
For weewx, I have a perl script that runs from cron that starts weewx if 
it's down.  Works great, except that I have to
remember to stop weewx by hand in care of a reboot or shutdown.  Some 
people like systemd.  I'm not one of them.

Chris


On Monday, December 18, 2023 at 1:10:12 AM UTC-7 David Hindley wrote:

> Thanks for your reply Vince.  Completely understand re network. I am using 
> Ethernet rather than WiFi for both my Rpi which hosts weewx and my davis 
> weather station. 
>
> Does anyone have any input on my question about stopping weewx please? 
> Repeated here: 
>
> In the meantime, I am having trouble stopping weewx - not sure if this is 
> related to my ongoing pipe errors or not.  When I type 
>
> ps -aux|grep weewx
>
> I get
>
> root   535  5.6  6.1 117524 58128 ?Sl   10:16   2:42 python2 
> /usr/share/weewx/weewxd --daemon --pidfile=/var/run/weewx.pid 
> /etc/weewx/weewx.conf
> pi2130  0.0  0.0   4368   564 pts/0S+   11:04   0:00 grep 
> --color=auto weewx
>
> And, then typing 
>
> sudo /etc/init.d/weewx stop
>
> produces
>
>  Stopping weewx (via systemctl): weewx.service.
>
> but then repeating the grep command, still shows the 535 process still 
> running?
>
> How do I stop weewx - do I have to use kill 535 perhaps?
>
> Thanks
>
> David. 
> On Sat, 16 Dec 2023 at 19:39, vince  wrote:
>
>> Sorry - we can't fix your network.  Lots of legacy embedded type 2.4GHz 
>> wifi things have issues staying on the network and stable.   I'd suggest 
>> you try to see if your wifi is being interfered with from a neighbor 
>> perhaps.  Maybe you can switch which channel your wifi is on.
>>
>> FWIW, we have too many neighbors here with misconfigured wifi to even 
>> count, depending on who moves in/out and who visits them occasionally.  
>> What I eventually needed to do was (a) move everything in the house that 
>> could do it over to 5GHz wifi, and (b) buy a Unifi AcLite AP and basically 
>> try to out-radiate the neighbors.  Problem went away at that point.
>>
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/weewx-user/q67cvEsXtjQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b4ebe949-5ee5-4221-b91c-ba84e21d64f4n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e9f3e79b-d362-4c4d-8d37-f3e2832d1f55n%40googlegroups.com.


[weewx-user] Re: Keep losing nameserver on ubuntu 22.04

2023-12-16 Thread cric...@pobox.com
I get tired of trying to figure out all the various ways /etc/resolve.conf 
can get modified, for all my static hosts,
if it's a link, I replace it with the file with the contents I want, then 
run:
chattr +i /etc/resolve/conf
That prevents any further messing with the file.  It does mean you are on 
the hook for any needed updates.
The alternative is figuring out who (which process(es)) is maintaining the 
file and get the configs to those files
straightened out.  I manage my own DNS and DHCP servers so I know what 
resolve.conf needs to have, but the
various OS's drive me nuts, so I remove their ability to screw things up.

Chris

On Friday, December 15, 2023 at 7:48:22 AM UTC-7 WindnFog wrote:

> I wouldn't touch /etc/resolv.conf as the O/S manages this.  I use the 
> Ubuntu Gnome GUI to set my DNS servers. Under the network icon on the top 
> left, select Settings and beside "Wired," again, pick Settings.  I pick the 
> IPv4 tab and select Manual . . . I'm using a static IP on my LAN.  At the 
> bottom, there is a DNS slot.  Turn off Automatic and put in your DNS 
> servers separated by commas. Use the DNS servers your ISP specifies, or go 
> with proven public ones like Google (8.8.8.8. 8.8.4.4), Cloudflare 
> (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), etc.
>
> I don't see how weeWX could be changing these. It's almost certainly a 
> Ubuntu issue.
>
> On Friday, December 15, 2023 at 8:54:06 AM UTC-4 bgra...@umw.edu wrote:
>
>> Hello,
>> Weewx 4.10.2 has been running fine but suddenly stopped FTPing to the 
>> main site. After checking, I found that my dns servers were missing. After 
>> putting them back, it ran normally for a few hours and then FTP stopped 
>> again because dns had disappeared. Not sure what is happening here as weewx 
>> is running fine. Resolv.conf seems to be a simlink to something else and 
>> can’t be edited. Using webmin to reset the dns servers only works for a 
>> short while.
>> I realize this probably isn’t a weewx problem but I’m completely stumped 
>> as to how to fix the problem. Any help or suggestions would be greatly 
>> appreciated. Thanks in advance.
>> Cheers,
>> Bob
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/bebc8bfe-dec8-459b-b990-3da90c61f2e3n%40googlegroups.com.


Re: [weewx-user] Rsyc Error

2023-11-02 Thread cric...@pobox.com
At the end of the day, we're still back to debugging the interaction 
between you and your web hosting service.
It is unlikely, but not impossible, that weewx contributes to the issue.  
Debug logs are required, and maybe the logs
again from your hosting service.

As an alternative, do you have another computer/VM you can set up as your 
rsync destination to see if that works
cleanly or not?  It's possible to set up two "Reports" that use the rsync 
skin with different configs, just name them
differently.  Like this:
[StdReport]
[[RSYNCa]]
[[RSYNCb]]

Once basic ssh connectivity is set up, the rest of all this shouldn't be so 
difficult to make work.  For you, debugging outside
of weewx is likely more expedient, since it feels like a you verses web 
hosting service issue.  You should have the rsync
command lines from the logs when debug is set > 0.  Just run those a few 
times in a row (try to work around weews's
time slot) and see what results you get.

Chris

On Tuesday, October 31, 2023 at 7:27:56 PM UTC-6 Tom -KQ5S wrote:

> I guess I installed V5.  The config file shows version = 4.10.2.  I 
> followed the install instructions at 
> https://weewx.com/docs/5.0/quickstarts/debian/.
>
> On Tuesday, October 31, 2023 at 8:20:16 PM UTC-5 Tom -KQ5S wrote:
>
>> As a follow-up I did a clean install of bookworm and WeeWX 5, using 
>> apt-get,  on my Pi.  I did nothing else except set up Rsync and I am 
>> getting the same sporadic errors as before.  No crons.  No extensions.  
>> Nothing was added to the base install.
>>
>> On Monday, October 30, 2023 at 8:19:09 AM UTC-5 Tom -KQ5S wrote:
>>
>>> Thanks to Vince and Chris for the help.  At this point I am giving up. 
>>>  I'll try a fresh install and see what happens. 
>>>
>>> Tom.  
>>>
>>> On Sunday, October 29, 2023 at 9:20:23 PM UTC-5 vince wrote:
>>>
 Tom - I'm at a loss at this point as to why you're not working (or 
 failing) consistently.

 I did a setup of rsync over ssh on a clean pi and here are the steps.
 Worked first time for me :-)

 (this example uses weewx v5.0b15 as user 'pi')

 # reimaged a raspberry pi
 # installed rsyslog to get traditional syslogging rather than systemd
 sudo apt-get install -y rsyslog

 # logged into the pi as unprivileged user pi (for this example)

 # installed weewx with the simulator driver

 # created a new ssh keypair for the user pi
 # taking the defaults to make a passwordless keypair
 # which will be ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
 ssh-keygen

 # added this key to the appropriate user@host for my server host
 ssh-copy-id vince@nuc2

 # verified I could log into the remote server
 ssh vince@nuc2
 # at this point ssh is known to work using the new ssh key

 # edited weewx.conf to set debug=1 for more verbose logging

 # edited weewx.conf to configure the RSYNC uploader
 # so this will upload the default public_html to the specified path

[[RSYNC]]
 skin = Rsync
 enable = true
 server = nuc2
 user = vince
 path = /home/vince/weehtml
 log_success = true
 log_failure = true
 delete = 0

 # restarted weewx, waited 5 minutes, I see the successful rsync of the 
 Seasons skin in syslog

 2023-10-29T19:00:20.236994-07:00 raspberrypi weewx[2416] DEBUG 
 weeutil.rsyncupload: rsyncupload: cmd: [['rsync', '--archive', '--stats', 
 '-e', 'ssh', '/home/pi/weewx-data/public_html/', 
 'vince@nuc2:/home/vince/weehtml']]

 2023-10-29T19:00:20.680310-07:00 raspberrypi weewx[2416] INFO 
 weeutil.rsyncupload: rsync'd 73 files (526,454 bytes) in 0.44 seconds

 # Notes:
 #  - no /home/pi/.ssh/config file was needed on a pi as long as the 
 specified 'server' resolves
 #   because ssh on the pi defaults to using ~/.ssh/id_rsa as the 
 private key
 #  - weewx assumes the local user is the one it is running as
 #  - weewx uses the RSYNC 'user' as the remote user it connects to




-- 
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/e8e66019-0ceb-476f-ab4f-c34fa08de169n%40googlegroups.com.


Re: [weewx-user] Rsyc Error

2023-10-29 Thread cric...@pobox.com
Need to better proofread before sending:
"Verify with cksum of sha256sum" should be   Verify with cksum or sha256sum
"Do you have matching keys in ~/root/.ssh, XXX.ssh, " should be: Do you 
have matching keys in ~root/.ssh, ~XXX/.ssh, 
"the remote end in ~/XXX/.ssh?  " should be the remote end in ~XXX/.ssh?  
On Sunday, October 29, 2023 at 6:54:38 PM UTC-6 cric...@pobox.com wrote:

> OK, still confused, but for sure, doing things as root to a remote server 
> you don't own is likely to fail.
> It looks like the second attempt with:  ssh xx...@kq5s.com 
> <https://groups.google.com/> -p -v
> seems to work, but you cut off the log with ...
> Anyhow, weewx is running as root (typical, not bad), and you've configured 
> rsync user as:
>  user = X ( not sure if I should post this or not.  It is a user on my 
> internet site)
> So... does user  have ssh keys, and do the contents of the key files 
> and the like match
> on the other end?  Verify with cksum of sha256sum on each of the files.  
> Are all the permissions
> correct.  ssh is very picky about tight permissions.  From the second log, 
> it looks like everything
> is OK as pi.  Seems like sudo ssh  also works.  Do you have 
> matching keys in ~/root/.ssh,
> XXX.ssh, and ~/pi/.ssh, and on the remote end in ~/XXX/.ssh?  All that has 
> to match up for things
> to work.  Do you actually have an XXX account on your local machine?  
> Maybe that's a missing piece.
>
> Chris
>
> On Sunday, October 29, 2023 at 5:07:55 PM UTC-6 Tom -KQ5S wrote:
>
>> Without root:
>>
>> ssh xx...@kq5s.com -p -v
>>
>> OpenSSH_8.4p1 Raspbian-5+deb11u2, OpenSSL 1.1.1w  11 Sep 2023
>> debug1: Reading configuration data /etc/ssh/ssh_config
>> debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf 
>> matched no files
>> debug1: /etc/ssh/ssh_config line 21: Applying options for *
>> debug1: Connecting to kq5s.com [199.250.194.206] port .
>> debug1: Connection established.
>> debug1: identity file /home/pi/.ssh/id_rsa type 0
>> debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
>> debug1: identity file /home/pi/.ssh/id_dsa type -1
>> debug1: identity file /home/pi/.ssh/id_dsa-cert type -1
>> debug1: identity file /home/pi/.ssh/id_ecdsa type -1
>> debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1
>> debug1: identity file /home/pi/.ssh/id_ecdsa_sk type -1
>> debug1: identity file /home/pi/.ssh/id_ecdsa_sk-cert type -1
>> debug1: identity file /home/pi/.ssh/id_ed25519 type -1
>> debug1: identity file /home/pi/.ssh/id_ed25519-cert type -1
>> debug1: identity file /home/pi/.ssh/id_ed25519_sk type -1
>> debug1: identity file /home/pi/.ssh/id_ed25519_sk-cert type -1
>> debug1: identity file /home/pi/.ssh/id_xmss type -1
>> debug1: identity file /home/pi/.ssh/id_xmss-cert type -1
>>
>> debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Raspbian-5+deb11u2
>> debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
>> debug1: match: OpenSSH_7.4 pat 
>> OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7*
>>  
>> compat 0x0402
>> debug1: Authenticating to kq5s.com: as 'xx'
>>
>> debug1: SSH2_MSG_KEXINIT sent
>> debug1: SSH2_MSG_KEXINIT received
>> debug1: kex: algorithm: curve25519-sha256
>> debug1: kex: host key algorithm: ecdsa-sha2-nistp256
>> debug1: kex: server->client cipher: aes128-ctr MAC: umac-...@openssh.com 
>> compression: none
>> debug1: kex: client->server cipher: aes128-ctr MAC: umac-...@openssh.com 
>> compression: none
>> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
>> debug1: Server host key: ecdsa-sha2-nistp256 
>> SHA256:p4xX8yxXsJ+3l/Xg8B29Qbdc5r9iHXvoX0bpFCpCwes
>> debug1: Host '[kq5s.com]:' is known and matches the ECDSA host key.
>> debug1: Found key in /home/pi/.ssh/known_hosts:2
>>
>> debug1: rekey out after 4294967296 blocks
>> debug1: SSH2_MSG_NEWKEYS sent
>> debug1: expecting SSH2_MSG_NEWKEYS
>> debug1: SSH2_MSG_NEWKEYS received
>> debug1: rekey in after 4294967296 blocks
>> debug1: Will attempt key: /home/pi/.ssh/id_rsa RSA 
>> SHA256:PCS+HvqfV/Y0X/UuplMbVw+cfzk+v5Bk+pC7hQubdbU
>> debug1: Will attempt key: /home/pi/.ssh/id_dsa 
>> debug1: Will attempt key: /home/pi/.ssh/id_ecdsa 
>> debug1: Will attempt key: /home/pi/.ssh/id_ecdsa_sk 
>> debug1: Will attempt key: /home/pi/.ssh/id_ed25519 
>> debug1: Will attempt key: /home/pi/.ssh/id_ed25519_sk 
>> debug1: Will attempt key: /home/pi/.ssh/id_xmss 
>> debug1: SSH2_MSG_EXT_INFO received
>>

Re: [weewx-user] Rsyc Error

2023-10-29 Thread cric...@pobox.com
debug1: pledge: network
>>> debug1: client_input_global_request: rtype hostk...@openssh.com 
>>> want_reply 0
>>> debug1: Sending environment.
>>> debug1: Sending env LANG = en_US.UTF-8
>>> debug1: Sending env LC_ALL = en_US.UTF-8
>>> [k@ecbiz246 ~]$ 
>>> On Sunday, October 29, 2023 at 5:33:37 PM UTC-5 vince wrote:
>>>
>>>> So yet again - what is the ~/.ssh/config entry for kq5s.com for the 
>>>> user weewx is running as.
>>>> Typically that is root based on the paths you've provided.
>>>>
>>>>
>>>>- Are you 'sure' you are running weewx specifically as user pi ?
>>>>
>>>>
>>>>- if you're running as the non-standard user pi, show us how you 
>>>>did that
>>>>
>>>>
>>>>- What is in /root/.ssh/config ?
>>>>
>>>>
>>>>- What is in /home/pi/.ssh/config ?
>>>>
>>>>
>>>>- Are you 'sure' you do not have any cron entries trying to do 
>>>>rsync outside weewx ?
>>>>
>>>>
>>>> You should be able to do something like "ssh xx...@kq5s.com date" 
>>>> successfully if you have shell access there.
>>>>
>>>> On Sunday, October 29, 2023 at 3:25:55 PM UTC-7 Tom -KQ5S wrote:
>>>>
>>>>> Thanks Chris.
>>>>>
>>>>> ps uaxw | grep weewx
>>>>> root 10111  2.6  0.6 117148 52824 ?Ssl  11:31   9:09 
>>>>> /usr/bin/python3 /home/weewx/bin/weewxd /home/weewx/weewx.conf
>>>>> pi   13411  0.0  0.0   7444   580 pts/4S+   17:21   0:00 grep 
>>>>> --color=auto weewx
>>>>>
>>>>> [[RSYNC]]
>>>>>
>>>>> # rsync'ing to a webserver is treated as just another report
>>>>> skin = Rsync
>>>>> enable = true
>>>>> server = kq5s.com
>>>>> user = X ( not sure if I should post this or not.  It is a 
>>>>> user on my internet site)
>>>>> path = public_html
>>>>> port = 
>>>>> 
>>>>> delete = 0
>>>>>
>>>>>
>>>>> On Sunday, October 29, 2023 at 5:10:44 PM UTC-5 cric...@pobox.com 
>>>>> wrote:
>>>>>
>>>>>> So, here's one of mine:
>>>>>> renogy0_/home/crichmon> cat .ssh/config 
>>>>>> # hosts with more than two components are probably external
>>>>>> PubkeyAuthentication yes
>>>>>> # relax checking on internal hosts/networks # hopefully this list 
>>>>>> will not grow and all new site's networks will be
>>>>>> Host 192.168.0.* 192.168.1.* 192.168.2.* 192.168.3.*
>>>>>> StrictHostKeyChecking no
>>>>>> Host *.chaos.home *.csrhome.home *.garage.home
>>>>>> StrictHostKeyChecking no
>>>>>> Host *.*
>>>>>> StrictHostKeyChecking yes
>>>>>>
>>>>>> Not particularly interesting.  I'd suggest looking at: man ssh_config
>>>>>> At the end of the day, this is not the likely problem.  As you said, 
>>>>>> the issue seems to be somewhat intermittent, so it isn't
>>>>>> a complete config failure, but something a bit harder to figure out.
>>>>>>
>>>>>> Still, we need as many details as you can provide.  One thing... You 
>>>>>> said you are running weewx as userID pi.
>>>>>> Is that a fact or an assumption?  How do you know?  ps uaxw | grep 
>>>>>> weewx will give that answer.  Knowing that
>>>>>> will narrow down the possible problems.  The other bit is how your 
>>>>>> rsync is configured.  We can sort-of see that
>>>>>> from the logs, but nothing is clear yet.
>>>>>> You still haven't provided the RSYNC config.  One of mine is:
>>>>>> [[RSYNC]]
>>>>>> skin   = Rsync
>>>>>> enable = false
>>>>>> server = router1
>>>>>> user   = crichmon
>>>>>> path   = /var/www/html/solar
>>>>>> delete = 0
>>>>>> Nothing secret here, at least for me.  This one is internal to my 
>>>>>> network.  I don't ac

Re: [weewx-user] Rsyc Error

2023-10-29 Thread cric...@pobox.com
>> 
>>>> delete = 0
>>>>
>>>>
>>>> Tom
>>>> On Sunday, October 29, 2023 at 2:31:10 PM UTC-5 vince wrote:
>>>>
>>>>> I'm not understanding what you guys think you see.   I don't see 
>>>>> anything in his logs saying the total time to do things is exceeding the 
>>>>> 5-minute default archive interval.  His possibly edited log snippet above 
>>>>> showed rsync happening every 5 minutes which is normal.  It only takes a 
>>>>> couple seconds which is normal.   The number of files is reasonable given 
>>>>> the skins he's using. 
>>>>>
>>>>> What is 'not' normal is the support ticket reply from his ISP saying 
>>>>> he's intermittently trying to connect to an invalid user id on the remote 
>>>>> side.
>>>>>
>>>>> Again - lets see your RSYNC stanza(s) from weewx.conf and also your 
>>>>> .ssh/config stanza for the account you're using locally to connect to the 
>>>>> ISP server.   This is almost certainly a rsync/ssh configuration issue 
>>>>> based on what I've seen in the thread above.
>>>>>
>>>>> On Sunday, October 29, 2023 at 11:48:48 AM UTC-7 cric...@pobox.com 
>>>>> wrote:
>>>>>
>>>>>> Tom,
>>>>>> So, from your hosting provider, you are getting two types of 
>>>>>> errors.  One for userID, the other for MaxStartups.  The #27 and #28 are 
>>>>>> the number of
>>>>>> Startups, so something is getting hung up somewhere between you and 
>>>>>> your hosting service, and weewx seems to be the victim.  This sure seems 
>>>>>> like
>>>>>> a basic networking/ssh setup issue that's best debugged by hand 
>>>>>> outside of weewx.  One more thing you can try is simply ssh'ing to your 
>>>>>> hosting site,
>>>>>> but include a -v (or two or three v's) in the command line.  It 
>>>>>> generates a LOT of messages, but take your time to see what it's telling 
>>>>>> you if there's a failure.
>>>>>> Make sure all your permissions are correct in all the places you have 
>>>>>> an .ssh directory (directory: chmod 2700, files: chmod 0600).
>>>>>> Chris
>>>>>>
>>>>>> On Sunday, October 29, 2023 at 12:16:10 PM UTC-6 vince wrote:
>>>>>>
>>>>>>> You are posting very cryptic information making helping you very 
>>>>>>> difficult.  And your font looks like you're yelling.
>>>>>>>
>>>>>>> We need to see pieces of your actual configuration files:
>>>>>>>
>>>>>>>- post your weewx.conf RSYNC section(s)
>>>>>>>- post your ~/.ssh/config section for the host(s) you referenced 
>>>>>>>in the RSYNC section in weewx.conf
>>>>>>>- (make sure you show use the ssh config for the user weewx runs 
>>>>>>>as, whatever you are using)
>>>>>>>
>>>>>>> It almost sounds like you have multiple RSYNC sections in weewx and 
>>>>>>> you are trying to upload twice, once to one user, once to a different 
>>>>>>> user. 
>>>>>>>  Regardless, we need to see your actual config file sections to help 
>>>>>>> much.
>>>>>>>
>>>>>>>

-- 
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/0c69c474-d0dc-440a-9ce3-3690d1a64d61n%40googlegroups.com.


Re: [weewx-user] Rsyc Error

2023-10-29 Thread cric...@pobox.com
Tom,
So, from your hosting provider, you are getting two types of errors.  
One for userID, the other for MaxStartups.  The #27 and #28 are the number 
of
Startups, so something is getting hung up somewhere between you and your 
hosting service, and weewx seems to be the victim.  This sure seems like
a basic networking/ssh setup issue that's best debugged by hand outside of 
weewx.  One more thing you can try is simply ssh'ing to your hosting site,
but include a -v (or two or three v's) in the command line.  It generates a 
LOT of messages, but take your time to see what it's telling you if there's 
a failure.
Make sure all your permissions are correct in all the places you have an 
.ssh directory (directory: chmod 2700, files: chmod 0600).
Chris

On Sunday, October 29, 2023 at 12:16:10 PM UTC-6 vince wrote:

> You are posting very cryptic information making helping you very 
> difficult.  And your font looks like you're yelling.
>
> We need to see pieces of your actual configuration files:
>
>- post your weewx.conf RSYNC section(s)
>- post your ~/.ssh/config section for the host(s) you referenced in 
>the RSYNC section in weewx.conf
>- (make sure you show use the ssh config for the user weewx runs as, 
>whatever you are using)
>
> It almost sounds like you have multiple RSYNC sections in weewx and you 
> are trying to upload twice, once to one user, once to a different user. 
>  Regardless, we need to see your actual config file sections to help much.
>
>

-- 
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/a5e8e198-0141-4146-8bb5-5a6d8cb883b0n%40googlegroups.com.


Re: [weewx-user] Rsyc Error

2023-10-29 Thread cric...@pobox.com
Yeah, I need to read slower.  :^)
You are running weewx as user pi? Default is to run the process as root.
So, I'm assuming since you running as pi, you've rync'd your those ssh keys 
to the remote host?

BTW, do you have debug=1 (or 2) in your weewx.conf?  That might help shed 
some light.

Please post your [[RSYNC]] config from the [StdReport].

The one other thing to try is running the rsync by hand from the command 
line several times and see
if you can reproduce the error and get more messaging.

I'm pretty sure weewx only starts one rsync at a time.  Looking through the 
code, I can only find one place
where those error messages are generated, and it always prints the command, 
and should print any of the cmd's output.
bin/weeutil/rsyncupload.py: log.error("rsync reported errors. Original 
command: %s", cmd)
I'm going to have to defer to the experts on this one.

Chris

On Saturday, October 28, 2023 at 9:35:04 AM UTC-6 kq5...@gmail.com wrote:

> I’m using the standard 5 minute interval.  The files being uploaded are 
> the files generated by the standard and seasons report and the Saratoga 
> extension.  As you can see the upload takes less than 2 seconds.  When I 
> was using ftp to upload I was getting errors due to the time it took. 
>  Rsync was suggested and it has been working well.  I don’t know much about 
> how weewx and rsync work but my internet host seems to think it is a 
> software problem.
>
> It appears your Pi is intermittently trying to connect with an incorrect 
>>>> SSH user string, and subsequent connections are maxing the limit for 
>>>> concurrent SSH connections (MaxStartups), so the excess connections are 
>>>> simply dropped by the server. I suggest reviewing the SSH connection 
>>>> string 
>>>> for the PI, as well as ensuring it is closing connections correctly. 
>>>> Additionally, you will want to ensure you are not opening too many 
>>>> concurrent connections for transfer. If the issue persists you may want to 
>>>> increase the amount of time between uploads, as we are unable to increase 
>>>> the MaxStartups setting on shared server.
>>>>
>>>> On Oct 28, 2023, at 8:54 AM, cric...@pobox.com  
> wrote:
>
> Just an observation, but that's a LOT of files and data getting uploaded, 
> and the total time is
> close to 5 minutes, which is the default archive interval.  That 
> MaxStartups limit may be set to 1,
> so is it possible weewx is starting another upload cycle while the last 
> one is in progress?  You could
> try changing this to 600 and see if it helps (in your weewx.conf):
>
> [StdArchive]
> archive_interval  = 300
>
> Chris
> On Friday, October 27, 2023 at 3:56:51 PM UTC-6 Tom -KQ5S wrote:
>
>> It has worked in the past.  I am unsure when it started the working/not 
>> working behavior since I don’t look at the logs that often and the error 
>> was not showing up in the logwatch file.
>>
>> I am running as user pi.
>>
>> version = 4.10.2
>>
>> Pi OS Bullseye
>>
>> SKIN_NAME = Rsync
>> SKIN_VERSION = 4.10.2
>>
>> [Generators]
>> generator_list = weewx.reportengine.RsyncGenerator
>>
>>
>> The fact that it is intermittent makes me think the authorizations are 
>> OK.  Below is the last couple of iterations where you can see it failed and 
>> then worked
>>
>> Oct 27 13:55:21 raspberrypi weewx[15431] ERROR weeutil.rsyncupload: 
>> rsync reported errors.:
>>
>> Oct 27 14:00:26 raspberrypi weewx[15431] INFO weeutil.rsyncupload: 
>> rsync'd 149 files (919,702 bytes) in 1.94 seconds
>>
>> Oct 27 14:05:20 raspberrypi weewx[15431] INFO weeutil.rsyncupload: 
>> rsync'd 29 files (448,591 bytes) in 1.34 seconds
>>
>> Oct 27 14:10:22 raspberrypi weewx[15431] INFO weeutil.rsyncupload: 
>> rsync'd 32 files (453,999 bytes) in 1.28 seconds
>>
>> Oct 27 14:15:19 raspberrypi weewx[15431] ERROR weeutil.rsyncupload: rsync 
>> reported errors.
>>
>> Oct 27 14:20:22 raspberrypi weewx[15431] INFO weeutil.rsyncupload: 
>> rsync'd 32 files (454,465 bytes) in 1.29 seconds
>>
>> Oct 27 14:25:19 raspberrypi weewx[15431] ERROR weeutil.rsyncupload: rsync 
>> reported errors. Original command: ['rsync', '--archive', '--stats', '-e', 
>> 'ssh -p 2222', '/home/weewx/public_html/', 'kq5...@kq5s.com:public_html']
>>
>> Oct 27 14:30:21 raspberrypi weewx[15431] ERROR weeutil.rsyncupload: rsync 
>> reported errors
>>
>> Oct 27 14:35:20 raspberrypi weewx[15431] INFO weeutil.rsyncupload: 
>> rsync'd 32 files (457,673 bytes) in 1.39 seconds
>>
>> Oct 27 14:40:22 raspberrypi weewx[1543

Re: [weewx-user] Rsyc Error

2023-10-28 Thread cric...@pobox.com
Just an observation, but that's a LOT of files and data getting uploaded, 
and the total time is
close to 5 minutes, which is the default archive interval.  That 
MaxStartups limit may be set to 1,
so is it possible weewx is starting another upload cycle while the last one 
is in progress?  You could
try changing this to 600 and see if it helps (in your weewx.conf):

[StdArchive]
archive_interval  = 300

Chris
On Friday, October 27, 2023 at 3:56:51 PM UTC-6 Tom -KQ5S wrote:

> It has worked in the past.  I am unsure when it started the working/not 
> working behavior since I don’t look at the logs that often and the error 
> was not showing up in the logwatch file.
>
> I am running as user pi.
>
> version = 4.10.2
>
> Pi OS Bullseye
>
> SKIN_NAME = Rsync
> SKIN_VERSION = 4.10.2
>
> [Generators]
> generator_list = weewx.reportengine.RsyncGenerator
>
>
> The fact that it is intermittent makes me think the authorizations are OK. 
>  Below is the last couple of iterations where you can see it failed and 
> then worked
>
> Oct 27 13:55:21 raspberrypi weewx[15431] ERROR weeutil.rsyncupload: rsync 
> reported errors.:
>
> Oct 27 14:00:26 raspberrypi weewx[15431] INFO weeutil.rsyncupload: rsync'd 
> 149 files (919,702 bytes) in 1.94 seconds
>
> Oct 27 14:05:20 raspberrypi weewx[15431] INFO weeutil.rsyncupload: rsync'd 
> 29 files (448,591 bytes) in 1.34 seconds
>
> Oct 27 14:10:22 raspberrypi weewx[15431] INFO weeutil.rsyncupload: rsync'd 
> 32 files (453,999 bytes) in 1.28 seconds
>
> Oct 27 14:15:19 raspberrypi weewx[15431] ERROR weeutil.rsyncupload: rsync 
> reported errors.
>
> Oct 27 14:20:22 raspberrypi weewx[15431] INFO weeutil.rsyncupload: rsync'd 
> 32 files (454,465 bytes) in 1.29 seconds
>
> Oct 27 14:25:19 raspberrypi weewx[15431] ERROR weeutil.rsyncupload: rsync 
> reported errors. Original command: ['rsync', '--archive', '--stats', '-e', 
> 'ssh -p ', '/home/weewx/public_html/', 'kq5...@kq5s.com:public_html']
>
> Oct 27 14:30:21 raspberrypi weewx[15431] ERROR weeutil.rsyncupload: rsync 
> reported errors
>
> Oct 27 14:35:20 raspberrypi weewx[15431] INFO weeutil.rsyncupload: rsync'd 
> 32 files (457,673 bytes) in 1.39 seconds
>
> Oct 27 14:40:22 raspberrypi weewx[15431] INFO weeutil.rsyncupload: rsync'd 
> 32 files (457,727 bytes) in 1.28 seconds
>
> On Friday, October 27, 2023 at 8:30:37 AM UTC-5 cric...@pobox.com wrote:
>
>> Is this a new setup, or has it worked in the past?
>> What userID is running weewx?
>> What version of weewx are you running?
>> The contents of my rsync/skin.conf is:
>> SKIN_NAME = Rsync
>> SKIN_VERSION = 4.10.2
>>
>> [Generators]
>> generator_list = weewx.reportengine.RsyncGenerator
>>
>> Does rsync of your /home/weewx/public_html to your web hosting service 
>> work from the command line?
>> If, as which user?
>>
>> On Friday, October 27, 2023 at 4:20:53 AM UTC-6 kq5...@gmail.com wrote:
>>
>>> Anyone? 
>>>
>>>
>>> On Oct 26, 2023, at 8:24 AM, Tom -KQ5S  wrote:
>>>
>>> I am getting the following error from time to time.  Rsync will work 
>>> fine for a while and then I get the error.  I might get the error for a 
>>> couple of cycles then it will work again, then the error again.  I have 
>>> included the reply from my internet host as well.  Ideas?
>>>
>>> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weewx.reportengine: 
>>> Running report 'RSYNC'
>>> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weewx.reportengine: Found 
>>> configuration file /home/weewx/skins/Rsync/skin.conf for report 'RSYNC'
>>> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weewx.reportengine: 
>>> Cannot read localization file /home/weewx/skins/Rsync/lang/en.conf for 
>>> report 'RSYNC': Config file not found: 
>>> "/home/weewx/skins/Rsync/lang/en.conf".
>>> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weewx.reportengine:  
>>> Using defaults instead.
>>> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weeutil.rsyncupload: 
>>> rsyncupload: cmd: [['rsync', '--archive', '--stats', '-e', 'ssh -p ', 
>>> '/home/weewx/public_html/', ‘xx...@kq5s.com]]
>>> Oct 26 07:50:27 raspberrypi weewx[30090] ERROR weeutil.rsyncupload: 
>>> rsync reported errors. Original command: ['rsync', '--archive', '--stats', 
>>> '-e', 'ssh -p ', '/home/weewx/public_html/', ‘xxx...@kq5s.com:’]
>>> Oct 26 07:50:27 raspberrypi weewx[30090] ERROR weeutil.rsyncupload:  
>>> kex_exchange_identification: Connection closed by remote host
>>> Oct 26 07:50:27 raspberrypi weewx[30

Re: [weewx-user] Rsyc Error

2023-10-27 Thread cric...@pobox.com
Is this a new setup, or has it worked in the past?
What userID is running weewx?
What version of weewx are you running?
The contents of my rsync/skin.conf is:
SKIN_NAME = Rsync
SKIN_VERSION = 4.10.2

[Generators]
generator_list = weewx.reportengine.RsyncGenerator

Does rsync of your /home/weewx/public_html to your web hosting service work 
from the command line?
If, as which user?

On Friday, October 27, 2023 at 4:20:53 AM UTC-6 kq5...@gmail.com wrote:

> Anyone? 
>
>
> On Oct 26, 2023, at 8:24 AM, Tom -KQ5S  wrote:
>
> I am getting the following error from time to time.  Rsync will work fine 
> for a while and then I get the error.  I might get the error for a couple 
> of cycles then it will work again, then the error again.  I have included 
> the reply from my internet host as well.  Ideas?
>
> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weewx.reportengine: Running 
> report 'RSYNC'
> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weewx.reportengine: Found 
> configuration file /home/weewx/skins/Rsync/skin.conf for report 'RSYNC'
> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weewx.reportengine: Cannot 
> read localization file /home/weewx/skins/Rsync/lang/en.conf for report 
> 'RSYNC': Config file not found: "/home/weewx/skins/Rsync/lang/en.conf".
> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weewx.reportengine:  
> Using defaults instead.
> Oct 26 07:50:26 raspberrypi weewx[30090] DEBUG weeutil.rsyncupload: 
> rsyncupload: cmd: [['rsync', '--archive', '--stats', '-e', 'ssh -p ', 
> '/home/weewx/public_html/', ‘xx...@kq5s.com]]
> Oct 26 07:50:27 raspberrypi weewx[30090] ERROR weeutil.rsyncupload: rsync 
> reported errors. Original command: ['rsync', '--archive', '--stats', '-e', 
> 'ssh -p ', '/home/weewx/public_html/', ‘xxx...@kq5s.com:’]
> Oct 26 07:50:27 raspberrypi weewx[30090] ERROR weeutil.rsyncupload:  
> kex_exchange_identification: Connection closed by remote host
> Oct 26 07:50:27 raspberrypi weewx[30090] ERROR weeutil.rsyncupload:  
> Connection closed by xxx.xx.xxx.xx port 
> Oct 26 07:50:27 raspberrypi weewx[30090] ERROR weeutil.rsyncupload:  
> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
> Oct 26 07:50:27 raspberrypi weewx[30090] ERROR weeutil.rsyncupload:  
> rsync error: unexplained error (code 255) at io.c(228) [sender=3.2.3]
>
> ==
> From Internet host.  I'm not sure where the user weewx is coming from.  It 
> is not the user set in my config file for rsync.
>
> Regarding SSH, a review of the server's logs shows two repeated 
> occurrences for your user ID "weewx". I've copied an example of each error 
> below:
>
> *Oct 11 15:37:17 ecbiz246 sshd[55604]: Invalid user weewx from 
> xxx.xx.xxx.xx port 60374*
> *Oct 11 15:37:17 ecbiz246 sshd[55604]: Received disconnect from *
> *xxx.xx.xxx.xx** port 60374:11: Bye Bye [preauth]*
> *Oct 11 15:37:17 ecbiz246 sshd[55604]: Disconnected from **xxx.xx.xxx.xx** 
> port 
> 60374 [preauth]*
>  
>
> *Oct 11 06:46:23 ecbiz246 sshd[3762]: drop connection #28 
>  from 
> [**xxx.xx.xxx.xx**]:42380 
> on [**xxx.xx.xxx.xx**]: past MaxStartups*
> *...*
> *Oct 11 09:30:20 ecbiz246 sshd[3762]: drop connection #27 
>  from 
> [x**xxx.xx.xxx.xx**]:47222 
> on [**xxx.xx.xxx.xx**]: past MaxStartups*
>
> It appears your Pi is intermittently trying to connect with an incorrect 
> SSH user string, and subsequent connections are maxing the limit for 
> concurrent SSH connections (MaxStartups), so the excess connections are 
> simply dropped by the server. I suggest reviewing the SSH connection string 
> for the PI, as well as ensuring it is closing connections correctly. 
> Additionally, you will want to ensure you are not opening too many 
> concurrent connections for transfer. If the issue persists you may want to 
> increase the amount of time between uploads, as we are unable to increase 
> the MaxStartups setting on shared server.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/038c234b-113e-4ace-9a62-24c896e5bac2n%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/99d8265e-2310-4db4-9ff5-a1857636d1b8n%40googlegroups.com.


[weewx-user] Re: time tagging images in index.html

2023-10-26 Thread cric...@pobox.com
So this is what I was able to make work in image.html.tmpl:

#if $show_plot

#end if
that results in this:


I'll give your version a try and see if it works the same; which it does.  
What's funny is that the public version
of all this web stuff already has the timestamps, but that's done with 
post-processing as part of the publishing flow
to swap out the host names in the various hrefs before pushing the files 
out.

Thx, Chris
On Thursday, October 26, 2023 at 10:59:15 AM UTC-6 Karen K wrote:

> Sorry
>
> 
>
> Karen K schrieb am Donnerstag, 26. Oktober 2023 um 18:58:29 UTC+2:
>
>> If it is a browser caching issue you can add ?v=$current.dateTime to all 
>> the image references. In your example:
>>
>> 
>>
>> cric...@pobox.com schrieb am Donnerstag, 26. Oktober 2023 um 15:53:21 
>> UTC+2:
>>
>>> Hi Karen,
>>>  So, the images get generated on an RPi, then rsync'd to the machine 
>>> with the web server.  I'd never used
>>> wee_report standalone, and made a directory to run it in, which was 
>>> empty afterwards.  The updated plots
>>> did generate (verified manually, and weewx isn't running, so nothing 
>>> newer from there), and they did sync over.
>>> I used a different browser, and the correct plots id display, so it 
>>> certainly looks like a browser caching issue.
>>> Checking the web comes up with the same solution I found for the same 
>>> problem as shown above.  I'll try finding
>>> a solution in cheetah, since that's generating the index.html.
>>> Thx, Chris
>>> On Thursday, October 26, 2023 at 5:39:08 AM UTC-6 Karen K wrote:
>>>
>>>> May be, the plot image files were not updated because newer versions of 
>>>> it exist. Have you checked the file date/time of the PNG files?
>>>>
>>>> vince schrieb am Mittwoch, 25. Oktober 2023 um 23:06:54 UTC+2:
>>>>
>>>>> Sorry - no help here.  I've had webcam snapshot images that are 
>>>>> uploaded periodically by cron referenced in my templates and unrelated 
>>>>> static pages for many years and have never had any caching issues in any 
>>>>> browser on any platform.  I don't do anything at all re: caching or not 
>>>>> caching images.
>>>>>
>>>>> I use nginx on linux as the webserver, if that's at all relevant.
>>>>>
>>>>>

-- 
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/b6372957-a9b1-4f0b-aa87-53465e63736an%40googlegroups.com.


[weewx-user] Re: time tagging images in index.html

2023-10-26 Thread cric...@pobox.com
Hi Karen,
 So, the images get generated on an RPi, then rsync'd to the machine 
with the web server.  I'd never used
wee_report standalone, and made a directory to run it in, which was empty 
afterwards.  The updated plots
did generate (verified manually, and weewx isn't running, so nothing newer 
from there), and they did sync over.
I used a different browser, and the correct plots id display, so it 
certainly looks like a browser caching issue.
Checking the web comes up with the same solution I found for the same 
problem as shown above.  I'll try finding
a solution in cheetah, since that's generating the index.html.
Thx, Chris
On Thursday, October 26, 2023 at 5:39:08 AM UTC-6 Karen K wrote:

> May be, the plot image files were not updated because newer versions of it 
> exist. Have you checked the file date/time of the PNG files?
>
> vince schrieb am Mittwoch, 25. Oktober 2023 um 23:06:54 UTC+2:
>
>> Sorry - no help here.  I've had webcam snapshot images that are uploaded 
>> periodically by cron referenced in my templates and unrelated static pages 
>> for many years and have never had any caching issues in any browser on any 
>> platform.  I don't do anything at all re: caching or not caching images.
>>
>> I use nginx on linux as the webserver, if that's at all relevant.
>>
>>

-- 
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/a0aed539-dafb-4094-953f-5aaa52b67f82n%40googlegroups.com.


[weewx-user] time tagging images in index.html

2023-10-25 Thread cric...@pobox.com
Hi All,
   Again, semi-unusual use case, but I'm trying to re-plot data from my 
solar system for a particular date using wee_reports.  Everything generates 
OK, but pulling up the web page
hasn't refreshed the plots, only the rest of the data.  I'm assuming this 
is a browser caching problem.  Since clearing the browser cache isn't free 
(side effects), I'm wondering if there's a way to include an argument in 
the href to 'break' browser caching?  I did this with my seismometer pages 
like this:
 day 

The v= breaks the cache in that the image updates regularly (for 
12hrs), but before this, a basic browser refresh wouldn't update the 
image.  After that, the problem was resolved.  A browser refresh would 
indeed pull up the updated plot.

In this problem case, this is the image href that's generated:

hence the caching issue.

I'm game to try to fix this given a few hints.  It sure seems like this 
question has come up before for regular weather plots, but can't recall how 
it was addressed.  I checked my regular weather site, and didn't see 
anything about browser hints to not cache data.

Thx, Chris 

-- 
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/5b75bcdd-4b56-4183-9d43-810903258e20n%40googlegroups.com.


Re: [weewx-user] Re: How to revive 'frozen' WeeWX?

2023-10-18 Thread cric...@pobox.com
This might be a bit more comprehensive:
> sudo find / -xdev -size +100 -ls

This will report any "large" files.  If I'm reading the manpage correctly, 
the number is the count of 512 byte
blocks by default, so you can fiddle with the number and/or tack on a scale 
character.  See "man find" and see
the options for the -size test.

The sudo prevents permissions warnings.

Chris
On Wednesday, October 18, 2023 at 11:47:04 AM UTC-6 vince wrote:

> I know we have a language issue here, but I think you might need a little 
> Linux training too.
>
> We have already established that your /var/log directory is filling up. 
>  That is very unusual.  You need to determine what is causing the big logs.
>
> Please run the following and provide the output:
> ls -al /var/log
>
>

-- 
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/d521769b-0cbf-4070-8a93-00657f7b659cn%40googlegroups.com.


Re: [weewx-user] group_delta_time in Customization guide, but doesn't seem to exist in 4.10.2

2023-09-02 Thread cric...@pobox.com
Noted, thanks.

Chris

On Saturday, September 2, 2023 at 8:14:45 AM UTC-6 Tom Keffer wrote:

> It's "group_deltatime" (not group_delta_time). The reference guide has a 
> typo.
>
> On Sat, Sep 2, 2023 at 6:59 AM cric...@pobox.com  
> wrote:
>
>> Hi Again,
>> At one point setting up this solar panel monitor I thought I 
>> wanted group_delta_time,
>> but weewx failed to start when I used it.  I grepped through all the 
>> weewx .py, .conf, and .tmpl files and it doesn't show up.  Did it get 
>> dropped, or is it new for v5?  I ended up not needing it, just pointing out 
>> the issue.  I'm looking in 4.10.2.  I checked 4.2, not there either.
>>
>> Thx, Chris
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b9dd044a-c952-4ccd-8635-b8fd836abfa7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/b9dd044a-c952-4ccd-8635-b8fd836abfa7n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/444ee6e0-27dc-4de4-8602-75b4109f628bn%40googlegroups.com.


[weewx-user] group_delta_time in Customization guide, but doesn't seem to exist in 4.10.2

2023-09-02 Thread cric...@pobox.com
Hi Again,
At one point setting up this solar panel monitor I thought I 
wanted group_delta_time,
but weewx failed to start when I used it.  I grepped through all the weewx 
.py, .conf, and .tmpl files and it doesn't show up.  Did it get dropped, or 
is it new for v5?  I ended up not needing it, just pointing out the issue.  
I'm looking in 4.10.2.  I checked 4.2, not there either.

Thx, Chris

-- 
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/b9dd044a-c952-4ccd-8635-b8fd836abfa7n%40googlegroups.com.


Re: [weewx-user] comma in label in Seasons skin.conf causes failure

2023-08-31 Thread cric...@pobox.com
Thanks Graham,
   Yes, I'm aware, and have run multilple weewxes from a single directory 
(still multiple daemons) in the past.
In this case, it was a deliberate decision since the solar setup will be 
remote and I also intend on reproducing it
for a friend that's really remote, so this one is fully self contained.

Tom,
I surmised that the comma was a configobj problem interpreting that 
entry as a list.  It still seems a bit
odd that labels with spaces also don't need to be quoted, but..."when in 
Rome..."  :^)  Learn something new
every day.

Thx, Chris

On Wednesday, August 30, 2023 at 11:53:52 PM UTC-6 Graham Eddy wrote:

> for the forum search record, you can do a lot of stuff (especially using 
> services) within one instance of weewx. you only *must* use separate 
> instances when you need multiple drivers, or services conflict with each 
> other. you *may* separate instances for operational or scalability purposes
> *⊣GE⊢*
>
> On 31 Aug 2023, at 9:09 am, cric...@pobox.com  wrote:
>
> I'm setting up yet another weewx instance, this time for plotting a solar 
> charge controller.
>
>
>

-- 
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/8ff5dbd3-575a-4a3b-9126-eea202c78403n%40googlegroups.com.


[weewx-user] comma in label in Seasons skin.conf causes failure

2023-08-30 Thread cric...@pobox.com
I'm setting up yet another weewx instance, this time for plotting a solar 
charge controller.
Not stuck on this, but ran into an issue where having a comma in a label 
name causes
the traceback below.  I didn't try quoting the string, but removing the 
comma cleared
the issue.
This is the latest version; 4.10.2.
  Here's the config that causes the issue:
[[[dayBatteryPwr]]]
battV
battC
   label = Battery Voltage, Current
and the error:
Traceback (most recent call last):
  File "/home/crichmon/weewx/bin/weewx/reportengine.py", line 197, in run
obj.start()
  File "/home/crichmon/weewx/bin/weewx/reportengine.py", line 385, in start
self.run()
  File "/home/crichmon/weewx/bin/weewx/imagegenerator.py", line 42, in run
self.gen_images(self.gen_ts)
  File "/home/crichmon/weewx/bin/weewx/imagegenerator.py", line 107, in 
gen_images
plot = self.gen_plot(plotgen_ts,
  File "/home/crichmon/weewx/bin/weewx/imagegenerator.py", line 293, in 
gen_plot
label = self.text_dict.get(label, label)
  File "/usr/lib/python3/dist-packages/configobj.py", line 642, in get
return self[key]
  File "/usr/lib/python3/dist-packages/configobj.py", line 554, in 
__getitem__
val = dict.__getitem__(self, key)
TypeError: unhashable type: 'list'

Thx,Chris

-- 
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/06808da0-95e7-4b9b-aad9-11fe17648360n%40googlegroups.com.


Re: [weewx-user] Re: Seasons skin - Can't switch to Week/Month/Year

2023-07-31 Thread cric...@pobox.com
Hi Tom,
   I'm finally checking into a similar problem.  In this case, still the 
3.9.1 code base; what doesn't work is selecting the
year or month.  Selecting the History for week, month, year works, but 
selecting which year or month doesn't.  I did futz with
the titlebar.inc.  These should be the differences:
pivp2_/home/weewx/skins.vp2/Seasons> diff 
../../skins.vue/Seasons/titlebar.inc titlebar.inc
11c11,14
<   RSS
---
>   
> http://router1.csrhome.home/vp2weather/smartphone/index.html;>Smartphone
> http://router1.csrhome.home/devices/index.html;>AC 
Devices
>   
At one point I had two stations in two places, so consider the Vue a less 
modified reference.

The whole site is available 
at: https://www.csrhome.online/vp2weather/index.html
Now, what's funny is that if you pull up the AC devices, the year and month 
selectors do work.
I don't know enough about web programming to make sense of it.  I tried 
using the inspection
thing, but that didn't make sense.  One caution, I generate everything for 
a local web server, and
for public consumption, I've got a publishing script that's supposed to 
rewrite all the href's, but it
seems to be missing a couple.  Any suggestions/guesses on what I broke?

Thx, Chris

On Friday, March 29, 2019 at 4:20:37 PM UTC-6 Thomas Keffer wrote:

> Are you uploading the results to somewhere on the web where we can look at 
> it?
>
> -tk
>
> On Fri, Mar 29, 2019 at 3:09 PM Orv Beach  wrote:
>
>> On my install, all 4 in High/Low display all the time.My graphs 
>> (temperature, wind speed) etc. are all the Day views; I can't switch them 
>> to view Week, Month or Year as the Standard skin did.
>>
>> Orv
>> On 3/29/19 12:31 PM, Lloyd Brown wrote:
>>
>> When you refresh the display does it momentarily show all 4 in High/Low?  
>> When you say at the top - the only thing that changes when you select Day 
>> Week Month Year is the High/Low not Current Conditions.  I have a fresh 
>> install of 3.9.1 (within the week) on Raspbian Stretch using the Debian 
>> install, that is how mine works (shows in High/Low) and I did not have to 
>> do anything.
>>
>> On Friday, March 29, 2019 at 1:14:32 PM UTC-6, Orv Beach wrote: 
>>>
>>> Fresh install of 3.9.1 on Debian Stretch, w/Seasons skin (like the skin 
>>> - props to all that worked on it!).  Works well except at the top, although 
>>> I can highlight the Week, Month, and Year, when I click on them the view 
>>> doesn't change away from the Day view.  Is there something I need to enable 
>>> someplace to make that happen?
>>>
>>> Thanks.
>>>
>>> Orv
>>>
>> -- 
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/53736ff2-b651-4292-bb4d-9a182b796538n%40googlegroups.com.


[weewx-user] Re: RSync using NFS

2023-03-02 Thread cric...@pobox.com
Well...not exactly.  I didn't look to see what weewx does with the empty 
server in the config, but either way rsync still works over ssh, which
isn't nfs.  Just straight using nfs, you soft link could link between your 
weewx directory and your destination on the other machine.
Or you can set up passwordless ssh so that rsync works.  ssh uses keys, and 
at least one (.pub) needs to be on the remote end.

What problem are you trying to solve?  Some more clear details would get 
you a better answer.

Chris

On Thursday, March 2, 2023 at 1:24:38 AM UTC-7 Mark Fraser wrote:

> I have set up file sharing between 2 devices using NFS so that I don't 
> have to store passwords. Is it possible to have weewx rsync over this 
> connection as it seems to want a server name and port as part of the 
> configuration?
>

-- 
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/f369fba1-0abb-4955-a3a0-6f3946db6944n%40googlegroups.com.


[weewx-user] Re: Simple MQTT question

2023-02-18 Thread cric...@pobox.com
I skipped setting debug=1, but the config change does seem to work.  The 
original issue was that my thermostat, which
displays setpoint and current inside temp, as well as outside temp and wild 
chill when there is one, was 'stuck' with an outdated
outside temp, which it gets over mqtt from weewx.  The fault was on the 
thermostat end, a restart of that code cleared the issue, and
I'm testing some changes there to see what's up.  Wifey thinks I'm a bit 
nutty, but it keeps me out of the bars.  :^)

Thx, Chris

On Saturday, February 18, 2023 at 12:13:07 PM UTC-7 vince wrote:

> From the comments in the top of the code:
>"Use the inputs map to customize name, format, or unit for any 
> observation."
> So it's not defining what is published.  It's customizing 'some' of what 
> is published.
>
> And also in the comments:
> obs_to_upload: Which observations to upload. Possible values are
> none or all. When none is specified, only items in the inputs list
> will be uploaded. When all is specified, all observations will be
> uploaded, subject to overrides in the inputs list.
> Default is all
>
> So yes. Set debug=1 in weewx.conf and try it.  You can't break anything.
>
> On Saturday, February 18, 2023 at 10:26:47 AM UTC-8 cric...@pobox.com 
> wrote:
>
>> In the process of debugging a non-weewx problem, I realized that weewx is 
>> publishing all observations, even those there's a list to be published 
>> defined in weewx.conf:
>> [StdRESTful]
>> [[StationRegistry]]
>> register_this_station = false
>> [[MQTT]]
>> server_url = mqtt://router1.csrhome.home:1883
>> topic = weather
>> unit_system = US
>> qos = 2# options are 0, 1, 2
>> retain = true  # options are true or false
>> aggregation = individual
>> binding = archive
>> [[[inputs]]]
>> dateTime
>> name   = weewx_time
>> format = %d
>> units  = unix_epoch
>> inTemp
>> name   = inside_temperature
>> format = %.2f
>> units  = degree_F
>> outTemp
>> name   = outside_temperature
>> format = %.2f
>> units  = degree_F
>> windchill
>> name   = outside_wc_temp
>> format = %.2f
>> units  = degree_F
>> windGust
>> name   = windGust
>> format = %.1f
>> units  = mile_per_hour
>>
>> Reading the mqtt,py code (class MQTT), I found the description 
>> for obs_to_upload.  To  publish just the items in the input list, just add 
>> 'obs_to_upload = None' under [[MQTT]],
>> say after the aggregation = individual?
>> Thx, Chris
>>
>

-- 
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/44d5e955-9144-4a8e-b279-cc7329839debn%40googlegroups.com.


[weewx-user] Simple MQTT question

2023-02-18 Thread cric...@pobox.com
In the process of debugging a non-weewx problem, I realized that weewx is 
publishing all observations, even those there's a list to be published 
defined in weewx.conf:
[StdRESTful]
[[StationRegistry]]
register_this_station = false
[[MQTT]]
server_url = mqtt://router1.csrhome.home:1883
topic = weather
unit_system = US
qos = 2# options are 0, 1, 2
retain = true  # options are true or false
aggregation = individual
binding = archive
[[[inputs]]]
dateTime
name   = weewx_time
format = %d
units  = unix_epoch
inTemp
name   = inside_temperature
format = %.2f
units  = degree_F
outTemp
name   = outside_temperature
format = %.2f
units  = degree_F
windchill
name   = outside_wc_temp
format = %.2f
units  = degree_F
windGust
name   = windGust
format = %.1f
units  = mile_per_hour

Reading the mqtt,py code (class MQTT), I found the description 
for obs_to_upload.  To  publish just the items in the input list, just add 
'obs_to_upload = None' under [[MQTT]],
say after the aggregation = individual?
Thx, Chris

-- 
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/e7907c7f-769e-4722-9a8d-18f256dc223fn%40googlegroups.com.


Re: [weewx-user] Dedicated user account for weewx?

2023-01-18 Thread cric...@pobox.com
Aside from communicating with your weather station, the only other non-root 
hang up was where
the PID file was being written.  That's an easy command line option to 
write it somewhere the user
does have permissions.  I don't let systemd manage the process, so I don't 
need the pid file any
particular place.
Chris
On Tuesday, January 17, 2023 at 4:37:36 PM UTC-7 Greg Troxel wrote:

>
> Wayne  writes:
>
> > Hello - I am a new weewx user with medium proficiency in linux. Running 
> on a Raspberry Pi 4 installed from DEB package.
> >
> > Is there any benefit to creating a superuser account specifically for
> > weewx instead of running as "root"? It seems to me it would be a
> > better practice for using rsync to transfer files to an http server on
> > another machine. Or maybe it's not worth the effort. Comments??
>
> Yes, it's basically always better to have a uid (and to a lesser extend
> gid) for each daemon and to grant them access to as little as possible.
>
> weewx doesn't need to be root, in general. It just needs rw access to
> devices that access weather stations, at least in my case.
>
> https://en.wikipedia.org/wiki/Principle_of_least_privilege
>

-- 
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/ffcf6767-2322-4e75-8109-3c5bd1548204n%40googlegroups.com.


Re: [weewx-user] Re: Rsync Help or User Help :o)

2022-11-16 Thread cric...@pobox.com
Important detail:

What is important with the slashes and the path are related to the SOURCE 
path.  It doesn't matter if
the destination does or doesn't have a trailing slash.  It does matter if 
the destination specifies a file rather than
a directory, though.

On Tuesday, November 15, 2022 at 9:51:30 AM UTC-7 FIA Ranch wrote:

> Okay.. Thanks all for the thoughts and comments.
>
> For the sake of anyone fighting this same issue somewhere in the future, 
> let me get this refocused, clarified, up to date.
>
> Baseline Info
> --
> 1) Host Machine is a hosting company
> 2) The host machine is a shared Linux based machine
> 3) I own the domain and rent the hosting
> 4) In the absolute path... home3/fiaranch/ - everything under and 
> past 'fiaranch' I have full control of
>
> 5) Client Machine is mine and is a private machine to be used and abused 
> as I see fit. :o)
>
> Users Question - Closed
> With regards to this issue with WeeWX, all activity will be with my root 
> hat on.
>
> SSH Keys Issue - Closed
> Thanks to Vince I learned that user and root keys are independant.  Now 
> both root and user have their own keys and they have been tested.
>
> SSH Port Question - Closed
> The hosting company states two ports as follows:
> SSH - 22
> SSH Shared/Reseller Servers - 
> NOTE - Command line Rsync actually works with both
>
>
> Question of "/" placement - Closed
>
> Thank you cric...@pobox.com for the definition of differentiation.
>
> File placement on the host is absolute path 
> /home3/fiaranch/public_html/weather/*.*
>
> Using command line, Rsync will accept both, which makes sense based on 
> what cric...@pobox.com stated.
>
> Command (WITH trailing '/') - root@weather:~# rsync -avhze ssh --progress 
> --update --stats  /var/www/html/ --delete 
> fiar...@fiaranch.com:/home3/fiaranch/public_html/weather/
>
> Result (without all the superfulous data)
> sent 595.67K bytes  received 17.85K bytes  31.46K bytes/sec
> total size is 1.79M  speedup is 2.91
>
> Command (WITHOUT trailing '/') - root@weather:~# rsync -avhze ssh 
> --progress --update --stats  /var/www/html/ --delete 
> fiar...@fiaranch.com:/home3/fiaranch/public_html/weather
>
> Result (without all the superfulous data)
> sent 309.53K bytes  received 12.20K bytes  71.49K bytes/sec
> total size is 1.86M  speedup is 5.77
>
> Note - The result difference is mainly a time difference.  However, based 
> on differentiation cric...@pobox.com stated, I am going to go forward 
> without the trailing '/'.
>
> So that brings me to WeeWX config discussion.
>
> The WeeWX Config is now as follows:
> skin = Rsync
> enable = true
> server = fiaranch.com
> user = fiaranch
> path = /home3/fiaranch/public_html/weather
> port = 
> log_success = true
> log_failure = true
> HTML_ROOT = /var/www/html
> delete = 1
>
> Notes:
> 1) The two log entries I added from what Vince posted.  Just to see if 
> that provides any additional information.
> 2) Removed the trailing '/' from the path.
>
> Results
> Nov 15 09:34:23 weather weewx[5274] DEBUG weewx.reportengine: Running 
> report 'RSYNC'
> Nov 15 09:34:23 weather weewx[5274] DEBUG weewx.reportengine: Found 
> configuration file /etc/weewx/skins/Rsync/skin.conf for report 'RSYNC'
> Nov 15 09:34:23 weather weewx[5274] DEBUG weewx.reportengine: Cannot read 
> localization file /etc/weewx/skins/Rsync/lang/en.conf for report 'RSYNC': 
> Config file not found: "/etc/weewx/skins/Rsync/lang/en.conf".
> Nov 15 09:34:23 weather weewx[5274] DEBUG weewx.reportengine:  Using 
> defaults instead.
> Nov 15 09:34:23 weather weewx[5274] DEBUG weeutil.rsyncupload: 
> rsyncupload: cmd: [['rsync', '--archive', '--stats', '--delete', '-e', 'ssh 
> -p ', '/var/www/html/', 
> 'fiar...@fiaranch.com:/home3/fiaranch/public_html/weather']]
> Nov 15 09:34:26 weather weewx[5274] INFO weeutil.rsyncupload: rsync'd 56 
> files (1,093,360 bytes) in 2.42 seconds
>
> WHAT !
>
> All said and done the failures can be attributed to two things:
> 1) SSH Keys must be paired under root, not user - Thank You Vince
> 2) No trailing '/' in the path.  Even though it will work in a command 
> line Rsync, it will not work in WeeWX.
>
> Discussion Closed
>
> Thanks to all for the comments, ideas, assistance, and sharing your 
> experience!
>
> Now going to play with Rsync options to see if I can break it again!! 
>  LMFAO
>
>
>
>
>
>
>
> On Tuesday, November 15, 2022 at 9:17:55 AM UTC-7 jo...@johnkline.com 
> wrote:
>
>> A trailing slash means copy the contents of the directory.
>>
>> Note that WeeWX code will add the slash if it 

Re: [weewx-user] Re: Rsync Help or User Help :o)

2022-11-15 Thread cric...@pobox.com
A couple of points about the trailing slashes.  A trailing slash means copy 
the contents of the directory.  The --archive
means copy everything below the specified directory.  Not including a 
trailing slash means copy this directory and with
--archive, everything below it.  It's not a matter of rsync not working 
because of the slashes, it just does two similar, but
different things.  The man pages for rsync are pretty good.
As for the ssh keys, I'm pretty sure you can just copy the 
~fiaranch/.ssh/id_rsa to ~root/.ssh.  No need to create root-specific
key pair and copy the public server's .ssh directory.  Oh, one other thing 
that's really important:

The .ssh directory permissions are critical.  The directory itself must be 
chmod 0700.  The files inside it should be chmod 0600.
This is true for all the .ssh directories on both ends of the connection.

My setup is a little different; I rsync to another local machine that runs 
a web server.  Then I've got a separate script for
publishing the weewx (and a few other sites) to a public host, since the 
various href's need to be updated.

On Tuesday, November 15, 2022 at 5:25:11 AM UTC-7 Greg Troxel wrote:

>
> "gszla...@gmail.com"  writes:
>
> > 1. Vince is correct. WeeWX runs as root and RSA generation must be done 
> as 
> > root.
>
> I was sure Vince was correct to start with :-) but I think running weewx
> as root is the wrong thing to do. I run it as a non-root user, and
> really there should be a dedicated weewx user that has permissions to do
> what it needs (read the serial port, write the db, access credentials
> for upload) and no more.
>
> But this is really "how best to configure weewx on operating system X",
> which is orthogonal to "how should I made weewx on system X already
> configured as Y work".
>

-- 
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/a69561f5-048a-4e2f-bc8f-e009a9cc2911n%40googlegroups.com.


Re: [weewx-user] Re: Power outage without RTC module

2022-08-23 Thread cric...@pobox.com
My solution was to install ntp, plus add a wait routine in 
bin/user/extensions that waits for ntpq -pn to
report sync'd time.  I use that code on the rest of my Rpi's as well.  Can 
send if interested.  FWIW, the RPi that
runs my weather station does have a RTC stacked on the serial port 
(pre-dates said code block).

On Monday, August 22, 2022 at 5:34:27 PM UTC-6 pa...@pauland.net wrote:

> fake-hwclock is just plain silly, by design it sets the OS time to a known 
> wrong state with the premise that it's a better than nothing choice.
> Funny the further down the rabbit hole I go the more I see that I don't 
> like.  Such as debian setting NTPD or timesyncd to use debian.pool.ntp.org 
> ntp servers.
> I certainly don't trust their list of rotating servers to all be accurate. 
> Always set systems to use known highly available servers I trust.
> It's a jungle out there a minimum you need, Belt, Suspenders, and of 
> course a good quality Tin Foil Hat.
>
> Paul
>
>
>
>
>
>
>
>
>
> so strange that a simple thing lige starting
>
> On Mon, Aug 22, 2022 at 5:28 PM vince  wrote:
>
>> On Monday, August 22, 2022 at 10:12:59 AM UTC-7 pa...@pauland.net wrote:
>>
>>> Problem I've seen in the past was that on a Rasberry Pi installrd NTP , 
>>> like I have on every system I've installed since 2004, yet after a power 
>>> outage weeWx started with a bad Os Time. Investigated and found that if I 
>>> removed purged fake-hwclock the expected wait for ntp worked. Now on some 
>>> systems I install ntp others I don't, if it's a PI remove fake-hwclock and 
>>> even if the machine has a RTC I enable systemd-time-wait-sync.
>>>
>>
>> Yes - but be careful there.  Lots of os now have that blasted 
>> fake-hwclock kludge.
>>
>> I remove fake-hwclock and install/enable ntpd everywhere and it's nice 
>> and simple and reliable.  No need to edit anything in weewx at all, which 
>> is an added plus.
>>
>> The pi time-related details are in the FAQ 
>>  and wiki 
>> .
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/221eacc6-2833-420d-ad00-0d6cb4d56c00n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/50432a30-e42b-423a-bb13-98bb4886aadcn%40googlegroups.com.


Re: [weewx-user] Re: Weewx-Multi not quite working

2022-03-24 Thread cric...@pobox.com
I've been doing something similar for years, and one or a couple of tricks 
is to specify the
pid file location and name.  In my case, I use a single directory, but 
multiple config files,
multiple skin directories, and separate archive directories and database 
names.
I use a perl script to do the restarting (can't stand systemd).

Chris

On Wednesday, March 23, 2022 at 5:17:09 PM UTC-6 tom.h...@gmail.com wrote:

> I'm using 4.7 installed on Ubuntu server - I downloaded the github version 
> of weewx-multi since the Ubuntu package doesn't include it. There's no log 
> info - it just doesn't work correctly when trying to stop or report status, 
> while it *does* work correctly when starting or restarting. Just walked 
> back through the script, thinking maybe there was a typo in PIDFILE or 
> related, but nothing looks amiss. So, I re-grabbed a new copy from github 
> and saved it. Didn't touch anything in it - set all the variables in 
> /etc/default/weewx-multi and tried again - same result. Restart worked, but 
> status says it isn't running. Checked /run/tempest.pid and it correlates to 
> the actual pid of the running tempest instance. Killed all the running 
> weewx instances, deleted the pid files, started them back up with weewx 
> start vp2 and weewx start tempest, both are running, both pids are the same 
> as the pid files created, and yet it still says neither is running when 
> querying status...
>
> This is truly weird, although since it's running and doing all it's 
> weather goodness it's not an emergency or anything. I might let it stew for 
> a few days and look at it again this weekend.
>
>
>
> On Wed, Mar 23, 2022 at 9:44 AM matthew wall  wrote:
>
>> tom,
>>
>> which operating system are you using, and which release?
>>
>> which version of weewx are you using?  more importantly, which 
>> weewx-multi script are you using?
>>
>> if you are not using weewx-multi from the latest weewx release (4.7.0), 
>> could you grab weewx-multi from github and see if that behaves any 
>> differently from the weewx-multi currently on your system?
>>
>> m
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/weewx-user/nZjzDRm6dtY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/146ab416-728b-4ce3-bdb5-e1b366b52efbn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/61428b99-91ea-428f-8e7b-31be8d38e81an%40googlegroups.com.


Re: [weewx-user] how to delete '#FTP.last' file

2022-03-02 Thread cric...@pobox.com
Even using wildcards fails sometimes.  Here's something I wrote years ago.  
It's meant for tweaking
when you run across a nasty file or directory name, so it won't solve your 
problem without a little work.
The foreach loop at the bottom is to print out non-printable characters are 
their ordinal value, which
is invaluable when you can't figure out what's going on.  The trick is not 
trying to handle the names
in a shell at all.  Even perl can fail in this regard using rename and 
unlink.  I may have something to
do with invoking a shell anyway when there are shell variables in the name, 
but that's what the added
backslashes are supposed to prevent.

Chris

#!/usr/bin/perl -w

# adjust as necessary.  This was written to delete a dir that included a 
0xA (\n)
# and square brackets in the actual name, so it was really tough to handle 
from the shell.

opendir(DIR, '.');

while(defined($dir_ent=readdir(DIR))) {
   #next if ( $dir_ent !~ /GetSubrDir/ );

   print " \$dir_ent [$dir_ent]\n";

   $dir_ent =~ s/([\[])/\\$1/g; # '\' protect the brackets so they aren't 
handled as special shell things
   $dir_ent =~ s/([\]])/\\$1/g;

   print " \$dir_ent [$dir_ent]\n";

#   rename( $dir_ent, 'bad_dir' ) or print "failed to rename: $!\n";

   @chars = split('',$dir_ent);  # the split is on a pair of single quotes 
with no space; you get a list of individual characters

   foreach $char(@chars) {
  $ord=ord($char);
  #print " \$ord [$ord], \$char [$char]\n";
  }
   }


On Wednesday, March 2, 2022 at 2:36:41 PM UTC-7 tke...@gmail.com wrote:

> What I use to delete hard to handle names is either a wild card, or the 
> Emacs "directory" mode.
>
> Try something like
>
> *rm *FTP**
>
> Adjust as necessary. Make sure you do an "ls *FTP*" first, so you know 
> what you're targeting!
>
>
> On Wed, Mar 2, 2022 at 1:27 PM Eric Gammeter  wrote:
>
>> Need to delete my #FTP.last file but I cannot get RM or UNLINK commands 
>> to do the job.  I get "missing operand" for both commands.  The file name 
>> has a  '   (single quote) in front and at the end of the name.  ??  
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/d5c3b71b-32e7-44c7-9961-bcf520731aden%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/b747bd9b-188e-4f8a-a8ce-56d2c58f85fbn%40googlegroups.com.


[weewx-user] Re: Belchertown skin - large rsync uploads?

2022-02-05 Thread cric...@pobox.com
The other thing...  Do you have shell access on your hosting provider?  You 
could verify that between rsync runs, the files aren't
getting modified somehow.  Failing that, stop weewx long enough to pull all 
the files from your web host and check them against
your sources locally.  Another option would be to capture a recursive long 
listing (and maybe all the file cksums) of your source directory
before each rsync run.  Diff the captures and see if it's those same files 
that are getting pushed.  rsync in intended to only re-send when
there are differences, and it sounds like you have more differences than 
expected, so that needs to be understood before worrying about
the next thing.

Chris

On Friday, February 4, 2022 at 6:20:55 AM UTC-7 gszla...@gmail.com wrote:

> Thanks vince. You are right - all my sensors update every 60 seconds 
> except the anemometer which is every 16.5 secs so for "realtime",  I chose 
> 20 secs. However I expected rsync to upload only the file differences 
> rather than re-copying the entire local skin. I think the whole template 
> as-is without adding any extra graphs - is about 1.2 MB to 1.3 MB. Rsync is 
> uploading the whole she-bang at a time. Definitely "heavy" on resources 
> when you add a few instances of weewx and a bunch of weather templates plus 
> GW1000 custom upload.(realtime)...Not complaining though..rsync is still 
> the way to go. Many thanks for all the suggestions and 
> recommendations..much appreciated!
>
> On Thursday, February 3, 2022 at 7:18:33 PM UTC-5 vince wrote:
>
>> rsync syncs whatever you have it configured to sync and does so every 
>> archive interval.
>>
>> A 20-second archive interval is very quick especially since your ecowitt 
>> gear only changes readings once per minute probably for most of the 
>> readings other than wind.   You might want to look into the websockets 
>> setup for Belchertown if you are looking for realtime updates.
>>
>> FWIW - mine rsyncs a bit under 3 MB every 5-minute period but I have a 
>> lot of skins and images to upload.
>>
>> You could probably get there via a cron entry that runs less often if you 
>> wanted to dial back how often you rsync, assuming you turned it off in 
>> weewx of course.
>>
>>

-- 
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/045b8a5b-39c6-49d4-839f-a74bc9de16d2n%40googlegroups.com.