[weewx-user] Re: FineOffset Hang ups

[Andrew Milner]

Just a thought - as you say it has sat there for 5 years with never a 
screwdriver near it - have you tried something as simple as cleaning the 
usb connectors - plugs and sockets - with switch cleaner - or even using a 
different lead - in case there is any grime accumulation before resorting 
to the screwdriver.


On Thursday, 14 December 2017 09:27:48 UTC+2, Redanman wrote:

> I'll have a look inside the console, I must admit that I have a habit of 
> taking things to bits to see what's inside, but the weather station has sat 
> there for 5 years and I've never taken a screwdriver to it.
>
> On Monday, 11 December 2017 22:54:03 UTC, Redanman wrote:
>>
>> My old WH1080 is getting more more and more USB hang-ups.  I have to 
>> reset the unit (remove the USB cable) to reboot the it.  I obviously lose 
>> the data in the circular buffer, so, depending on when I notice the 
>> hang-up, it leads to data loss of several hours or even days.
>> I power the WH1080 through the USB cable connected to my Pi, but I do not 
>> have a USB hub, so cannot cycle the power through the hub.  I have noticed 
>> that if I reboot the Pi it cycles the power on the Pi's own USB ports, so 
>> resetting the WH1080.  Is it possible to do this automatically within Weewx 
>> if it detects a USB hang-up?
>> 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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: FineOffset Hang ups

[Redanman]

I'll have a look inside the console, I must admit that I have a habit of 
taking things to bits to see what's inside, but the weather station has sat 
there for 5 years and I've never taken a screwdriver to it.

On Monday, 11 December 2017 22:54:03 UTC, Redanman wrote:
>
> My old WH1080 is getting more more and more USB hang-ups.  I have to reset 
> the unit (remove the USB cable) to reboot the it.  I obviously lose the 
> data in the circular buffer, so, depending on when I notice the hang-up, it 
> leads to data loss of several hours or even days.
> I power the WH1080 through the USB cable connected to my Pi, but I do not 
> have a USB hub, so cannot cycle the power through the hub.  I have noticed 
> that if I reboot the Pi it cycles the power on the Pi's own USB ports, so 
> resetting the WH1080.  Is it possible to do this automatically within Weewx 
> if it detects a USB hang-up?
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Not reporting Wind Gusts

[Andrew Milner]

I would guess it will be WU ignoring archive data if rapid fire is enabled 
- after all, as Tom said, they do say use one or the other and not both!!


On Thursday, 14 December 2017 07:03:58 UTC+2, Francisco Puig wrote:

> Hi Tom, 
>
> Thanks for the suggestion, I tried it but apparently when rapid-fire 
> option is selected the archive_post doesn't work or maybe WU don't take 
> into consideration the non rapid-fire data if rapid-fire report is enabled.
>
>
> On Wednesday, December 13, 2017 at 5:50:15 PM UTC-5, Tom Keffer wrote:
>>
>> ​As is often the case, this is caused by bugs in the WU servers, so there 
>> is not much we can do about it.
>>
>> But, one thing you could try is to post BOTH Rapidfire, and the regular 
>> archive records. This is done by setting *both* option rapidfire and 
>> archive_post to true:
>>
>> [StdRestful]
>> [[Wunderground]]
>> enable = true
>> station = 
>> password = XXX
>> rapidfire = true
>> archive_post = true
>>
>> See the User's Guide section on the WU 
>> .
>>
>> The Weather Underground recommends against doing this, but it's worth a 
>> try.
>>
>> -tk​
>>
>> On Tue, Dec 12, 2017 at 9:19 PM, Francisco Puig  wrote:
>>
>>> Ok, finally I had time and disabled "rapidfire" and the wind gust 
>>> started reporting fine on WU. So the question is, is there a way that I can 
>>> get the gusts reporting with rapifire ON or, could be possible to decrease 
>>> the reporting interval of the script with the rapidfire in OFF?
>>>
>>> Thanks for the help...
>>>
>>> On Sunday, November 26, 2017 at 1:14:25 AM UTC-5, gjr80 wrote:

 It may well have worked before but it is not now. Other services such 
 as CWOP, WOW etc are updated every archive period using data from the 
 archive record covering that archive period. Many stations report 
 windSpeed 
 in loop packets but windGust is not calculated/reported (by weeWX or the 
 station) until the end of the archive period when windGust is calculated 
 as 
 the highest loop packet windSpeed value seen during the archive period. 
 Rapidfire uses loop packets, so if there is no windGust field included in 
 the loop packet then no windGust data will be posted. Because windGust is 
 included in the archive record posting to CWOP etc includes the windGust 
 data.

 You can see what is in each loop packet along with what is being posted 
 to WU when using rapidfire by turning on rapidfire and setting debug=3. 
 There will be an entry in the log just before each rapidfire post that 
 lists the contents of the loop packet.

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

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Not reporting Wind Gusts

