Re: [weewx-user] Attempting to switch to non-root user for rsync

[Thomas Keffer]

Rather than put the PID file in /var/run (which could have permission
problems), put it somewhere else where your user has write permissions. See
steps #3 and #4 in *Run as a non-root user
*. In that
example, /home/weewx/run is used as a writable directory for user 'weewx'.

-tk

On Tue, May 7, 2019 at 5:25 PM Steve Chiz  wrote:

> I've tried a dozen things since then, all to no avail. I found an old post
> from Tom regarding commenting out the username lines to run as root again,
> and that is what I did to get the weewx.service to start.
>
> Running the chown returned a file not found, so I assume one or more hard
> reboots (shutdown -r) deleted that file. I removed the commenting on the
> user name and this is the result. Oh, for a troubleshooting guide...
>
> I did not make any database owner changes as I use mariadb.
>
> May  7 20:18:47 WeeWx1 weewx[773]: engine: Locale is 'en_GB.UTF-8'
> May  7 20:18:47 WeeWx1 weewx[773]: engine: pid file is /var/run/weewx.pid
> May  7 20:18:47 WeeWx1 weewxd[773]: Traceback (most recent call last):
> May  7 20:18:47 WeeWx1 weewxd[773]:   File "/usr/bin/weewxd", line 64, in
> 
> May  7 20:18:47 WeeWx1 weewxd[773]: weewx.engine.main(options, args)
> May  7 20:18:47 WeeWx1 weewxd[773]:   File
> "/usr/share/weewx/weewx/engine.py", line 841, in main
> May  7 20:18:47 WeeWx1 weewxd[773]:
> daemon.daemonize(pidfile=options.pidfile)
> May  7 20:18:47 WeeWx1 weewxd[773]:   File "/usr/share/weewx/daemon.py",
> line 77, in daemonize
> May  7 20:18:47 WeeWx1 weewxd[773]: if pidfile:
> file(pidfile,'w+').write("%s\n" % pid)
> May  7 20:18:47 WeeWx1 weewxd[773]: IOError: [Errno 13] Permission denied:
> '/var/run/weewx.pid'
>
> I am changing permissions back to root/ftp and calling it a day. Thanks
> for your help.
>
> On Tuesday, May 7, 2019 at 6:46:51 PM UTC-4, Leon Shaner wrote:
>>
>> Steve,
>>
>> Probably a leftover.
>> I expect this should do it:
>>
>> $ sudo chown weewx /var/run/weewx.pid
>>
>> I would expect that file to be deleted on host reboot, except of course
>> it is pronounced reboot, but spelled:
>>
>> $ sudo shutdown -r now
>>
>> If you use actual "reboot" then it skips shutdown scripts, so it's a big
>> no-no.
>>
>> What about the other files, did you change their owner, too, such as for
>> the DB?
>>
>> Regards,
>> \Leon
>> --
>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>>
>> On May 7, 2019, at 5:42 PM, Steve Chiz  wrote:
>>
>> Guess I spoke too soon. After a reboot, weewx won't start. IOError:
>> [Errno 13] Permission denied: '/var/run/weewx.pid'
>>
>> On Tuesday, May 7, 2019 at 4:37:44 PM UTC-4, Steve Chiz wrote:
>>>
>>> Basically, it was my lack of understanding on how the .rules files work.
>>> I appreciate the explanation of the granular permissions as it helped me
>>> understand the 'why'. I am not worried about others plugging USB devices
>>> into the pi, so I went ahead and edited the 99-usb.rules and added my newly
>>> created weewx user to the plugdev group. I am successfully running weewx as
>>> non-root, thanks again!  WeeWx still complains that my key verification
>>> fails, but I can directly ssh successfully to my remote host as the weewx
>>> user without a password, so I'm close.
>>>
>>> Oh, and thanks for updating the wiki. I had run the "lsusb", I just
>>> wasn't entirely sure what to do with the output. The edit makes it more
>>> clear.
>>>
>>> On Tuesday, May 7, 2019 at 11:28:35 AM UTC-4, Leon Shaner wrote:

 Steve,
 Hope it works!  =D

 I just updated the wiki.  That section now reads:

 First find the idVendor and idProduct of your weatherstation with lsusb 
 command
 then add a rules file in /etc/udev/rules.d/ with this content:

 SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
 ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"

 Name the udev rules file something descriptive, such as an abbreviation
 of your weatherstation model or just weewx.rules, a la
 /etc/udev/rules.d/weewx.rules (extension must be .rules and filename
 should be simple, no spaces or special characters other than '-' and/or '_'
 and should not contain more than one period '.').

 Regards,
 \Leon
 --
 Leon Shaner :: Dearborn, Michigan (iPad Pro)

 On May 7, 2019, at 10:39 AM, Leon Shaner  wrote:

 Steve,

 In my first reply, I failed to answer your first question.

 Yes, if you use the first form with idVendor, idProduct explicitly
 filled in, you can call the UDEV rules file anything you like, as long as
 the extension is .rules and you place it in the /etc/udev/rules.d 
 directory.

 I used a more generic /etc/udev/rules.d/99-usb.rules in my example,
 because my example is very generic, not tied to weewx, but would work for
 weewx provided weewx user is in the plugdev group.

 The (optional) number prefixes on the UDE

Re: [weewx-user] Attempting to switch to non-root user for rsync

[Steve Chiz]

I've tried a dozen things since then, all to no avail. I found an old post 
from Tom regarding commenting out the username lines to run as root again, 
and that is what I did to get the weewx.service to start. 

Running the chown returned a file not found, so I assume one or more hard 
reboots (shutdown -r) deleted that file. I removed the commenting on the 
user name and this is the result. Oh, for a troubleshooting guide...

I did not make any database owner changes as I use mariadb.

May  7 20:18:47 WeeWx1 weewx[773]: engine: Locale is 'en_GB.UTF-8'
May  7 20:18:47 WeeWx1 weewx[773]: engine: pid file is /var/run/weewx.pid
May  7 20:18:47 WeeWx1 weewxd[773]: Traceback (most recent call last):
May  7 20:18:47 WeeWx1 weewxd[773]:   File "/usr/bin/weewxd", line 64, in 

May  7 20:18:47 WeeWx1 weewxd[773]: weewx.engine.main(options, args)
May  7 20:18:47 WeeWx1 weewxd[773]:   File 
"/usr/share/weewx/weewx/engine.py", line 841, in main
May  7 20:18:47 WeeWx1 weewxd[773]: 
daemon.daemonize(pidfile=options.pidfile)
May  7 20:18:47 WeeWx1 weewxd[773]:   File "/usr/share/weewx/daemon.py", 
line 77, in daemonize
May  7 20:18:47 WeeWx1 weewxd[773]: if pidfile: 
file(pidfile,'w+').write("%s\n" % pid)
May  7 20:18:47 WeeWx1 weewxd[773]: IOError: [Errno 13] Permission denied: 
'/var/run/weewx.pid'

I am changing permissions back to root/ftp and calling it a day. Thanks for 
your help.

On Tuesday, May 7, 2019 at 6:46:51 PM UTC-4, Leon Shaner wrote:
>
> Steve,
>
> Probably a leftover.
> I expect this should do it:
>
> $ sudo chown weewx /var/run/weewx.pid
>
> I would expect that file to be deleted on host reboot, except of course it 
> is pronounced reboot, but spelled:
>
> $ sudo shutdown -r now
>
> If you use actual "reboot" then it skips shutdown scripts, so it's a big 
> no-no.
>
> What about the other files, did you change their owner, too, such as for 
> the DB?
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 5:42 PM, Steve Chiz > 
> wrote:
>
> Guess I spoke too soon. After a reboot, weewx won't start. IOError: [Errno 
> 13] Permission denied: '/var/run/weewx.pid'
>
> On Tuesday, May 7, 2019 at 4:37:44 PM UTC-4, Steve Chiz wrote:
>>
>> Basically, it was my lack of understanding on how the .rules files work. 
>> I appreciate the explanation of the granular permissions as it helped me 
>> understand the 'why'. I am not worried about others plugging USB devices 
>> into the pi, so I went ahead and edited the 99-usb.rules and added my newly 
>> created weewx user to the plugdev group. I am successfully running weewx as 
>> non-root, thanks again!  WeeWx still complains that my key verification 
>> fails, but I can directly ssh successfully to my remote host as the weewx 
>> user without a password, so I'm close. 
>>
>> Oh, and thanks for updating the wiki. I had run the "lsusb", I just 
>> wasn't entirely sure what to do with the output. The edit makes it more 
>> clear.
>>
>> On Tuesday, May 7, 2019 at 11:28:35 AM UTC-4, Leon Shaner wrote:
>>>
>>> Steve,
>>> Hope it works!  =D
>>>
>>> I just updated the wiki.  That section now reads:
>>>
>>> First find the idVendor and idProduct of your weatherstation with lsusb 
>>> command 
>>> then add a rules file in /etc/udev/rules.d/ with this content:
>>>
>>> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
>>> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>>>
>>> Name the udev rules file something descriptive, such as an abbreviation 
>>> of your weatherstation model or just weewx.rules, a la 
>>> /etc/udev/rules.d/weewx.rules (extension must be .rules and filename 
>>> should be simple, no spaces or special characters other than '-' and/or '_' 
>>> and should not contain more than one period '.').
>>>
>>> Regards,
>>> \Leon
>>> --
>>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>>>
>>> On May 7, 2019, at 10:39 AM, Leon Shaner  wrote:
>>>
>>> Steve,
>>>
>>> In my first reply, I failed to answer your first question.
>>>
>>> Yes, if you use the first form with idVendor, idProduct explicitly 
>>> filled in, you can call the UDEV rules file anything you like, as long as 
>>> the extension is .rules and you place it in the /etc/udev/rules.d directory.
>>>
>>> I used a more generic /etc/udev/rules.d/99-usb.rules in my example, 
>>> because my example is very generic, not tied to weewx, but would work for 
>>> weewx provided weewx user is in the plugdev group.
>>>
>>> The (optional) number prefixes on the UDEV .rules files establish an 
>>> order of precedence with later rules overriding earlier rules.  Really it's 
>>> ordered lexicographically, so files that start with letters, such as 
>>> weewx.rules will be evaluated after (take precedence over) the files that 
>>> do start with numbers.
>>>
>>> Regards,
>>> \Leon
>>> --
>>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>>>
>>> On May 7, 2019, at 10:31 AM, Leon Shaner  wrote:
>>>
>>> Hey, Steve,
>>>
>>> That first wiki looks pretty complete.

