[weewx-user] Re: WeeWX v3.8.2 released

[James Greiner]

Updated my 3.8.1 to 3.8.2 no issues... Thanks for the hard work!

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

Re: [weewx-user] Re: WeeWX v3.8.2 released

[G Hammer]

I've had a quick look and it seems there is only the merge or leave it 
alone option.

I'd say to put a warning in the upgrade guide.

On Thursday, August 16, 2018 at 4:55:41 PM UTC-4, Thomas Keffer wrote:
>
> Yes, it would be nicer. How about a Pull Request that addresses the 
> problem?
>
> -tk
>
> On Thu, Aug 16, 2018 at 1:53 PM G Hammer > 
> wrote:
>
>> It would be nicer if either this were corrected or if the upgrade guide 
>> had a warning in it.
>> As there were no program changes in weewx.conf, I just moved the 3.8.1 
>> version back in place and wiped the web of all files.
>> The scheduled ftp put the site back to the desired state/look.
>>
>>
>> On Thursday, August 16, 2018 at 4:40:15 PM UTC-4, Thomas Keffer wrote:
>>>
>>> Yes, this is a known bug. Issue #217 
>>> .
>>>
>>> -tk
>>>
>>> On Thu, Aug 16, 2018 at 1:35 PM G Hammer  wrote:
>>>

 Update changed my skin to default. Now looking for what else it may 
 have changed.
 setup.by install & upgrade method.

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

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

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

Re: [weewx-user] Recommened Hardware For Solid Driver Integration

[Greg Troxel]

Thomas Keffer  writes:

> Hard to beat the Davis Vantage series for reliability. They publish their
> API, so the driver is very mature.

I'll second that.  I have a VP2 with the solar radiation sensor, and
since getting the davis computer interface (serial), it has just worked
since about new year's with no trouble.

Reading the list, I see a bit of trouble with some kinds of hardware,
but with the Davis VP2, the only complaint is that its expensive.  That
means not a lot of trouble with talking to weewx, or with failing.

Also, the official Davis computer interface for the VP2, while costing
$110ish (in the US), which is sort of offensive since a console should
come with that these days, at least is capable of recording data every 5
mimutes all by itself, for a long time, and weewx will catch up when you
restart it, if your computer is down (power, crashed, upgrade).

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


signature.asc
Description: PGP signature

Re: [weewx-user] Me Again - Trying this again...

[vince]

On Thursday, August 16, 2018 at 3:40:43 PM UTC-7, Cycle London wrote:
>
> Couldn't run test.py as I don't know what's supposed to be in it, but 
> after running yum install libusb and trying to restart weewx... 
>
>
>
oh - I just put Tom's commands in a file so I could run it easier.. 

-- 
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: Recommened Hardware For Solid Driver Integration

[Pat]

Can't beat the Davis Vantage Pro 2 Plus  (which 
has the UV and Solar Radiation sensors). There's other sensors you can add 
to it like leaf wetness and soil sensors if you wanted. It outputs a 
weather packet every 2.5 seconds. 

If you don't want to do the DIY route to get the outdoor unit's packet data 
for cheap 
 like I 
did, then you'd need a Weather Link dongle of some sort. They have IP 
dongles  or if you prefer there's also the USB 
dongles  - both work with weewx. 

Using the data for a smart home all depends on how you want to use the 
data. Once it's in weewx, you can install the MQTT extension and hook it 
into almost every smart home software out there. Mine hooks into hass.io 
using MQTT. MQTT also runs my weather website, so every time weewx receives 
a new packet from the outdoor unit, it's instantly on the website (thanks 
to weewx). 


On Thursday, August 16, 2018 at 4:09:35 PM UTC-4, Ray Racine wrote:
>
> Looking for recommendation as to which hardware  (Weather Station) to get 
> with the following guidelines.  
>
> - Fairly recent released model.
> - Hobbiest friendly.  SOLID SIMPLE INTEGRATION to the data.  e.g.  Which 
> hardware is best for solid, reliable USB integration to the data?  i.e. 
> Which Vendor Hardware's Weewx (USB) driver is the most solid and reliable.
> - Home / Personal station for use with "Smart Home" DIY software - which 
> is why solid driver integration to directly get the station data is key.  
> No cloud, no internet, no scrapping, no DNS redirect tricks, I just want to 
> be able to query the hardware (via USB or otherwise) to directly get "my" 
> weather data from my weather station.  
> - Vendor is supportative, makes available the docs, allowing everyone to 
> put together and maintain a solid Weewx driver for directly reading the 
> data. 
>
> The above is the key criteria - which hardware supports the "best" 
> integration capability
>
> Above that would be good value for the price.  
> Solar powered station.  
> LUX light intensity besides all the usual weather stats.   
>
> I'd take a "better" hardware external weather station with regards to 
> reliability and accuracy over a fancy a TFT fancy color console. 
>
>
>
>
>
>

-- 
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] Me Again - Trying this again...

[Thomas Keffer]

The first results suggests that your WMR300 is not registering on the USB
bus. From a command line, try this

$ *lsusb*
Post the results.

-tk

On Thu, Aug 16, 2018 at 3:40 PM Cycle London 
wrote:

> Couldn't run test.py as I don't know what's supposed to be in it, but
> after running yum install libusb and trying to restart weewx...
>
> Aug 16 23:35:19 weather systemd: Stopping SYSV: start and stop the weewx
> weather system...
> Aug 16 23:35:21 weather weewx: Shutting down weewx: [FAILED]
> Aug 16 23:35:21 weather systemd: Starting SYSV: start and stop the weewx
> weather system...
> Aug 16 23:35:22 weather weewx[2129]: engine: Initializing weewx version
> 3.8.0
> Aug 16 23:35:22 weather weewx[2129]: engine: Using Python 2.7.5 (default,
> Jul 13 2018, 13:06:57) #012[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]
> Aug 16 23:35:22 weather weewx[2129]: engine: Platform
> Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core
> Aug 16 23:35:22 weather weewx[2129]: engine: Locale is 'en_GB.UTF-8'
> Aug 16 23:35:22 weather weewx[2129]: engine: pid file is /var/run/weewx.pid
> Aug 16 23:35:22 weather weewx: Starting weewx: [  OK  ]
> Aug 16 23:35:22 weather weewx[2133]: engine: Using configuration file
> /home/weewx/weewx.conf
> Aug 16 23:35:22 weather weewx[2133]: engine: Loading station type WMR300
> (weewx.drivers.wmr300)
> Aug 16 23:35:22 weather systemd: Started SYSV: start and stop the weewx
> weather system.
> Aug 16 23:35:22 weather weewx[2133]: wmr300: driver version is 0.18
> Aug 16 23:35:22 weather weewx[2133]: wmr300: usb info: pyusb_version=1.0.2
> Aug 16 23:35:22 weather weewx[2133]: wmr300: sensor map is {'outHumidity':
> 'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 'windchill',
> 'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 'heatindex':
> 'heatindex_1', 'inTemp': 'temperature_0', 'windGustDir': 'wind_gust_dir',
> 'extraDewpoint2': 'dewpoint_3', 'extraDewpoint3': 'dewpoint_4',
> 'extraDewpoint1': 'dewpoint_2', 'barometer': 'barometer', 'extraDewpoint7':
> 'dewpoint_8', 'dewpoint': 'dewpoint_1', 'extraDewpoint5': 'dewpoint_6',
> 'extraHumid6': 'humidity_7', 'pressure': 'pressure', 'extraHumid4':
> 'humidity_5', 'extraHumid5': 'humidity_6', 'extraHumid2': 'humidity_3',
> 'extraHumid3': 'humidity_4', 'extraHumid1': 'humidity_2', 'extraTemp6':
> 'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4':
> 'temperature_5', 'extraTemp5': 'temperature_6', 'extraTemp2':
> 'temperature_3', 'extraTemp3': 'temperature_4', 'extraTemp1':
> 'temperature_2', 'extraHeatindex3': 'heatindex_4', 'extraHeatindex2':
> 'heatindex_3', 'extraHeatindex1': 'heatindex_2', 'extraHeatindex7':
> 'heatindex_8', 'extraHeatindex6': 'heatindex_7', 'extraHeatindex5':
> 'heatindex_6', 'extraHumid7': 'humidity_8', 'extraHeatindex4':
> 'heatindex_5', 'windDir': 'wind_dir', 'outTemp': 'temperature_1',
> 'windSpeed': 'wind_avg', 'inHumidity': 'humidity_0', 'windGust':
> 'wind_gust'}
> Aug 16 23:35:25 weather kernel: usb 2-2.1: reset full-speed USB device
> number 4 using uhci_hcd
> Aug 16 23:35:25 weather weewx[2133]: engine: StdConvert target unit is 0x1
> Aug 16 23:35:25 weather weewx[2133]: wxcalculate: The following values
> will be calculated: barometer=prefer_hardware, windchill=hardware,
> dewpoint=hardware, appTemp=prefer_hardware, rainRate=hardware,
> windrun=prefer_hardware, heatindex=hardware, maxSolarRad=prefer_hardware,
> humidex=prefer_hardware, pressure=prefer_hardware,
> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware,
> cloudbase=prefer_hardware
> Aug 16 23:35:25 weather weewx[2133]: wxcalculate: The following algorithms
> will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
> Aug 16 23:35:25 weather weewx[2133]: engine: Archive will use data binding
> wx_binding
> Aug 16 23:35:25 weather weewx[2133]: engine: Record generation will be
> attempted in 'hardware'
> Aug 16 23:35:25 weather weewx[2133]: engine: Using archive interval of 300
> seconds (specified in weewx configuration)
> Aug 16 23:35:25 weather weewx[2133]: manager: Created and initialized
> table 'archive' in database 'weewx.sdb'
> Aug 16 23:35:26 weather weewx[2133]: manager: Created daily summary tables
> Aug 16 23:35:26 weather weewx[2133]: engine: Using binding 'wx_binding' to
> database 'weewx.sdb'
> Aug 16 23:35:26 weather weewx[2133]: manager: Starting backfill of daily
> summaries
> Aug 16 23:35:26 weather weewx[2133]: restx: StationRegistry: Registration
> not requested.
> Aug 16 23:35:26 weather weewx[2133]: restx: Wunderground: Posting not
> enabled.
> Aug 16 23:35:26 weather weewx[2133]: restx: PWSweather: Posting not
> enabled.
> Aug 16 23:35:26 weather weewx[2133]: restx: CWOP: Posting not enabled.
> Aug 16 23:35:26 weather weewx[2133]: restx: WOW: Posting not enabled.
> Aug 16 23:35:26 weather weewx[2133]: restx: AWEKAS: Posting not enabled.
> Aug 16 23:35:26 weather weewx[2133]: engine: Starting up weewx version
> 3.8.0
> Aug 16 23:35:26 weather weewx[2133]: wmr300: 

Re: [weewx-user] Me Again - Trying this again...

[Cycle London]

Couldn't run test.py as I don't know what's supposed to be in it, but after 
running yum install libusb and trying to restart weewx... 

Aug 16 23:35:19 weather systemd: Stopping SYSV: start and stop the weewx 
weather system...
Aug 16 23:35:21 weather weewx: Shutting down weewx: [FAILED]
Aug 16 23:35:21 weather systemd: Starting SYSV: start and stop the weewx 
weather system...
Aug 16 23:35:22 weather weewx[2129]: engine: Initializing weewx version 
3.8.0
Aug 16 23:35:22 weather weewx[2129]: engine: Using Python 2.7.5 (default, 
Jul 13 2018, 13:06:57) #012[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]
Aug 16 23:35:22 weather weewx[2129]: engine: Platform 
Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core
Aug 16 23:35:22 weather weewx[2129]: engine: Locale is 'en_GB.UTF-8'
Aug 16 23:35:22 weather weewx[2129]: engine: pid file is /var/run/weewx.pid
Aug 16 23:35:22 weather weewx: Starting weewx: [  OK  ]
Aug 16 23:35:22 weather weewx[2133]: engine: Using configuration file 
/home/weewx/weewx.conf
Aug 16 23:35:22 weather weewx[2133]: engine: Loading station type WMR300 
(weewx.drivers.wmr300)
Aug 16 23:35:22 weather systemd: Started SYSV: start and stop the weewx 
weather system.
Aug 16 23:35:22 weather weewx[2133]: wmr300: driver version is 0.18
Aug 16 23:35:22 weather weewx[2133]: wmr300: usb info: pyusb_version=1.0.2
Aug 16 23:35:22 weather weewx[2133]: wmr300: sensor map is {'outHumidity': 
'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 'windchill', 
'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 'heatindex': 
'heatindex_1', 'inTemp': 'temperature_0', 'windGustDir': 'wind_gust_dir', 
'extraDewpoint2': 'dewpoint_3', 'extraDewpoint3': 'dewpoint_4', 
'extraDewpoint1': 'dewpoint_2', 'barometer': 'barometer', 'extraDewpoint7': 
'dewpoint_8', 'dewpoint': 'dewpoint_1', 'extraDewpoint5': 'dewpoint_6', 
'extraHumid6': 'humidity_7', 'pressure': 'pressure', 'extraHumid4': 
'humidity_5', 'extraHumid5': 'humidity_6', 'extraHumid2': 'humidity_3', 
'extraHumid3': 'humidity_4', 'extraHumid1': 'humidity_2', 'extraTemp6': 
'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4': 
'temperature_5', 'extraTemp5': 'temperature_6', 'extraTemp2': 
'temperature_3', 'extraTemp3': 'temperature_4', 'extraTemp1': 
'temperature_2', 'extraHeatindex3': 'heatindex_4', 'extraHeatindex2': 
'heatindex_3', 'extraHeatindex1': 'heatindex_2', 'extraHeatindex7': 
'heatindex_8', 'extraHeatindex6': 'heatindex_7', 'extraHeatindex5': 
'heatindex_6', 'extraHumid7': 'humidity_8', 'extraHeatindex4': 
'heatindex_5', 'windDir': 'wind_dir', 'outTemp': 'temperature_1', 
'windSpeed': 'wind_avg', 'inHumidity': 'humidity_0', 'windGust': 
'wind_gust'}
Aug 16 23:35:25 weather kernel: usb 2-2.1: reset full-speed USB device 
number 4 using uhci_hcd
Aug 16 23:35:25 weather weewx[2133]: engine: StdConvert target unit is 0x1
Aug 16 23:35:25 weather weewx[2133]: wxcalculate: The following values will 
be calculated: barometer=prefer_hardware, windchill=hardware, 
dewpoint=hardware, appTemp=prefer_hardware, rainRate=hardware, 
windrun=prefer_hardware, heatindex=hardware, maxSolarRad=prefer_hardware, 
humidex=prefer_hardware, pressure=prefer_hardware, 
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
cloudbase=prefer_hardware
Aug 16 23:35:25 weather weewx[2133]: wxcalculate: The following algorithms 
will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Aug 16 23:35:25 weather weewx[2133]: engine: Archive will use data binding 
wx_binding
Aug 16 23:35:25 weather weewx[2133]: engine: Record generation will be 
attempted in 'hardware'
Aug 16 23:35:25 weather weewx[2133]: engine: Using archive interval of 300 
seconds (specified in weewx configuration)
Aug 16 23:35:25 weather weewx[2133]: manager: Created and initialized table 
'archive' in database 'weewx.sdb'
Aug 16 23:35:26 weather weewx[2133]: manager: Created daily summary tables
Aug 16 23:35:26 weather weewx[2133]: engine: Using binding 'wx_binding' to 
database 'weewx.sdb'
Aug 16 23:35:26 weather weewx[2133]: manager: Starting backfill of daily 
summaries
Aug 16 23:35:26 weather weewx[2133]: restx: StationRegistry: Registration 
not requested.
Aug 16 23:35:26 weather weewx[2133]: restx: Wunderground: Posting not 
enabled.
Aug 16 23:35:26 weather weewx[2133]: restx: PWSweather: Posting not enabled.
Aug 16 23:35:26 weather weewx[2133]: restx: CWOP: Posting not enabled.
Aug 16 23:35:26 weather weewx[2133]: restx: WOW: Posting not enabled.
Aug 16 23:35:26 weather weewx[2133]: restx: AWEKAS: Posting not enabled.
Aug 16 23:35:26 weather weewx[2133]: engine: Starting up weewx version 3.8.0
Aug 16 23:35:26 weather weewx[2133]: wmr300: reading records since *** 
N/A *** (N/A   )
Aug 16 23:35:26 weather weewx[2133]: wmr300: usb failure: [Errno 110] 
Operation timed out
Aug 16 23:35:26 weather weewx[2133]: engine: Caught WeeWxIOError: [Errno 
110] Operation timed out
Aug 16 23:35:26 weather weewx[2133]:  Waiting 60 seconds then 