[Francisco Puig]

Hi Tom, 

Thanks for the suggestion, I tried it but apparently when rapid-fire option 
is selected the archive_post doesn't work or maybe WU don't take into 
consideration the non rapid-fire data if rapid-fire report is enabled.


On Wednesday, December 13, 2017 at 5:50:15 PM UTC-5, Tom Keffer wrote:
>
> ​As is often the case, this is caused by bugs in the WU servers, so there 
> is not much we can do about it.
>
> But, one thing you could try is to post BOTH Rapidfire, and the regular 
> archive records. This is done by setting *both* option rapidfire and 
> archive_post to true:
>
> [StdRestful]
> [[Wunderground]]
> enable = true
> station = 
> password = XXX
> rapidfire = true
> archive_post = true
>
> See the User's Guide section on the WU 
> .
>
> The Weather Underground recommends against doing this, but it's worth a 
> try.
>
> -tk​
>
> On Tue, Dec 12, 2017 at 9:19 PM, Francisco Puig  > wrote:
>
>> Ok, finally I had time and disabled "rapidfire" and the wind gust started 
>> reporting fine on WU. So the question is, is there a way that I can get the 
>> gusts reporting with rapifire ON or, could be possible to decrease the 
>> reporting interval of the script with the rapidfire in OFF?
>>
>> Thanks for the help...
>>
>> On Sunday, November 26, 2017 at 1:14:25 AM UTC-5, gjr80 wrote:
>>>
>>> It may well have worked before but it is not now. Other services such as 
>>> CWOP, WOW etc are updated every archive period using data from the archive 
>>> record covering that archive period. Many stations report windSpeed in loop 
>>> packets but windGust is not calculated/reported (by weeWX or the station) 
>>> until the end of the archive period when windGust is calculated as the 
>>> highest loop packet windSpeed value seen during the archive period. 
>>> Rapidfire uses loop packets, so if there is no windGust field included in 
>>> the loop packet then no windGust data will be posted. Because windGust is 
>>> included in the archive record posting to CWOP etc includes the windGust 
>>> data.
>>>
>>> You can see what is in each loop packet along with what is being posted 
>>> to WU when using rapidfire by turning on rapidfire and setting debug=3. 
>>> There will be an entry in the log just before each rapidfire post that 
>>> lists the contents of the loop packet.
>>>
>>> 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+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: TFA Weatherhub vs KlimaLogg Pro

[mwall]

hi andy,

welcome to weewx!

TFA uses the same hardware as many other vendors.  For example:

TFA matrix = lacrosse ws23xx

TFA primus = lacrosse ws28xx

TFA nexus = hideki te923

the klimalogg and klimalogg pro use the same sensors, but i think the 
klimalog pro has a computer interface whereas the klimalogg does not.  the 
klimalogg pro console communicates with a computer via a usb RF receiver.

the klimalogg pro transceiver uses almost the same protocol as the 
transceiver for the lacross ws28xx weather stations.

the TFA weatherhub looks a lot like the lacross gw1000u, and the sensors 
that go with it look identical to the lacrosse sensors.  i see "mobile 
alerts" on the TFA gateway device:

http://wettershop.de/31-4003-02-weatherhub-mit-regenmesser-fuer-smartphones-ios-oder-android-starter-set-3.html