Re: [weewx-user] Attempting to switch to non-root user for rsync

[Leon Shaner]

Steve,

Probably a leftover.
I expect this should do it:

$ sudo chown weewx /var/run/weewx.pid

I would expect that file to be deleted on host reboot, except of course it is 
pronounced reboot, but spelled:

$ sudo shutdown -r now

If you use actual "reboot" then it skips shutdown scripts, so it's a big no-no.

What about the other files, did you change their owner, too, such as for the DB?

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 7, 2019, at 5:42 PM, Steve Chiz  wrote:
> 
> Guess I spoke too soon. After a reboot, weewx won't start. IOError: [Errno 
> 13] Permission denied: '/var/run/weewx.pid'
> 
>> On Tuesday, May 7, 2019 at 4:37:44 PM UTC-4, Steve Chiz wrote:
>> Basically, it was my lack of understanding on how the .rules files work. I 
>> appreciate the explanation of the granular permissions as it helped me 
>> understand the 'why'. I am not worried about others plugging USB devices 
>> into the pi, so I went ahead and edited the 99-usb.rules and added my newly 
>> created weewx user to the plugdev group. I am successfully running weewx as 
>> non-root, thanks again!  WeeWx still complains that my key verification 
>> fails, but I can directly ssh successfully to my remote host as the weewx 
>> user without a password, so I'm close. 
>> 
>> Oh, and thanks for updating the wiki. I had run the "lsusb", I just wasn't 
>> entirely sure what to do with the output. The edit makes it more clear.
>> 
>>> On Tuesday, May 7, 2019 at 11:28:35 AM UTC-4, Leon Shaner wrote:
>>> Steve,
>>> Hope it works!  =D
>>> 
>>> I just updated the wiki.  That section now reads:
>>> 
>>> First find the idVendor and idProduct of your weatherstation with lsusb 
>>> command then add a rules file in /etc/udev/rules.d/ with this content:
>>> 
>>> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
>>> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>>> Name the udev rules file something descriptive, such as an abbreviation of 
>>> your weatherstation model or just weewx.rules, a la 
>>> /etc/udev/rules.d/weewx.rules (extension must be .rules and filename should 
>>> be simple, no spaces or special characters other than '-' and/or '_' and 
>>> should not contain more than one period '.').
>>> 
>>> 
>>> Regards,
>>> \Leon
>>> --
>>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>>> 
 On May 7, 2019, at 10:39 AM, Leon Shaner  wrote:
 
 Steve,
 
 In my first reply, I failed to answer your first question.
 
 Yes, if you use the first form with idVendor, idProduct explicitly filled 
 in, you can call the UDEV rules file anything you like, as long as the 
 extension is .rules and you place it in the /etc/udev/rules.d directory.
 
 I used a more generic /etc/udev/rules.d/99-usb.rules in my example, 
 because my example is very generic, not tied to weewx, but would work for 
 weewx provided weewx user is in the plugdev group.
 
 The (optional) number prefixes on the UDEV .rules files establish an order 
 of precedence with later rules overriding earlier rules.  Really it's 
 ordered lexicographically, so files that start with letters, such as 
 weewx.rules will be evaluated after (take precedence over) the files that 
 do start with numbers.
 
 Regards,
 \Leon
 --
 Leon Shaner :: Dearborn, Michigan (iPad Pro)
 
> On May 7, 2019, at 10:31 AM, Leon Shaner  wrote:
> 
> Hey, Steve,
> 
> That first wiki looks pretty complete.
> Did you in fact try the "lsusb" command to get the values you need for 
> the first form of the udev rules?
> Using the first form with the idVendor and idProduct for your weather 
> station is preferred.
> 
> As an alternative, and if it's just you with physical access to the host 
> and USB devices, e.g. you aren't too worried about other people 
> connecting USB devices and accessing them as non-root, you can also just 
> do this:
> 
> File:  /etc/udev/rules.d/99-usb.rules
> Contents:
> SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660"
> 
> Then be sure to put the wxuser and any other users in the "plugdev" group 
> in /etc/group, a la:
> 
> plugdev:x:46:steve,pi,weewx
> 
> (Or whatever usernames you care to be allowed to access USB ports).
> (Your GID may differ from 46)...
> 
> Notice that for perms, above, I put 0660.  I can't think why "others" / 
> "nobody" should even need to read the USB ports.  Anybody that needs to 
> read(or write) USB ports should be in the "plugdev" group.
> 
> You could of course put GROUP="weewx" in my example above, but then any 
> user would need to be in the weewx port to use any USB device, even those 
> unrelated to weewx.  The "plugdev" group is commonly used for other USB 
> devices, such as auto-mounting removable media, so that is why I chose it 
> in my example.  If you used my example and 

Re: [weewx-user] Re: Installation paths -debian package

[gjr80]

Would help to see exactly what it barfed.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/d04f7388-e163-4043-a685-3a147ba95454%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Installation paths -debian package

[JM]

This did not help. 
If I include the /etc/weewx/weewx.conf  path, it barfs. 
It will run from the 

$ sudo weewxd weewx.conf

This was a straightforward install i have done before. Not sure what I'm 
doing wrong but I feel like I went on three hour cruise and now I'm on 
gilligan's island. :(


On Monday, May 6

, 2019 at 8:34:26 PM UTC-4, Thomas Keffer wrote:

> This is not the first time that Gary has corrected me on the workings of 
> my own software!
>
> He is correct. The search "in the usual places" applies only to the 
> utilities. A path must be specified for weewxd.
>
> -tk
>
> On Mon, May 6, 2019 at 3:54 PM gjr80 > 
> wrote:
>
>> My understanding was that when weewxd is invoked the first command line 
>> parameter is the path and file name of the config file to be be used and no 
>> attempts are made to search elsewhere for the config file. My further 
>> understanding is that searches for the config file 'in the usual places' 
>> occur in the likes of the WeeWX utilities etc. Back to weewxd. If the 
>> config file (as given on the command like) does not exist WeeWX exits.
>>
>> In the case above the command:
>>
>> pi@raspberrypi:~ $ sudo weewxd weewx.conf
>>
>> irrespective of WeeWX installation type, will cause weewxd to use 
>> /home/pi/weewx.conf as the config file, but of course that file does not 
>> exist so WeeWX exits. If WeeWX was installed via a deb package then 
>> weewx.conf will be in /etc/weewx and the correct command to use is:
>>
>> $ sudo weewxd /etc/weewx/weewx.conf
>>
>> Unless of course the present working directory is /etc/weewx in which 
>> case the original command would work.
>>
>> Perhaps there is some confusion here over the command used to run WeeWX 
>> directly. The command is frequently given as:
>>
>> $ sudo weewxd weewx.conf
>>
>> which is often taken literally when in fact there is an implied need to 
>> include the path to weewx.conf. I don't have a problem with this format but 
>> perhaps there is a need for an explanatory note about the requirement for a 
>> path. Though I am not sure this is the only instance of an implied path in 
>> the documents, so if it is done for one it may need to be done for many.
>>
>> In this case I would also remove all of the files copied to /home/pi 
>> (and any other non-standard WeeWX deb package locations), WeeWX may work 
>> with them in place now but you are setting yourself up for chasing your 
>> tail in the future when something does not work and you have multiples 
>> copies of WeeWX on your system.
>>
>> Gary
>>
>> On Tuesday, 7 May 2019 07:35:22 UTC+10, JM wrote:
>>>
>>> To clarify, my understanding is that setup.py installs to different 
>>> paths than the DEB package. it almost seems as if they got switched. 
>>>
>>>
>>> On Monday, May 6, 2019 at 5:32:08 PM UTC-4, JM wrote:

 No its there, I copied the weewx.conf and weewx.conf.dist there. 
 without it, it will not run. 
 FWIW, I originally set up Raspian on a different, New MicroSD and 
 encountered the same problem. both instances behaved the same way. 
 Initially I thought maybe the SD card was defective. 
 So I imaged another card and encountered the same result. 

 I also copied the entire weewx folder from /etc/weewx/ to home/pi/  I 
 dont think this made any difference. I'm confused, since I didn't run 
 Setup.py and that installs to the paths this version is expecting. 
 Any help is appreciated. 



 On Sunday, May 5, 2019 at 8:47:52 PM UTC-4, JM wrote:
>
> I have previously set up two other weather stations using weewx. Just 
> set up a new instance and I am finding that the default installation path 
> for weewx.conf is incorrect. 
> below is a error received in it's initial installation state. I have 
> moved weewx.conf to the /home/pi/ directory and it runs. The weewx 
> documentation indicates that the default DEB package will install to : 
> /etc/weewx/weewx.conf.
> Can anyone give me insight on how to point weewx to the /etc/weewx 
> directory instead of /home/pi ?
>  
>
> pi@raspberrypi:~ $ sudo weewxd weewx.conf
> Traceback (most recent call last):
>   File "/usr/bin/weewxd", line 64, in 
> weewx.engine.main(options, args)
>   File "/usr/share/weewx/weewx/engine.py", line 848, in main
> sane = os.stat(config_path).st_ctime
> OSError: [Errno 2] No such file or directory: '/home/pi/weewx.conf'
>
> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/9d87d861-3da0-44b7-9c95-54f3af4eb0e2%40googlegroups.com
>>  
>> 

Re: [weewx-user] Attempting to switch to non-root user for rsync

[Steve Chiz]

Guess I spoke too soon. After a reboot, weewx won't start. IOError: [Errno 
13] Permission denied: '/var/run/weewx.pid'