Re: [weewx-user] Me Again - Trying this again...

[Cycle London]

Hi Thomas. 

The results of the tests are below. 


[root@weather ~]# python
Python 2.7.5 (default, Jul 13 2018, 13:06:57) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes.util import find_library
>>> print find_library('c')
libc.so.6
>>> print find_library('usb-1.0')
libusb-1.0.so.0
>>> print find_library('usb-0.1')
libusb-0.1.so.4
>>> import usb.core
>>> print usb.core.find()
DEVICE ID 1d6b:0002 on Bus 001 Address 001 =
 bLength:   0x12 (18 bytes)
 bDescriptorType:0x1 Device
 bcdUSB :  0x200 USB 2.0
 bDeviceClass   :0x9 Hub
 bDeviceSubClass:0x0
 bDeviceProtocol:0x0
 bMaxPacketSize0:   0x40 (64 bytes)
 idVendor   : 0x1d6b
 idProduct  : 0x0002
 bcdDevice  :  0x310 Device 3.1
 iManufacturer  :0x3 Linux 3.10.0-862.11.6.el7.x86_64 ehci_hcd
 iProduct   :0x2 EHCI Host Controller
 iSerialNumber  :0x1 :02:03.0
 bNumConfigurations :0x1
  CONFIGURATION 1: 0 mA 
   bLength  :0x9 (9 bytes)
   bDescriptorType  :0x2 Configuration
   wTotalLength :   0x19 (25 bytes)
   bNumInterfaces   :0x1
   bConfigurationValue  :0x1
   iConfiguration   :0x0 
   bmAttributes :   0xe0 Self Powered, Remote Wakeup
   bMaxPower:0x0 (0 mA)
INTERFACE 0: Hub ===
 bLength:0x9 (9 bytes)
 bDescriptorType:0x4 Interface
 bInterfaceNumber   :0x0
 bAlternateSetting  :0x0
 bNumEndpoints  :0x1
 bInterfaceClass:0x9 Hub
 bInterfaceSubClass :0x0
 bInterfaceProtocol :0x0
 iInterface :0x0 
  ENDPOINT 0x81: Interrupt IN ==
   bLength  :0x7 (7 bytes)
   bDescriptorType  :0x5 Endpoint
   bEndpointAddress :   0x81 IN
   bmAttributes :0x3 Interrupt
   wMaxPacketSize   :0x4 (4 bytes)
   bInterval:0xc
>>> 




On Thursday, 16 August 2018 19:29:05 UTC+1, Thomas Keffer wrote:
>
> You are probably missing the underlying libusb "C" library. 
>
> Try running this test, using the Python interpreter. You type what's in 
> *bold*.
>
> $ *python*
> >>> *from ctypes.util import find_library*
> >>> *print find_library('c')*
> >>> *print find_library('usb-1.0')*
> >>> *print find_library('usb-0.1')*
> >>> *import usb.core*
> >>> *print usb.core.find()*
>
> -tk
>
> On Thu, Aug 16, 2018 at 10:50 AM Cycle London  > wrote:
>
>> So I asked for your help a while back in migrating a faulty Pi install to 
>> a CentOS 7 box.   I gave up then, because I thought that I'd be able to 
>> handle the constant crashes of the Pi, but having to unplug it and plug it 
>> back in three times a day is getting a bit much.  And if we go away 
>> anywhere and it crashes.. 
>>
>> So I have a CentOS 7.5.1804 box up and running.The Oregon Scientific 
>> WMR300 weather station is recognised and appears in dmesg.   
>>
>> This is a completely fresh install of weewx, in that although I have a 
>> complete back up of /home/weewx from the Pi, I have not transferred any of 
>> the files from the backup.  Everything in /home/weewx on this VM, is 
>> 'pristine' from the install.  I used the setup.py install.   So... 
>>
>> /etc/rc.d/init.d/weewx restart
>> Aug 16 18:48:13 weather systemd: Stopping SYSV: start and stop the weewx 
>> weather system...
>> Aug 16 18:48:13 weather weewx: Shutting down weewx: [FAILED]
>> Aug 16 18:48:13 weather systemd: Starting SYSV: start and stop the weewx 
>> weather system...
>> Aug 16 18:48:14 weather weewx[1854]: engine: Initializing weewx version 
>> 3.8.0
>> Aug 16 18:48:14 weather weewx[1854]: engine: Using Python 2.7.5 (default, 
>> Jul 13 2018, 13:06:57) #012[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]
>> Aug 16 18:48:14 weather weewx[1854]: engine: Platform 
>> Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core
>> Aug 16 18:48:14 weather weewx[1854]: engine: Locale is 'en_GB.UTF-8'
>> Aug 16 18:48:14 weather weewx[1854]: engine: pid file is 
>> /var/run/weewx.pid
>> Aug 16 18:48:14 weather weewx[1858]: engine: Using configuration file 
>> /home/weewx/weewx.conf
>> Aug 16 18:48:14 weather weewx[1858]: engine: Loading station type WMR300 
>> (weewx.drivers.wmr300)
>> Aug 16 18:48:14 weather weewx: Starting weewx: [  OK  ]
>> Aug 16 18:48:14 weather weewx[1858]: wmr300: driver version is 0.18
>> Aug 16 18:48:14 weather weewx[1858]: wmr300: usb info: pyusb_version=1.0.2
>> Aug 16 18:48:14 weather weewx[1858]: wmr300: sensor map is 
>> {'outHumidity': 'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 
>> 'windchill', 'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 
>> 'heatindex': 'heatindex_1', 'inTemp': 

Re: [weewx-user] Re: WeeWX v3.8.2 released

[G Hammer]

Ahhh, I compared the conf files and found what happened.
I do not use [[StandardReport]]and have the section commented out.
The upgrade added it back without commenting it out.
That, of course, caused the website to be completely changed.
No real issue as it was easy to recover from, just wanted to point out that 
it did change my conf file and that did change the website.
I'm using Weewx-WD to provide the data for a Saratoga templated site.


I shall look to see if I can spot and make a correction for this in setup. 
If so, I'll do a pull request.

On Thursday, August 16, 2018 at 5:00:44 PM UTC-4, vince wrote:
>
> On Thursday, August 16, 2018 at 1:53:55 PM UTC-7, G Hammer wrote:
>>
>> It would be nicer if either this were corrected or if the upgrade guide 
>> had a warning in it.
>> As there were no program changes in weewx.conf, I just moved the 3.8.1 
>> version back in place and wiped the web of all files.
>> The scheduled ftp put the site back to the desired state/look.
>>
>>>

> H - I did a 'setup.py build' and 'setup.py install' to upgrade mine 
> and there was no ripple at all.
>
> One thing I do that might be helpful as a risk prevention thing is change 
> the location that the Standard_Skin writes to, so while it still runs, my 
> actual site uses my modified local skin.  You might want to think about 
> that as a risk prevention thing...
>
> [[StandardReport]]
> skin = Standard
> HTML_ROOT = public_html/Standard
>
> # units entries omitted for brevity...
> # units entries omitted for brevity...
> # units entries omitted for brevity...
>
> [[my-local]]
> skin = my-local
> HTML_ROOT = public_html
>
>
>  
>

-- 
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] Recommened Hardware For Solid Driver Integration

[Colin Larsen]

If you don't mind DIY and ultimate flexibility you could look at
WeatherDuino. Emulates the VPs USB connection.

On Fri, 17 Aug 2018, 09:00 Thomas Keffer,  wrote:

> Hard to beat the Davis Vantage series for reliability. They publish their
> API, so the driver is very mature.
>
> Fine Offset derivatives can also be made to work. The driver has been
> reverse engineered, but Matthew has a long history with them and has come
> up with a stable, predictable driver.
>
> Stay clear of the WMR series. We have had to reverse engineer everything,
> to uneven results.
>
> -tk
>
> On Thu, Aug 16, 2018 at 1:09 PM Ray Racine  wrote:
>
>> Looking for recommendation as to which hardware  (Weather Station) to get
>> with the following guidelines.
>>
>> - Fairly recent released model.
>> - Hobbiest friendly.  SOLID SIMPLE INTEGRATION to the data.  e.g.  Which
>> hardware is best for solid, reliable USB integration to the data?  i.e.
>> Which Vendor Hardware's Weewx (USB) driver is the most solid and reliable.
>> - Home / Personal station for use with "Smart Home" DIY software - which
>> is why solid driver integration to directly get the station data is key.
>> No cloud, no internet, no scrapping, no DNS redirect tricks, I just want to
>> be able to query the hardware (via USB or otherwise) to directly get "my"
>> weather data from my weather station.
>> - Vendor is supportative, makes available the docs, allowing everyone to
>> put together and maintain a solid Weewx driver for directly reading the
>> data.
>>
>> The above is the key criteria - which hardware supports the "best"
>> integration capability
>>
>> Above that would be good value for the price.
>> Solar powered station.
>> LUX light intensity besides all the usual weather stats.
>>
>> I'd take a "better" hardware external weather station with regards to
>> reliability and accuracy over a fancy a TFT fancy color console.
>>
>>
>>
>>
>>
>> --
>> 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.
>

-- 
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 v3.8.2 released

[vince]

On Thursday, August 16, 2018 at 1:53:55 PM UTC-7, G Hammer wrote:
>
> It would be nicer if either this were corrected or if the upgrade guide 
> had a warning in it.
> As there were no program changes in weewx.conf, I just moved the 3.8.1 
> version back in place and wiped the web of all files.
> The scheduled ftp put the site back to the desired state/look.
>
>>
>>>
H - I did a 'setup.py build' and 'setup.py install' to upgrade mine and 
there was no ripple at all.

One thing I do that might be helpful as a risk prevention thing is change 
the location that the Standard_Skin writes to, so while it still runs, my 
actual site uses my modified local skin.  You might want to think about 
that as a risk prevention thing...

[[StandardReport]]
skin = Standard
HTML_ROOT = public_html/Standard

# units entries omitted for brevity...
# units entries omitted for brevity...
# units entries omitted for brevity...

[[my-local]]
skin = my-local
HTML_ROOT = public_html


 

-- 
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] Recommened Hardware For Solid Driver Integration

[Thomas Keffer]

Hard to beat the Davis Vantage series for reliability. They publish their
API, so the driver is very mature.

Fine Offset derivatives can also be made to work. The driver has been
reverse engineered, but Matthew has a long history with them and has come
up with a stable, predictable driver.

Stay clear of the WMR series. We have had to reverse engineer everything,
to uneven results.

-tk

On Thu, Aug 16, 2018 at 1:09 PM Ray Racine  wrote:

> Looking for recommendation as to which hardware  (Weather Station) to get
> with the following guidelines.
>
> - Fairly recent released model.
> - Hobbiest friendly.  SOLID SIMPLE INTEGRATION to the data.  e.g.  Which
> hardware is best for solid, reliable USB integration to the data?  i.e.
> Which Vendor Hardware's Weewx (USB) driver is the most solid and reliable.
> - Home / Personal station for use with "Smart Home" DIY software - which
> is why solid driver integration to directly get the station data is key.
> No cloud, no internet, no scrapping, no DNS redirect tricks, I just want to
> be able to query the hardware (via USB or otherwise) to directly get "my"
> weather data from my weather station.
> - Vendor is supportative, makes available the docs, allowing everyone to
> put together and maintain a solid Weewx driver for directly reading the
> data.
>
> The above is the key criteria - which hardware supports the "best"
> integration capability
>
> Above that would be good value for the price.
> Solar powered station.
> LUX light intensity besides all the usual weather stats.
>
> I'd take a "better" hardware external weather station with regards to
> reliability and accuracy over a fancy a TFT fancy color console.
>
>
>
>
>
> --
> 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 v3.8.2 released