lacrosse has a "mobile alerts" service too:

http://www.lacrossealertsmobile.com/

so to answer your question: if the tfa weatherhub is the same as the 
lacrosse gw1000u, and if they use the same protocol, then you can use the 
weewx-interceptor driver to capture data from it.

m

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: new acurite bridge hardware

[Andrew Milner]

Just put the sensor in a Stephenson screen or similar enclosure to get it 
to be in the shade, as all temperature sensors should be anyway!!

On Thursday, 14 December 2017 01:09:42 UTC+2, vince wrote:
>
> On Wednesday, December 13, 2017 at 2:52:16 PM UTC-8, mwall wrote:
>>
>> details like these are why i am encouraged by the weatherflow hardware - 
>> it does local tcp/ip broadcasts of the sensor data (in json format!).  so 
>> it is trivial to capture the data.
>>
>>
> This weatherflow hardware that's still in prototype stage ?
> http://weatherflow.com/smart-home-weather-stations/
>
> Like the haptic rain gauge (maybe) and the ultrasonic wind sensor, but I 
> think the birds will love to perch on'em more.  A little disappointed in 
> the "put in the shade" temperature sensor.  I literally have no such place 
> on the property that doesn't get direct sun for at least part of the day. 
>  But it does look pretty cool as a half-the-VantageVue-price thing.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] TFA Weatherhub vs KlimaLogg Pro

['Andy Smith' via weewx-user]

Hi,

Just dipping my toe in the water with weather station products and weeWX.  
Here in UK, the TFA range of products seem to be readily available and 
include a range based around the Weatherhub which is marketed with an LCD 
console under the brand 'Klimalogg' it seems.  This LCD console does not 
seem to match the image shown in the hardware list for Klimlogg pro and the 
readme for that driver certainly talks about a USB interface whereas the 
Weatherhub is an ethernet connected device.  So, the question is, does 
weeWX support the Weatherhub under some other driver?  I see in the 
Hardware Guide in the Wiki that all the drivers except one are either USB 
or Serial.
Thanks
-- 
Andy

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: new acurite bridge hardware

[vince]

On Wednesday, December 13, 2017 at 2:52:16 PM UTC-8, mwall wrote:
>
> details like these are why i am encouraged by the weatherflow hardware - 
> it does local tcp/ip broadcasts of the sensor data (in json format!).  so 
> it is trivial to capture the data.
>
>
This weatherflow hardware that's still in prototype stage ?
http://weatherflow.com/smart-home-weather-stations/

Like the haptic rain gauge (maybe) and the ultrasonic wind sensor, but I 
think the birds will love to perch on'em more.  A little disappointed in 
the "put in the shade" temperature sensor.  I literally have no such place 
on the property that doesn't get direct sun for at least part of the day. 
 But it does look pretty cool as a half-the-VantageVue-price thing.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: new acurite bridge hardware

[mwall]

although it is encouraging to see some new products at the low end of 
weather station hardware, a few words of warning:

- apparently the new bridge establishes an encrypted connection with the 
acurite servers, so unless acurite provides decryption keys or someone is 
able to crack it, you will not be able to decode data from the bridge that 
is bound for the acurite servers

- wu uploads are currently not encrypted, so until wu starts encrypting 
connections, it should be possible to sniff data from the bridge that are 
bound for the wu servers

- the wu protocol does not support an unlimited number of sensors, so it 
might not be possible to obtain all of the bridge data by capturing just 
the wu traffic

netatmo did this encryption nonsense in an unsolicited firmware update some 
time ago.  by doing so they made it so that even though you bought the 
hardware, you do not really own it - it is useless without the netatmo 
servers.

details like these are why i am encouraged by the weatherflow hardware - it 
does local tcp/ip broadcasts of the sensor data (in json format!).  so it 
is trivial to capture the data.

m

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Not reporting Wind Gusts

[Thomas Keffer]

​As is often the case, this is caused by bugs in the WU servers, so there
is not much we can do about it.