On Tuesday, May 7, 2019 at 4:37:44 PM UTC-4, Steve Chiz wrote:
>
> Basically, it was my lack of understanding on how the .rules files work. I 
> appreciate the explanation of the granular permissions as it helped me 
> understand the 'why'. I am not worried about others plugging USB devices 
> into the pi, so I went ahead and edited the 99-usb.rules and added my newly 
> created weewx user to the plugdev group. I am successfully running weewx as 
> non-root, thanks again!  WeeWx still complains that my key verification 
> fails, but I can directly ssh successfully to my remote host as the weewx 
> user without a password, so I'm close. 
>
> Oh, and thanks for updating the wiki. I had run the "lsusb", I just wasn't 
> entirely sure what to do with the output. The edit makes it more clear.
>
> On Tuesday, May 7, 2019 at 11:28:35 AM UTC-4, Leon Shaner wrote:
>>
>> Steve,
>> Hope it works!  =D
>>
>> I just updated the wiki.  That section now reads:
>>
>> First find the idVendor and idProduct of your weatherstation with lsusb 
>> command 
>> then add a rules file in /etc/udev/rules.d/ with this content:
>>
>> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
>> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>>
>> Name the udev rules file something descriptive, such as an abbreviation 
>> of your weatherstation model or just weewx.rules, a la 
>> /etc/udev/rules.d/weewx.rules (extension must be .rules and filename 
>> should be simple, no spaces or special characters other than '-' and/or '_' 
>> and should not contain more than one period '.').
>>
>> Regards,
>> \Leon
>> --
>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>>
>> On May 7, 2019, at 10:39 AM, Leon Shaner  wrote:
>>
>> Steve,
>>
>> In my first reply, I failed to answer your first question.
>>
>> Yes, if you use the first form with idVendor, idProduct explicitly filled 
>> in, you can call the UDEV rules file anything you like, as long as the 
>> extension is .rules and you place it in the /etc/udev/rules.d directory.
>>
>> I used a more generic /etc/udev/rules.d/99-usb.rules in my example, 
>> because my example is very generic, not tied to weewx, but would work for 
>> weewx provided weewx user is in the plugdev group.
>>
>> The (optional) number prefixes on the UDEV .rules files establish an 
>> order of precedence with later rules overriding earlier rules.  Really it's 
>> ordered lexicographically, so files that start with letters, such as 
>> weewx.rules will be evaluated after (take precedence over) the files that 
>> do start with numbers.
>>
>> Regards,
>> \Leon
>> --
>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>>
>> On May 7, 2019, at 10:31 AM, Leon Shaner  wrote:
>>
>> Hey, Steve,
>>
>> That first wiki looks pretty complete.
>> Did you in fact try the "lsusb" command to get the values you need for 
>> the first form of the udev rules?
>> Using the first form with the idVendor and idProduct for your weather 
>> station is preferred.
>>
>> As an alternative, and if it's just you with physical access to the host 
>> and USB devices, e.g. you aren't too worried about other people connecting 
>> USB devices and accessing them as non-root, you can also just do this:
>>
>> File:  /etc/udev/rules.d/99-usb.rules
>> Contents:
>> SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660"
>>
>> Then be sure to put the wxuser and any other users in the "plugdev" group 
>> in /etc/group, a la:
>>
>> plugdev:x:46:steve,pi,weewx
>>
>> (Or whatever usernames you care to be allowed to access USB ports).
>> (Your GID may differ from 46)...
>>
>> Notice that for perms, above, I put 0660.  I can't think why "others" / 
>> "nobody" should even need to read the USB ports.  Anybody that needs to 
>> read(or write) USB ports should be in the "plugdev" group.
>>
>> You could of course put GROUP="weewx" in my example above, but then any 
>> user would need to be in the weewx port to use any USB device, even those 
>> unrelated to weewx.  The "plugdev" group is commonly used for other USB 
>> devices, such as auto-mounting removable media, so that is why I chose it 
>> in my example.  If you used my example and put GROUP="weewx" it would 
>> likely break auto-mounting of removable media (maybe you don't care; maybe 
>> you don't use the usbmount service, etc.).
>>
>> Note that changes in /etc/group take a log out / log in to take effect.
>> Check group membership via "id -a" ...
>>
>> Of course the explicit method, per the wiki, using the idVendor and 
>> idProduct values for your specific USB device avoids any conflict, because 
>> then assigning group weewx would only ever happen to that one device that 
>> exactly matches the idVendor and idProduct values from "lsusb" output.
>>
>> Hope that helps!  =D
>>
>> Regards,
>> \Leon
>> --
>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>>
>> On May 7, 2019, at 9:37 AM, Steve Chiz  wrot

Re: [weewx-user] Re: Add additional rain gauge via second data source

[Thomas Keffer]

Yes. That's certainly possible.

-tk

On Tue, May 7, 2019 at 1:35 PM engolling  wrote:

> Hello together,
>
> it's me again with hopefully a last question...
> As you know I'm augmenting some extra data from my service to the WeeWx
> archive records. But if archive records are loaded of the stations logger
> this data (which is in the future) is also augmented.
> Is it possible to read the timestamp of the archive record beeing saved at
> the moment and then decide if data should be augmented or not?
> Im thinking of a code like this:
> if dateTime_AugmentedData - event.record[dateTime] < 300:
>--> augment_data
>
>
>
>
>
> Am Mittwoch, 3. April 2019 00:54:17 UTC+2 schrieb gjr80:
>>
>> Good that you have tracked down the issue. Running hardware record
>> generation on a Davis station has it advantages, though maybe not so
>> advantageous on emulated hardware.
>>
>> Regards plotting rain data from two sensors. The current WeeWX plot
>> engine will certainly allow you to plot two obs in a bar graph plot, though
>> I expect the outcome will be one bar plotted over the top of the other. Not
>> really what you are seeking. There is no option to plot the bars adjacent
>> to each other. It may be possible to modify the plot engine though I do not
>> expect it would be a simple modification, the plot engine is fairly
>> rudimentary. You may need to use an external charting package which should
>> easily do what you want, though this too will not be a turn key solution as
>> you will need to generate the necessary data for the package as well as
>> integrate it into your web page(s).
>>
>> Gary
>>
>> On Wednesday, 3 April 2019 03:44:09 UTC+10, engolling wrote:
>>>
>>> Hi Gary,
>>>
>>> again thanks for your extended reply.
>>> Meanwhile I added a lot of debugging code in the vantage driver and the
>>> WeatherDuino code and was able to find out the reason what happened.
>>> Their is a buffer on the flash chip which is written before storing the
>>> data in the flash page. And this buffer always had the outdated data of the
>>> page before in the last entries.
>>> This lead to this behaviour that the actual written page contained wrong
>>> data, but the page before and the page after was pretty fine...
>>>
>>> It took me quite some time to find the system behind this error.
>>> I'm in touch with the developper of the WeatherDuino and this issue will
>>> be fixed in the next firmware release so there will be full compatibility
>>> with WeeWx.
>>>
>>> Now that erverything is working I have a last question - do you, or
>>> anybody else, think it is possible to draw a bar graph having the rain bars
>>> of two sensors right beside?
>>> I did not find anything in the manual and if I define the diagramm like
>>> in the line / dot graphs the two bars overlay, so that the bar of the
>>> second rain sensor is not visible, if it is a bit smaller.
>>>
>>> Thank you for all your replies.
>>>
>>> Regards,
>>> engolling
>>>
>>> Am Dienstag, 2. April 2019 16:01:11 UTC+2 schrieb gjr80:

 Sorry for being a little tardy in replying but I wanted to sit down and
 work my way through the Davis protocol. It seems everything is being
 followed, I do not know if the lack of a final acknowledgement is critical
 or not but what I would say is that the Davis driver works with real Davis
 hardware without issue.

 One thing I did wonder, the DMPAFT command downloads all archive
 records after a given timestamp. Archive records are downloaded a page at a
 time and a page contains 5 archive records. When we look at the earlier log
 extracts you have provided there seems to be groups of 5 archive records
 being processed (1 page?) but of course all that are already in the archive
 are rejected, for example:

 Mar 18 22:45:18 WeatherDuinoPi weewx[12220]: manager: Unable to add
 record 2019-03-18 22:43:00 CET (1552945380) to database 'weewx.sdb':
 UNIQUE constraint failed: archive.dateTime
 Mar 18 22:45:20 WeatherDuinoPi weewx[12220]: manager: Added record 2019
 -03-18 22:44:00 CET (1552945440) to database 'weewx.sdb'
 Mar 18 22:45:20 WeatherDuinoPi weewx[12220]: manager: Added record 2019
 -03-18 22:44:00 CET (1552945440) to daily summary in 'weewx.sdb'
 Mar 18 22:45:22 WeatherDuinoPi weewx[12220]: manager: Unable to add
 record 2019-03-18 22:40:00 CET (1552945200) to database 'weewx.sdb':
 UNIQUE constraint failed: archive.dateTime
 Mar 18 22:45:24 WeatherDuinoPi weewx[12220]: manager: Unable to add
 record 2019-03-18 22:41:00 CET (1552945260) to database 'weewx.sdb':
 UNIQUE constraint failed: archive.dateTime
 Mar 18 22:45:25 WeatherDuinoPi weewx[12220]: manager: Unable to add
 record 2019-03-18 22:42:00 CET (1552945320) to database 'weewx.sdb':
 UNIQUE constraint failed: archive.dateTime

 I did not see anywhere where you ran WeeWX directly
  and provided a
>>

Re: [weewx-user] New station migration

[Thomas Keffer]

Did you restart weewx? The software reads a code from the console's EEPROM
to determine the hardware type. So, a simple restart should work.

If not, set debug=1, restart, then post the log from when weewx starts up.
It will log the hardware code.

-tk

On Tue, May 7, 2019 at 9:55 AM  wrote:

> Team,
>
> I upgraded from a Davis Vantage Vue to a Davis VP2 Plus.
>
> What I need to do to make weewx see the new station model?
>
> I did a re-configure but the index.html still shows that the hardware is
> "Vantage Vue"
>
> 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/1855e9b1-7a10-4a07-88cc-a0498896ed48%40googlegroups.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/CAPq0zEBP9rzRiEgvy%3DU2%2BEMz9rjJCLasW7MyT9FtNLNzU0Vmeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Attempting to switch to non-root user for rsync

[Steve Chiz]

Basically, it was my lack of understanding on how the .rules files work. I 
appreciate the explanation of the granular permissions as it helped me 
understand the 'why'. I am not worried about others plugging USB devices 
into the pi, so I went ahead and edited the 99-usb.rules and added my newly 
created weewx user to the plugdev group. I am successfully running weewx as 
non-root, thanks again!  WeeWx still complains that my key verification 
fails, but I can directly ssh successfully to my remote host as the weewx 
user without a password, so I'm close. 

Oh, and thanks for updating the wiki. I had run the "lsusb", I just wasn't 
entirely sure what to do with the output. The edit makes it more clear.

On Tuesday, May 7, 2019 at 11:28:35 AM UTC-4, Leon Shaner wrote:
>
> Steve,
> Hope it works!  =D
>
> I just updated the wiki.  That section now reads:
>
> First find the idVendor and idProduct of your weatherstation with lsusb 
> command 
> then add a rules file in /etc/udev/rules.d/ with this content:
>
> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>
> Name the udev rules file something descriptive, such as an abbreviation of 
> your weatherstation model or just weewx.rules, a la 
> /etc/udev/rules.d/weewx.rules (extension must be .rules and filename 
> should be simple, no spaces or special characters other than '-' and/or '_' 
> and should not contain more than one period '.').
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 10:39 AM, Leon Shaner > 
> wrote:
>
> Steve,
>
> In my first reply, I failed to answer your first question.
>
> Yes, if you use the first form with idVendor, idProduct explicitly filled 
> in, you can call the UDEV rules file anything you like, as long as the 
> extension is .rules and you place it in the /etc/udev/rules.d directory.
>
> I used a more generic /etc/udev/rules.d/99-usb.rules in my example, 
> because my example is very generic, not tied to weewx, but would work for 
> weewx provided weewx user is in the plugdev group.
>
> The (optional) number prefixes on the UDEV .rules files establish an order 
> of precedence with later rules overriding earlier rules.  Really it's 
> ordered lexicographically, so files that start with letters, such as 
> weewx.rules will be evaluated after (take precedence over) the files that 
> do start with numbers.
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 10:31 AM, Leon Shaner > 
> wrote:
>
> Hey, Steve,
>
> That first wiki looks pretty complete.
> Did you in fact try the "lsusb" command to get the values you need for the 
> first form of the udev rules?
> Using the first form with the idVendor and idProduct for your weather 
> station is preferred.
>
> As an alternative, and if it's just you with physical access to the host 
> and USB devices, e.g. you aren't too worried about other people connecting 
> USB devices and accessing them as non-root, you can also just do this:
>
> File:  /etc/udev/rules.d/99-usb.rules
> Contents:
> SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660"
>
> Then be sure to put the wxuser and any other users in the "plugdev" group 
> in /etc/group, a la:
>
> plugdev:x:46:steve,pi,weewx
>
> (Or whatever usernames you care to be allowed to access USB ports).
> (Your GID may differ from 46)...
>
> Notice that for perms, above, I put 0660.  I can't think why "others" / 
> "nobody" should even need to read the USB ports.  Anybody that needs to 
> read(or write) USB ports should be in the "plugdev" group.
>
> You could of course put GROUP="weewx" in my example above, but then any 
> user would need to be in the weewx port to use any USB device, even those 
> unrelated to weewx.  The "plugdev" group is commonly used for other USB 
> devices, such as auto-mounting removable media, so that is why I chose it 
> in my example.  If you used my example and put GROUP="weewx" it would 
> likely break auto-mounting of removable media (maybe you don't care; maybe 
> you don't use the usbmount service, etc.).
>
> Note that changes in /etc/group take a log out / log in to take effect.
> Check group membership via "id -a" ...
>
> Of course the explicit method, per the wiki, using the idVendor and 
> idProduct values for your specific USB device avoids any conflict, because 
> then assigning group weewx would only ever happen to that one device that 
> exactly matches the idVendor and idProduct values from "lsusb" output.
>
> Hope that helps!  =D
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 9:37 AM, Steve Chiz > 
> wrote:
>
> I've been trying to use the wiki to resolve this on my own, but can't seem 
> to sort it out. This page suggests I create a rules file, but no indication 
> on what that file should be named...  weewx.rules?  
> https://github.com/weewx/weewx/wiki/systemd 
>
> I hunted up an older page 
> http

[weewx-user] Re: Add additional rain gauge via second data source

[engolling]

Hello together,

it's me again with hopefully a last question...
As you know I'm augmenting some extra data from my service to the WeeWx 
archive records. But if archive records are loaded of the stations logger 
this data (which is in the future) is also augmented.
Is it possible to read the timestamp of the archive record beeing saved at 
the moment and then decide if data should be augmented or not?
Im thinking of a code like this:
if dateTime_AugmentedData - event.record[dateTime] < 300:
   --> augment_data





Am Mittwoch, 3. April 2019 00:54:17 UTC+2 schrieb gjr80:
>
> Good that you have tracked down the issue. Running hardware record 
> generation on a Davis station has it advantages, though maybe not so 
> advantageous on emulated hardware.
>
> Regards plotting rain data from two sensors. The current WeeWX plot engine 
> will certainly allow you to plot two obs in a bar graph plot, though I 
> expect the outcome will be one bar plotted over the top of the other. Not 
> really what you are seeking. There is no option to plot the bars adjacent 
> to each other. It may be possible to modify the plot engine though I do not 
> expect it would be a simple modification, the plot engine is fairly 
> rudimentary. You may need to use an external charting package which should 
> easily do what you want, though this too will not be a turn key solution as 
> you will need to generate the necessary data for the package as well as 
> integrate it into your web page(s).
>
> Gary
>
> On Wednesday, 3 April 2019 03:44:09 UTC+10, engolling wrote:
>>
>> Hi Gary,
>>
>> again thanks for your extended reply.
>> Meanwhile I added a lot of debugging code in the vantage driver and the 
>> WeatherDuino code and was able to find out the reason what happened.
>> Their is a buffer on the flash chip which is written before storing the 
>> data in the flash page. And this buffer always had the outdated data of the 
>> page before in the last entries.
>> This lead to this behaviour that the actual written page contained wrong 
>> data, but the page before and the page after was pretty fine...
>>
>> It took me quite some time to find the system behind this error.
>> I'm in touch with the developper of the WeatherDuino and this issue will 
>> be fixed in the next firmware release so there will be full compatibility 
>> with WeeWx.
>>
>> Now that erverything is working I have a last question - do you, or 
>> anybody else, think it is possible to draw a bar graph having the rain bars 
>> of two sensors right beside?
>> I did not find anything in the manual and if I define the diagramm like 
>> in the line / dot graphs the two bars overlay, so that the bar of the 
>> second rain sensor is not visible, if it is a bit smaller.
>>
>> Thank you for all your replies.
>>
>> Regards,
>> engolling
>>
>> Am Dienstag, 2. April 2019 16:01:11 UTC+2 schrieb gjr80:
>>>
>>> Sorry for being a little tardy in replying but I wanted to sit down and 
>>> work my way through the Davis protocol. It seems everything is being 
>>> followed, I do not know if the lack of a final acknowledgement is critical 
>>> or not but what I would say is that the Davis driver works with real Davis 
>>> hardware without issue.
>>>
>>> One thing I did wonder, the DMPAFT command downloads all archive records 
>>> after a given timestamp. Archive records are downloaded a page at a time 
>>> and a page contains 5 archive records. When we look at the earlier log 
>>> extracts you have provided there seems to be groups of 5 archive records 
>>> being processed (1 page?) but of course all that are already in the archive 
>>> are rejected, for example:
>>>
>>> Mar 18 22:45:18 WeatherDuinoPi weewx[12220]: manager: Unable to add 
>>> record 2019-03-18 22:43:00 CET (1552945380) to database 'weewx.sdb': 
>>> UNIQUE constraint failed: archive.dateTime 
>>> Mar 18 22:45:20 WeatherDuinoPi weewx[12220]: manager: Added record 2019-
>>> 03-18 22:44:00 CET (1552945440) to database 'weewx.sdb' 
>>> Mar 18 22:45:20 WeatherDuinoPi weewx[12220]: manager: Added record 2019-
>>> 03-18 22:44:00 CET (1552945440) to daily summary in 'weewx.sdb' 
>>> Mar 18 22:45:22 WeatherDuinoPi weewx[12220]: manager: Unable to add 
>>> record 2019-03-18 22:40:00 CET (1552945200) to database 'weewx.sdb': 
>>> UNIQUE constraint failed: archive.dateTime 
>>> Mar 18 22:45:24 WeatherDuinoPi weewx[12220]: manager: Unable to add 
>>> record 2019-03-18 22:41:00 CET (1552945260) to database 'weewx.sdb': 
>>> UNIQUE constraint failed: archive.dateTime 
>>> Mar 18 22:45:25 WeatherDuinoPi weewx[12220]: manager: Unable to add 
>>> record 2019-03-18 22:42:00 CET (1552945320) to database 'weewx.sdb': 
>>> UNIQUE constraint failed: archive.dateTime
>>>
>>> I did not see anywhere where you ran WeeWX directly 
>>>  and provided a 
>>> few minutes of console output. Maybe that may shed more light on the 
>>> problem. Failing that you may need to put some logging in the vantage 
>>>

Re: [weewx-user] FilePile help please

[Colin Larsen]

Hi Thomas,

Done :) and it's been stable overnight, thanks again for the advice.

Colin

On Wed, May 8, 2019 at 1:59 AM Thomas Keffer  wrote:

> You should terminate your lines with '\n', not '\r' when you write your
> file.
>
> while True:
> data, addr = sock.recvfrom(1024) # buffer size is 1024 bytes
> print "Received message:", data
> with open(fname, 'w') as f:
> for ds in data.split(','):
> f.write(ds + "\n")
>
> -tk
>
>
> On Tue, May 7, 2019 at 3:35 AM Colin Larsen 
> wrote:
>
>> Thanks Gary appreciate the thoughts, I'll try those out tomorrow
>>
>> Colin
>>
>> On Tue, 7 May 2019, 20:23 gjr80,  wrote:
>>
>>> A few thoughts. If it works sometimes and not others there must be a
>>> problem with either the consistency of the format of the data or the
>>> algorithm being used to parse the data. Can't say I am a big fan of slicing
>>> in a situation like this, I think it can be a bit rigid at times. Maybe
>>> consider using split. To to obtain your name, value pair maybe something
>>> like:
>>>
>>> ...
>>> for line in fd:
>>> data = line.split("=")
>>> if len(data) != 2:
>>> continue
>>> name,value = data
>>> new_record_data[self.label_map.get(name, name)] =
>>> to_float(value)
>>> ...
>>>
>>> or cut out the middle man if you like:
>>>
>>> ...
>>> for line in fd:
>>> data = line.split("=")
>>> if len(data) != 2:
>>> continue
>>> new_record_data[self.label_map.get(data[0], data[0])] =
>>> to_float(data[1])
>>> ...
>>>
>>> Gary
>>>
>>> On Tuesday, 7 May 2019 17:05:27 UTC+10, Colin Larsen wrote:

 And this is the code the writes the txt file - capturing a string via
 UDP

 *#!/usr/bin/env python*

 *import* socket

 *from* shutil *import* copyfile


 UDP_IP = *"0.0.0.0"*

 UDP_PORT = 9886

 fname = *"/home/pi/AQIData.txt"*


 sock = socket.socket(socket.AF_INET,* # Internet*

  socket.SOCK_DGRAM)* # UDP*

 sock.bind((UDP_IP, UDP_PORT))



 *while* True:


 data, addr = sock.recvfrom(1024)* # buffer size is 1024 bytes*

 *print* *"Received message:"*, data

 dataSplit = data.split(*','*)

 f = open(fname,*'w'*)

 *for* ds *in* dataSplit:

 f.write(ds + *"\r"*)

 f.write(*'\n'*)

 f.close()

 On Tue, May 7, 2019 at 7:01 PM Colin Larsen  wrote:

> Apparently #015 is a numeric representation of \r or 'return' to we
> can rule that out?
>
> On Tue, May 7, 2019 at 6:56 PM Colin Larsen 
> wrote:
>
>> Well this is a little strange. This went fine for a while then
>> stopped again with pretty much the same error. It appears to be missing 
>> the
>> beginning of the first line in the file which is AQI25 = then gets the
>> reading which is 4.55
>>
>> invalid literal for float(): 4.55#015AQI100 = 9.09#015AQIIndex =
>> 18#015AQICO2 = 863
>>
>> Is the #015 a clue of any sorts?
>>
>> The file looks ok
>>
>> AQI25 = 4.55
>>
>> AQI100 = 9.09
>>
>> AQIIndex = 18
>>
>> AQICO2 = 863
>>
>>
>> Error;
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: engine: Main loop exiting.
>> Shutting engine down.
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: engine: Caught
>> unrecoverable exception in engine:
>>
>> May  7 18:50:16 raspberrypi weewx[11960]:   invalid literal
>> for float(): 4.55#015AQI100 = 9.09#015AQIIndex = 18#015AQICO2 = 863
>>
>> May  7 18:50:16 raspberrypi weewx[11960]:   Traceback (most
>> recent call last):
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: File
>> "/usr/share/weewx/weewx/engine.py", line 890, in main
>>
>> May  7 18:50:16 raspberrypi weewx[11960]:   engine.run()
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: File
>> "/usr/share/weewx/weewx/engine.py", line 202, in run
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: 
>> self.dispatchEvent(weewx.Event(weewx.POST_LOOP))
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: File
>> "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: 
>> callback(event)
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: File
>> "/usr/share/weewx/weewx/engine.py", line 574, in post_loop
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: 
>> self._software_catchup()
>>
>> May  7 18:50:16 raspberrypi weewx[11960]: File
>> "/usr/share/weewx/weewx/engine.py", lin

[weewx-user] New station migration

[digitaldistro]

Team,

I upgraded from a Davis Vantage Vue to a Davis VP2 Plus.

What I need to do to make weewx see the new station model?

I did a re-configure but the index.html still shows that the hardware is 
"Vantage Vue"

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/1855e9b1-7a10-4a07-88cc-a0498896ed48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Attempting to switch to non-root user for rsync

[Leon Shaner]

Steve,
Hope it works!  =D

I just updated the wiki.  That section now reads:

First find the idVendor and idProduct of your weatherstation with lsusb command 
then add a rules file in /etc/udev/rules.d/ with this content:

SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", ATTR{idProduct}=="your_value", 
ACTION=="add", GROUP="weewx", MODE="0664"
Name the udev rules file something descriptive, such as an abbreviation of your 
weatherstation model or just weewx.rules, a la /etc/udev/rules.d/weewx.rules 
(extension must be .rules and filename should be simple, no spaces or special 
characters other than '-' and/or '_' and should not contain more than one 
period '.').


Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 7, 2019, at 10:39 AM, Leon Shaner  wrote:
> 
> Steve,
> 
> In my first reply, I failed to answer your first question.
> 
> Yes, if you use the first form with idVendor, idProduct explicitly filled in, 
> you can call the UDEV rules file anything you like, as long as the extension 
> is .rules and you place it in the /etc/udev/rules.d directory.
> 
> I used a more generic /etc/udev/rules.d/99-usb.rules in my example, because 
> my example is very generic, not tied to weewx, but would work for weewx 
> provided weewx user is in the plugdev group.
> 
> The (optional) number prefixes on the UDEV .rules files establish an order of 
> precedence with later rules overriding earlier rules.  Really it's ordered 
> lexicographically, so files that start with letters, such as weewx.rules will 
> be evaluated after (take precedence over) the files that do start with 
> numbers.
> 
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
> 
>> On May 7, 2019, at 10:31 AM, Leon Shaner  wrote:
>> 
>> Hey, Steve,
>> 
>> That first wiki looks pretty complete.
>> Did you in fact try the "lsusb" command to get the values you need for the 
>> first form of the udev rules?
>> Using the first form with the idVendor and idProduct for your weather 
>> station is preferred.
>> 
>> As an alternative, and if it's just you with physical access to the host and 
>> USB devices, e.g. you aren't too worried about other people connecting USB 
>> devices and accessing them as non-root, you can also just do this:
>> 
>> File:  /etc/udev/rules.d/99-usb.rules
>> Contents:
>> SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660"
>> 
>> Then be sure to put the wxuser and any other users in the "plugdev" group in 
>> /etc/group, a la:
>> 
>> plugdev:x:46:steve,pi,weewx
>> 
>> (Or whatever usernames you care to be allowed to access USB ports).
>> (Your GID may differ from 46)...
>> 
>> Notice that for perms, above, I put 0660.  I can't think why "others" / 
>> "nobody" should even need to read the USB ports.  Anybody that needs to 
>> read(or write) USB ports should be in the "plugdev" group.
>> 
>> You could of course put GROUP="weewx" in my example above, but then any user 
>> would need to be in the weewx port to use any USB device, even those 
>> unrelated to weewx.  The "plugdev" group is commonly used for other USB 
>> devices, such as auto-mounting removable media, so that is why I chose it in 
>> my example.  If you used my example and put GROUP="weewx" it would likely 
>> break auto-mounting of removable media (maybe you don't care; maybe you 
>> don't use the usbmount service, etc.).
>> 
>> Note that changes in /etc/group take a log out / log in to take effect.
>> Check group membership via "id -a" ...
>> 
>> Of course the explicit method, per the wiki, using the idVendor and 
>> idProduct values for your specific USB device avoids any conflict, because 
>> then assigning group weewx would only ever happen to that one device that 
>> exactly matches the idVendor and idProduct values from "lsusb" output.
>> 
>> Hope that helps!  =D
>> 
>> Regards,
>> \Leon
>> --
>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>> 
>>> On May 7, 2019, at 9:37 AM, Steve Chiz  wrote:
>>> 
>>> I've been trying to use the wiki to resolve this on my own, but can't seem 
>>> to sort it out. This page suggests I create a rules file, but no indication 
>>> on what that file should be named...  weewx.rules?  
>>> https://github.com/weewx/weewx/wiki/systemd 
>>> 
>>> I hunted up an older page 
>>> https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user that cites an 
>>> example for Vantage (name the file vpro.rules) but what about other 
>>> devices? In any event, the contents of the rules file is different than the 
>>> more recently edited page. Which should I use? 
>>> 
>>> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
>>> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>>>  or 
>>> SUBSYSTEM=="usb", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", 
>>> MODE: = "664", GROUP = "wxuser"
>>> 
>>> I get that one page is about systemd specifically, which I am using, but 
>>> both address the need to run weewx as a non-root user. If someone could 
>>> point me to some documentation on how t

Re: [weewx-user] Attempting to switch to non-root user for rsync

[Steve Chiz]

Hi Leon,

Terrific explanation! Thanks very much, and I'll give it a try.   

On Tuesday, May 7, 2019 at 10:39:56 AM UTC-4, Leon Shaner wrote:
>
> Steve,
>
> In my first reply, I failed to answer your first question.
>
> Yes, if you use the first form with idVendor, idProduct explicitly filled 
> in, you can call the UDEV rules file anything you like, as long as the 
> extension is .rules and you place it in the /etc/udev/rules.d directory.
>
> I used a more generic /etc/udev/rules.d/99-usb.rules in my example, 
> because my example is very generic, not tied to weewx, but would work for 
> weewx provided weewx user is in the plugdev group.
>
> The (optional) number prefixes on the UDEV .rules files establish an order 
> of precedence with later rules overriding earlier rules.  Really it's 
> ordered lexicographically, so files that start with letters, such as 
> weewx.rules will be evaluated after (take precedence over) the files that 
> do start with numbers.
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 10:31 AM, Leon Shaner > 
> wrote:
>
> Hey, Steve,
>
> That first wiki looks pretty complete.
> Did you in fact try the "lsusb" command to get the values you need for the 
> first form of the udev rules?
> Using the first form with the idVendor and idProduct for your weather 
> station is preferred.
>
> As an alternative, and if it's just you with physical access to the host 
> and USB devices, e.g. you aren't too worried about other people connecting 
> USB devices and accessing them as non-root, you can also just do this:
>
> File:  /etc/udev/rules.d/99-usb.rules
> Contents:
> SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660"
>
> Then be sure to put the wxuser and any other users in the "plugdev" group 
> in /etc/group, a la:
>
> plugdev:x:46:steve,pi,weewx
>
> (Or whatever usernames you care to be allowed to access USB ports).
> (Your GID may differ from 46)...
>
> Notice that for perms, above, I put 0660.  I can't think why "others" / 
> "nobody" should even need to read the USB ports.  Anybody that needs to 
> read(or write) USB ports should be in the "plugdev" group.
>
> You could of course put GROUP="weewx" in my example above, but then any 
> user would need to be in the weewx port to use any USB device, even those 
> unrelated to weewx.  The "plugdev" group is commonly used for other USB 
> devices, such as auto-mounting removable media, so that is why I chose it 
> in my example.  If you used my example and put GROUP="weewx" it would 
> likely break auto-mounting of removable media (maybe you don't care; maybe 
> you don't use the usbmount service, etc.).
>
> Note that changes in /etc/group take a log out / log in to take effect.
> Check group membership via "id -a" ...
>
> Of course the explicit method, per the wiki, using the idVendor and 
> idProduct values for your specific USB device avoids any conflict, because 
> then assigning group weewx would only ever happen to that one device that 
> exactly matches the idVendor and idProduct values from "lsusb" output.
>
> Hope that helps!  =D
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 9:37 AM, Steve Chiz > 
> wrote:
>
> I've been trying to use the wiki to resolve this on my own, but can't seem 
> to sort it out. This page suggests I create a rules file, but no indication 
> on what that file should be named...  weewx.rules?  
> https://github.com/weewx/weewx/wiki/systemd 
>
> I hunted up an older page 
> https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user that cites an 
> example for Vantage (name the file vpro.rules) but what about other 
> devices? In any event, the contents of the rules file is different than the 
> more recently edited page. Which should I use? 
>
> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>  or 
> SUBSYSTEM=="usb", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", 
> MODE: = "664", GROUP = "wxuser"
>
> I get that one page is about systemd specifically, which I am using, but both 
> address the need to run weewx as a non-root user. If someone could point me 
> to some documentation on how to switch from running weewx as root to a 
> non-root user, that would be great! I probably should have set it up that way 
> initially, regardless of rsync, as running as root always seems like a risky 
> idea.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com
>  
> 
> .
> For more options, visit http

Re: [weewx-user] Attempting to switch to non-root user for rsync

[Leon Shaner]

Steve,

In my first reply, I failed to answer your first question.

Yes, if you use the first form with idVendor, idProduct explicitly filled in, 
you can call the UDEV rules file anything you like, as long as the extension is 
.rules and you place it in the /etc/udev/rules.d directory.

I used a more generic /etc/udev/rules.d/99-usb.rules in my example, because my 
example is very generic, not tied to weewx, but would work for weewx provided 
weewx user is in the plugdev group.

The (optional) number prefixes on the UDEV .rules files establish an order of 
precedence with later rules overriding earlier rules.  Really it's ordered 
lexicographically, so files that start with letters, such as weewx.rules will 
be evaluated after (take precedence over) the files that do start with numbers.

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 7, 2019, at 10:31 AM, Leon Shaner  wrote:
> 
> Hey, Steve,
> 
> That first wiki looks pretty complete.
> Did you in fact try the "lsusb" command to get the values you need for the 
> first form of the udev rules?
> Using the first form with the idVendor and idProduct for your weather station 
> is preferred.
> 
> As an alternative, and if it's just you with physical access to the host and 
> USB devices, e.g. you aren't too worried about other people connecting USB 
> devices and accessing them as non-root, you can also just do this:
> 
> File:  /etc/udev/rules.d/99-usb.rules
> Contents:
> SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660"
> 
> Then be sure to put the wxuser and any other users in the "plugdev" group in 
> /etc/group, a la:
> 
> plugdev:x:46:steve,pi,weewx
> 
> (Or whatever usernames you care to be allowed to access USB ports).
> (Your GID may differ from 46)...
> 
> Notice that for perms, above, I put 0660.  I can't think why "others" / 
> "nobody" should even need to read the USB ports.  Anybody that needs to 
> read(or write) USB ports should be in the "plugdev" group.
> 
> You could of course put GROUP="weewx" in my example above, but then any user 
> would need to be in the weewx port to use any USB device, even those 
> unrelated to weewx.  The "plugdev" group is commonly used for other USB 
> devices, such as auto-mounting removable media, so that is why I chose it in 
> my example.  If you used my example and put GROUP="weewx" it would likely 
> break auto-mounting of removable media (maybe you don't care; maybe you don't 
> use the usbmount service, etc.).
> 
> Note that changes in /etc/group take a log out / log in to take effect.
> Check group membership via "id -a" ...
> 
> Of course the explicit method, per the wiki, using the idVendor and idProduct 
> values for your specific USB device avoids any conflict, because then 
> assigning group weewx would only ever happen to that one device that exactly 
> matches the idVendor and idProduct values from "lsusb" output.
> 
> Hope that helps!  =D
> 
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
> 
>> On May 7, 2019, at 9:37 AM, Steve Chiz  wrote:
>> 
>> I've been trying to use the wiki to resolve this on my own, but can't seem 
>> to sort it out. This page suggests I create a rules file, but no indication 
>> on what that file should be named...  weewx.rules?  
>> https://github.com/weewx/weewx/wiki/systemd 
>> 
>> I hunted up an older page 
>> https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user that cites an 
>> example for Vantage (name the file vpro.rules) but what about other devices? 
>> In any event, the contents of the rules file is different than the more 
>> recently edited page. Which should I use? 
>> 
>> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
>> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>>  or 
>> SUBSYSTEM=="usb", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", 
>> MODE: = "664", GROUP = "wxuser"
>> 
>> I get that one page is about systemd specifically, which I am using, but 
>> both address the need to run weewx as a non-root user. If someone could 
>> point me to some documentation on how to switch from running weewx as root 
>> to a non-root user, that would be great! I probably should have set it up 
>> that way initially, regardless of rsync, as running as root always seems 
>> like a risky idea.
>> -- 
>> 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/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.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 

Re: [weewx-user] cannot find 'avg' while searching for 'hour.windspeed.avg.raw'

[HoracioDos]

Hello Tom.
This is not related to belchertown. It is a customized version of NOAA 
reports. It could happen with any other skin.  I didn't noticed the capital 
letter in windSpeed. Palm face!! I'll change it and I'll see what happens. 
Now I have a doubt, why this report complains only in that period and not 
in others. If the tag name is wrong it should show errors in every report 
cycle. Perhaps Andrew has a point there.
Thank you both! I'll keep you informed.

On Tuesday, May 7, 2019 at 11:05:44 AM UTC-3, Thomas Keffer wrote:
>
> Sorry, but I don't know anything about the Belchertown skins. However, in 
> the rest of weewx, it would be $hour.windSpeed.avg.raw. Note the capital 
> 'S' in windSpeed.
>
> -tk
>
> On Tue, May 7, 2019 at 5:49 AM HoracioDos > 
> wrote:
>
>> Hello Tom.
>> I have this text report which is having some problem with avg wind speed 
>> only at 01:00 AM everyday. I'm using simulator driver and it generates many 
>> times 0 mph and direction north = 0. I don't know if both situations are 
>> related. I attached the errors and report.
>> Thanks in advance
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/7a88d411-695d-4f22-9bc2-46bdd4fb3243%40googlegroups.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/f4fa5126-210e-46a0-a212-c110f7a6db3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Attempting to switch to non-root user for rsync

[Leon Shaner]

Hey, Steve,

That first wiki looks pretty complete.
Did you in fact try the "lsusb" command to get the values you need for the 
first form of the udev rules?
Using the first form with the idVendor and idProduct for your weather station 
is preferred.

As an alternative, and if it's just you with physical access to the host and 
USB devices, e.g. you aren't too worried about other people connecting USB 
devices and accessing them as non-root, you can also just do this:

File:  /etc/udev/rules.d/99-usb.rules
Contents:
SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660"

Then be sure to put the wxuser and any other users in the "plugdev" group in 
/etc/group, a la:

plugdev:x:46:steve,pi,weewx

(Or whatever usernames you care to be allowed to access USB ports).
(Your GID may differ from 46)...

Notice that for perms, above, I put 0660.  I can't think why "others" / 
"nobody" should even need to read the USB ports.  Anybody that needs to read(or 
write) USB ports should be in the "plugdev" group.

You could of course put GROUP="weewx" in my example above, but then any user 
would need to be in the weewx port to use any USB device, even those unrelated 
to weewx.  The "plugdev" group is commonly used for other USB devices, such as 
auto-mounting removable media, so that is why I chose it in my example.  If you 
used my example and put GROUP="weewx" it would likely break auto-mounting of 
removable media (maybe you don't care; maybe you don't use the usbmount 
service, etc.).

Note that changes in /etc/group take a log out / log in to take effect.
Check group membership via "id -a" ...

Of course the explicit method, per the wiki, using the idVendor and idProduct 
values for your specific USB device avoids any conflict, because then assigning 
group weewx would only ever happen to that one device that exactly matches the 
idVendor and idProduct values from "lsusb" output.

Hope that helps!  =D

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 7, 2019, at 9:37 AM, Steve Chiz  wrote:
> 
> I've been trying to use the wiki to resolve this on my own, but can't seem to 
> sort it out. This page suggests I create a rules file, but no indication on 
> what that file should be named...  weewx.rules?  
> https://github.com/weewx/weewx/wiki/systemd 
> 
> I hunted up an older page 
> https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user that cites an 
> example for Vantage (name the file vpro.rules) but what about other devices? 
> In any event, the contents of the rules file is different than the more 
> recently edited page. Which should I use? 
> 
> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>  or 
> SUBSYSTEM=="usb", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", 
> MODE: = "664", GROUP = "wxuser"
> 
> I get that one page is about systemd specifically, which I am using, but both 
> address the need to run weewx as a non-root user. If someone could point me 
> to some documentation on how to switch from running weewx as root to a 
> non-root user, that would be great! I probably should have set it up that way 
> initially, regardless of rsync, as running as root always seems like a risky 
> idea.
> -- 
> 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/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.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/0130621D-4F28-4F79-8036-1EF1743D9A95%40isylum.org.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] cannot find 'avg' while searching for 'hour.windspeed.avg.raw'

[Thomas Keffer]

Sorry, but I don't know anything about the Belchertown skins. However, in
the rest of weewx, it would be $hour.windSpeed.avg.raw. Note the capital
'S' in windSpeed.

-tk

On Tue, May 7, 2019 at 5:49 AM HoracioDos  wrote:

> Hello Tom.
> I have this text report which is having some problem with avg wind speed
> only at 01:00 AM everyday. I'm using simulator driver and it generates many
> times 0 mph and direction north = 0. I don't know if both situations are
> related. I attached the errors and report.
> Thanks in advance
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/7a88d411-695d-4f22-9bc2-46bdd4fb3243%40googlegroups.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/CAPq0zED%3DFTGoz0UnM9fee8d4B7tsrV4DVkegBVMRVo9b18aDug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] FilePile help please

[Thomas Keffer]

You should terminate your lines with '\n', not '\r' when you write your
file.

while True:
data, addr = sock.recvfrom(1024) # buffer size is 1024 bytes
print "Received message:", data
with open(fname, 'w') as f:
for ds in data.split(','):
f.write(ds + "\n")

-tk


On Tue, May 7, 2019 at 3:35 AM Colin Larsen  wrote:

> Thanks Gary appreciate the thoughts, I'll try those out tomorrow
>
> Colin
>
> On Tue, 7 May 2019, 20:23 gjr80,  wrote:
>
>> A few thoughts. If it works sometimes and not others there must be a
>> problem with either the consistency of the format of the data or the
>> algorithm being used to parse the data. Can't say I am a big fan of slicing
>> in a situation like this, I think it can be a bit rigid at times. Maybe
>> consider using split. To to obtain your name, value pair maybe something
>> like:
>>
>> ...
>> for line in fd:
>> data = line.split("=")
>> if len(data) != 2:
>> continue
>> name,value = data
>> new_record_data[self.label_map.get(name, name)] =
>> to_float(value)
>> ...
>>
>> or cut out the middle man if you like:
>>
>> ...
>> for line in fd:
>> data = line.split("=")
>> if len(data) != 2:
>> continue
>> new_record_data[self.label_map.get(data[0], data[0])] =
>> to_float(data[1])
>> ...
>>
>> Gary
>>
>> On Tuesday, 7 May 2019 17:05:27 UTC+10, Colin Larsen wrote:
>>>
>>> And this is the code the writes the txt file - capturing a string via UDP
>>>
>>> *#!/usr/bin/env python*
>>>
>>> *import* socket
>>>
>>> *from* shutil *import* copyfile
>>>
>>>
>>> UDP_IP = *"0.0.0.0"*
>>>
>>> UDP_PORT = 9886
>>>
>>> fname = *"/home/pi/AQIData.txt"*
>>>
>>>
>>> sock = socket.socket(socket.AF_INET,* # Internet*
>>>
>>>  socket.SOCK_DGRAM)* # UDP*
>>>
>>> sock.bind((UDP_IP, UDP_PORT))
>>>
>>>
>>>
>>> *while* True:
>>>
>>>
>>> data, addr = sock.recvfrom(1024)* # buffer size is 1024 bytes*
>>>
>>> *print* *"Received message:"*, data
>>>
>>> dataSplit = data.split(*','*)
>>>
>>> f = open(fname,*'w'*)
>>>
>>> *for* ds *in* dataSplit:
>>>
>>> f.write(ds + *"\r"*)
>>>
>>> f.write(*'\n'*)
>>>
>>> f.close()
>>>
>>> On Tue, May 7, 2019 at 7:01 PM Colin Larsen  wrote:
>>>
 Apparently #015 is a numeric representation of \r or 'return' to we
 can rule that out?

 On Tue, May 7, 2019 at 6:56 PM Colin Larsen  wrote:

> Well this is a little strange. This went fine for a while then stopped
> again with pretty much the same error. It appears to be missing the
> beginning of the first line in the file which is AQI25 = then gets the
> reading which is 4.55
>
> invalid literal for float(): 4.55#015AQI100 = 9.09#015AQIIndex =
> 18#015AQICO2 = 863
>
> Is the #015 a clue of any sorts?
>
> The file looks ok
>
> AQI25 = 4.55
>
> AQI100 = 9.09
>
> AQIIndex = 18
>
> AQICO2 = 863
>
>
> Error;
>
> May  7 18:50:16 raspberrypi weewx[11960]: engine: Main loop exiting.
> Shutting engine down.
>
> May  7 18:50:16 raspberrypi weewx[11960]: engine: Caught
> unrecoverable exception in engine:
>
> May  7 18:50:16 raspberrypi weewx[11960]:   invalid literal
> for float(): 4.55#015AQI100 = 9.09#015AQIIndex = 18#015AQICO2 = 863
>
> May  7 18:50:16 raspberrypi weewx[11960]:   Traceback (most
> recent call last):
>
> May  7 18:50:16 raspberrypi weewx[11960]: File
> "/usr/share/weewx/weewx/engine.py", line 890, in main
>
> May  7 18:50:16 raspberrypi weewx[11960]:   engine.run()
>
> May  7 18:50:16 raspberrypi weewx[11960]: File
> "/usr/share/weewx/weewx/engine.py", line 202, in run
>
> May  7 18:50:16 raspberrypi weewx[11960]: 
> self.dispatchEvent(weewx.Event(weewx.POST_LOOP))
>
> May  7 18:50:16 raspberrypi weewx[11960]: File
> "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
>
> May  7 18:50:16 raspberrypi weewx[11960]: 
> callback(event)
>
> May  7 18:50:16 raspberrypi weewx[11960]: File
> "/usr/share/weewx/weewx/engine.py", line 574, in post_loop
>
> May  7 18:50:16 raspberrypi weewx[11960]: 
> self._software_catchup()
>
> May  7 18:50:16 raspberrypi weewx[11960]: File
> "/usr/share/weewx/weewx/engine.py", line 646, in _software_catchup
>
> May  7 18:50:16 raspberrypi weewx[11960]:   
> self.engine.dispatchEvent(weewx.Event(weewx.NEW_ARCHIVE_RECORD,
> record=record, origin='software'))
>
> May  7 18:50:16 raspberrypi weewx[11960]: File
> "/usr/share/weewx/weewx/engine.py", line 224, in dis

[weewx-user] Attempting to switch to non-root user for rsync

[Steve Chiz]

I've been trying to use the wiki to resolve this on my own, but can't seem 
to sort it out. This page suggests I create a rules file, but no indication 
on what that file should be named...  weewx.rules?  
https://github.com/weewx/weewx/wiki/systemd 

I hunted up an older page 
https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user that cites an 
example for Vantage (name the file vpro.rules) but what about other 
devices? In any event, the contents of the rules file is different than the 
more recently edited page. Which should I use? 

SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", ATTR{idProduct}=="your_value", 
ACTION=="add", GROUP="weewx", MODE="0664"
 or 
SUBSYSTEM=="usb", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", 
MODE: = "664", GROUP = "wxuser"

I get that one page is about systemd specifically, which I am using, but both 
address the need to run weewx as a non-root user. If someone could point me to 
some documentation on how to switch from running weewx as root to a non-root 
user, that would be great! I probably should have set it up that way initially, 
regardless of rsync, as running as root always seems like a risky idea.

-- 
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/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: cannot find 'avg' while searching for 'hour.windspeed.avg.raw'

[Andrew Milner]

I would suspect it is because an archive record times at say 00:00 actually 
contains data for the previous day
The first record for the current day will not be (assuming 5 minute 
intervals) until 00:05
This means that there is no avg for an hour period in the current day 
available until 01:05 - so I suspect you need a little bit of code to get 
around the edge condition at 01:00 or something similar .

unless of course it is indeed a bug of some kind caused by the edge 
condition at 01:00.




On Tuesday, 7 May 2019 15:49:15 UTC+3, HoracioDos wrote:
>
> Hello Tom.
> I have this text report which is having some problem with avg wind speed 
> only at 01:00 AM everyday. I'm using simulator driver and it generates many 
> times 0 mph and direction north = 0. I don't know if both situations are 
> related. I attached the errors and report.
> Thanks in advance
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/3e51ad44-c4a6-4a2f-8ba5-71c53dff29ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] cannot find 'avg' while searching for 'hour.windspeed.avg.raw'