[Pat]

Standard disclaimer on being volunteers on an open source software project. 
If you spot the fix, you can submit the changes for the next version.

If you want to force an update to re-ftp your web files, you can run 
wee_reports and not wait until the archive period. 

On Thursday, August 16, 2018 at 4:53:55 PM UTC-4, G Hammer wrote:
>
> It would be nicer if either this were corrected or if the upgrade guide 
> had a warning in it.
> As there were no program changes in weewx.conf, I just moved the 3.8.1 
> version back in place and wiped the web of all files.
> The scheduled ftp put the site back to the desired state/look.
>
>
> On Thursday, August 16, 2018 at 4:40:15 PM UTC-4, Thomas Keffer wrote:
>>
>> Yes, this is a known bug. Issue #217 
>> .
>>
>> -tk
>>
>> On Thu, Aug 16, 2018 at 1:35 PM G Hammer  wrote:
>>
>>>
>>> Update changed my skin to default. Now looking for what else it may have 
>>> changed.
>>> setup.by install & upgrade method.
>>>
>>> -- 
>>> 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] Re: WeeWX v3.8.2 released

[Thomas Keffer]

Yes, it would be nicer. How about a Pull Request that addresses the problem?

-tk

On Thu, Aug 16, 2018 at 1:53 PM G Hammer  wrote:

> It would be nicer if either this were corrected or if the upgrade guide
> had a warning in it.
> As there were no program changes in weewx.conf, I just moved the 3.8.1
> version back in place and wiped the web of all files.
> The scheduled ftp put the site back to the desired state/look.
>
>
> On Thursday, August 16, 2018 at 4:40:15 PM UTC-4, Thomas Keffer wrote:
>>
>> Yes, this is a known bug. Issue #217
>> .
>>
>> -tk
>>
>> On Thu, Aug 16, 2018 at 1:35 PM G Hammer  wrote:
>>
>>>
>>> Update changed my skin to default. Now looking for what else it may have
>>> changed.
>>> setup.by install & upgrade method.
>>>
>>> --
>>> 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.
>

-- 
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] Avoid bad data with StdQC

[Thomas Keffer]

Because the WMR300 supplies rainRate in hardware, you will need to supply
limits for both rain and rainRate. It's up to you to pick sensible values,
but something like this should work.

[StdQC]
  rain = 0, 10, mm
  rainRate = 0, 100.0, mm_per_hour

-tk

On Thu, Aug 16, 2018 at 1:10 PM Alberto Sánchez  wrote:

> Sometimes, in my Oregon WMR300, there are more than 8000mm rains.It is a
> mistake of the station, because the error also appears in the console.
>
> I have cleaned those records from the database but I would like to avoid
> them by software. I read that by using
> http://weewx.com/docs/usersguide.htm#StdQC I could do it, but I do not
> know what parameters I would have to put, rain_rate?
>
> An example in wunderground (
> https://www.wunderground.com/personal-weather-station/dashboard?ID=IVILLAVA2.June
> 13, 2018 ) because from the database I have deleted the errors.
>
> 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.
> 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 v3.8.2 released

[G Hammer]

It would be nicer if either this were corrected or if the upgrade guide had 
a warning in it.
As there were no program changes in weewx.conf, I just moved the 3.8.1 
version back in place and wiped the web of all files.
The scheduled ftp put the site back to the desired state/look.


On Thursday, August 16, 2018 at 4:40:15 PM UTC-4, Thomas Keffer wrote:
>
> Yes, this is a known bug. Issue #217 
> .
>
> -tk
>
> On Thu, Aug 16, 2018 at 1:35 PM G Hammer > 
> wrote:
>
>>
>> Update changed my skin to default. Now looking for what else it may have 
>> changed.
>> setup.by install & upgrade method.
>>
>> -- 
>> 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] Re: WeeWX v3.8.2 released

[Thomas Keffer]

Yes, this is a known bug. Issue #217
.

-tk

On Thu, Aug 16, 2018 at 1:35 PM G Hammer  wrote:

>
> Update changed my skin to default. Now looking for what else it may have
> changed.
> setup.by install & upgrade method.
>
> --
> 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.

[weewx-user] Re: WeeWX v3.8.2 released

[G Hammer]

Update changed my skin to default. Now looking for what else it may have 
changed.
setup.by install & upgrade method.

-- 
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] Avoid bad data with StdQC

[Alberto Sánchez]

Sometimes, in my Oregon WMR300, there are more than 8000mm rains.It is a 
mistake of the station, because the error also appears in the console.

I have cleaned those records from the database but I would like to avoid them 
by software. I read that by using http://weewx.com/docs/usersguide.htm#StdQC I 
could do it, but I do not know what parameters I would have to put, rain_rate?

An example in wunderground 
(https://www.wunderground.com/personal-weather-station/dashboard?ID=IVILLAVA2.June
 13, 2018 ) because from the database I have deleted the errors.

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

[weewx-user] Recommened Hardware For Solid Driver Integration

[Ray Racine]

Looking for recommendation as to which hardware  (Weather Station) to get 
with the following guidelines.  

- Fairly recent released model.
- Hobbiest friendly.  SOLID SIMPLE INTEGRATION to the data.  e.g.  Which 
hardware is best for solid, reliable USB integration to the data?  i.e. 
Which Vendor Hardware's Weewx (USB) driver is the most solid and reliable.
- Home / Personal station for use with "Smart Home" DIY software - which is 
why solid driver integration to directly get the station data is key.  No 
cloud, no internet, no scrapping, no DNS redirect tricks, I just want to be 
able to query the hardware (via USB or otherwise) to directly get "my" 
weather data from my weather station.  
- Vendor is supportative, makes available the docs, allowing everyone to 
put together and maintain a solid Weewx driver for directly reading the 
data. 

The above is the key criteria - which hardware supports the "best" 
integration capability

Above that would be good value for the price.  
Solar powered station.  
LUX light intensity besides all the usual weather stats.   

I'd take a "better" hardware external weather station with regards to 
reliability and accuracy over a fancy a TFT fancy color console. 





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

Re: [weewx-user] WeeWX v3.8.2 released

[Alberto Sánchez]

Great job. Thank you very much to all the people who have collaborated.

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

Re: [weewx-user] WeeWX v3.8.2 released

[Matthew Wall]

> On 16 Aug 2018, at 13:55, Pat  wrote:
> 
> It seems the apt repository isn't updated with 3.8.2 yet. Anything in 
> addition I need besides the usual Debian install instructions?

the apt repository at weewx.com has now been updated

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


signature.asc
Description: Message signed with OpenPGP

Re: [weewx-user] Me Again - Trying this again...

[vince]

He's missing the 'libusb' rpm

On a clean centos/7 vagrant box with only pyusb rpm added

[vagrant@localhost ~]$ python test.py
libc.so.6
None
None
Traceback (most recent call last):
  File "f.py", line 6, in 
print usb.core.find()
  File "/usr/lib/python2.7/site-packages/usb/core.py", line 864, in find
raise ValueError('No backend available')
ValueError: No backend available



After also doing a 'yum install libusb' things look cleaner:

[vagrant@localhost ~]$ python f.py
libc.so.6
libusb-1.0.so.0
libusb-0.1.so.4
None 

-- 
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] Me Again - Trying this again...

[Thomas Keffer]

You are probably missing the underlying libusb "C" library.

Try running this test, using the Python interpreter. You type what's in
*bold*.

$ *python*
>>> *from ctypes.util import find_library*
>>> *print find_library('c')*
>>> *print find_library('usb-1.0')*
>>> *print find_library('usb-0.1')*
>>> *import usb.core*
>>> *print usb.core.find()*

-tk

On Thu, Aug 16, 2018 at 10:50 AM Cycle London 
wrote:

> So I asked for your help a while back in migrating a faulty Pi install to
> a CentOS 7 box.   I gave up then, because I thought that I'd be able to
> handle the constant crashes of the Pi, but having to unplug it and plug it
> back in three times a day is getting a bit much.  And if we go away
> anywhere and it crashes..
>
> So I have a CentOS 7.5.1804 box up and running.The Oregon Scientific
> WMR300 weather station is recognised and appears in dmesg.
>
> This is a completely fresh install of weewx, in that although I have a
> complete back up of /home/weewx from the Pi, I have not transferred any of
> the files from the backup.  Everything in /home/weewx on this VM, is
> 'pristine' from the install.  I used the setup.py install.   So...
>
> /etc/rc.d/init.d/weewx restart
> Aug 16 18:48:13 weather systemd: Stopping SYSV: start and stop the weewx
> weather system...
> Aug 16 18:48:13 weather weewx: Shutting down weewx: [FAILED]
> Aug 16 18:48:13 weather systemd: Starting SYSV: start and stop the weewx
> weather system...
> Aug 16 18:48:14 weather weewx[1854]: engine: Initializing weewx version
> 3.8.0
> Aug 16 18:48:14 weather weewx[1854]: engine: Using Python 2.7.5 (default,
> Jul 13 2018, 13:06:57) #012[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]
> Aug 16 18:48:14 weather weewx[1854]: engine: Platform
> Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core
> Aug 16 18:48:14 weather weewx[1854]: engine: Locale is 'en_GB.UTF-8'
> Aug 16 18:48:14 weather weewx[1854]: engine: pid file is /var/run/weewx.pid
> Aug 16 18:48:14 weather weewx[1858]: engine: Using configuration file
> /home/weewx/weewx.conf
> Aug 16 18:48:14 weather weewx[1858]: engine: Loading station type WMR300
> (weewx.drivers.wmr300)
> Aug 16 18:48:14 weather weewx: Starting weewx: [  OK  ]
> Aug 16 18:48:14 weather weewx[1858]: wmr300: driver version is 0.18
> Aug 16 18:48:14 weather weewx[1858]: wmr300: usb info: pyusb_version=1.0.2
> Aug 16 18:48:14 weather weewx[1858]: wmr300: sensor map is {'outHumidity':
> 'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 'windchill',
> 'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 'heatindex':
> 'heatindex_1', 'inTemp': 'temperature_0', 'windGustDir': 'wind_gust_dir',
> 'extraDewpoint2': 'dewpoint_3', 'extraDewpoint3': 'dewpoint_4',
> 'extraDewpoint1': 'dewpoint_2', 'barometer': 'barometer', 'extraDewpoint7':
> 'dewpoint_8', 'dewpoint': 'dewpoint_1', 'extraDewpoint5': 'dewpoint_6',
> 'extraHumid6': 'humidity_7', 'pressure': 'pressure', 'extraHumid4':
> 'humidity_5', 'extraHumid5': 'humidity_6', 'extraHumid2': 'humidity_3',
> 'extraHumid3': 'humidity_4', 'extraHumid1': 'humidity_2', 'extraTemp6':
> 'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4':
> 'temperature_5', 'extraTemp5': 'temperature_6', 'extraTemp2':
> 'temperature_3', 'extraTemp3': 'temperature_4', 'extraTemp1':
> 'temperature_2', 'extraHeatindex3': 'heatindex_4', 'extraHeatindex2':
> 'heatindex_3', 'extraHeatindex1': 'heatindex_2', 'extraHeatindex7':
> 'heatindex_8', 'extraHeatindex6': 'heatindex_7', 'extraHeatindex5':
> 'heatindex_6', 'extraHumid7': 'humidity_8', 'extraHeatindex4':
> 'heatindex_5', 'windDir': 'wind_dir', 'outTemp': 'temperature_1',
> 'windSpeed': 'wind_avg', 'inHumidity': 'humidity_0', 'windGust':
> 'wind_gust'}
> Aug 16 18:48:14 weather systemd: Started SYSV: start and stop the weewx
> weather system.
> Aug 16 18:48:14 weather weewx[1858]: import of driver failed: No backend
> available ()
> Aug 16 18:48:14 weather weewx[1858]: engine: Unable to load driver: No
> backend available
> Aug 16 18:48:14 weather weewx[1858]:  Exiting...
>
> So near, and yet so far.
>
> 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.
> 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 v3.8.2 released

[Thomas Keffer]

I'm afraid Matthew is going to have to do that. Matthew?

-tk

On Thu, Aug 16, 2018 at 10:56 AM Pat  wrote:

> Great news!
>
> I created 2 new virtual machines (Ubuntu 16.04 and Ubuntu 18.04) and did a
> clean install of weewx. It seems the apt repository isn't updated with
> 3.8.2 yet. Anything in addition I need besides the usual Debian install
>  instructions?
>
> root@weewxubuntu18lab:~# date
> Thu Aug 16 17:54:20 UTC 2018
>
> root@weewxubuntu18lab:~# apt-cache show weewx | grep Version
> Version: 3.8.0-1
>
>
> On Thursday, August 16, 2018 at 1:25:04 PM UTC-4, Thomas Keffer wrote:
>>
>> This is a combined release, which includes changes for v3.8.1.
>>
>> In the usual place .
>>
>> Change log:
>>
>> 3.8.2 08/15/2018
>>
>> Added flag to weewx-multi init script to prevent systemd from breaking it.
>> Thanks to users Timo, Glenn McKechnie, and Paul Oversmith.
>>
>> Fixed problem that caused wind direction in archive records to always be
>> calculated in software, even with stations that provide it in hardware.
>> Fixes issue #336 .
>>
>> 3.8.1 06/27/2018
>>
>> Map cc3000 backup battery to consBatteryVoltage and station battery to
>> supplyVoltage to more accurately reflect the battery functions.
>>
>> Update the syntax in the rsyslog configuration sample
>>
>> Significant overhaul to the WMR300 driver. The driver should now work
>> reliably
>> on any version of pyusb and libusb. The driver will now delete history
>> records
>> from the logger before the logger fills up (the WMR300 logger is not a
>> circular
>> buffer). Thanks to users Markus Biewer and Cameron. Fixes issue #288
>> .
>>
>> Added automatic clearing of logger for CC3000 driver to prevent logger
>> overflow (the CC3000 logger is not a circular buffer). The default is to
>> not clear the history, but it is highly recommended that you add a logging
>> threshold once you are confident that all logger data have been captured
>> to
>> the weewx database.
>>
>> Improved the robustness of reading from the CC3000 logger.
>>
>> Better CRC error message in Vantage driver.
>>
>> Parameterize the configuration directory in weewx-multi init script.
>>
>> In StdWXCalculate, use None for an observation only if the variables on
>> which
>> the derived depends are available and None. Fixes issue #291
>> .
>>
>> Fixed bug that prevented specifying an explicit alamanac time from
>> working.
>>
>> Fixed bug that prevented historical records from being downloaded from
>> ws23xx
>> stations. Thanks to user Matt Brown! Fixes issue #295
>> 
>>
>> Fixed bug that crashed program if a sqlite permission error occurred.
>>
>> If wind speed is zero, accumulators now return last known wind direction
>> (instead of None). Thanks to user DigitalDan05. PR #303
>> .
>>
>> Windrun calculations now include the "current" record. Fixes issue #294
>> .
>>
>> Fixed bug involving stations that report windGust, but not windGustDir, in
>> their LOOP data (e.g., Fine Offset), which prevented the direction of max
>> wind from appearing in statistics. Fixes issue #320
>> .
>>
>> The engine now waits until the system time is greater than the creation
>> time
>> of the weewx.conf file before starting up. Fixes issue #330
>> .
>>
> --
> 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.