But, one thing you could try is to post BOTH Rapidfire, and the regular
archive records. This is done by setting *both* option rapidfire and
archive_post to true:

[StdRestful]
[[Wunderground]]
enable = true
station = 
password = XXX
rapidfire = true
archive_post = true

See the User's Guide section on the WU
.

The Weather Underground recommends against doing this, but it's worth a try.

-tk​

On Tue, Dec 12, 2017 at 9:19 PM, Francisco Puig  wrote:

> Ok, finally I had time and disabled "rapidfire" and the wind gust started
> reporting fine on WU. So the question is, is there a way that I can get the
> gusts reporting with rapifire ON or, could be possible to decrease the
> reporting interval of the script with the rapidfire in OFF?
>
> Thanks for the help...
>
> On Sunday, November 26, 2017 at 1:14:25 AM UTC-5, gjr80 wrote:
>>
>> It may well have worked before but it is not now. Other services such as
>> CWOP, WOW etc are updated every archive period using data from the archive
>> record covering that archive period. Many stations report windSpeed in loop
>> packets but windGust is not calculated/reported (by weeWX or the station)
>> until the end of the archive period when windGust is calculated as the
>> highest loop packet windSpeed value seen during the archive period.
>> Rapidfire uses loop packets, so if there is no windGust field included in
>> the loop packet then no windGust data will be posted. Because windGust is
>> included in the archive record posting to CWOP etc includes the windGust
>> data.
>>
>> You can see what is in each loop packet along with what is being posted
>> to WU when using rapidfire by turning on rapidfire and setting debug=3.
>> There will be an entry in the log just before each rapidfire post that
>> lists the contents of the loop packet.
>>
>> Gary
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: weewx-owfs failure with new Raspbian Stretch

[Glenn McKechnie]

Howard, Miguel

Okay. The details of the pi I ran the working test on are...

PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"

Linux weewx-public 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l
GNU/Linux
owfs-common  2.9p8-6   all
python-ow2.9p8-6   armhf
weewx  3.7.1-1all
owfs  0.21

I've since done a fresh install of Raspian lite on another pi

Raspbian Stretch Lite

Minimal image based on Debian Stretch
Version: November 2017
Release date: 2017-11-29
Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l
GNU/Linux

PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"

with the packages defaulting to

libow-3.1-5_3.1p5-1_armhf.deb
owfs-common_3.1p5-1_all.deb
python-ow_3.1p5-1_armhf.deb

weewx   3.8.0-1
owfs 0.21

If I then run...
root@raspberrypi:~/owpkg9# PYTHONPATH=/usr/share/weewx python
/usr/share/weewx/user/owfs.py --sensors
Traceback (most recent call last):
  File "/usr/share/weewx/user/owfs.py", line 618, in 
main()
  File "/usr/share/weewx/user/owfs.py", line 578, in main
ow.init(iface)
  File "/usr/lib/python2.7/dist-packages/ow/__init__.py", line 224, in init
raise exNoController
ow.exNoController

with syslog stating that...
Dec 13 22:04:35 raspberrypi OWFS[2440]: DEFAULT: owlib.c:(208) Cannot open
USB bus master
Dec 13 22:04:35 raspberrypi OWFS[2440]: DEFAULT: owlib.c:(52) No valid
1-wire buses found

So I'm getting the same result as you.

If then do the following...
 apt-get remove libow-3.1-5 python-ow owfs-common

and copy the equivalent packages (in /var/cache/apt/archives/) from the
Debian 8 install on the that working machine ...

libow-2.9-8_2.9p8-6_armhf.deb
owfs-common_2.9p8-6_all.deb
python-ow_2.9p8-6_armhf.deb

Cross the fingers and hope that the nothing breaks with such an ugly
manoeuvre.

dpkg --install owfs-common_2.9p8-6_all.deb
dpkg --install libow-2.9-8_2.9p8-6_armhf.deb
dpkg --install python-ow_2.9p8-6_armhf.deb

and run the same command as before, I get a result!
root@raspberrypi:~/owpkg8# PYTHONPATH=/usr/share/weewx python
/usr/share/weewx/user/owfs.py --sensors
B2352D00: /81.B2352D00 DS1420