[HoracioDos]

Hello Tom.
I have this text report which is having some problem with avg wind speed 
only at 01:00 AM everyday. I'm using simulator driver and it generates many 
times 0 mph and direction north = 0. I don't know if both situations are 
related. I attached the errors and report.
Thanks in advance

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7a88d411-695d-4f22-9bc2-46bdd4fb3243%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


stats--MM.txt.tmpl
Description: Binary data
May 07 01:01:09 PiWeewx weewx[395]: cheetahgenerator: Generate failed with 
exception ''
May 07 01:01:09 PiWeewx weewx[395]: cheetahgenerator:  Ignoring template 
/etc/weewx/skins/Belchertown/stats/stats--MM.txt.tmpl
May 07 01:01:09 PiWeewx weewx[395]: cheetahgenerator:  Reason: cannot find 
'avg' while searching for 'hour.windspeed.avg.raw'
May 07 01:01:09 PiWeewx weewx[395]:   Traceback (most recent call last):
May 07 01:01:09 PiWeewx weewx[395]: File 
"/usr/share/weewx/weewx/cheetahgenerator.py", line 332, in generate
May 07 01:01:09 PiWeewx weewx[395]:   fd.write(str(compiled_template))
May 07 01:01:09 PiWeewx weewx[395]: File 
"/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in __str__
May 07 01:01:09 PiWeewx weewx[395]:   rc = getattr(self, mainMethName)()
May 07 01:01:09 PiWeewx weewx[395]: File 
"_etc_weewx_skins_Belchertown_stats_stats__MM_txt_tmpl.py", line 1154, in 
respond
May 07 01:01:09 PiWeewx weewx[395]:   NotFound: cannot find 'avg' while 
searching for 'hour.windspeed.avg.raw'