[weewx-user] Re: WeeWX v3.8.2 released

[Pat]

Great news!

I created 2 new virtual machines (Ubuntu 16.04 and Ubuntu 18.04) and did a 
clean install of weewx. It seems the apt repository isn't updated with 
3.8.2 yet. Anything in addition I need besides the usual Debian install 
 instructions?

root@weewxubuntu18lab:~# date
Thu Aug 16 17:54:20 UTC 2018

root@weewxubuntu18lab:~# apt-cache show weewx | grep Version
Version: 3.8.0-1


On Thursday, August 16, 2018 at 1:25:04 PM UTC-4, Thomas Keffer wrote:
>
> This is a combined release, which includes changes for v3.8.1. 
>
> In the usual place .
>
> Change log:
>
> 3.8.2 08/15/2018
>
> Added flag to weewx-multi init script to prevent systemd from breaking it.
> Thanks to users Timo, Glenn McKechnie, and Paul Oversmith.
>
> Fixed problem that caused wind direction in archive records to always be
> calculated in software, even with stations that provide it in hardware.
> Fixes issue #336 .
>
> 3.8.1 06/27/2018
>
> Map cc3000 backup battery to consBatteryVoltage and station battery to
> supplyVoltage to more accurately reflect the battery functions.
>
> Update the syntax in the rsyslog configuration sample
>
> Significant overhaul to the WMR300 driver. The driver should now work 
> reliably
> on any version of pyusb and libusb. The driver will now delete history 
> records
> from the logger before the logger fills up (the WMR300 logger is not a 
> circular
> buffer). Thanks to users Markus Biewer and Cameron. Fixes issue #288 
> .
>
> Added automatic clearing of logger for CC3000 driver to prevent logger
> overflow (the CC3000 logger is not a circular buffer). The default is to
> not clear the history, but it is highly recommended that you add a logging
> threshold once you are confident that all logger data have been captured to
> the weewx database.
>
> Improved the robustness of reading from the CC3000 logger.
>
> Better CRC error message in Vantage driver.
>
> Parameterize the configuration directory in weewx-multi init script.
>
> In StdWXCalculate, use None for an observation only if the variables on 
> which
> the derived depends are available and None. Fixes issue #291 
> .
>
> Fixed bug that prevented specifying an explicit alamanac time from working.
>
> Fixed bug that prevented historical records from being downloaded from 
> ws23xx
> stations. Thanks to user Matt Brown! Fixes issue #295 
> 
>
> Fixed bug that crashed program if a sqlite permission error occurred.
>
> If wind speed is zero, accumulators now return last known wind direction
> (instead of None). Thanks to user DigitalDan05. PR #303 
> .
>
> Windrun calculations now include the "current" record. Fixes issue #294 
> .
>
> Fixed bug involving stations that report windGust, but not windGustDir, in
> their LOOP data (e.g., Fine Offset), which prevented the direction of max
> wind from appearing in statistics. Fixes issue #320 
> .
>
> The engine now waits until the system time is greater than the creation 
> time
> of the weewx.conf file before starting up. Fixes issue #330 
> .
>

-- 
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] Me Again - Trying this again...

[Cycle London]

So I asked for your help a while back in migrating a faulty Pi install to a 
CentOS 7 box.   I gave up then, because I thought that I'd be able to 
handle the constant crashes of the Pi, but having to unplug it and plug it 
back in three times a day is getting a bit much.  And if we go away 
anywhere and it crashes.. 

So I have a CentOS 7.5.1804 box up and running.The Oregon Scientific 
WMR300 weather station is recognised and appears in dmesg.   

This is a completely fresh install of weewx, in that although I have a 
complete back up of /home/weewx from the Pi, I have not transferred any of 
the files from the backup.  Everything in /home/weewx on this VM, is 
'pristine' from the install.  I used the setup.py install.   So... 

/etc/rc.d/init.d/weewx restart
Aug 16 18:48:13 weather systemd: Stopping SYSV: start and stop the weewx 
weather system...
Aug 16 18:48:13 weather weewx: Shutting down weewx: [FAILED]
Aug 16 18:48:13 weather systemd: Starting SYSV: start and stop the weewx 
weather system...
Aug 16 18:48:14 weather weewx[1854]: engine: Initializing weewx version 
3.8.0
Aug 16 18:48:14 weather weewx[1854]: engine: Using Python 2.7.5 (default, 
Jul 13 2018, 13:06:57) #012[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]
Aug 16 18:48:14 weather weewx[1854]: engine: Platform 
Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core
Aug 16 18:48:14 weather weewx[1854]: engine: Locale is 'en_GB.UTF-8'
Aug 16 18:48:14 weather weewx[1854]: engine: pid file is /var/run/weewx.pid
Aug 16 18:48:14 weather weewx[1858]: engine: Using configuration file 
/home/weewx/weewx.conf
Aug 16 18:48:14 weather weewx[1858]: engine: Loading station type WMR300 
(weewx.drivers.wmr300)
Aug 16 18:48:14 weather weewx: Starting weewx: [  OK  ]
Aug 16 18:48:14 weather weewx[1858]: wmr300: driver version is 0.18
Aug 16 18:48:14 weather weewx[1858]: wmr300: usb info: pyusb_version=1.0.2
Aug 16 18:48:14 weather weewx[1858]: wmr300: sensor map is {'outHumidity': 
'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 'windchill', 
'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 'heatindex': 
'heatindex_1', 'inTemp': 'temperature_0', 'windGustDir': 'wind_gust_dir', 
'extraDewpoint2': 'dewpoint_3', 'extraDewpoint3': 'dewpoint_4', 
'extraDewpoint1': 'dewpoint_2', 'barometer': 'barometer', 'extraDewpoint7': 
'dewpoint_8', 'dewpoint': 'dewpoint_1', 'extraDewpoint5': 'dewpoint_6', 
'extraHumid6': 'humidity_7', 'pressure': 'pressure', 'extraHumid4': 
'humidity_5', 'extraHumid5': 'humidity_6', 'extraHumid2': 'humidity_3', 
'extraHumid3': 'humidity_4', 'extraHumid1': 'humidity_2', 'extraTemp6': 
'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4': 
'temperature_5', 'extraTemp5': 'temperature_6', 'extraTemp2': 
'temperature_3', 'extraTemp3': 'temperature_4', 'extraTemp1': 
'temperature_2', 'extraHeatindex3': 'heatindex_4', 'extraHeatindex2': 
'heatindex_3', 'extraHeatindex1': 'heatindex_2', 'extraHeatindex7': 
'heatindex_8', 'extraHeatindex6': 'heatindex_7', 'extraHeatindex5': 
'heatindex_6', 'extraHumid7': 'humidity_8', 'extraHeatindex4': 
'heatindex_5', 'windDir': 'wind_dir', 'outTemp': 'temperature_1', 
'windSpeed': 'wind_avg', 'inHumidity': 'humidity_0', 'windGust': 
'wind_gust'}
Aug 16 18:48:14 weather systemd: Started SYSV: start and stop the weewx 
weather system.
Aug 16 18:48:14 weather weewx[1858]: import of driver failed: No backend 
available ()
Aug 16 18:48:14 weather weewx[1858]: engine: Unable to load driver: No 
backend available
Aug 16 18:48:14 weather weewx[1858]:  Exiting...

So near, and yet so far. 

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

Re: [weewx-user] Re: after raspbian and weewx updates, weewx is still collecting data but stopped publishing to CWOP and Wunderground

[Michael Gray]

Yes -- I had debug=1 -- did not see any sign of trouble either in 
/var/log/messages or to the terminal running weewxd in the foreground (vs. 
daemon mode as a service).

m.

On Thursday, August 16, 2018 at 10:54:15 AM UTC-4, Thomas Keffer wrote:
>
> It does seem odd. Did you have debug=1? That should have logged all 
> failures.
>
> Otherwise, only the final failure gets logged.
>
> -tk
>
> On Thu, Aug 16, 2018 at 7:46 AM Michael Gray  > wrote:
>
>> I have found/fixed my problem!As I suspected, it was nothing to do 
>> with weewx per se...   Somehow, my DNS config (resolv.conf etc.) was changed
>> so my Pi was not resolving hostnames.   This caused weewx rest code not 
>> to resolve urls needed for posting to public servers:
>>
>> ./weewx/restx.py:rf_url = "
>> http://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
>> ./weewx/restx.py:pws_url = "
>> http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php
>> "
>> ./weewx/restx.py:default_servers = ['cwop.aprs.net:14580', '
>> cwop.aprs.net:23']
>>
>> Once I got name resolution back on the rails, weewx publishing started 
>> working.
>>
>> I'm a little surprised that with all the error checking in the code, 
>> weewx was silent on the issue of not being able to resolve the hostnames in 
>> the URLs
>> upon which it depends -- nothing about GET failing or anything...
>>
>> It looks like the except's on the try's to connect to the servers could 
>> use some more generic error catching -- I might give it a go but my python 
>> foo is not strong...
>>
>> Would a bug report be in order here?  I know this wasn't weewx fault per 
>> se, but had there been an error like "unknown host", I would have probably 
>> found the
>> name resolution problem quickly... 
>>
>> Thanks to all who looked at my post and sent along their thoughts -- 
>> great community here!
>>
>>
>> On Thursday, August 16, 2018 at 10:02:34 AM UTC-4, Michael Gray wrote:
>>>
>>> It's always said that -- I never explicitly requested "hardware 
>>> generation" -- I'll try adding  record_generation = software   explicitly
>>>
>>> last restart before "upgrade" when all was well:Aug 14 15:17:11 
>>> raspberrypi weewx[654]: engine: Record generation will be attempted in 
>>> 'hardware'
>>> post-upgrade:Aug 
>>> 15 22:01:18 raspberrypi weewx[29842]: engine: Record generation will be 
>>> attempted in 'hardware'
>>>
>>> hardware is the default and comments suggest it will use hardware in 
>>> devices that support it -- software if not...But I've added the 
>>> following:
>>>
>>> # If possible, new archive records are downloaded from the station
>>> # hardware. *If the hardware does not support this, then new 
>>> archive*
>>> *# records will be generated in software.*
>>> # Set the following to "software" to force software record 
>>> generation.
>>> *#*record_generation = hardware
>>> *record_generation = software*
>>>
>>> Log now reports this:
>>>
>>> Aug 16 09:56:18 raspberrypi weewx[2791]: engine: *Record generation 
>>> will be attempted in 'software'*
>>>
>>> No change in behavior -- still getting data, storing records and 
>>> generating web pages -- but no publish...
>>>
>>> I'm wondering if something in all the linux updates (not updated for 
>>> several months) changed -- python or some library weewx uses...
>>>
>>>
>>> On Thursday, August 16, 2018 at 8:15:00 AM UTC-4, gjr80 wrote:

 Let's try that again.

 Hi,

 Any reason you are using hardware record generation? As far as I am 
 aware the AcuRite stations only emit loop packets (in fact the AcuRite 
 driver does not have a genArchiveRecords() method necessary to generate 
 archive records from the hardware). Suggest you try setting 
 record_generation = software under [StdArchive] in weewx.conf. Once you 
 make  the change you will need to restart weeWX.

 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] WeeWX v3.8.2 released

[Thomas Keffer]

This is a combined release, which includes changes for v3.8.1.

In the usual place .

Change log:

3.8.2 08/15/2018

Added flag to weewx-multi init script to prevent systemd from breaking it.
Thanks to users Timo, Glenn McKechnie, and Paul Oversmith.

Fixed problem that caused wind direction in archive records to always be
calculated in software, even with stations that provide it in hardware.
Fixes issue #336 .

3.8.1 06/27/2018

Map cc3000 backup battery to consBatteryVoltage and station battery to
supplyVoltage to more accurately reflect the battery functions.

Update the syntax in the rsyslog configuration sample

Significant overhaul to the WMR300 driver. The driver should now work
reliably
on any version of pyusb and libusb. The driver will now delete history
records
from the logger before the logger fills up (the WMR300 logger is not a
circular
buffer). Thanks to users Markus Biewer and Cameron. Fixes issue #288
.

Added automatic clearing of logger for CC3000 driver to prevent logger
overflow (the CC3000 logger is not a circular buffer). The default is to
not clear the history, but it is highly recommended that you add a logging
threshold once you are confident that all logger data have been captured to
the weewx database.

Improved the robustness of reading from the CC3000 logger.

Better CRC error message in Vantage driver.

Parameterize the configuration directory in weewx-multi init script.

In StdWXCalculate, use None for an observation only if the variables on
which
the derived depends are available and None. Fixes issue #291
.

Fixed bug that prevented specifying an explicit alamanac time from working.

Fixed bug that prevented historical records from being downloaded from
ws23xx
stations. Thanks to user Matt Brown! Fixes issue #295


Fixed bug that crashed program if a sqlite permission error occurred.

If wind speed is zero, accumulators now return last known wind direction
(instead of None). Thanks to user DigitalDan05. PR #303
.