If I connect my 1-wire network into the dongle, I get...
root@raspberrypi:~#  PYTHONPATH=/usr/share/weewx python
/usr/share/weewx/user/owfs.py --iface u --sensors
B2352D00: /81.B2352D00 DS1420
E953E700: /1F.4C690500/main/26.E953E700 DS2438
0B930C00: /1F.4C690500/main/1D.0B930C00 DS2423
67110D00: /1F.4C690500/main/1D.67110D00 DS2423
DE9813020800: /1F.4C690500/aux/10.DE9813020800 DS18S20
B0F7F100: /1F.4C690500/aux/26.B0F7F100 DS2438
816E0F00: /1F.CC670500/main/1D.816E0F00 DS2423
7FCF0F00: /1F.CC670500/main/1D.7FCF0F00 DS2423
7EA2ED010800: /1F.45580500/main/10.7EA2ED010800 DS18S20
EC46E700: /1F.45580500/main/26.EC46E700 DS2438
AB79BC00: /1F.45580500/aux/26.AB79BC00 DS2438


So, besides the ugly kludge, which was really just to try and zero in on
the issue. It does appear to be a problem with those latest versions, and
surprisingly, the older ones will drop in and work.

I'm not suggesting that replacing them with the 2.9p8-6 versions is a fix,
but if you want to test it for yourself the files are here...

http://203.213.243.61/weewx/owpkg/owpkg.tar.gz




Miguel,

I think I now know why you were getting a result via localhost:4304.  The
owfs.conf has an entry

# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
server: FAKE = DS18S20,DS2405

and you were picking that up.

Also your manual build of owfs earlier in this thread is broken.
If you check the .config output you'll see that owpython is DISABLED, it
has an umet dependency of the swig package.


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] new acurite bridge hardware

[mwall]

folks,

acurite has finally announced their new bridge hardware:

https://www.acurite.com/access-invitation

it is supposed to ship january 2018.  it is supposed to be compatible with 
existing sensors, as well as their new sensors (i suspect that means the 
lightning detector and whatever new sensors are coming with the atlas 
series of hardware).

m

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Acurite (ugh), and weewx ona RasbPi.

[John R Pierce]

On 12/13/2017 9:03 AM, Andy wrote:
I switched to the USB SDR receiver so no longer using the USB console 
connection. This driver 
<%20%20https://github.com/matthewwall/weewx-sdr> and a $10 receiver 
from aliexpress like this 
.  
You lose pressure and inside temperature since you are only connecting 
to the outside unit, but there are ways to solve that issue



does the inside panel still work?  I guess it would as its radio 
recieve/only, eh?



--
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx and aercus weatherRanger problem with updating

[F Mitchell]

The error message:

Sep 11 08:32:46 webserver weewx[26283]: HP1000: Timed out too many times


indicates that your weather station probably is not connected to the network. 
Reset your weather station and make sure that it is connected to your network 
and it should connect and solve the problem.


I just had the problem last night when I updated my router software and it 
knocked my wx station off of the network. Once I reconnected, weewx connected 
and is operating properly.


Mitch W4OA