Re: [weewx-user] FilePile help please

[Colin Larsen]

Thanks Gary appreciate the thoughts, I'll try those out tomorrow

Colin

On Tue, 7 May 2019, 20:23 gjr80,  wrote:

> A few thoughts. If it works sometimes and not others there must be a
> problem with either the consistency of the format of the data or the
> algorithm being used to parse the data. Can't say I am a big fan of slicing
> in a situation like this, I think it can be a bit rigid at times. Maybe
> consider using split. To to obtain your name, value pair maybe something
> like:
>
> ...
> for line in fd:
> data = line.split("=")
> if len(data) != 2:
> continue
> name,value = data
> new_record_data[self.label_map.get(name, name)] = to_float
> (value)
> ...
>
> or cut out the middle man if you like:
>
> ...
> for line in fd:
> data = line.split("=")
> if len(data) != 2:
> continue
> new_record_data[self.label_map.get(data[0], data[0])] =
> to_float(data[1])
> ...
>
> Gary
>
> On Tuesday, 7 May 2019 17:05:27 UTC+10, Colin Larsen wrote:
>>
>> And this is the code the writes the txt file - capturing a string via UDP
>>
>> *#!/usr/bin/env python*
>>
>> *import* socket
>>
>> *from* shutil *import* copyfile
>>
>>
>> UDP_IP = *"0.0.0.0"*
>>
>> UDP_PORT = 9886
>>
>> fname = *"/home/pi/AQIData.txt"*
>>
>>
>> sock = socket.socket(socket.AF_INET,* # Internet*
>>
>>  socket.SOCK_DGRAM)* # UDP*
>>
>> sock.bind((UDP_IP, UDP_PORT))
>>
>>
>>
>> *while* True:
>>
>>
>> data, addr = sock.recvfrom(1024)* # buffer size is 1024 bytes*
>>
>> *print* *"Received message:"*, data
>>
>> dataSplit = data.split(*','*)
>>
>> f = open(fname,*'w'*)
>>
>> *for* ds *in* dataSplit:
>>
>> f.write(ds + *"\r"*)
>>
>> f.write(*'\n'*)
>>
>> f.close()
>>
>> On Tue, May 7, 2019 at 7:01 PM Colin Larsen  wrote:
>>
>>> Apparently #015 is a numeric representation of \r or 'return' to we can
>>> rule that out?
>>>
>>> On Tue, May 7, 2019 at 6:56 PM Colin Larsen  wrote:
>>>
 Well this is a little strange. This went fine for a while then stopped
 again with pretty much the same error. It appears to be missing the
 beginning of the first line in the file which is AQI25 = then gets the
 reading which is 4.55

 invalid literal for float(): 4.55#015AQI100 = 9.09#015AQIIndex =
 18#015AQICO2 = 863

 Is the #015 a clue of any sorts?

 The file looks ok

 AQI25 = 4.55

 AQI100 = 9.09

 AQIIndex = 18

 AQICO2 = 863


 Error;

 May  7 18:50:16 raspberrypi weewx[11960]: engine: Main loop exiting.
 Shutting engine down.

 May  7 18:50:16 raspberrypi weewx[11960]: engine: Caught unrecoverable
 exception in engine:

 May  7 18:50:16 raspberrypi weewx[11960]:   invalid literal
 for float(): 4.55#015AQI100 = 9.09#015AQIIndex = 18#015AQICO2 = 863

 May  7 18:50:16 raspberrypi weewx[11960]:   Traceback (most
 recent call last):

 May  7 18:50:16 raspberrypi weewx[11960]: File
 "/usr/share/weewx/weewx/engine.py", line 890, in main

 May  7 18:50:16 raspberrypi weewx[11960]:   engine.run()

 May  7 18:50:16 raspberrypi weewx[11960]: File
 "/usr/share/weewx/weewx/engine.py", line 202, in run

 May  7 18:50:16 raspberrypi weewx[11960]: 
 self.dispatchEvent(weewx.Event(weewx.POST_LOOP))

 May  7 18:50:16 raspberrypi weewx[11960]: File
 "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent

 May  7 18:50:16 raspberrypi weewx[11960]:   callback(event)

 May  7 18:50:16 raspberrypi weewx[11960]: File
 "/usr/share/weewx/weewx/engine.py", line 574, in post_loop

 May  7 18:50:16 raspberrypi weewx[11960]: 
 self._software_catchup()

 May  7 18:50:16 raspberrypi weewx[11960]: File
 "/usr/share/weewx/weewx/engine.py", line 646, in _software_catchup

 May  7 18:50:16 raspberrypi weewx[11960]:   
 self.engine.dispatchEvent(weewx.Event(weewx.NEW_ARCHIVE_RECORD,
 record=record, origin='software'))

 May  7 18:50:16 raspberrypi weewx[11960]: File
 "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent

 May  7 18:50:16 raspberrypi weewx[11960]:   callback(event)

 May  7 18:50:16 raspberrypi weewx[11960]: File
 "/usr/share/weewx/user/filepile.py", line 91, in new_archive_record

 May  7 18:50:16 raspberrypi weewx[11960]:   
 new_record_data[self.label_map.get(name,
 name)] = to_float(value)

 May  7 18:50:16 raspberrypi weewx[11960]: File
 "/usr/share/weewx/weeutil/weeutil.py", line 1280, in to