Windrun calculations now include the "current" record. Fixes issue #294
.

Fixed bug involving stations that report windGust, but not windGustDir, in
their LOOP data (e.g., Fine Offset), which prevented the direction of max
wind from appearing in statistics. Fixes issue #320
.

The engine now waits until the system time is greater than the creation time
of the weewx.conf file before starting up. Fixes issue #330
.

-- 
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: PWS data format for Interceptor

[Pat]

That's my thought is trying to find the right combination. The 
documentation isn't exactly complete, but looking at the "supported" node 
library they reference, it shows the URL they are using. But they explicitly 
define websockets there too 

. 

There's a way to get socket.io to fallback onto websockets 
 where you can use wss, but I 
haven't figured that bit out yet with AW.



On Thursday, August 16, 2018 at 11:47:49 AM UTC-4, Thomas Keffer wrote:
>
> I guess I was wrong!
>
> I find it hard to believe that the Python socket.io library is incapable 
> of handling such a simple case. The problem must be some combination of 
> getting the base host, api endpoint, and parameters right.
>
> -tk
>
> On Thu, Aug 16, 2018 at 8:34 AM Pat > 
> wrote:
>
>> I tried that too and couldn't get it to work. Forgot to mention that. 
>>
>> Trying it a couple of different ways again, I get the apiKey is missing:
>>
>> with SocketIO('
>> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APP_KEY=YOUR_API_KEY',
>>  
>> 443, LoggingNamespace, verify=False ) as socketIO:
>> socketIO.on('connect', on_connect)
>>
>> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
>> InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
>> certificate verification is strongly advised. See: https://
>> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
>> InsecureRequestWarning)
>>
>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
>> engine.io waiting for connection] unexpected status code (401 {"error":
>> "apiKey-missing"})
>>
>> Or the 404 again
>>
>> SocketIO(
>> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDR', 443, 
>> LoggingNamespace,
>> verify=False,
>> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 'YOUR_APP_KEY' })
>>
>>
>> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
>> InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
>> certificate verification is strongly advised. See: https://
>> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
>> InsecureRequestWarning)
>>
>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
>> YOUR_MAC_ADDR/socket.io [engine.io waiting for connection] unexpected 
>> status code (404 {"name":"NotFound","message":"Page not found","code":404
>> ,"className":"not-found","errors":{}})
>>
>> Pat
>>
>>
>>
>>
>> On Thursday, August 16, 2018 at 11:24:00 AM UTC-4, Thomas Keffer wrote:
>>>
>>> I'm betting this is a ssl certificate problem. Try setting verify=False.
>>>
>>> -tk
>>>
>>> On Thu, Aug 16, 2018 at 8:15 AM Pat  wrote:
>>>
 I'm still thinking about this, and since I can't get the socket.io 
 real time stream 
  
 to work in Python, I thought about using a timer to poll the endpoint. 
 However it looks like they only update the endpoint every 5 minutes. I'm 
 thinking that's not really a good option since you probably want real time 
 loop data, and not a 5 minute archive. 

 Since it seems to be working with node, and you're familiar with node, 
 maybe that's your best bet right now to get the real time updates out of 
 AW? 



 Since you're a customer of AW, you could also email them asking for 
 Python help with the real time endpoint 
  
 and see what they say. Their API docs 
  
 say "The easiest way to use the API is to use a Socket.io helper library. 
 They are available in most languages.", but when I use their endpoint with 
 a Python helper library all I get is a 404. 

 Here's the code from sockerIO_client's sample code 
 . Nothing fancy here yet, 
 just trying to connect, and it doesn't. 

 After doing sudo pip install socketIO_client

 I ran this code

 import logging
 logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
 logging.basicConfig()


 from socketIO_client import SocketIO, LoggingNamespace


 def on_connect():
 print('connect')


 with SocketIO('
 https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY
 ', 443, LoggingNamespace ) as socketIO:
 socketIO.on('connect', on_connect)


 which outputs:

 WARNING:socketIO-client:api.ambientweather.net:443//socket.io [
 engine.io waiting for connection] unexpected status code (404 
 {"name":"NotFound","message":"Page not 
 found","code":404,"className":"not-found","errors":{}})

 Adding your API Key to that HTTPS endpoint:

 

Re: [weewx-user] Re: PWS data format for Interceptor

[Douglas Krug]

I've sent this conversation to supp...@ambientweather.com to see if they 
could offer some guidance or get involved with the discussion here. They 
have a Facebook API group for questions and discussion, but I think they 
didn't expect it to be so unloved! Nobody had posted a single comment there 
in the last 30 days.

On Thursday, August 16, 2018 at 11:15:26 AM UTC-4, Pat wrote:
>
> I'm still thinking about this, and since I can't get the socket.io real 
> time stream 
>  
> to work in Python, I thought about using a timer to poll the endpoint. 
> However it looks like they only update the endpoint every 5 minutes. I'm 
> thinking that's not really a good option since you probably want real time 
> loop data, and not a 5 minute archive. 
>
> Since it seems to be working with node, and you're familiar with node, 
> maybe that's your best bet right now to get the real time updates out of 
> AW? 
>
>
>
> Since you're a customer of AW, you could also email them asking for Python 
> help with the real time endpoint 
>  
> and see what they say. Their API docs 
>  
> say "The easiest way to use the API is to use a Socket.io helper library. 
> They are available in most languages.", but when I use their endpoint with 
> a Python helper library all I get is a 404. 
>
> Here's the code from sockerIO_client's sample code 
> . Nothing fancy here yet, just 
> trying to connect, and it doesn't. 
>
> After doing sudo pip install socketIO_client
>
> I ran this code
>
> import logging
> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
> logging.basicConfig()
>
>
> from socketIO_client import SocketIO, LoggingNamespace
>
>
> def on_connect():
> print('connect')
>
>
> with SocketIO('
> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY'
> , 443, LoggingNamespace ) as socketIO:
> socketIO.on('connect', on_connect)
>
>
> which outputs:
>
> WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io 
> waiting for connection] unexpected status code (404 
> {"name":"NotFound","message":"Page not 
> found","code":404,"className":"not-found","errors":{}})
>
> Adding your API Key to that HTTPS endpoint:
>
> with SocketIO('
> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY
> ', 443, LoggingNamespace ) as socketIO:
> socketIO.on('connect', on_connect)
>
> gave me:
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
> engine.io waiting for connection] unexpected status code (401 {"error":
> "apiKey-missing"})
>
> But the API key isn't missing, it's in the string :)
>
>
>
> Or if I did something even different (again from the examples 
> )
>
> SocketIO(
> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443, 
> LoggingNamespace,
> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 
> 'YOUR_APPLICATION_KEY' })
>
> I get
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
> YOUR_MAC_ADDRESS/socket.io [engine.io waiting for connection] unexpected 
> status code (404 {"name":"NotFound","message":"Page not found","code":404,
> "className":"not-found","errors":{}})
>
>
>
>
>
> However, if I go to an online socket.io test tool 
> , and enter in your real 
> time endpoint, it connects just fine. This is farther than Python is 
> letting me get. 
>
> [image: socketio.png]
> Again, not sure where to go from here. Maybe Node is your best bet. But 
> also maybe the information above is enough info to get help from them if 
> you do end up reaching out to them?
>
>
>
>
> On Wednesday, August 15, 2018 at 9:04:34 AM UTC-4, Pat wrote:
>>
>> No, those are using sockets like how you and I think sockets are. I'm 
>> familiar with traditional sockets (my SocketLogger driver, and I forked the 
>> meteostick driver to use sockets) and I'm familiar with websockets, but 
>> this is using socket.io which is a websocket, but not a normal websocket 
>> apparently. It's designed to support old browsers so they use a bit of a 
>> custom algo to make it happen. 
>>
>> Since AW is using https and not wss, only the socketIO-client Python lib 
>> will work, but when trying to connect to the endpoint it gives a 404. But 
>> using the same endpoint on an online JavaScript socket.io test tool, its 
>> a success. Could be a limitation with the lib.
>>
>> The AW socket.io endpoint is for the real-time streaming data from 
>> AmbientWeather. Perhaps plan B is to implement a time.sleep() in the 
>> driver and just request data every 10 seconds (or something) and submit to 
>> the loop. Downside could be duplicate timestamps, unless the weewx loop 
>> already allocates for that? 

[weewx-user] Re: how to implement forecast table on standard skin or sofaskin?

[Andres Revilla]

Hi .. 

I have tried to follow your tutorial but no luck ...

I get data , but no images ... i copy icons , etc ... If i use standar 
forecast web all its working ok , but when i use standar modified webpage , 
i get data but images / colors

I have installed ( weewx 3.8.0 and forecast 3.2.19) .

Maybe config problem? 



El jueves, 24 de noviembre de 2016, 15:05:02 (UTC+1), mwall escribió:
>
> hi marc,
>
> this is how to insert the forecast table into the standard report:
>
> 1) copy the icons and table template to the standard skin
>
> cp -r skins/forecast/icons skins/Standard
> cp skins/forecast/forecast_table.inc skins/Standard
>
> 2) modify skin.conf for the standard report.  add the following to the 
> sections already in skin.conf (the ... indicates existing parameters):
>
> [Extras]
> ...
> [[forecast_table_settings]]
> forecast_source = WU
> num_periods = 84
>
> [CheetahGenerator]
> search_list_extensions = user.forecast.ForecastVariables
> ...
>
> [CopyGenerator]
> copy_once = ..., icons/*.png
>
> 3) include the table in one of the template files.  for example, put this 
> in skins/Standard/index.html.tmpl:
>
> #include "forecast_table.inc"
>
> that should do it!
>
> if things do not work as you expect, take a look at the log.
>
> 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: PWS data format for Interceptor

[Thomas Keffer]

I guess I was wrong!

I find it hard to believe that the Python socket.io library is incapable of
handling such a simple case. The problem must be some combination of
getting the base host, api endpoint, and parameters right.

-tk

On Thu, Aug 16, 2018 at 8:34 AM Pat  wrote:

> I tried that too and couldn't get it to work. Forgot to mention that.
>
> Trying it a couple of different ways again, I get the apiKey is missing:
>
> with SocketIO('
> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APP_KEY=YOUR_API_KEY',
> 443, LoggingNamespace, verify=False ) as socketIO:
> socketIO.on('connect', on_connect)
>
> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See: https://
> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
> InsecureRequestWarning)
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
> engine.io waiting for connection] unexpected status code (401 {"error":
> "apiKey-missing"})
>
> Or the 404 again
>
> SocketIO(
> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDR', 443,
> LoggingNamespace,
> verify=False,
> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 'YOUR_APP_KEY' })
>
>
> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See: https://
> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
> InsecureRequestWarning)
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
> YOUR_MAC_ADDR/socket.io [engine.io waiting for connection] unexpected
> status code (404 {"name":"NotFound","message":"Page not found","code":404,
> "className":"not-found","errors":{}})
>
> Pat
>
>
>
>
> On Thursday, August 16, 2018 at 11:24:00 AM UTC-4, Thomas Keffer wrote:
>>
>> I'm betting this is a ssl certificate problem. Try setting verify=False.
>>
>> -tk
>>
>> On Thu, Aug 16, 2018 at 8:15 AM Pat  wrote:
>>
>>> I'm still thinking about this, and since I can't get the socket.io real
>>> time stream
>>> 
>>> to work in Python, I thought about using a timer to poll the endpoint.
>>> However it looks like they only update the endpoint every 5 minutes. I'm
>>> thinking that's not really a good option since you probably want real time
>>> loop data, and not a 5 minute archive.
>>>
>>> Since it seems to be working with node, and you're familiar with node,
>>> maybe that's your best bet right now to get the real time updates out of
>>> AW?
>>>
>>>
>>>
>>> Since you're a customer of AW, you could also email them asking for
>>> Python help with the real time endpoint
>>> 
>>> and see what they say. Their API docs
>>> 
>>> say "The easiest way to use the API is to use a Socket.io helper library.
>>> They are available in most languages.", but when I use their endpoint with
>>> a Python helper library all I get is a 404.
>>>
>>> Here's the code from sockerIO_client's sample code
>>> . Nothing fancy here yet,
>>> just trying to connect, and it doesn't.
>>>
>>> After doing sudo pip install socketIO_client
>>>
>>> I ran this code
>>>
>>> import logging
>>> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
>>> logging.basicConfig()
>>>
>>>
>>> from socketIO_client import SocketIO, LoggingNamespace
>>>
>>>
>>> def on_connect():
>>> print('connect')
>>>
>>>
>>> with SocketIO('
>>> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY
>>> ', 443, LoggingNamespace ) as socketIO:
>>> socketIO.on('connect', on_connect)
>>>
>>>
>>> which outputs:
>>>
>>> WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io
>>> waiting for connection] unexpected status code (404
>>> {"name":"NotFound","message":"Page not
>>> found","code":404,"className":"not-found","errors":{}})
>>>
>>> Adding your API Key to that HTTPS endpoint:
>>>
>>> with SocketIO('
>>> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY
>>> ', 443, LoggingNamespace ) as socketIO:
>>> socketIO.on('connect', on_connect)
>>>
>>> gave me:
>>>
>>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io
>>> [engine.io waiting for connection] unexpected status code (401 {"error":
>>> "apiKey-missing"})
>>>
>>> But the API key isn't missing, it's in the string :)
>>>
>>>
>>>
>>> Or if I did something even different (again from the examples
>>> )
>>>
>>> SocketIO(
>>> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443,
>>> LoggingNamespace,
>>> params={'apiKey': 'YOUR_API_KEY', 

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

I tried that too and couldn't get it to work. Forgot to mention that. 

Trying it a couple of different ways again, I get the apiKey is missing:

with 
SocketIO('https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APP_KEY=YOUR_API_KEY',
 
443, LoggingNamespace, verify=False ) as socketIO:
socketIO.on('connect', on_connect)

/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
InsecureRequestWarning)

WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
engine.io waiting for connection] unexpected status code (401 {"error":
"apiKey-missing"})

Or the 404 again

SocketIO(
'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDR', 443, 
LoggingNamespace,
verify=False,
params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 'YOUR_APP_KEY' })


/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
InsecureRequestWarning)

WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/YOUR_MAC_ADDR/
socket.io [engine.io waiting for connection] unexpected status code (404 {
"name":"NotFound","message":"Page not found","code":404,"className":
"not-found","errors":{}})

Pat




On Thursday, August 16, 2018 at 11:24:00 AM UTC-4, Thomas Keffer wrote:
>
> I'm betting this is a ssl certificate problem. Try setting verify=False.
>
> -tk
>
> On Thu, Aug 16, 2018 at 8:15 AM Pat > 
> wrote:
>
>> I'm still thinking about this, and since I can't get the socket.io real 
>> time stream 
>>  
>> to work in Python, I thought about using a timer to poll the endpoint. 
>> However it looks like they only update the endpoint every 5 minutes. I'm 
>> thinking that's not really a good option since you probably want real time 
>> loop data, and not a 5 minute archive. 
>>
>> Since it seems to be working with node, and you're familiar with node, 
>> maybe that's your best bet right now to get the real time updates out of 
>> AW? 
>>
>>
>>
>> Since you're a customer of AW, you could also email them asking for 
>> Python help with the real time endpoint 
>>  
>> and see what they say. Their API docs 
>>  
>> say "The easiest way to use the API is to use a Socket.io helper library. 
>> They are available in most languages.", but when I use their endpoint with 
>> a Python helper library all I get is a 404. 
>>
>> Here's the code from sockerIO_client's sample code 
>> . Nothing fancy here yet, 
>> just trying to connect, and it doesn't. 
>>
>> After doing sudo pip install socketIO_client
>>
>> I ran this code
>>
>> import logging
>> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
>> logging.basicConfig()
>>
>>
>> from socketIO_client import SocketIO, LoggingNamespace
>>
>>
>> def on_connect():
>> print('connect')
>>
>>
>> with SocketIO('
>> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY
>> ', 443, LoggingNamespace ) as socketIO:
>> socketIO.on('connect', on_connect)
>>
>>
>> which outputs:
>>
>> WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io 
>> waiting for connection] unexpected status code (404 
>> {"name":"NotFound","message":"Page not 
>> found","code":404,"className":"not-found","errors":{}})
>>
>> Adding your API Key to that HTTPS endpoint:
>>
>> with SocketIO('
>> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY
>> ', 443, LoggingNamespace ) as socketIO:
>> socketIO.on('connect', on_connect)
>>
>> gave me:
>>
>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
>> engine.io waiting for connection] unexpected status code (401 {"error":
>> "apiKey-missing"})
>>
>> But the API key isn't missing, it's in the string :)
>>
>>
>>
>> Or if I did something even different (again from the examples 
>> )
>>
>> SocketIO(
>> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443, 
>> LoggingNamespace,
>> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 
>> 'YOUR_APPLICATION_KEY' })
>>
>> I get
>>
>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
>> YOUR_MAC_ADDRESS/socket.io [engine.io waiting for connection] unexpected 
>> status code (404 {"name":"NotFound","message":"Page not found","code":404
>> ,"className":"not-found","errors":{}})
>>
>>
>>
>>
>>
>> However, if I go to an online socket.io test tool 
>> 

Re: [weewx-user] Re: PWS data format for Interceptor

[Thomas Keffer]

I'm betting this is a ssl certificate problem. Try setting verify=False.

-tk

On Thu, Aug 16, 2018 at 8:15 AM Pat  wrote:

> I'm still thinking about this, and since I can't get the socket.io real
> time stream
> 
> to work in Python, I thought about using a timer to poll the endpoint.
> However it looks like they only update the endpoint every 5 minutes. I'm
> thinking that's not really a good option since you probably want real time
> loop data, and not a 5 minute archive.
>
> Since it seems to be working with node, and you're familiar with node,
> maybe that's your best bet right now to get the real time updates out of
> AW?
>
>
>
> Since you're a customer of AW, you could also email them asking for Python
> help with the real time endpoint
> 
> and see what they say. Their API docs
> 
> say "The easiest way to use the API is to use a Socket.io helper library.
> They are available in most languages.", but when I use their endpoint with
> a Python helper library all I get is a 404.
>
> Here's the code from sockerIO_client's sample code
> . Nothing fancy here yet, just
> trying to connect, and it doesn't.
>
> After doing sudo pip install socketIO_client
>
> I ran this code
>
> import logging
> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
> logging.basicConfig()
>
>
> from socketIO_client import SocketIO, LoggingNamespace
>
>
> def on_connect():
> print('connect')
>
>
> with SocketIO('
> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY'
> , 443, LoggingNamespace ) as socketIO:
> socketIO.on('connect', on_connect)
>
>
> which outputs:
>
> WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io
> waiting for connection] unexpected status code (404
> {"name":"NotFound","message":"Page not
> found","code":404,"className":"not-found","errors":{}})
>
> Adding your API Key to that HTTPS endpoint:
>
> with SocketIO('
> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY
> ', 443, LoggingNamespace ) as socketIO:
> socketIO.on('connect', on_connect)
>
> gave me:
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
> engine.io waiting for connection] unexpected status code (401 {"error":
> "apiKey-missing"})
>
> But the API key isn't missing, it's in the string :)
>
>
>
> Or if I did something even different (again from the examples
> )
>
> SocketIO(
> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443,
> LoggingNamespace,
> params={'apiKey': 'YOUR_API_KEY', 'applicationKey':
> 'YOUR_APPLICATION_KEY' })
>
> I get
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
> YOUR_MAC_ADDRESS/socket.io [engine.io waiting for connection] unexpected
> status code (404 {"name":"NotFound","message":"Page not found","code":404,
> "className":"not-found","errors":{}})
>
>
>
>
>
> However, if I go to an online socket.io test tool
> , and enter in your real
> time endpoint, it connects just fine. This is farther than Python is
> letting me get.
>
> [image: socketio.png]
> Again, not sure where to go from here. Maybe Node is your best bet. But
> also maybe the information above is enough info to get help from them if
> you do end up reaching out to them?
>
>
>
>
> On Wednesday, August 15, 2018 at 9:04:34 AM UTC-4, Pat wrote:
>>
>> No, those are using sockets like how you and I think sockets are. I'm
>> familiar with traditional sockets (my SocketLogger driver, and I forked the
>> meteostick driver to use sockets) and I'm familiar with websockets, but
>> this is using socket.io which is a websocket, but not a normal websocket
>> apparently. It's designed to support old browsers so they use a bit of a
>> custom algo to make it happen.
>>
>> Since AW is using https and not wss, only the socketIO-client Python lib
>> will work, but when trying to connect to the endpoint it gives a 404. But
>> using the same endpoint on an online JavaScript socket.io test tool, its
>> a success. Could be a limitation with the lib.
>>
>> The AW socket.io endpoint is for the real-time streaming data from
>> AmbientWeather. Perhaps plan B is to implement a time.sleep() in the
>> driver and just request data every 10 seconds (or something) and submit to
>> the loop. Downside could be duplicate timestamps, unless the weewx loop
>> already allocates for that? Which could be a non-issue.
>>
>>
>> On Tuesday, August 14, 2018 at 11:39:10 PM UTC-4, gjr80 wrote:
>>>
>>> So nothing in the vantage or ws1 drivers or restx.py to help?
>>>
>>> Gary
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe 

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

I'm still thinking about this, and since I can't get the socket.io real 
time stream 
 to 
work in Python, I thought about using a timer to poll the endpoint. However 
it looks like they only update the endpoint every 5 minutes. I'm thinking 
that's not really a good option since you probably want real time loop 
data, and not a 5 minute archive. 

Since it seems to be working with node, and you're familiar with node, 
maybe that's your best bet right now to get the real time updates out of 
AW? 



Since you're a customer of AW, you could also email them asking for Python 
help with the real time endpoint 
 and 
see what they say. Their API docs 
 say 
"The easiest way to use the API is to use a Socket.io helper library. They 
are available in most languages.", but when I use their endpoint with a 
Python helper library all I get is a 404. 

Here's the code from sockerIO_client's sample code 
. Nothing fancy here yet, just 
trying to connect, and it doesn't. 

After doing sudo pip install socketIO_client

I ran this code

import logging
logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
logging.basicConfig()


from socketIO_client import SocketIO, LoggingNamespace


def on_connect():
print('connect')


with SocketIO(
'https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY', 
443, LoggingNamespace ) as socketIO:
socketIO.on('connect', on_connect)


which outputs:

WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io 
waiting for connection] unexpected status code (404 
{"name":"NotFound","message":"Page not 
found","code":404,"className":"not-found","errors":{}})

Adding your API Key to that HTTPS endpoint:

with SocketIO(
'https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY'
, 443, LoggingNamespace ) as socketIO:
socketIO.on('connect', on_connect)

gave me:

WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
engine.io waiting for connection] unexpected status code (401 {"error":
"apiKey-missing"})

But the API key isn't missing, it's in the string :)



Or if I did something even different (again from the examples 
)

SocketIO(
'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443, 
LoggingNamespace,
params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 
'YOUR_APPLICATION_KEY' })

I get

WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
YOUR_MAC_ADDRESS/socket.io [engine.io waiting for connection] unexpected 
status code (404 {"name":"NotFound","message":"Page not found","code":404,
"className":"not-found","errors":{}})





However, if I go to an online socket.io test tool 
, and enter in your real 
time endpoint, it connects just fine. This is farther than Python is 
letting me get. 

[image: socketio.png] 
Again, not sure where to go from here. Maybe Node is your best bet. But 
also maybe the information above is enough info to get help from them if 
you do end up reaching out to them?




On Wednesday, August 15, 2018 at 9:04:34 AM UTC-4, Pat wrote:
>
> No, those are using sockets like how you and I think sockets are. I'm 
> familiar with traditional sockets (my SocketLogger driver, and I forked the 
> meteostick driver to use sockets) and I'm familiar with websockets, but 
> this is using socket.io which is a websocket, but not a normal websocket 
> apparently. It's designed to support old browsers so they use a bit of a 
> custom algo to make it happen. 
>
> Since AW is using https and not wss, only the socketIO-client Python lib 
> will work, but when trying to connect to the endpoint it gives a 404. But 
> using the same endpoint on an online JavaScript socket.io test tool, its 
> a success. Could be a limitation with the lib.
>
> The AW socket.io endpoint is for the real-time streaming data from 
> AmbientWeather. Perhaps plan B is to implement a time.sleep() in the 
> driver and just request data every 10 seconds (or something) and submit to 
> the loop. Downside could be duplicate timestamps, unless the weewx loop 
> already allocates for that? Which could be a non-issue. 
>
>
> On Tuesday, August 14, 2018 at 11:39:10 PM UTC-4, gjr80 wrote:
>>
>> So nothing in the vantage or ws1 drivers or restx.py to help?
>>
>> Gary
>>
>

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

Re: [weewx-user] Re: Degrees measurement in exact figures

[Thomas Keffer]

Andrew has it exactly right.

For the difference between LOOP packets (every 2.5 seconds) and archive
records (depends on console setting, but in your case, every 10 minutes),
see the section *LOOP packets vs archive records
*
in
the Customizing Guide.

-tk

On Thu, Aug 16, 2018 at 7:12 AM Antonis Katsonis <
nafpaktia.weat...@gmail.com> wrote:

> If archive records is set to 10 minutes, the record generation set in
> software, when will the weewx request new packets from the console?
> Every 10 minutes or every 2.5 seconds? ( 2.5 sec is the update interval
> between console and ISS )
> The type of packets will be archive record or loop packet or both?
>
> --
> 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: after raspbian and weewx updates, weewx is still collecting data but stopped publishing to CWOP and Wunderground

[Thomas Keffer]

It does seem odd. Did you have debug=1? That should have logged all
failures.

Otherwise, only the final failure gets logged.

-tk

On Thu, Aug 16, 2018 at 7:46 AM Michael Gray  wrote:

> I have found/fixed my problem!As I suspected, it was nothing to do
> with weewx per se...   Somehow, my DNS config (resolv.conf etc.) was changed
> so my Pi was not resolving hostnames.   This caused weewx rest code not to
> resolve urls needed for posting to public servers:
>
> ./weewx/restx.py:rf_url = "
> http://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
> ./weewx/restx.py:pws_url = "
> http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php
> "
> ./weewx/restx.py:default_servers = ['cwop.aprs.net:14580', '
> cwop.aprs.net:23']
>
> Once I got name resolution back on the rails, weewx publishing started
> working.
>
> I'm a little surprised that with all the error checking in the code, weewx
> was silent on the issue of not being able to resolve the hostnames in the
> URLs
> upon which it depends -- nothing about GET failing or anything...
>
> It looks like the except's on the try's to connect to the servers could
> use some more generic error catching -- I might give it a go but my python
> foo is not strong...
>
> Would a bug report be in order here?  I know this wasn't weewx fault per
> se, but had there been an error like "unknown host", I would have probably
> found the
> name resolution problem quickly...
>
> Thanks to all who looked at my post and sent along their thoughts -- great
> community here!
>
>
> On Thursday, August 16, 2018 at 10:02:34 AM UTC-4, Michael Gray wrote:
>>
>> It's always said that -- I never explicitly requested "hardware
>> generation" -- I'll try adding  record_generation = software   explicitly
>>
>> last restart before "upgrade" when all was well:Aug 14 15:17:11
>> raspberrypi weewx[654]: engine: Record generation will be attempted in
>> 'hardware'
>> post-upgrade:Aug
>> 15 22:01:18 raspberrypi weewx[29842]: engine: Record generation will be
>> attempted in 'hardware'
>>
>> hardware is the default and comments suggest it will use hardware in
>> devices that support it -- software if not...But I've added the
>> following:
>>
>> # If possible, new archive records are downloaded from the station
>> # hardware. *If the hardware does not support this, then new archive*
>> *# records will be generated in software.*
>> # Set the following to "software" to force software record generation.
>> *#*record_generation = hardware
>> *record_generation = software*
>>
>> Log now reports this:
>>
>> Aug 16 09:56:18 raspberrypi weewx[2791]: engine: *Record generation will
>> be attempted in 'software'*
>>
>> No change in behavior -- still getting data, storing records and
>> generating web pages -- but no publish...
>>
>> I'm wondering if something in all the linux updates (not updated for
>> several months) changed -- python or some library weewx uses...
>>
>>
>> On Thursday, August 16, 2018 at 8:15:00 AM UTC-4, gjr80 wrote:
>>>
>>> Let's try that again.
>>>
>>> Hi,
>>>
>>> Any reason you are using hardware record generation? As far as I am
>>> aware the AcuRite stations only emit loop packets (in fact the AcuRite
>>> driver does not have a genArchiveRecords() method necessary to generate
>>> archive records from the hardware). Suggest you try setting
>>> record_generation = software under [StdArchive] in weewx.conf. Once you
>>> make  the change you will need to restart weeWX.
>>>
>>> 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.

[weewx-user] Re: after raspbian and weewx updates, weewx is still collecting data but stopped publishing to CWOP and Wunderground

[Michael Gray]

I have found/fixed my problem!As I suspected, it was nothing to do with 
weewx per se...   Somehow, my DNS config (resolv.conf etc.) was changed
so my Pi was not resolving hostnames.   This caused weewx rest code not to 
resolve urls needed for posting to public servers:

./weewx/restx.py:rf_url = 
"http://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
./weewx/restx.py:pws_url = 
"http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
./weewx/restx.py:default_servers = ['cwop.aprs.net:14580', 
'cwop.aprs.net:23']

Once I got name resolution back on the rails, weewx publishing started 
working.

I'm a little surprised that with all the error checking in the code, weewx 
was silent on the issue of not being able to resolve the hostnames in the 
URLs
upon which it depends -- nothing about GET failing or anything...

It looks like the except's on the try's to connect to the servers could use 
some more generic error catching -- I might give it a go but my python foo 
is not strong...

Would a bug report be in order here?  I know this wasn't weewx fault per 
se, but had there been an error like "unknown host", I would have probably 
found the
name resolution problem quickly... 

Thanks to all who looked at my post and sent along their thoughts -- great 
community here!


On Thursday, August 16, 2018 at 10:02:34 AM UTC-4, Michael Gray wrote:
>
> It's always said that -- I never explicitly requested "hardware 
> generation" -- I'll try adding  record_generation = software   explicitly
>
> last restart before "upgrade" when all was well:Aug 14 15:17:11 
> raspberrypi weewx[654]: engine: Record generation will be attempted in 
> 'hardware'
> post-upgrade:Aug 
> 15 22:01:18 raspberrypi weewx[29842]: engine: Record generation will be 
> attempted in 'hardware'
>
> hardware is the default and comments suggest it will use hardware in 
> devices that support it -- software if not...But I've added the 
> following:
>
> # If possible, new archive records are downloaded from the station
> # hardware. *If the hardware does not support this, then new archive*
> *# records will be generated in software.*
> # Set the following to "software" to force software record generation.
> *#*record_generation = hardware
> *record_generation = software*
>
> Log now reports this:
>
> Aug 16 09:56:18 raspberrypi weewx[2791]: engine: *Record generation will 
> be attempted in 'software'*
>
> No change in behavior -- still getting data, storing records and 
> generating web pages -- but no publish...
>
> I'm wondering if something in all the linux updates (not updated for 
> several months) changed -- python or some library weewx uses...
>
>
> On Thursday, August 16, 2018 at 8:15:00 AM UTC-4, gjr80 wrote:
>>
>> Let's try that again.
>>
>> Hi,
>>
>> Any reason you are using hardware record generation? As far as I am aware 
>> the AcuRite stations only emit loop packets (in fact the AcuRite driver 
>> does not have a genArchiveRecords() method necessary to generate archive 
>> records from the hardware). Suggest you try setting record_generation = 
>> software under [StdArchive] in weewx.conf. Once you make  the change you 
>> will need to restart weeWX.
>>
>> Gary
>>
>>

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

Re: [weewx-user] Re: C84612 with GW1000U gateway

[Tony McConnell]

GAS utility is to change network settings on the bridge device. It was
created by LaCrosse specifically for the bridge. Should be able to find the
download with a quick Google.

On Tue, Aug 14, 2018, 10:51 PM Charlie Huang  wrote:

> what's the GAS utility? i'm pretty on this step. need some help.
>
> On Tuesday, January 10, 2017 at 10:13:16 AM UTC+8, Tony McConnell wrote:
>>
>> I am having trouble configuring weewx to grab data from my GW1000U
>> gateway and C84612 weather station. I have installed weewx to an Ubuntu
>> Server (fresh install of ubuntu I might add), installed the driver from
>> this , configured
>> weewx using the same settings as mentioned in "Example: GW1000U" and set
>> the proxy on the GAS to the same address as my server. Not really sure
>> where to go from there because when I run
>>
>> sudo weewxd weewx.conf
>>
>> nothing is displayed on the console. Even tried with -r argument with no
>> luck.
>>
>> Not sure what I'm missing, any advice?
>>
>> Thanks
>>
> --
> 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/W6z-3aF_PQA/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

[weewx-user] Re: Degrees measurement in exact figures

[Antonis Katsonis]

If archive_interval is set to 10 minutes, the record generation set in 
software, when will the weewx request new packets from the console?
Every 10 minutes or every 2.5 seconds? ( 2.5 sec is the update interval 
between console and ISS )
The type of packets will be archive record or loop packet or both?

-- 
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: Degrees measurement in exact figures

[Antonis Katsonis]

If archive records is set to 10 minutes, the record generation set in 
software, when will the weewx request new packets from the console?
Every 10 minutes or every 2.5 seconds? ( 2.5 sec is the update interval 
between console and ISS )
The type of packets will be archive record or loop packet or both?

-- 
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: after raspbian and weewx updates, weewx is still collecting data but stopped publishing to CWOP and Wunderground

[Michael Gray]

It's always said that -- I never explicitly requested "hardware generation" 
-- I'll try adding  record_generation = software   explicitly

last restart before "upgrade" when all was well:Aug 14 15:17:11 
raspberrypi weewx[654]: engine: Record generation will be attempted in 
'hardware'
post-upgrade:Aug 15 
22:01:18 raspberrypi weewx[29842]: engine: Record generation will be 
attempted in 'hardware'

hardware is the default and comments suggest it will use hardware in 
devices that support it -- software if not...But I've added the 
following:

# If possible, new archive records are downloaded from the station
# hardware. *If the hardware does not support this, then new archive*
*# records will be generated in software.*
# Set the following to "software" to force software record generation.
*#*record_generation = hardware
*record_generation = software*

Log now reports this:

Aug 16 09:56:18 raspberrypi weewx[2791]: engine: *Record generation will be 
attempted in 'software'*

No change in behavior -- still getting data, storing records and generating 
web pages -- but no publish...

I'm wondering if something in all the linux updates (not updated for 
several months) changed -- python or some library weewx uses...


On Thursday, August 16, 2018 at 8:15:00 AM UTC-4, gjr80 wrote:
>
> Let's try that again.
>
> Hi,
>
> Any reason you are using hardware record generation? As far as I am aware 
> the AcuRite stations only emit loop packets (in fact the AcuRite driver 
> does not have a genArchiveRecords() method necessary to generate archive 
> records from the hardware). Suggest you try setting record_generation = 
> software under [StdArchive] in weewx.conf. Once you make  the change you 
> will need to restart weeWX.
>
> Gary
>
>

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

Re: [weewx-user] after raspbian and weewx updates, weewx has stopped publishing to wunderground and CWOP

[Michael Gray]

Running in the foreground (sudo weewxd /etc/weewx/weewx.conf) -- I only see 
LOOP and REC messages -- nothing about attempting to publish anything...

These are the only config diffs between pre (working) and post (no publish) 
upgrade:

mgray@raspberrypi:/etc/weewx $* diff weewx.conf-3.7.1 weewx.conf*
11,12c11
< debug = 0
---
> debug = 1
21c20
< version = 3.7.1
---
> version = 3.8.0




Here's the whole StdRESTfull section:

[StdRESTful]

[[StationRegistry]]
# To register this weather station with weewx, set this to true
register_this_station = false

[[AWEKAS]]
# This section is for configuring posts to AWEKAS.

# If you wish to do this, set the option 'enable' to true,
# and specify a username and password.
enable = false
username = replace_me
password = replace_me

[[CWOP]]
# This section is for configuring posts to CWOP.

# If you wish to do this, set the option 'enable' to true,
# and specify the station ID (e.g., CW1234).
enable = true
station = DW7229
#   post_interval = 600
post_interval = 300

# If this is an APRS (radio amateur) station, uncomment
# the following and replace with a passcode (e.g., 12345).
#passcode = replace_me (APRS stations only)

[[PWSweather]]
# This section is for configuring posts to PWSweather.com.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
enable = false
station = KNHHAMPS9
password = 

[[WOW]]
# This section is for configuring posts to WOW.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
enable = false
station = replace_me
password = replace_me

[[Wunderground]]
# This section is for configuring posts to the Weather Underground.

# If you wish to do this, set the option 'enable' to true,
# and specify a station (e.g., 'KORHOODR3') and password.
enable = true
station = KNHHAMPS9
password = 

# Set the following to True to have weewx use the WU "Rapidfire"
# protocol. Not all hardware can support it. See the User's Guide.
rapidfire = False


On Thursday, August 16, 2018 at 9:06:11 AM UTC-4, Thomas Keffer wrote:
>
> That all looks normal to me as well.
>
> Take a look at the [StdRESTful] section of your weewx.conf configuration 
> file. Did anything get mangled by the upgrade process? Is the option 
> "log_success" set to false? You can post the section here after obscuring 
> any passwords.
>
> -tk
>
> On Thu, Aug 16, 2018 at 4:30 AM Michael Gray  > wrote:
>
>> Last night, I performed routine Rapbian (Jessie) updates to my RaspBerry 
>> Pi and also updated weewx from 3.7.1-1 to 3.8.0.1 and after the updates,
>> weewx has stopped publishing data to CWOP and Wunderground -- I'm still 
>> getting data from my (Acurite) weather station which are going into the
>> database, creating graphs etc.  --  it seems to be just the publishing 
>> part that's stopped.  I enabled debug (debug=1) in config file but don't 
>> see any
>> errors -- just not publishing -- I'd appreciate any guidance in debugging 
>> this...
>>
>> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using configuration file 
>> /etc/weewx/weewx.conf
>> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Loading station type 
>> AcuRite (weewx.drivers.acurite)
>> *Aug 15 23:25:24 raspberrypi weewx[1648]: acurite: driver version is 0.24*
>> Aug 15 23:25:24 raspberrypi weewx[1648]: acurite: R2 will be decoded 
>> using sensor constants
>> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: StdConvert target unit 
>> is 0x1
>> Aug 15 23:25:24 raspberrypi weewx[1648]: 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_ha
>> rdware, ET=prefer_hardware, altimeter=prefer_hardware, 
>> cloudbase=prefer_hardware
>> Aug 15 23:25:24 raspberrypi weewx[1648]: wxcalculate: The following 
>> algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
>> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Archive will use data 
>> binding wx_binding
>> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Record generation will 
>> be attempted in 'hardware'
>> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using archive interval 
>> of 300 seconds (specified in weewx configuration)
>> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using binding 
>> 'wx_binding' to database 'weewx.sdb'
>> Aug 15 23:25:24 raspberrypi weewx[1648]: manager: Starting backfill of 
>> daily summaries
>> Aug 

[weewx-user] Re: RainMachine API for weewx- Driver Wanted/Needed

[G Hammer]

QPF- Quantitative Precipitation Forecast NOAA QPF Page 

minrh & maxrh- Min/Max relative humidity.


On Thursday, August 16, 2018 at 7:59:41 AM UTC-4, Antonis Katsonis wrote:
>
> What is the qpf, minrh and maxrh?
>

-- 
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: Degrees measurement in exact figures

[Andrew Milner]

The VP2 archive record only contains the 16 points - so that is what you 
should get when you select hardware record generation.  There was a bug 
introduced at 3.7 which meant weewx was overriding the hardware value even 
if hardware was selected.  This is what Thomas has corrected if am 
understanding correctly.

If you select sw generation then weewx can perform its magic from the loop 
data and give you a different (possibly more accurate) value

I think I have understood this correctly

ie if you select hardware records you will only ever get the 16 compass 
points in the archive record.



On Thursday, 16 August 2018 16:26:38 UTC+3, Antonis Katsonis wrote:
>
> The test was done with 2 different PC's.
> The first with version 3.4.0 and the second with version 3.8.0.
>
> The results have been attached in 4 jpg files.
> 2 files are with hardware record generation and the other 2 with software 
> record generation.
>
> The problem occurs only in version 3.4.0 with hardware record generation.
> I tried editing the /bin/weewx/accum.py file based on commit 2b5764 
> 
>  
> and the problem still exists.
>
> It seems as if the program is trying to show degrees from 16 points of the 
> compass.
>
> What else can be wrong?
>
> If the console supports archive records, what is the difference when the 
> weewx.conf is in hardware record generation or the weewx.conf is in 
> software record generation?
>

-- 
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] after raspbian and weewx updates, weewx has stopped publishing to wunderground and CWOP

[Thomas Keffer]

That all looks normal to me as well.

Take a look at the [StdRESTful] section of your weewx.conf configuration
file. Did anything get mangled by the upgrade process? Is the option
"log_success" set to false? You can post the section here after obscuring
any passwords.

-tk

On Thu, Aug 16, 2018 at 4:30 AM Michael Gray  wrote:

> Last night, I performed routine Rapbian (Jessie) updates to my RaspBerry
> Pi and also updated weewx from 3.7.1-1 to 3.8.0.1 and after the updates,
> weewx has stopped publishing data to CWOP and Wunderground -- I'm still
> getting data from my (Acurite) weather station which are going into the
> database, creating graphs etc.  --  it seems to be just the publishing
> part that's stopped.  I enabled debug (debug=1) in config file but don't
> see any
> errors -- just not publishing -- I'd appreciate any guidance in debugging
> this...
>
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using configuration file
> /etc/weewx/weewx.conf
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Loading station type
> AcuRite (weewx.drivers.acurite)
> *Aug 15 23:25:24 raspberrypi weewx[1648]: acurite: driver version is 0.24*
> Aug 15 23:25:24 raspberrypi weewx[1648]: acurite: R2 will be decoded using
> sensor constants
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: StdConvert target unit is
> 0x1
> Aug 15 23:25:24 raspberrypi weewx[1648]: 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_ha
> rdware, ET=prefer_hardware, altimeter=prefer_hardware,
> cloudbase=prefer_hardware
> Aug 15 23:25:24 raspberrypi weewx[1648]: wxcalculate: The following
> algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Archive will use data
> binding wx_binding
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Record generation will be
> attempted in 'hardware'
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using archive interval of
> 300 seconds (specified in weewx configuration)
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using binding
> 'wx_binding' to database 'weewx.sdb'
> Aug 15 23:25:24 raspberrypi weewx[1648]: manager: Starting backfill of
> daily summaries
> Aug 15 23:25:24 raspberrypi weewx[1648]: restx: StationRegistry:
> Registration not requested.
> *Aug 15 23:25:24 raspberrypi weewx[1648]: restx: Wunderground-PWS: Data
> for station KNHHAMPS9 will be posted*
> Aug 15 23:25:24 raspberrypi weewx[1648]: restx: PWSweather: Posting not
> enabled.
> *Aug 15 23:25:24 raspberrypi weewx[1648]: restx: CWOP: Data for station
> DW7229 will be posted*
> Aug 15 23:25:24 raspberrypi weewx[1648]: restx: WOW: Posting not enabled.
> Aug 15 23:25:24 raspberrypi weewx[1648]: restx: AWEKAS: Posting not
> enabled.
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Starting up weewx version
> 3.8.0
> Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Starting main packet loop.
> Aug 15 23:30:25 raspberrypi weewx[1648]: manager: Added record 2018-08-15
> 23:30:00 EDT (1534390200) to database 'weewx.sdb'
> Aug 15 23:30:25 raspberrypi weewx[1648]: manager: Added record 2018-08-15
> 23:30:00 EDT (1534390200) to daily summary in 'weewx.sdb'
> Aug 15 23:30:29 raspberrypi weewx[1648]: cheetahgenerator: Generated 14
> files for report StandardReport in 3.95 seconds
> Aug 15 23:30:30 raspberrypi weewx[1648]: imagegenerator: Generated 12
> images for StandardReport in 0.77 seconds
> Aug 15 23:30:30 raspberrypi weewx[1648]: copygenerator: copied 9 files to
> /var/www/html/weewx
> Aug 15 23:35:20 raspberrypi weewx[1648]: manager: Added record 2018-08-15
> 23:35:00 EDT (1534390500) to database 'weewx.sdb'
> Aug 15 23:35:20 raspberrypi weewx[1648]: manager: Added record 2018-08-15
> 23:35:00 EDT (1534390500) to daily summary in 'weewx.sdb'
> Aug 15 23:35:22 raspberrypi weewx[1648]: cheetahgenerator: Generated 14
> files for report StandardReport in 1.65 seconds
> Aug 15 23:35:22 raspberrypi weewx[1648]: imagegenerator: Generated 12
> images for StandardReport in 0.76 seconds
> Aug 15 23:35:22 raspberrypi weewx[1648]: copygenerator: copied 0 files to
> /var/www/html/weewx
> Aug 15 23:40:27 raspberrypi weewx[1648]: manager: Added record 2018-08-15
> 23:40:00 EDT (1534390800) to database 'weewx.sdb'
> Aug 15 23:40:27 raspberrypi weewx[1648]: manager: Added record 2018-08-15
> 23:40:00 EDT (1534390800) to daily summary in 'weewx.sdb'
> Aug 15 23:40:28 raspberrypi weewx[1648]: cheetahgenerator: Generated 14
> files for report StandardReport in 1.66 seconds
> Aug 15 23:40:29 raspberrypi weewx[1648]: imagegenerator: Generated 12
> images for StandardReport in 0.76 seconds
> Aug 15 23:40:29 raspberrypi weewx[1648]: copygenerator: copied 0 files to
> /var/www/html/weewx

[weewx-user] after raspbian and weewx updates, weewx is still collecting data but stopped publishing to CWOP and Wunderground

[gjr80]

Let's try that again.

Hi,

Any reason you are using hardware record generation? As far as I am aware the 
AcuRite stations only emit loop packets (in fact the AcuRite driver does not 
have a genArchiveRecords() method necessary to generate archive records from 
the hardware). Suggest you try setting record_generation = software under 
[StdArchive] in weewx.conf. Once you make  the change you will need to restart 
weeWX.

Gary

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

[weewx-user] after raspbian and weewx updates, weewx is still collecting data but stopped publishing to CWOP and Wunderground

[gjr80]

Hi,

Any reason you are using hardware record generation? As far as I am aware the 
AcuRite station only emit loop packets.(in fact the AcuRite driver does have a 
genArchiveRecords() method to generate the necessary archive records from 
hardware). Suggest you try setting record_generation = software under 
[StdArchive] in weewx.conf. Once you make  the change you will need to restart 
weeWX.

Gary

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

[weewx-user] Re: RainMachine API for weewx- Driver Wanted/Needed

[Antonis Katsonis]

What is the qpf, minrh and maxrh?

-- 
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] after raspbian and weewx updates, weewx is still collecting data but stopped publishing to CWOP and Wunderground

[Michael Gray]

Last night, I performed routine Rapbian (Jessie) updates to my RaspBerry Pi 
and also updated weewx from 3.7.1-1 to 3.8.0.1 and after the updates,
weewx has stopped publishing data to CWOP and Wunderground -- I'm still 
getting data from my (Acurite) weather station which are going into the
database, creating graphs etc.  --  it seems to be just the publishing part 
that's stopped.  I enabled debug (debug=1) in config file but don't see any
errors -- just not publishing -- I've tried downgrading weewx back to 
3.7.1-1 to no avail -- I have not attempted to revert all the raspbian 
updates yet.
 
I'd appreciate any advice as to how to go about debugging this -- thanks in 
advance!

*weewx.log*

Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using configuration file 
/etc/weewx/weewx.conf
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Loading station type 
AcuRite (weewx.drivers.acurite)
Aug 15 23:25:24 raspberrypi weewx[1648]: acurite: driver version is 0.24
Aug 15 23:25:24 raspberrypi weewx[1648]: acurite: R2 will be decoded using 
sensor constants
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: StdConvert target unit is 
0x1
Aug 15 23:25:24 raspberrypi weewx[1648]: 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_ha
rdware, ET=prefer_hardware, altimeter=prefer_hardware, 
cloudbase=prefer_hardware
Aug 15 23:25:24 raspberrypi weewx[1648]: wxcalculate: The following 
algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Archive will use data 
binding wx_binding
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Record generation will be 
attempted in 'hardware'
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using archive interval of 
300 seconds (specified in weewx configuration)
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using binding 'wx_binding' 
to database 'weewx.sdb'
Aug 15 23:25:24 raspberrypi weewx[1648]: manager: Starting backfill of 
daily summaries
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: StationRegistry: 
Registration not requested.
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: Wunderground-PWS: Data for 
station KNHHAMPS9 will be posted
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: PWSweather: Posting not 
enabled.
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: CWOP: Data for station 
DW7229 will be posted
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: WOW: Posting not enabled.
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: AWEKAS: Posting not enabled.
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Starting up weewx version 
3.8.0
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Starting main packet loop.
Aug 15 23:30:25 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:30:00 EDT (1534390200) to database 'weewx.sdb'
Aug 15 23:30:25 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:30:00 EDT (1534390200) to daily summary in 'weewx.sdb'
Aug 15 23:30:29 raspberrypi weewx[1648]: cheetahgenerator: Generated 14 
files for report StandardReport in 3.95 seconds
Aug 15 23:30:30 raspberrypi weewx[1648]: imagegenerator: Generated 12 
images for StandardReport in 0.77 seconds
Aug 15 23:30:30 raspberrypi weewx[1648]: copygenerator: copied 9 files to 
/var/www/html/weewx
Aug 15 23:35:20 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:35:00 EDT (1534390500) to database 'weewx.sdb'
Aug 15 23:35:20 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:35:00 EDT (1534390500) to daily summary in 'weewx.sdb'
Aug 15 23:35:22 raspberrypi weewx[1648]: cheetahgenerator: Generated 14 
files for report StandardReport in 1.65 seconds
Aug 15 23:35:22 raspberrypi weewx[1648]: imagegenerator: Generated 12 
images for StandardReport in 0.76 seconds
Aug 15 23:35:22 raspberrypi weewx[1648]: copygenerator: copied 0 files to 
/var/www/html/weewx
Aug 15 23:40:27 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:40:00 EDT (1534390800) to database 'weewx.sdb'
Aug 15 23:40:27 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:40:00 EDT (1534390800) to daily summary in 'weewx.sdb'
Aug 15 23:40:28 raspberrypi weewx[1648]: cheetahgenerator: Generated 14 
files for report StandardReport in 1.66 seconds
Aug 15 23:40:29 raspberrypi weewx[1648]: imagegenerator: Generated 12 
images for StandardReport in 0.76 seconds
Aug 15 23:40:29 raspberrypi weewx[1648]: copygenerator: copied 0 files to 
/var/www/html/weewx
Aug 15 23:45:15 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:45:00 EDT (1534391100) to database 'weewx.sdb'
Aug 15 23:45:15 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:45:00 EDT (1534391100) to daily summary in 'weewx.sdb'
Aug 15 23:45:17 raspberrypi 

[weewx-user] after raspbian and weewx updates, weewx has stopped publishing to wunderground and CWOP

[Michael Gray]

Last night, I performed routine Rapbian (Jessie) updates to my RaspBerry Pi 
and also updated weewx from 3.7.1-1 to 3.8.0.1 and after the updates,
weewx has stopped publishing data to CWOP and Wunderground -- I'm still 
getting data from my (Acurite) weather station which are going into the
database, creating graphs etc.  --  it seems to be just the publishing part 
that's stopped.  I enabled debug (debug=1) in config file but don't see any
errors -- just not publishing -- I'd appreciate any guidance in debugging 
this...

Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using configuration file 
/etc/weewx/weewx.conf
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Loading station type 
AcuRite (weewx.drivers.acurite)
*Aug 15 23:25:24 raspberrypi weewx[1648]: acurite: driver version is 0.24*
Aug 15 23:25:24 raspberrypi weewx[1648]: acurite: R2 will be decoded using 
sensor constants
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: StdConvert target unit is 
0x1
Aug 15 23:25:24 raspberrypi weewx[1648]: 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_ha
rdware, ET=prefer_hardware, altimeter=prefer_hardware, 
cloudbase=prefer_hardware
Aug 15 23:25:24 raspberrypi weewx[1648]: wxcalculate: The following 
algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Archive will use data 
binding wx_binding
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Record generation will be 
attempted in 'hardware'
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using archive interval of 
300 seconds (specified in weewx configuration)
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Using binding 'wx_binding' 
to database 'weewx.sdb'
Aug 15 23:25:24 raspberrypi weewx[1648]: manager: Starting backfill of 
daily summaries
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: StationRegistry: 
Registration not requested.
*Aug 15 23:25:24 raspberrypi weewx[1648]: restx: Wunderground-PWS: Data for 
station KNHHAMPS9 will be posted*
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: PWSweather: Posting not 
enabled.
*Aug 15 23:25:24 raspberrypi weewx[1648]: restx: CWOP: Data for station 
DW7229 will be posted*
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: WOW: Posting not enabled.
Aug 15 23:25:24 raspberrypi weewx[1648]: restx: AWEKAS: Posting not enabled.
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Starting up weewx version 
3.8.0
Aug 15 23:25:24 raspberrypi weewx[1648]: engine: Starting main packet loop.
Aug 15 23:30:25 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:30:00 EDT (1534390200) to database 'weewx.sdb'
Aug 15 23:30:25 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:30:00 EDT (1534390200) to daily summary in 'weewx.sdb'
Aug 15 23:30:29 raspberrypi weewx[1648]: cheetahgenerator: Generated 14 
files for report StandardReport in 3.95 seconds
Aug 15 23:30:30 raspberrypi weewx[1648]: imagegenerator: Generated 12 
images for StandardReport in 0.77 seconds
Aug 15 23:30:30 raspberrypi weewx[1648]: copygenerator: copied 9 files to 
/var/www/html/weewx
Aug 15 23:35:20 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:35:00 EDT (1534390500) to database 'weewx.sdb'
Aug 15 23:35:20 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:35:00 EDT (1534390500) to daily summary in 'weewx.sdb'
Aug 15 23:35:22 raspberrypi weewx[1648]: cheetahgenerator: Generated 14 
files for report StandardReport in 1.65 seconds
Aug 15 23:35:22 raspberrypi weewx[1648]: imagegenerator: Generated 12 
images for StandardReport in 0.76 seconds
Aug 15 23:35:22 raspberrypi weewx[1648]: copygenerator: copied 0 files to 
/var/www/html/weewx
Aug 15 23:40:27 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:40:00 EDT (1534390800) to database 'weewx.sdb'
Aug 15 23:40:27 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:40:00 EDT (1534390800) to daily summary in 'weewx.sdb'
Aug 15 23:40:28 raspberrypi weewx[1648]: cheetahgenerator: Generated 14 
files for report StandardReport in 1.66 seconds
Aug 15 23:40:29 raspberrypi weewx[1648]: imagegenerator: Generated 12 
images for StandardReport in 0.76 seconds
Aug 15 23:40:29 raspberrypi weewx[1648]: copygenerator: copied 0 files to 
/var/www/html/weewx
Aug 15 23:45:15 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:45:00 EDT (1534391100) to database 'weewx.sdb'
Aug 15 23:45:15 raspberrypi weewx[1648]: manager: Added record 2018-08-15 
23:45:00 EDT (1534391100) to daily summary in 'weewx.sdb'
Aug 15 23:45:17 raspberrypi weewx[1648]: cheetahgenerator: Generated 14 
files for report StandardReport in 1.70 seconds
Aug 15 23:45:18 raspberrypi weewx[1648]: imagegenerator: Generated 12