On Monday, September 11, 2017 at 2:01:18 AM UTC-5, Damjan Hajsek wrote:
>
> I checked log and it is full of this
>
> weewx[26283]: HP1000: Timed out too many times
>
>
> Sep 11 08:28:10 webserver weewx[26279]: engine: Initializing weewx version 
> 3.7.1
> Sep 11 08:28:10 webserver weewx[26279]: engine: Using Python 2.7.5 (default, 
> Nov  6 2016, 00:28:07) #012[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)]
> Sep 11 08:28:11 webserver weewx[26279]: engine: Platform 
> Linux-3.10.0-514.26.1.el7.x86_64-x86_64-with-centos-7.3.1611-Core
> Sep 11 08:28:11 webserver weewx[26279]: engine: Locale is 'sl_SI.UTF-8'
> Sep 11 08:28:11 webserver weewx[26279]: engine: pid file is /var/run/weewx.pid
> Sep 11 08:28:11 webserver weewx[26283]: engine: Using configuration file 
> /etc/weewx/weewx.conf
> Sep 11 08:28:11 webserver weewx: Starting weewx: [  V redu  ]
> Sep 11 08:28:11 webserver weewx[26283]: engine: Loading station type HP1000 
> (user.HP1000)
> Sep 11 08:28:11 webserver weewx[26283]: HP1000: HP1000 Starting
> Sep 11 08:28:11 webserver systemd: Started SYSV: start and stop the weewx 
> weather system.
> Sep 11 08:28:11 webserver weewx[26283]: HP1000: Using "netifaces" to 
> determine broadcast mask
> Sep 11 08:28:11 webserver weewx[26283]: HP1000: Address Mask = XXX.XXX.255.255
> Sep 11 08:28:11 webserver weewx[26283]: HP1000: Retry count = 5.00
> Sep 11 08:28:11 webserver weewx[26283]: HP1000: Socket timeout = 5.00
> Sep 11 08:28:11 webserver weewx[26283]: HP1000: Loop delay = 15.00
> Sep 11 08:28:11 webserver weewx[26283]: HP1000: Retry Wait = 5.00
> Sep 11 08:28:11 webserver weewx[26283]: HP1000: Max Retry = 3.00
> Sep 11 08:28:11 webserver weewx[26283]: engine: StdConvert target unit is 0x1
> Sep 11 08:28:11 webserver weewx[26283]: wxcalculate: The following values 
> will be calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
> dewpoint=prefer_hardware, appTemp=prefer_hardware, rainRate=prefer_hardware, 
> windrun=prefer_hardware, heatindex=prefer_hardware, 
> maxSolarRad=prefer_hardware, humidex=prefer_hardware, 
> pressure=prefer_hardware, inDewpoint=prefer_hardware, ET=prefer_hardware, 
> altimeter=prefer_hardware, cloudbase=prefer_hardware
> Sep 11 08:28:11 webserver weewx[26283]: wxcalculate: The following algorithms 
> will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
> Sep 11 08:28:11 webserver weewx[26283]: engine: Archive will use data binding 
> wx_binding
> Sep 11 08:28:11 webserver weewx[26283]: engine: Record generation will be 
> attempted in 'software'
> Sep 11 08:28:11 webserver weewx[26283]: engine: Using archive interval of 300 
> seconds (specified in weewx configuration)
> Sep 11 08:28:11 webserver weewx[26283]: engine: Using binding 'wx_binding' to 
> database 'weewx.sdb'
> Sep 11 08:28:11 webserver weewx[26283]: manager: Starting backfill of daily 
> summaries
> Sep 11 08:28:11 webserver weewx[26283]: restx: StationRegistry: Registration 
> not requested.
> Sep 11 08:28:11 webserver weewx[26283]: restx: Wunderground: Posting not 
> enabled.
> Sep 11 08:28:11 webserver weewx[26283]: restx: PWSweather: Posting not 
> enabled.
> Sep 11 08:28:11 webserver weewx[26283]: restx: CWOP: Posting not enabled.
> Sep 11 08:28:11 webserver weewx[26283]: restx: WOW: Posting not enabled.
> Sep 11 08:28:11 webserver weewx[26283]: restx: AWEKAS: Posting not enabled.
> Sep 11 08:28:11 webserver weewx[26283]: engine: Starting up weewx version 
> 3.7.1
> Sep 11 08:28:36 webserver weewx[26283]: HP1000: Timed out too many times
> Sep 11 08:29:01 webserver weewx[26283]: HP1000: Timed out too many times
> Sep 11 08:29:26 webserver weewx[26283]: HP1000: Timed out too many times
> Sep 11 08:29:51 webserver weewx[26283]: HP1000: Timed out too many times
> Sep 11 08:32:21 webserver weewx[26283]: HP1000: Timed out too many times
> Sep 11 08:32:46 webserver weewx[26283]: HP1000: Timed out too many times
>
>
>
> Dne nedelja, 10. september 2017 23.44.27 UTC+2 je oseba mwall napisala:
>>
>> http://weewx.com/docs/usersguide.htm#monitoring
>>
>> m
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Acurite (ugh), and weewx ona RasbPi.