Re: [weewx-user] FilePile help please

[gjr80]

A few thoughts. If it works sometimes and not others there must be a 
problem with either the consistency of the format of the data or the 
algorithm being used to parse the data. Can't say I am a big fan of slicing 
in a situation like this, I think it can be a bit rigid at times. Maybe 
consider using split. To to obtain your name, value pair maybe something 
like:

...
for line in fd:
data = line.split("=")
if len(data) != 2:
continue
name,value = data
new_record_data[self.label_map.get(name, name)] = to_float(
value)
...

or cut out the middle man if you like:

...
for line in fd:
data = line.split("=")
if len(data) != 2:
continue
new_record_data[self.label_map.get(data[0], data[0])] = 
to_float(data[1])
...

Gary

On Tuesday, 7 May 2019 17:05:27 UTC+10, Colin Larsen wrote:
>
> And this is the code the writes the txt file - capturing a string via UDP
>
> *#!/usr/bin/env python*
>
> *import* socket
>
> *from* shutil *import* copyfile
>
>
> UDP_IP = *"0.0.0.0"*
>
> UDP_PORT = 9886
>
> fname = *"/home/pi/AQIData.txt"*
>
>
> sock = socket.socket(socket.AF_INET,* # Internet*
>
>  socket.SOCK_DGRAM)* # UDP*
>
> sock.bind((UDP_IP, UDP_PORT))
>
>
>
> *while* True:
>
>
> data, addr = sock.recvfrom(1024)* # buffer size is 1024 bytes*
>
> *print* *"Received message:"*, data
>
> dataSplit = data.split(*','*)
>
> f = open(fname,*'w'*)
>
> *for* ds *in* dataSplit:
>
> f.write(ds + *"\r"*)
>
> f.write(*'\n'*)
>
> f.close()
>
> On Tue, May 7, 2019 at 7:01 PM Colin Larsen  > wrote:
>
>> Apparently #015 is a numeric representation of \r or 'return' to we can 
>> rule that out?
>>
>> On Tue, May 7, 2019 at 6:56 PM Colin Larsen > > wrote:
>>
>>> Well this is a little strange. This went fine for a while then stopped 
>>> again with pretty much the same error. It appears to be missing the 
>>> beginning of the first line in the file which is AQI25 = then gets the 
>>> reading which is 4.55
>>>
>>> invalid literal for float(): 4.55#015AQI100 = 9.09#015AQIIndex = 
>>> 18#015AQICO2 = 863
>>>
>>> Is the #015 a clue of any sorts?
>>>
>>> The file looks ok
>>>
>>> AQI25 = 4.55
>>>
>>> AQI100 = 9.09
>>>
>>> AQIIndex = 18
>>>
>>> AQICO2 = 863
>>>
>>>
>>> Error;
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: engine: Main loop exiting. 
>>> Shutting engine down.
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: engine: Caught unrecoverable 
>>> exception in engine:
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   invalid literal for 
>>> float(): 4.55#015AQI100 = 9.09#015AQIIndex = 18#015AQICO2 = 863
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   Traceback (most 
>>> recent call last):
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 890, in main
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   engine.run()
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 202, in run
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   
>>> self.dispatchEvent(weewx.Event(weewx.POST_LOOP))
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   callback(event)
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 574, in post_loop
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   
>>> self._software_catchup()
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 646, in _software_catchup
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   
>>> self.engine.dispatchEvent(weewx.Event(weewx.NEW_ARCHIVE_RECORD, 
>>> record=record, origin='software'))
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: File 
>>> "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   callback(event)
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: File 
>>> "/usr/share/weewx/user/filepile.py", line 91, in new_archive_record
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   
>>> new_record_data[self.label_map.get(name, 
>>> name)] = to_float(value)
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]: File 
>>> "/usr/share/weewx/weeutil/weeutil.py", line 1280, in to_float
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   return float(x) 
>>> if x is not None else None
>>>
>>> May  7 18:50:16 raspberrypi weewx[11960]:   ValueError: invalid 
>>> literal for float(): 4.55#015AQI100 = 9.09#015AQIIndex 