[Andy]

I switched to the USB SDR receiver so no longer using the USB console 
connection. This driver  and a 
$10 receiver from aliexpress like this 
.
  
You lose pressure and inside temperature since you are only connecting to 
the outside unit, but there are ways to solve that issue

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Acurite (ugh), and weewx ona RasbPi.

[Andy]

Move the console around to get better signal.  Looks like poor signal.  You may 
just need to move the console a few feet in one direction or another.

Andy

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: logrotate

[Andrew Milner]

looks as though centos once had a problem 
https://www.centos.org/forums/viewtopic.php?t=32715

guess the stop and start may not be necessary nowadays - but they should 
not cause any harm either



On Wednesday, 13 December 2017 16:58:01 UTC+2, Daniel Jönsson wrote:

> Sorry, I meant syslog, as I also wrote in the first post.
>
>
> Den onsdag 13 december 2017 kl. 15:36:53 UTC+1 skrev Andrew Milner:
>>
>> My logrotate stops and starts syslog at postrotate, it does not restart 
>> logrotate.
>>
>> /var/log/weewx.log {
>>   weekly
>>   missingok
>>   rotate 52
>>   compress
>>   delaycompress
>>   notifempty
>> # debian uses root:adm
>> #  create 644 root adm
>> # ubuntu uses syslog:adm
>> #  create 644 syslog adm
>>   sharedscripts
>>   postrotate
>> # standard way of invoking rc scripts
>> /etc/init.d/rsyslog stop
>> /etc/init.d/rsyslog start
>>
>>
>> On Wednesday, 13 December 2017 15:56:42 UTC+2, Daniel Jönsson wrote:
>>
>>> I understand. I am only familiar with Debian/Ubuntu so I can not help 
>>> you with that.
>>> And to me it seemed strange. Some times you restart/reload the 
>>> service/demaon, but I have never seen that a logrotate is restarting 
>>> logrotate...
>>>
>>>
>>>
>>> Den onsdag 13 december 2017 kl. 12:42:38 UTC+1 skrev mwall:

 On Wednesday, December 13, 2017 at 4:36:01 AM UTC-5, Daniel Jönsson 
 wrote:
>
> In this logrotate example you are restarting rsyslog postrotate!! Why?
>

 restarting rsyslog is probably not necessary for the most recent 
 operating systems.

 i found that on some systems, logrotate did not manage open file 
 handles properly.  when logrotate rotated the weewx log file, (r)syslog 
 would continue to write to the log that had been rotated.

 do you know of a way to ensure proper logrotate behavior that works on 
 all operating systems and all operating system versions?

 m

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: logrotate

[Daniel Jönsson]

Sorry, I meant syslog, as I also wrote in the first post.


Den onsdag 13 december 2017 kl. 15:36:53 UTC+1 skrev Andrew Milner:
>
> My logrotate stops and starts syslog at postrotate, it does not restart 
> logrotate.
>
> /var/log/weewx.log {
>   weekly
>   missingok
>   rotate 52
>   compress
>   delaycompress
>   notifempty
> # debian uses root:adm
> #  create 644 root adm
> # ubuntu uses syslog:adm
> #  create 644 syslog adm
>   sharedscripts
>   postrotate
> # standard way of invoking rc scripts
> /etc/init.d/rsyslog stop
> /etc/init.d/rsyslog start
>
>
> On Wednesday, 13 December 2017 15:56:42 UTC+2, Daniel Jönsson wrote:
>
>> I understand. I am only familiar with Debian/Ubuntu so I can not help you 
>> with that.
>> And to me it seemed strange. Some times you restart/reload the 
>> service/demaon, but I have never seen that a logrotate is restarting 
>> logrotate...
>>
>>
>>
>> Den onsdag 13 december 2017 kl. 12:42:38 UTC+1 skrev mwall:
>>>
>>> On Wednesday, December 13, 2017 at 4:36:01 AM UTC-5, Daniel Jönsson 
>>> wrote:

 In this logrotate example you are restarting rsyslog postrotate!! Why?

>>>
>>> restarting rsyslog is probably not necessary for the most recent 
>>> operating systems.
>>>
>>> i found that on some systems, logrotate did not manage open file handles 
>>> properly.  when logrotate rotated the weewx log file, (r)syslog would 
>>> continue to write to the log that had been rotated.
>>>
>>> do you know of a way to ensure proper logrotate behavior that works on 
>>> all operating systems and all operating system versions?
>>>
>>> m
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: logrotate

[Andrew Milner]

My logrotate stops and starts syslog at postrotate, it does not restart 
logrotate.

/var/log/weewx.log {
  weekly
  missingok
  rotate 52
  compress
  delaycompress
  notifempty
# debian uses root:adm
#  create 644 root adm
# ubuntu uses syslog:adm
#  create 644 syslog adm
  sharedscripts
  postrotate
# standard way of invoking rc scripts
/etc/init.d/rsyslog stop
/etc/init.d/rsyslog start


On Wednesday, 13 December 2017 15:56:42 UTC+2, Daniel Jönsson wrote:

> I understand. I am only familiar with Debian/Ubuntu so I can not help you 
> with that.
> And to me it seemed strange. Some times you restart/reload the 
> service/demaon, but I have never seen that a logrotate is restarting 
> logrotate...
>
>
>
> Den onsdag 13 december 2017 kl. 12:42:38 UTC+1 skrev mwall:
>>
>> On Wednesday, December 13, 2017 at 4:36:01 AM UTC-5, Daniel Jönsson wrote:
>>>
>>> In this logrotate example you are restarting rsyslog postrotate!! Why?
>>>
>>
>> restarting rsyslog is probably not necessary for the most recent 
>> operating systems.
>>
>> i found that on some systems, logrotate did not manage open file handles 
>> properly.  when logrotate rotated the weewx log file, (r)syslog would 
>> continue to write to the log that had been rotated.
>>
>> do you know of a way to ensure proper logrotate behavior that works on 
>> all operating systems and all operating system versions?
>>
>> m
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: logrotate

[Daniel Jönsson]

I understand. I am only familiar with Debian/Ubuntu so I can not help you 
with that.
And to me it seemed strange. Some times you restart/reload the 
service/demaon, but I have never seen that a logrotate is restarting 
logrotate...



Den onsdag 13 december 2017 kl. 12:42:38 UTC+1 skrev mwall:
>
> On Wednesday, December 13, 2017 at 4:36:01 AM UTC-5, Daniel Jönsson wrote:
>>
>> In this logrotate example you are restarting rsyslog postrotate!! Why?
>>
>
> restarting rsyslog is probably not necessary for the most recent operating 
> systems.
>
> i found that on some systems, logrotate did not manage open file handles 
> properly.  when logrotate rotated the weewx log file, (r)syslog would 
> continue to write to the log that had been rotated.
>
> do you know of a way to ensure proper logrotate behavior that works on all 
> operating systems and all operating system versions?
>
> m
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: logrotate

[mwall]

On Wednesday, December 13, 2017 at 4:36:01 AM UTC-5, Daniel Jönsson wrote:
>
> In this logrotate example you are restarting rsyslog postrotate!! Why?
>

restarting rsyslog is probably not necessary for the most recent operating 
systems.

i found that on some systems, logrotate did not manage open file handles 
properly.  when logrotate rotated the weewx log file, (r)syslog would 
continue to write to the log that had been rotated.

do you know of a way to ensure proper logrotate behavior that works on all 
operating systems and all operating system versions?

m

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] logrotate

[Daniel Jönsson]

Hello!

Seen there is a Issue on Github about the excessive logging from weewx I 
have been discussing in another thread.
Until then I am filtering out all messages from rsyslog to a separate log 
file as suggested. 

But when adding a logrotate I noticed something strange 
in weewx/util/logrotate.d/weewx

In this logrotate example you are restarting rsyslog postrotate!! Why?

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.