Re: [weewx-user] Re: not posting to cwop or wunderground

[Mark Hahn]

Thanks.  Clearing the station memory fixed the problem.

On Mon, May 6, 2019 at 11:52 PM gjr80  wrote:

> Hi,
>
> Chances are you have corrupt station memory, not unusual with a Davis
> station is there has been a power (or some other sort of) interruption. Try
> the steps under Corrupt station memory
>  in the User's
> Guide . Note the comment at the end
> of that section about dumping the loggers memory before you clear the
> loggers memory (if you get to that stage), this helps minimise any data
> loss.
>
> You might also want to adjust the archive_interval setting under
> [StdArchive] in weewx.conf to match the 60 seconds setting you have in
> your console, or if you in fact want a 5 minute archive interval as you
> have in weewx.conf, then change the interval setting in the console to
> match. That will prevent these messages:
>
> May  6 22:18:05 server weewx[8603]: engine: The archive interval in the
> configuration file (300) does not match the station hardware interval (60
> ).
>
> These messages are harmless, WeeWX will default to the console setting if
> there is a conflict, but it cuts down on some unnecessary output.
>
> Gary
>
>
> On Tuesday, 7 May 2019 15:34:18 UTC+10, Mark Hahn wrote:
>>
>> I've been using weewx for years and it was working a few days ago until
>> my server died and I installed a brand-new pc.  I installed weewx using
>> apt-get with instructions from http://weewx.com/docs/apt-get.htm.  I had
>> a backup of weewx.conf and overwrote the installed on with the backup.
>> Weewx is now talking to my davis vantage ok, but nothing is being posted to
>> the web.  I've enclosed a copy of syslog taken from starting the service
>> on.  I've also included my conf file.
>>
>> Any help would be appreciated ...
>>
>>
>> --
> 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/qKXoGU585L8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/e245cfa7-29c1-44bd-b95d-ef501fc5db9b%40googlegroups.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/CACrj35FP%2B_jKrffVGphi%2BvWBQVX3_NP5kbYW%3D0ydp-vem3g6%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Weewx crashing with error associated with ScalarStats.addHiLo

[gjr80]

OK, as far as I can tell cmon 0.16 is doing what it should and it should 
work fine with a RPi/Stretch. Clearly though something is not working 
correctly. Cmon is mildly complex with not a lot of debug output so in the 
absence of Matthew's input could you try making a change to the cmon code. 
First up make a copy of cmon.py just in case:

$ sudo usr/share/weewx/user/cmon.py usr/share/weewx/user/cmon_orig.py

Then edit usr/share/weewx/user/cmon.py and around line 711 change:

def save_data(self, record):
"""save data to database"""
self.dbm.addRecord(record)

to:

def save_data(self, record):
"""save data to database"""
loginf("cmon archive record=%s" % (record,))
self.dbm.addRecord(record)

Save cmon.py and restart WeeWX. Cmon will now log the archive record it is 
about to save. Next time cmon causes a crash post the log and we should be 
able to marry up the value in the stack trace with a field in the cmon 
archive record.

Gary

On Tuesday, 7 May 2019 16:50:13 UTC+10, Redanman wrote:
>
> My system configuration is :
>
> Weewx version 3.9.1 running on a Raspberry Pi Zero
> Aercus Weathersleuth weather station with Weewx using Interceptor driver 
> over local network
> PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
> NAME="Raspbian GNU/Linux"
> VERSION_ID="9"
> VERSION="9 (stretch)"
> ID=raspbian
> ID_LIKE=debian
> Kernel = 4.14.62+ #1134 Tue Aug 14 16:58:07 BST 2018 armv6l GNU/Linux
> cmon version = 0.16
>
> Hope that helps.
> Mike
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/878be265-1d20-4959-b499-c590b769ed52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.