weewx driver for acurite weather stations

[mwall]

folks,

here is a driver for acurite 5in1 weather stations.  it should work with any of the stations that have a usb port, including models 01025, 01035, 01036, 02032, 01057.

https://svn.code.sf.net/p/weewx/code/trunk/bin/weewx/drivers/acurite.py

many, many thanks to dave at 'desert home' for publishing his work

http://www.desert-home.com/

v0.1 will report outside sensor data: outTemp, outHumidity, rain, windSpeed, windDir

it will *not* report inTemp, inHumidity, or pressure

the console must be set to usb mode 3 or mode 4

enjoy!

m

[Andy]

This driver is working here:  http://www.wunderground.com/personal-weather-station/dashboard?ID=KCAROSEV36#history with a 2032 Costco station.   Thanks a bunch for getting this going!  Turned on rapidfire in the Wunderground section earlier today but started losing data.  Just turned that off to see what happens.  

[mwall]

the acurite driver has been updated to v0.5.  it now decodes the inside temperature and pressure from the console.

i *think* the pressure is the sensor pressure, but someone at high altitude should try this driver to verify.

every 18 seconds the driver opens the device, does two reads, then closes the device.  it is not clear whether it would be better to open the device when the driver loads and keep it open.

m

[Andy]

Giving it a try

Jan 14 13:45:37 raspberry-pi weewx[7576]: acurite: driver version is 0.8

[Andy]

signal level graph from default weewx skins is populating too!

[Preston Moulton]

I would love to see a larger write up on how you got this going. I am now trying to get my new weather station up and running. I now have an Acurite station after my ambient 2080 failed to communicate from the remote station. 

[mwall]

On Saturday, January 17, 2015 at 10:07:31 AM UTC-5, Preston Moulton wrote:

I would love to see a larger write up on how you got this going. I am now trying to get my new weather station up and running. I now have an Acurite station after my ambient 2080 failed to communicate from the remote station. 

preston,

the acurite driver is at v0.8.  it still beta quality.  it has been running reliably for me since december 2014, but there are still a few issues and needs to be tested on different types of acurite hardware.  for example, the wind speed calculation is still not correct, and i still need to add some error/bounds checking to the sensor data.

to try it out:

1) download and install weewx, choose the Simulator as station type (see the weewx user guide)

2) download the acurite driver

https://svn.code.sf.net/p/weewx/code/trunk/bin/weewx/drivers/acurite.py

3) copy the acurite driver to your weewx installation

cp acurite.py /home/weewx/bin/weewx/drivers

4) modify your weewx.conf like this:

[Station]
    ...
    station_type = AcuRite
    ...

[AcuRite]
    model = 'AcuRite 01036'
    driver = weewx.drivers.acurite

5) start weewx

sudo /home/weewx/bin/weewxd /home/weewx/weewx.conf

m

[Preston Moulton]

The exact station i am using is:

http://www.amazon.com/gp/product/B00NI57C14/ref=oh_aui_search_detailpage?ie=UTF8&psc=1

I have the station set in mode 4

I had done steps 1-3 on my own. I just had not found out exactly what I had needed to do for step 4

it looks like I still am missing something in my setup

Jan 17 12:19:56 raspberrypi weewx[29678]: engine: Terminating weewx version 3.0.1

Jan 17 12:19:59 raspberrypi weewx[29768]: engine: Initializing weewx version 3.0.1

Jan 17 12:19:59 raspberrypi weewx[29768]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]

Jan 17 12:19:59 raspberrypi weewx[29768]: engine: pid file is /var/run/weewx.pid

Jan 17 12:19:59 raspberrypi weewx[29770]: engine: Using configuration file /etc/weewx/weewx.conf

Jan 17 12:19:59 raspberrypi weewx[29770]: engine: Loading station type AcuRite (weewx.drivers.acurite)

Jan 17 12:20:00 raspberrypi weewx[29770]: acurite: driver version is 0.8

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: StdConvert target unit is 0x1

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Archive will use data binding wx_binding

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Record generation will be attempted in 'hardware'

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Using archive interval of 300 seconds

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Using binding 'wx_binding' to database '/var/lib/weewx/weewx.sdb'

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Starting backfill of daily summaries

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Daily summaries up to date.

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Starting up weewx version 3.0.1

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Starting main packet loop.

Jan 17 12:22:06 raspberrypi weewx[29770]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 17 12:22:34 raspberrypi weewx[29770]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 17 12:23:03 raspberrypi weewx[29770]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 17 12:23:13 raspberrypi weewx[29770]: acurite: Failed attempt 2 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 17 12:23:41 raspberrypi weewx[29770]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

[mwall]

On Saturday, January 17, 2015 at 12:24:50 PM UTC-5, Preston Moulton wrote:

I have the station set in mode 4

yes, the station must be in usb mode 3 or 4.  thank you for noting that.

 

Jan 17 12:20:00 raspberrypi weewx[29770]: engine: Starting main packet loop.

Jan 17 12:22:06 raspberrypi weewx[29770]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 17 12:22:34 raspberrypi weewx[29770]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 17 12:23:03 raspberrypi weewx[29770]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 17 12:23:13 raspberrypi weewx[29770]: acurite: Failed attempt 2 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 17 12:23:41 raspberrypi weewx[29770]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

it looks like everything is working.  do you see data in the standard report?  in the plots?
 
what operating system and system version are you using?

cat /etc/issue

the 'failed attempt x of y' indicates that there are some communication issues between the computer and the weather station console.  in this case, they appear to be non-fatal - the driver is able to recover. 

you might try a different usb cable - use a quality cable, preferably with ferrite cores.  see if there are any sources of electromagnetic interference near the console.

do you mind posting some raw data?  based on the amazon link you posted, you have a 02032 model, and some data samples will help me with the error-checking and decoding.

1) stop weewx

2) run the driver directly for 5 minutes or so

sudo PYTHONPATH=/usr/share/weewx python /usr/share/weewx/weewx/drivers/acurite.py

3) post the output

4) start weewx

m

[Preston Moulton]

I will be happy to pass you any information that you can use for testing. Please feel free to pass me testing scenarios or requests for information and I will do what I can.

I stopped and started weewx again and now it looks to be working.

I am now going to change to using mysql for the database

sudo /etc/init.d/weewx stop

sudo /etc/init.d/weewx start

pi@raspberrypi ~ $ cat /etc/issue

Raspbian GNU/Linux 7 \n \l

pi@raspberrypi ~ $ lsusb -t

1-1.5:1.0: No such file or directory

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M

    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/5p, 480M

        |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M

        |__ Port 5: Dev 8, If 0, Class=HID, Driver=, 1.5M

On Friday, January 9, 2015 at 11:55:37 PM UTC-5, mwall wrote:

[Preston Moulton]

http://www.wunderground.com/personal-weather-station/dashboard?ID=KNYCHAMP3

Change mysql went fine.

[Andy]

I am running two instances of weewx on a raspberry pi.  A 28xx LaCrosse and 2032c AcuRite.  Happened to notice the AcuRite instance had crashed.  Restarted and is working fine.  Here is a bit of syslog before the 18:30 crash

Jan 18 18:20:47 raspberry-pi weewx[16649]: cheetahgenerator: Generated 14 files foreport StandardReport in 16.53 seconds

Jan 18 18:20:47 raspberry-pi weewx[16645]: cheetahgenerator: Generated 14 files for report StandardReport in 16.91 seconds

Jan 18 18:20:55 raspberry-pi weewx[16649]: genimages: Generated 12 images for StandardReport in 7.49 seconds

Jan 18 18:20:55 raspberry-pi weewx[16645]: genimages: Generated 12 images for StandardReport in 7.84 seconds

Jan 18 18:20:58 raspberry-pi weewx[16649]: rsyncupload: rsync'd 26 files (158451 bytes) in 2.84 seconds

Jan 18 18:20:58 raspberry-pi weewx[16645]: rsyncupload: rsync'd 26 files (130176 bytes) in 2.97 seconds

Jan 18 18:25:19 raspberry-pi weewx[16649]: manager: added record 2015-01-18 18:25:00 PST (1421634300) to database '/var/lib/weewx/acurite-weewx.sdb'

Jan 18 18:25:19 raspberry-pi weewx[16649]: manager: added record 2015-01-18 18:25:00 PST (1421634300) to daily summary in '/var/lib/weewx/acurite-weewx.sdb'

Jan 18 18:25:19 raspberry-pi weewx[16649]: acurite: unknown data string with length 7

Jan 18 18:25:19 raspberry-pi weewx[16649]: acurite: 02 00 00 80 00 00 00

Jan 18 18:25:20 raspberry-pi weewx[16649]: restx: Wunderground-PWS: Published record 2015-01-18 18:25:00 PST (1421634300)

Jan 18 18:25:29 raspberry-pi weewx[16649]: cheetahgenerator: Generated 14 files for report StandardReport in 8.82 seconds

Jan 18 18:25:31 raspberry-pi weewx[16645]: manager: added record 2015-01-18 18:25:00 PST (1421634300) to database '/var/lib/weewx/ws28xx-weewx.sdb'

Jan 18 18:25:31 raspberry-pi weewx[16645]: manager: added record 2015-01-18 18:25:00 PST (1421634300) to daily summary in '/var/lib/weewx/ws28xx-weewx.sdb'

Jan 18 18:25:31 raspberry-pi weewx[16645]: restx: Wunderground-PWS: Published record 2015-01-18 18:25:00 PST (1421634300)

Jan 18 18:25:31 raspberry-pi weewx[16645]: restx: PWSWeather: Published record 2015-01-18 18:25:00 PST (1421634300)

Jan 18 18:25:34 raspberry-pi weewx[16649]: genimages: Generated 12 images for StandardReport in 5.86 seconds

Jan 18 18:25:38 raspberry-pi weewx[16649]: acurite: Failed attempt 1 of 10 to get LOOP data: could not detach kernel driver from interface 0: No data available

Jan 18 18:25:38 raspberry-pi weewx[16649]: rsyncupload: rsync'd 26 files (158754 bytes) in 3.34 seconds

Jan 18 18:25:42 raspberry-pi weewx[16645]: cheetahgenerator: Generated 14 files for report StandardReport in 10.05 seconds

Jan 18 18:25:46 raspberry-pi weewx[16645]: genimages: Generated 12 images for StandardReport in 3.95 seconds

Jan 18 18:25:49 raspberry-pi weewx[16645]: rsyncupload: rsync'd 26 files (130446 bytes) in 3.44 seconds

Jan 18 18:30:00 raspberry-pi weewx[16649]: engine: Caught unrecoverable exception in engine:

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****  [priority,] message string

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****  Traceback (most recent call last):

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****    File "/usr/share/weewx/weewx/engine.py", line 840, in main

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****      engine.run()

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****    File "/usr/share/weewx/weewx/engine.py", line 186, in run

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****      for packet in self.console.genLoopPackets():

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 254, in genLoopPackets

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****      with Station() as station:

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 322, in __enter__

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****      self.open()

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 341, in open

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****      logdbg('product: %s' % self.handle.getString(dev.iProduct,30))

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 214, in logdbg

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****      logmsg(syslog.LOG_DEBUG, msg)

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 211, in logmsg

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****      syslog.syslog(level, 'acurite: %s' % msg)

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****  TypeError: [priority,] message string

Jan 18 18:30:00 raspberry-pi weewx[16649]:     ****  Exiting.

[mwall]

On Sunday, January 18, 2015 at 11:48:07 PM UTC-5, Andy wrote:

I am running two instances of weewx on a raspberry pi.  A 28xx LaCrosse and 2032c AcuRite.  Happened to notice the AcuRite instance had crashed.  Restarted and is working fine.  Here is a bit of syslog before the 18:30 crash

andy,

you're getting garbage on the usb.  i'll add more error checking to prevent this in the future.

meanwhile, comment or remove these two lines in acurite.py:

        logdbg('mfr: %s' % self.handle.getString(dev.iManufacturer,30))

        logdbg('product: %s' % self.handle.getString(dev.iProduct,30))

they are supposed to report info about the usb device, but occasionally they return empty strings.  in your case they returned some non-ascii characters.

chaney mistakenly put their name in for iProduct and left iManufacturer blank, so they are not much use anyway.

m

[Andy]

Ok those two lines are commented out.  I will let you know.

The acurite db file is growing much faster than the ws28xx file.  

root@raspberry-pi:~# ls -l /var/lib/weewx

total 83844

-rw-r--r-- 1 root root 82972672 Jan 19 07:05 acurite-weewx.sdb

-rw-r--r-- 1 root root  2876416 Jan 19 07:05 ws28xx-weewx.sdb

[mwall]

On Monday, January 19, 2015 at 10:10:25 AM UTC-5, Andy wrote:

The acurite db file is growing much faster than the ws28xx file.  

root@raspberry-pi:~# ls -l /var/lib/weewx

total 83844

-rw-r--r-- 1 root root 82972672 Jan 19 07:05 acurite-weewx.sdb

-rw-r--r-- 1 root root  2876416 Jan 19 07:05 ws28xx-weewx.sdb

that is odd.

have you extended the schema?

are you using a very small archive interval?

how many records are in the 'archive' table of each database?

sqlite3 /var/lib/weewx/acurite-weewx.sdb

sqlite> select count(*) from archive;

m 

[Andy]

I will compare the records being put into the two sdb's.and report back

356670 archive records for acurite

archive_interval = 300

14634 archive records for ws28xx

archive_interval = 300

[Andy]

acurite records have more data

root@raspberry-pi:~# sqlite3 /var/lib/weewx/ws28xx-weewx.sdb 

SQLite version 3.7.13 2012-06-11 02:05:22

sqlite> select * from archive limit 2 ;

1417737540|1|1|30.0494518848096|29.923213230951|30.0421935432847|68.0|65.84|69.0|74.0|0.0||0.0|||0.0|57.3139304760511|65.84|65.84|||||||||||||||||||||||||||||||||

1417737600|1|1|30.0375886981199|29.9113998818665|30.0303393311693|68.0|65.84|69.0|74.0|0.22369362912|180.0|1.34216177472|180.0|0.0|0.0|57.3139304760511|65.84|65.84|||||||||||||||||||||||||||||||||

On Monday, January 19, 2015 at 10:25:30 AM UTC-8, Andy wrote:root@raspberry-pi:~# sqlite3 /var/lib/weewx/acurite-weewx.sdb 

SQLite version 3.7.13 2012-06-11 02:05:22

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite> select * from archive limit 2 ;

300|1|5|31.0999833361536|31.0999833361536|31.0911243361536|63.0003332719296|32.5806569228455|29.9993334561408|79.9995000846084|8.33192319441587e-05|359.994601072788|0.000297233794034568|359.991082986179|0.0|0.0|27.1079695493086|32.5806569228455|32.5806569228455||239.916105914468|3.35882548280256||||||||||||||||||||||||||||||

600|1|5|31.0998756410106|31.0998756410106|31.0910166410106|63.0024870012634|32.3790937588486|29.9950259974731|79.996269230318|0.000621794947001816|359.974159954299|0.00130563913997506|359.960830825801|0.0|0.0|26.9105448143657|32.3790937588486|32.3790937588486||222.297383758816|3.11216337262342||||||||||||||||||||||||||||||

[mwall]

andy,

the timestamps in your acurite database  do not look right.  you've got valus of 300 and 600 - much too small for a valid timestamp (unless you started collecting data in january 1970).

are you running anything else that might be writing to the acurite database?

check the log file to see what is going on.

run weewx directly to verify the data in LOOP and REC coming from the station.

m

[Andy]

see answers inline

On Monday, January 19, 2015 at 11:11:13 AM UTC-8, mwall wrote:

andy,

the timestamps in your acurite database  do not look right.  you've got valus of 300 and 600 - much too small for a valid timestamp (unless you started collecting data in january 1970).

Perhaps an NTP issue on the first raspberry pi which ran the single instance of weewx for acurite.  Also during startup before NTP gets the clock synchronized.   Deleted the "old" records in the acurite db. Timestamps were now sensible with the first record time stamp of 12/13/2014, 6:20:00 PM GMT-8:00.  However I did not start the acurite data collection till January 12 of this year. Maybe when copying/renaming db's got the wrong one.  

renamed the acurite db and started a new one.

1421724600|1|5|30.2279855156649|30.1033668044891|30.2164272311936|63.2171428571429|48.625||99.0|0.0|90.0|0.0||0.0|0.0|48.3564418768114|48.625|48.625|||||||||||||||||||||1.0|||||||||||0.0|

1421724900|1|5|30.22799165698|30.1033668044891|30.2164272311936|63.22|48.6||99.0|0.0|90.0|0.0|157.5|0.0|0.0|48.331472079414|48.6|48.6|||||||||||||||||||||1.0|||||||||||0.0|

1421725200|1|5|30.231319506271|30.1066482903459|30.2197194770844|63.21|48.4666666666667||99.0|0.0|90.0|0.0|180.0|0.0|0.0|48.1982997723202|48.4666666666667|48.4666666666667|||||||||||||||||||||1.0|||||||||||0.0|

are you running anything else that might be writing to the acurite database?

No I don't think so.  I typo'd my two instance init script and had multiple instances of acurite and ws28xx running at the same time Thursday of last week.  The acurite db was large when I copied it from the single instance raspberry pi. 

 

check the log file to see what is going on. Logs show db writes every five minutes:

Jan 19 17:20:28 raspberry-pi weewx[22320]: manager: added record 2015-01-19 17:20:00 PST (1421716800) to database '/var/lib/weewx/ws28xx-weewx.sdb'

Jan 19 17:20:28 raspberry-pi weewx[22320]: manager: added record 2015-01-19 17:20:00 PST (1421716800) to daily summary in '/var/lib/weewx/ws28xx-weewx.sdb'

Jan 19 17:20:32 raspberry-pi weewx[22324]: manager: added record 2015-01-19 17:20:00 PST (1421716800) to database '/var/lib/weewx/acurite-weewx.sdb'

Jan 19 17:20:32 raspberry-pi weewx[22324]: manager: added record 2015-01-19 17:20:00 PST (1421716800) to daily summary in '/var/lib/weewx/acurite-weewx.sdb'

Jan 19 17:25:21 raspberry-pi weewx[22324]: manager: added record 2015-01-19 17:25:00 PST (1421717100) to database '/var/lib/weewx/acurite-weewx.sdb'

Jan 19 17:25:21 raspberry-pi weewx[22324]: manager: added record 2015-01-19 17:25:00 PST (1421717100) to daily summary in '/var/lib/weewx/acurite-weewx.sdb'

Jan 19 17:25:58 raspberry-pi weewx[22320]: manager: added record 2015-01-19 17:25:00 PST (1421717100) to database '/var/lib/weewx/ws28xx-weewx.sdb'

Jan 19 17:25:59 raspberry-pi weewx[22320]: manager: added record 2015-01-19 17:25:00 PST (1421717100) to daily summary in '/var/lib/weewx/ws28xx-weewx.sdb'

 

run weewx directly to verify the data in LOOP and REC coming from the station.

root@raspberry-pi:~# PYTHONPATH=/usr/share/weewx python /usr/share/weewx/weewx/drivers/acurite.py

2015-01-19 18:16:10 PST (1421720170) 01 02 c0 71 00 08 0b 15 03 ff {'sensor_id': 704, 'windDir': 67.5, 'windSpeed': 0.0, 'sensor_battery': 255, 'rssi': 3, 'rain_total': 0.5334, 'channel': 3}

2015-01-19 18:16:10 PST (1421720170) 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8f 9f 4c b8 {'pressure': 1019.5, 'inTemp': 17.1}

2015-01-19 18:16:28 PST (1421720188) 01 02 c0 78 00 07 1f 5f 03 ff {'sensor_id': 704, 'outHumidity': 95, 'outTemp': 11.5, 'windSpeed': 0.0, 'sensor_battery': 255, 'rssi': 3, 'channel': 3}

2015-01-19 18:16:28 PST (1421720188) 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8f 9f 4c b8 {'pressure': 1019.5, 'inTemp': 17.1}

2015-01-19 18:16:46 PST (1421720206) 01 02 c0 71 00 08 0b 15 03 ff {'sensor_id': 704, 'windDir': 67.5, 'windSpeed': 0.0, 'sensor_battery': 255, 'rssi': 3, 'rain_total': 0.5334, 'channel': 3}

2015-01-19 18:16:46 PST (1421720206) 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8f 9f 4c b8 {'pressure': 1019.5, 'inTemp': 17.1}

Andy

[Bryan Gillespie]

Not sure if I should start a new topic for this, but since it appears to be an issue with the acurite driver or my setup.

Setup

I'm using an Acurite 1036 (5-in1), which is connected via USB (mode-4) to my Synology DiskStation running WeeWx 3.01.  It uses the SQLite driver to write to the DB 

Oddity

I get the following error in /var/log/messages 2-3 times per day:

Jan 20 18:04:01 DiskStation weewx[22763]: acurite: unknown R1 flavor ff
Jan 20 18:04:01 DiskStation weewx[22763]: acurite: 01 ff ff ff ff ff ff ff ff 00
Jan 20 18:11:53 DiskStation weewx[22763]: acurite: unknown R1 flavor ff
Jan 20 18:11:53 DiskStation weewx[22763]: acurite: 01 ff ff ff ff ff ff ff ff 00
Jan 20 18:14:54 DiskStation weewx[22763]: acurite: unknown R1 flavor ff
Jan 20 18:14:54 DiskStation weewx[22763]: acurite: 01 ff ff ff ff ff ff ff ff 00
Jan 21 05:22:59 DiskStation weewx[22763]: acurite: unknown R1 flavor ff
Jan 21 05:22:59 DiskStation weewx[22763]: acurite: 01 ff ff ff ff ff ff ff ff 00

Perhaps related - sometimes it matches the time of the error, sometimes not - I get a "surprise" amount of rain recorded.  The first instance of rain below is from the time of the first error (18:04:01). The other errors listed above do not trigger a recorded rain event (see graph below).  Additionally, there is no error recorded for the second rain event - the weather was clear without a cloud in the sky.  Perhaps an animal (bird?) landed on the weather station for the second event.

Finally, I'm a complete novice at this and I appreciate all the work that you have done for the Acurite driver. 

Cheers!

Bryan

[mwall]

hi bryan,

welcome to weewx.  and thank you for the feedback about the acurite driver.

On Wednesday, January 21, 2015 at 9:44:31 AM UTC-5, Bryan Gillespie wrote:

Oddity

I get the following error in /var/log/messages 2-3 times per day:

Jan 20 18:04:01 DiskStation weewx[22763]: acurite: unknown R1 flavor ff
Jan 20 18:04:01 DiskStation weewx[22763]: acurite: 01 ff ff ff ff ff ff ff ff 00
Jan 20 18:11:53 DiskStation weewx[22763]: acurite: unknown R1 flavor ff
Jan 20 18:11:53 DiskStation weewx[22763]: acurite: 01 ff ff ff ff ff ff ff ff 00
Jan 20 18:14:54 DiskStation weewx[22763]: acurite: unknown R1 flavor ff
Jan 20 18:14:54 DiskStation weewx[22763]: acurite: 01 ff ff ff ff ff ff ff ff 00
Jan 21 05:22:59 DiskStation weewx[22763]: acurite: unknown R1 flavor ff
Jan 21 05:22:59 DiskStation weewx[22763]: acurite: 01 ff ff ff ff ff ff ff ff 00

those look like R1 messages when the console has not found a 5in1 sensor.  perhaps you are having some rf interference?  or it could be due to solar activity (i am serious).  if it happens only infrequently i would not be concerned.  run logwatch to track it long term.

 

Perhaps related - sometimes it matches the time of the error, sometimes not - I get a "surprise" amount of rain recorded.  

i've seen the spurious rain too.  i also see occasional wind, even when i put the 5in1 in a wind-free testing area.

could you query your database to get the times of all the anomalies, then see if they correspond to the 'unknown flavor' messages?

m

[Bryan Gillespie]

Regarding the 'flavor' messages, I was unable to see a direct correlation with the rain anomalies.  I seem to get between 5-20 of these errors per day.  You mention running 'logwatch'.  I'm not familiar with that, but I'll look it up.

I queried the DB to pull all events where rain was detected (dateTime, rainRate, rain) as well as some odd signal anomalies (rxCheckPercent, outTempBatteryStatus) and may have found a correlation.

If I subtract 4 hours from the database 'unix epoch time' there appears to be a correlation between 

non-standard values in rxCheckPercent (!=1) and outTempBatteryStatus (!=0)

and

misrepresented rain recordings.

In other words each time it was sunny and bright and the sensor reported rain, these values were 'off'.  However when it was raining and assumed to be reporting correctly, these two values (rxCheckPercent and ouTempBatterStatus) report 'normal' (1 & 0, respectively).

I'm assuming this means the rain error is not related to the driver and may be a general Acurite device/communication issue.

In any case, thank you for taking the time to look at this.  I'd be happy to test (or at least try!) any future Acurite driver updates as needed.

[Bryan Gillespie]

Ironically, I just noticed that the weather console notes no rain in the past 48 hours.  However, since the data was written to the DB... :)

[mwall]

folks,

the acurite driver has been updated to v0.10.  changes include:

- check the calibration constants in R2

- check for changes to R2 calibration constants

- check for proper format of R1

- use high nibble of byte 8 instead of byte 9 as battery indicator (still not sure of this)

- require 0x70 in byte 3 of R1 (i am pretty sure this indicates a 5in1 sensor - please let me know if you discover otherwise)

- added debug_raw option to log raw R1 and R2 messages each time they are read

on a 01036 i have been experiencing periodic bogus R1 messages (perhaps once per day) that look similar to those reported by bryan.  this release logs those, does not use the data from them, and continues to collect data.

m

[Andy]

Below are the messages I had yesterday on the 2032c with v0.9.  Loading v0.10 now and we will see what changes.  We have had no rain here so can't really report on that data.  I can drip some water through to test if needed.

root@raspberry-pi:~# grep "DRIVER_VERSION =" /usr/share/weewx/weewx/drivers/acurite.py

DRIVER_VERSION = '0.9'

root@raspberry-pi:~# cat /var/log/syslog.1  | grep acurite | grep -v .sdb

Jan 23 07:36:50 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 07:37:08 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: 14

Jan 23 11:05:24 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 11:05:25 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: 1b

Jan 23 13:43:08 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 13:43:26 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: f6

Jan 23 15:01:24 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 80 00 00 00

Jan 23 15:01:42 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: e1

Jan 23 16:55:30 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 80 00 00 00 00

Jan 23 16:55:48 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: d3

Jan 23 17:00:19 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 80 00 00 00

Jan 23 17:00:37 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: d3

Jan 23 18:00:31 raspberry-pi weewx[27410]: acurite: unknown R1 length 7: 01 02 c0 71 00 08 15

Jan 23 18:12:16 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 18:12:34 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: db

Jan 23 18:40:16 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 18:40:34 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: de

Jan 23 19:56:07 raspberry-pi weewx[27410]: acurite: unknown R1 length 7: 01 02 c0 78 00 06 63

Jan 23 22:14:17 raspberry-pi weewx[27410]: acurite: unknown R1 length 7: 01 12 c0 78 00 46 63

Jan 24 01:54:04 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 24 01:54:22 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: eb

Jan 24 02:25:22 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 24 02:25:40 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: e8

Jan 24 03:52:04 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 24 03:52:22 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: e4

Jan 24 04:48:04 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 80 00 00 00

Jan 24 04:48:22 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: dc

root@raspberry-pi:~# cat /var/log/syslog.1  | grep acurite | grep -v .sdb

Jan 23 07:36:50 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 07:37:08 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: 14

Jan 23 11:05:24 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 11:05:25 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: 1b

Jan 23 13:43:08 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 13:43:26 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: f6

Jan 23 15:01:24 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 80 00 00 00

Jan 23 15:01:42 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: e1

Jan 23 16:55:30 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 80 00 00 00 00

Jan 23 16:55:48 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: d3

Jan 23 17:00:19 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 80 00 00 00

Jan 23 17:00:37 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: d3

Jan 23 18:00:31 raspberry-pi weewx[27410]: acurite: unknown R1 length 7: 01 02 c0 71 00 08 15

Jan 23 18:12:16 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 18:12:34 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: db

Jan 23 18:40:16 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 23 18:40:34 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: de

Jan 23 19:56:07 raspberry-pi weewx[27410]: acurite: unknown R1 length 7: 01 02 c0 78 00 06 63

Jan 23 22:14:17 raspberry-pi weewx[27410]: acurite: unknown R1 length 7: 01 12 c0 78 00 46 63

Jan 24 01:54:04 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 24 01:54:22 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: eb

Jan 24 02:25:22 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 24 02:25:40 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: e8

Jan 24 03:52:04 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 00 00 00 00

Jan 24 03:52:22 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: e4

Jan 24 04:48:04 raspberry-pi weewx[27410]: acurite: unknown R2 length 7: 02 00 00 80 00 00 00

Jan 24 04:48:22 raspberry-pi weewx[27410]: acurite: unknown R1 length 1: dc

Andy

[Andy]

And her is what I have so far

root@raspberry-pi:~/acuriteDriver# tail -fn 260 /var/log/syslog |  grep acurite | grep -v .sdb

Jan 24 12:11:06 raspberry-pi weewx[4660]: engine: Using configuration file /home/weewx/weewx-acurite.conf

Jan 24 12:11:06 raspberry-pi weewx[4660]: engine: Loading station type AcuRite (weewx.drivers.acurite)

Jan 24 12:11:06 raspberry-pi weewx[4660]: acurite: driver version is 0.10

Jan 24 12:20:08 raspberry-pi weewx[4660]: acurite: R1: dodgey data: 01 12 c0 71 00 27 0b 15 03 00

Jan 24 12:21:57 raspberry-pi weewx[4660]: acurite: R1: dodgey data: 01 02 c0 71 00 2a 0b 15 03 00

Jan 24 12:23:45 raspberry-pi weewx[4660]: acurite: R1: unknown: 01 02 c0 00 66 77 59

Jan 24 12:25:52 raspberry-pi weewx[4660]: acurite: R1: unknown: 01 02 71 00 2a 0b 15

Jan 24 12:32:11 raspberry-pi weewx[4660]: acurite: R1: unknown: 01 02 c0 71 00 0b 15

Andy

[mwall]

it looks like you are using channel C.  is that correct?

it looks like your sensor ID is 0x2c0 (704 decimal).  is that correct?

data in the 'dodgey data' messages are suspect because of the trailing 00 - even though the rssi is high (03), the 00 seems to indicate that the console has lost contact with the sensor cluster.  they are also suspect because some of the bytes look scrambled.

the 'unknown' messages are short reads - an R1 message should contain 10 bytes, but those three have only 7 bytes each.

m

[Andy]

Yes it is set to channel C, not sure where sensor id is.  Will find sensor id tomorrow.  Likely will move console closer to sensor tomorrow, so maybe errors will decrease.  Thank you.

[George Lass]

Upgraded to driver version 0.11 of the driver 1/26. Sorry I don't have debug on but I'm having sd card problems on my Raspberry PI so I wanted to keep writes to a minimum. This morning I noticed a gap in my feed to Wunderground at about 5:30 CST and then found lots of dodgey data message in the log file:

root@xbian:/var/log# grep dodgey messages
Jan 26 19:57:29 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 07 47 34 ff 00
Jan 26 20:05:40 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 ff ff ff ff ff ff ff ff 00
Jan 26 20:11:43 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 ff ff ff ff ff ff ff ff 00
Jan 26 20:13:13 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 ff ff ff ff ff ff 8f 86 00
Jan 26 20:19:15 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 ff ff ff ff ff ff ff ff 00
Jan 26 21:49:06 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 07 03 60 03 00
Jan 27 00:26:26 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 31 03 60 03 00
Jan 27 01:42:04 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 47 23 37 03 00
Jan 27 01:51:45 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 41 03 60 03 00
Jan 27 01:55:42 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 27 24 37 03 00
Jan 27 01:59:36 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 53 03 60 03 00
Jan 27 02:03:33 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 47 24 37 03 00
Jan 27 02:07:29 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 43 03 60 03 00
Jan 27 02:11:25 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 27 21 37 03 00
Jan 27 02:15:20 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 41 03 60 03 00
Jan 27 02:15:22 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 41 03 60 03 00
Jan 27 02:18:04 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 57 21 37 03 00
Jan 27 02:45:38 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 57 1b 38 03 00
Jan 27 04:05:11 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 23 03 60 03 00
Jan 27 04:05:29 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 23 03 60 02 00
Jan 27 04:05:31 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 23 03 60 02 00
Jan 27 04:05:49 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 23 03 60 01 00
Jan 27 04:06:07 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 23 03 60 00 00
Jan 27 04:06:25 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 23 03 60 00 00
Jan 27 04:06:43 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 23 03 60 00 00
Jan 27 04:07:01 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 43 03 60 01 00
Jan 27 04:07:19 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 27 09 3c 02 00
Jan 27 04:07:37 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 22 03 60 03 00
Jan 27 05:23:52 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 03 00
Jan 27 05:24:10 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 03 00
Jan 27 05:24:28 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 02 00
Jan 27 05:24:46 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 01 00
Jan 27 05:25:04 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 00 00
Jan 27 05:25:22 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 00 00
Jan 27 05:25:24 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 00 00
Jan 27 05:25:42 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 00 00
Jan 27 05:29:55 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 66 7f 40 00 00
Jan 27 06:14:06 xbian weewx[2488]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 63 03 60 03 00
Jan 27 07:19:15 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 42 03 60 03 00
Jan 27 07:24:07 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 36 65 46 03 00
Jan 27 07:38:25 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 36 64 47 03 00
Jan 27 07:51:51 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 43 03 60 03 00
Jan 27 08:20:44 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 37 0d 40 03 00
Jan 27 08:21:39 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 43 03 60 03 00
Jan 27 08:30:26 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 67 18 3d 03 00
Jan 27 08:30:28 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 67 18 3d 03 00
Jan 27 08:30:46 xbian weewx[2047]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 63 03 60 03 00
Jan 27 18:03:32 xbian weewx[2044]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 0d 03 60 03 00
Jan 27 18:07:30 xbian weewx[2044]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 08 3d 22 03 00
Jan 27 18:11:27 xbian weewx[2044]: acurite: R1: ignoring dodgey data: 01 c1 e3 71 00 0f 03 60 03 00
Jan 27 18:12:58 xbian weewx[2044]: acurite: R1: ignoring dodgey data: 01 c1 e3 78 00 08 38 23 03 00


Hope this helps out.

George

[Mark]

First of all thank you and great work on this (I followed you over from desert-home).  So sorry if this is a newb question but I am trying to get this to running on my mac mini and when it runs nothing happens.  I go and look at the logs and it has the following error:

weewx[1845]: acurite: Unable to claim USB interface 0: [Errno 13] Access denied (insufficient permissions)

 weewx[1845]: acurite: Failed attempt 1 of 10 to get LOOP data: [Errno 13] Access denied (insufficient permissions)

I am running it under Sudo and at a lost.  Any ideas?

-Mark

[mwall]

On Thursday, January 29, 2015 at 10:47:14 PM UTC-5, Mark wrote:

First of all thank you and great work on this (I followed you over from desert-home).  So sorry if this is a newb question but I am trying to get this to running on my mac mini and when it runs nothing happens.  I go and look at the logs and it has the following error:

weewx[1845]: acurite: Unable to claim USB interface 0: [Errno 13] Access denied (insufficient permissions)

 weewx[1845]: acurite: Failed attempt 1 of 10 to get LOOP data: [Errno 13] Access denied (insufficient permissions)

I am running it under Sudo and at a lost.  Any ideas?

mark,

is there anything else running that is claiming the usb interface for the acurite station?

could you try running the driver directly:

sudo PYTHONPATH=/Users/weewx/bin python /Users/weewx/bin/weewx/drivers/acurite.py

i do not know how macosx deals with usb devices, but maybe there is something analogous to the detachKernelDriver for linux systems that must be done on macosx systems...

m

[mwall]

On Thursday, January 29, 2015 at 10:47:14 PM UTC-5, Mark wrote:

First of all thank you and great work on this (I followed you over from desert-home).  So sorry if this is a newb question but I am trying to get this to running on my mac mini and when it runs nothing happens.  I go and look at the logs and it has the following error:

weewx[1845]: acurite: Unable to claim USB interface 0: [Errno 13] Access denied (insufficient permissions)

 weewx[1845]: acurite: Failed attempt 1 of 10 to get LOOP data: [Errno 13] Access denied (insufficient permissions)

I am running it under Sudo and at a lost.  Any ideas?

mark,

macosx automatically loads a HID (human interface device) kernel extension when you plug in the acurite station.  since the kernel has claimed the usb interface, weewx is not able to.  on linux systems we call detachKernelDriver but there is no equivalent on macosx.

apparently you can create a codeless kernel extension - basically an empty kernel extension that matches for your usb device, so that the kernel does not load the generic HID extension.  in this case we would match the vendor and product identifiers for the acurite station.

i have attached a rudimentary codeless kernel extension based on the sample from apple's developer website.  try the steps in the readme and let us know whether it solves the problem.

fwiw, the use of HID for usb devices is pretty common.  when a vendor makes their device advertise itself as a HID, they do not have to write a driver since most operating systems now automatically recognize any HID.  it is a bit disingenuous, however, since a weather station is not really a HID.

m

[Rich Falconburg]

A big Thank You for supporting the AcuRite systems.  I am using the most recent tarball, version (3.1.0).  My first run got the permission issue so I tried it as root.  Here is the syslog info from that attempt.

-------------------------------
Feb  7 09:43:24 telesto weewx[856]: engine: Using configuration file /home/weewx/weewx.conf
Feb  7 09:43:24 telesto weewx[856]: engine: Loading station type AcuRite (weewx.drivers.acurite)
Feb  7 09:43:24 telesto weewx[856]: acurite: driver version is 0.11
Feb  7 09:43:24 telesto weewx[856]: engine: StdConvert target unit is 0x1
Feb  7 09:43:24 telesto weewx[856]: engine: Archive will use data binding wx_binding
Feb  7 09:43:24 telesto weewx[856]: engine: Record generation will be attempted in 'hardware'
Feb  7 09:43:24 telesto weewx[856]: engine: Using archive interval of 300 seconds
Feb  7 09:43:24 telesto weewx[856]: engine: Using binding 'wx_binding' to database 'archive/weewx.sdb'
Feb  7 09:43:24 telesto weewx[856]: engine: Starting backfill of daily summaries
Feb  7 09:43:24 telesto weewx[856]: engine: Daily summaries up to date.
Feb  7 09:43:24 telesto weewx[856]: engine: Starting up weewx version 3.1.0
Feb  7 09:43:24 telesto weewx[856]: engine: Starting main packet loop.
Feb  7 09:43:24 telesto weewx[856]: acurite: Unable to claim USB interface 0: could not set alt intf 0/0: Protocol error
Feb  7 09:43:24 telesto weewx[856]: acurite: Failed attempt 1 of 10 to get LOOP data: could not set alt intf 0/0: Protocol error
Feb  7 09:43:34 telesto weewx[856]: acurite: Unable to claim USB interface 0: could not set alt intf 0/0: Protocol error
Feb  7 09:43:34 telesto weewx[856]: acurite: Failed attempt 2 of 10 to get LOOP data: could not set alt intf 0/0: Protocol error
Feb  7 09:43:45 telesto weewx[856]: acurite: Unable to claim USB interface 0: could not set alt intf 0/0: Protocol error
Feb  7 09:43:45 telesto weewx[856]: acurite: Failed attempt 3 of 10 to get LOOP data: could not set alt intf 0/0: Protocol error
Feb  7 09:43:55 telesto weewx[856]: acurite: Unable to claim USB interface 0: could not set alt intf 0/0: Protocol error
Feb  7 09:43:55 telesto weewx[856]: acurite: Failed attempt 4 of 10 to get LOOP data: could not set alt intf 0/0: Protocol error

 -----------------------------

Next, I followed one of the suggestions and tried to weewx directly as:

sudo PYTHONPATH=/usr/share/weewx python /home/weewx/bin/weewx/drivers/acurite.py

Traceback (most recent call last):

  File "/home/weewx/bin/weewx/drivers/acurite.py", line 225, in <module>
    import weewx.drivers
ImportError: No module named weewx.drivers


Then:

/home/weewx$ sudo PYTHONPATH=/home/weewx python /home/weewx/bin/weewx/drivers/acurite.py
[sudo] password for rich:

Traceback (most recent call last):

  File "/home/weewx/bin/weewx/drivers/acurite.py", line 225, in <module>
    import weewx.drivers
ImportError: No module named weewx.drivers

What am I doing wrong?  I'd like to get you some valid info to solve the Protocol error.

[mwall]

On Saturday, February 7, 2015 at 12:07:23 PM UTC-5, Rich Falconburg wrote:

What am I doing wrong?  I'd like to get you some valid info to solve the Protocol error.

rich,

for a setup.py install to /home/weewx, you should do this:

sudo PYTHONPATH=/home/weewx/bin python /home/weewx/bin/weewx/drivers/acurite.py

what kind of station do you have?

what operating system are you using?

m

[Rich Falconburg]

Sorry. Rushed that post. The station is an AcuRite 2032 and I'm running on a flavor of Unbuntu Linux.

[Rich Falconburg]

Here's some more information:

The station is an AcuRite 2032C and I'm running on a flavor of Ubuntu Linux 14.04 .1 (Bodhi Linux).  I'm currently testing on an old Dell Optiplex 755.

Got a bit of time to troubleshoot.  The following is the result of my efforts.

Using the command you provided I'm back to the Protocol error:

 /home/weewx$ sudo PYTHONPATH=/home/weewx/bin python /home/weewx/bin/weewx/drivers/acurite.py

Traceback (most recent call last):

  File "/home/weewx/bin/weewx/drivers/acurite.py", line 706, in <module>
    with Station() as s:
  File "/home/weewx/bin/weewx/drivers/acurite.py", line 393, in __enter__
    self.open()
  File "/home/weewx/bin/weewx/drivers/acurite.py", line 433, in open
    raise weewx.WeeWxIOError(e)
weewx.WeeWxIOError: could not set alt intf 0/0: Protocol error


I get this in both modes 3 and 4.


On plugging the AcuRite base USB cord in, syslog shows:

Feb  8 08:30:08 telesto kernel: [389668.200037] usb 4-1: new low-speed USB device number 20 using uhci_hcd
Feb  8 08:30:08 telesto kernel: [389668.369037] usb 4-1: New USB device found, idVendor=24c0, idProduct=0003
Feb  8 08:30:08 telesto kernel: [389668.369042] usb 4-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
Feb  8 08:30:08 telesto kernel: [389668.369046] usb 4-1: Product: Chaney Instrument
Feb  8 08:30:18 telesto kernel: [389678.389045] hid-generic 0003:24C0:0003.000D: timeout initializing reports
Feb  8 08:30:18 telesto kernel: [389678.389149] input: Chaney Instrument as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/input/input18
Feb  8 08:30:18 telesto kernel: [389678.389645] hid-generic 0003:24C0:0003.000D: input,hidraw4: USB HID v1.11 Device [Chaney Instrument] on usb-0000:00:1a.1-1/input0
Feb  8 08:30:18 telesto mtp-probe: checking bus 4, device 20: "/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1"
Feb  8 08:30:18 telesto mtp-probe: bus: 4, device: 20 was not an MTP device

lsusb output is:

Bus 004 Device 020: ID 24c0:0003 

No text identifying the device.  Without a system driver, that's expected.

/dev/input/by-id lists the device as:

usb-24c0_Chaney_Instrument-event-if00 -> ../event5
(link is: crw-r----- 1 root root 13, 69 Feb  8 08:19 /dev/input/event5)


Then, running the command you provided adds this to syslog:

Feb  8 08:16:17 telesto acurite[6620]: acurite: Found station at bus=004 device=020
Feb  8 08:16:17 telesto acurite[6620]: acurite: Unable to claim USB interface 0: could not set alt intf 0/0: Protocol error

Which will then remove /dev/input/event5.


Hope this info helps.  I should have some time later today to work on this if you have other ideas...

Rich

[mwall]

rich,

thanks for the details.  what version of libusb is installed?  what version of pyusb is installed?

try commenting line 429 of acurite.py (the setAltInterface line):

        # attempt to claim the interface                                       
        try:
            self.handle.claimInterface(interface)
#            self.handle.setAltInterface(interface)
        except usb.USBError, e:
            self.close()
            logcrt("Unable to claim USB interface %s: %s" % (interface, e))
            raise weewx.WeeWxIOError(e)

then run the 'sudo PYTHONPATH=...' command again.

m

[Rich Falconburg]

Ah!  Good point about libusb.  I had built and installed the version as suggested by Dave at Desert Home and that may be causing some conflict.  The system installed versions:  libusb-1.0-0,  python-usb  0.4.3-1

I'll do some cleanup and try again.

Commenting that line out gives:

/home/weewx$ sudo PYTHONPATH=/home/weewx/bin python /home/weewx/bin/weewx/drivers/acurite.py
Traceback (most recent call last):

  File "/home/weewx/bin/weewx/drivers/acurite.py", line 723, in <module>
    r1 = s.read_R1()
  File "/home/weewx/bin/weewx/drivers/acurite.py", line 454, in read_R1
    return self.read(1, 10)
  File "/home/weewx/bin/weewx/drivers/acurite.py", line 451, in read
    timeout=self.timeout)
usb.USBError: error sending control message: Protocol error

[Andy]

This is what is working with my Acurite console.

root@raspberry-pi:~# uname -a

Linux raspberry-pi 3.12.25+ #700 PREEMPT Thu Jul 24 17:51:46 BST 2014 armv6l GNU/Linux

root@raspberry-pi:~# apt-cache show python-usb 

Package: python-usb

Source: pyusb

Version: 0.4.3-1

root@raspberry-pi:~# apt-cache show libusb-0.1-4

Package: libusb-0.1-4

Source: libusb

Version: 2:0.1.12-20+nmu1

[mwall]

this configuration is working for me:

acurite 01036CA1 console

$ uname -a
Linux saga 2.6.34.9 #1 PREEMPT Thu Jun 23 10:15:49 PHT 2011 armv5tel GNU/Linux

$ apt-cache show libusb-0.1-4
Package: libusb-0.1-4
Source: libusb
Version: 2:0.1.12-16

$ apt-cache show python-usb
Package: python-usb
Source: pyusb (0.4.2-2)
Version: 0.4.2-2+b2

not so much luck yet with macosx (10.6.8) and fink:

$ uname -a
Darwin gouda 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

$ apt-cache show libusb
Package: libusb
Source: libusb
Version: 0.1.12-1015

$ apt-cache show pyusb-py26
Package: pyusb-py26
Source: pyusb-py26
Version: 0.4.1-1

a codeless kext appears to work (prevents the os from capturing the interface), but then there are timing problems when communicating with the device, resulting in 'broken pipe' and 'transaction timed out' on the usb_control_msg invocations.

clearly there are differences between libusb-0.1 and libusb-1.0 and the corresponding python interfaces.  a bigger unknown is how the firmware behavior differs between 0103x and 02032 consoles, or even from one 02032 to another.

m

[Mark]

Hi Matt,

Thanks for all the hard work on this.  Tried to get this working over the last week but come to find out on OSX 10.10 you can't even self sign a Kext.  So unfortunately I don't think it going to work on a mac.  On the other hand put it on a raspberrypi and its been running beautiful for 3 days now :).

-Mark

[Rich Falconburg]

Finally got a bit of time to look at this again and tried again, this time on Debian 6.0.

libusb = 0.1-4
python-usb = 0.4.2-2+b1

Unforunately,  even with line 429 commented out I still get the same error.  This was also on different hardware (32 Bit Netbook).  While I don't have a RPi, I do have the BBB and other uControllers.  I'd like to run it on the Beagle Bone so I'll try to get some time to do that and see if I get better results.

[Rich Falconburg]

Got it running on one of my dev boards (Radxa) with no effort but that was after I made sure the station was working under MS Win.  I wanted to be certain that the base station was actually working.  It was.  Next opportunity I'll check again on the other hardware.

[Tryphon Cosinus]

Hello,

I have the weather station Accurite 1036. According to Dave at Desert Home, I get a connection between Ubuntu 14 and the station. I am not interested to use my computer because I have a home server (low consumption). This server own libusb-1.0.8 (not sure for the 8).

1) Now, accurite.py driver is provided with the last version of weewx (thank you). I would like to test it but I am not sure about the minimum requirement for this driver :

which minimum version of libusb does it need ?

Dave used libusb-1.0.19 with some new functions (missing in the first versions of libusb-1.0) that he uses to communicate with the Accurite station. So this point is not clear for me.

2) My home server does not handle udev features but it is not needed for a connection with a USB device (at least, Dave's program is able to identify my weather station throught libusb-1.0.8). Then, I have no communication port created in /dev. Should I leave the port parameter blank in weewx.conf ? Will it work ?

Thank you

[mwall]

On Monday, March 2, 2015 at 5:08:54 AM UTC-5, Tryphon Cosinus wrote:

1) Now, accurite.py driver is provided with the last version of weewx (thank you). I would like to test it but I am not sure about the minimum requirement for this driver :

which minimum version of libusb does it need ?

libusb 0.1

it will not work with libusb 1.0

the programming interfaces are different.  as of weewx 3.1, the acurite.py driver is written using the libusb 0.1 interface.

if anyone is interested, it should be quite easy to make a usb shim so that every driver in weewx that uses a usb hid interface can automatically work with libusb 0.1, libusb 1.0, hidapi, etc.  are there any volunteers?

 

Dave used libusb-1.0.19 with some new functions (missing in the first versions of libusb-1.0) that he uses to communicate with the Accurite station. So this point is not clear for me.

what are these new functions/features? afaik, the only usb functions we need are:

handleControlMsg
detachKernelDriver
claimInterface
releaseInterface
setConfiguration (might not be necessary)
setAltConfiguration (might not be necessary)

the jury is still out as to whether libusb 0.1 works any better/worse than libusb 1.0, and we still have some work to make everything function properly on macosx.

 

2) My home server does not handle udev features but it is not needed for a connection with a USB device (at least, Dave's program is able to identify my weather station throught libusb-1.0.8). Then, I have no communication port created in /dev. Should I leave the port parameter blank in weewx.conf ? Will it work ?

there is no need to specify a port - the acurite.py driver will automatically detect the station using the vendor/product id.

m

[Phil W]

Fantastic work Matt!!!  I have a question though...
I was previously using Dave's C code and dumping it to both the screen and a python script that was sending it to weather underground.

I'm running into some troubles with data sent to wunderground via rapidupdate and I'd like to troubleshoot to validate data being sent without running wireshark to view the gets. 

Is there a way to pipe the data that is destined to wunderground to a log file someplace to troubleshoot?  Not sure if it's part of the driver here or in the restx.py in weewx.

[mwall]

On Thursday, March 5, 2015 at 5:05:05 PM UTC-5, Phil W wrote:

Fantastic work Matt!!!  I have a question though...
I was previously using Dave's C code and dumping it to both the screen and a python script that was sending it to weather underground.

I'm running into some troubles with data sent to wunderground via rapidupdate and I'd like to troubleshoot to validate data being sent without running wireshark to view the gets. 

Is there a way to pipe the data that is destined to wunderground to a log file someplace to troubleshoot?  Not sure if it's part of the driver here or in the restx.py in weewx.

phil,

the acurite hardware sends partial packets.  unfortunately wunderground does not deal well with partial packets.

any software that *does* do wunderground rapidfire from an acurite station is lying - it is retaining data from previous readings in order to fabricate a complete packet.

you can see exactly what weewx is reading by running weewxd directly (see the weewx user guide), and you can get even more info by setting debug=1 then looking in the log.

m

[Tryphon Cosinus]

Thank you for the reply,

I install Python 2.7.9 to install Weewx 3.1.0. I selected the Accurite driver.

My system includes both libusb 0.1 and 1.0. I connect my station in mode 3.

/share/HDA_DATA/.qpkg/weewx/bin/weewxd /share/HDA_DATA/.qpkg/weewx/weewx.conf

This produces these lines :

Traceback (most recent call last):

  File "/share/HDA_DATA/.qpkg/weewx/bin/weewxd", line 63, in <module>
    weewx.engine.main(options, args)
  File "/share/HDA_DATA/.qpkg/weewx/bin/weewx/engine.py", line 836, in main
    engine.run()
  File "/share/HDA_DATA/.qpkg/weewx/bin/weewx/engine.py", line 187, in run
    for packet in self.console.genLoopPackets():
  File "/share/HDA_DATA/.qpkg/weewx/bin/weewx/drivers/acurite.py", line 292, in genLoopPackets
    with Station() as station:
  File "/share/HDA_DATA/.qpkg/weewx/bin/weewx/drivers/acurite.py", line 393, in __enter__
    self.open()
  File "/share/HDA_DATA/.qpkg/weewx/bin/weewx/drivers/acurite.py", line 429, in open
    self.handle.setAltInterface(interface)
  File "/share/HDA_DATA/.qpkg/QPython2/lib/python2.7/site-packages/usb/legacy.py", line 261, in setAltInterface
    self.dev.set_interface_altsetting(self.__claimed_interface, alternate)
  File "/share/HDA_DATA/.qpkg/QPython2/lib/python2.7/site-packages/usb/core.py", line 832, in set_interface_altsetting
    self._ctx.managed_set_interface(self, interface, alternate_setting)
  File "/share/HDA_DATA/.qpkg/QPython2/lib/python2.7/site-packages/usb/core.py", line 179, in managed_set_interface
    self.backend.set_interface_altsetting(self.handle, i.bInterfaceNumber, alt)
  File "/share/HDA_DATA/.qpkg/QPython2/lib/python2.7/site-packages/usb/backend/libusb1.py", line 743, in set_interface_altsetting
    altsetting))
  File "/share/HDA_DATA/.qpkg/QPython2/lib/python2.7/site-packages/usb/backend/libusb1.py", line 552, in _check
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
  File "/share/HDA_DATA/.qpkg/QPython2/lib/python2.7/site-packages/usb/backend/libusb1.py", line 541, in _strerror
    return _lib.libusb_strerror(errcode).decode('utf8')
  File "/share/HDA_DATA/.qpkg/QPython2/lib/python2.7/ctypes/__init__.py", line 378, in __getattr__
    func = self.__getitem__(name)
  File "/share/HDA_DATA/.qpkg/QPython2/lib/python2.7/ctypes/__init__.py", line 383, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/lib/libusb-1.0.so.0: undefined symbol: libusb_strerror

1) Why is libusb-1.0 called instead of libusb-0.1 ?

2) If I try the Dave's program with libusb-1.0.8 (limited to GLIBC 2.6 or less), it claims for some missing functions (libusb_strerror, libusb transfert function seems to be different)  ... so there is some new functions now included in libusb-1.0.19 ? ... I am not expert.

Thank you for help.

[mwall]

On Saturday, March 7, 2015 at 11:36:26 AM UTC-5, Tryphon Cosinus wrote:

Thank you for the reply,

I install Python 2.7.9 to install Weewx 3.1.0. I selected the Accurite driver.

My system includes both libusb 0.1 and 1.0. I connect my station in mode 3.

 
is this still ubuntu?  which version?

which pyusb is installed?

m

[Tryphon Cosinus]

It is not under Ubuntu : I used Ubuntu only to understand the connexion of the Accurite station via libusb-1.0.19 since Dave uses this version only.

The linux system I use for Weewx is QTS 4 from QNAP based on Debian : Weewx is reported to work on the NAS at http://forum.qnap.com/viewtopic.php?f=50&t=95822.

I see pyusb 1.0.0b2 listed for Python 2.7.9

Thanks.

[mwall]

On Saturday, March 7, 2015 at 1:04:09 PM UTC-5, Tryphon Cosinus wrote:

I see pyusb 1.0.0b2 listed for Python 2.7.9

tryphon,

can you install pyusb 0.1 instead of pyusb 1.0?

m

[mwall]

On Saturday, March 7, 2015 at 11:36:26 AM UTC-5, Tryphon Cosinus wrote:

1) Why is libusb-1.0 called instead of libusb-0.1 ?

weewx uses the pyusb 0.1 interface for all usb drivers (they are almost all HID, but that is a separate discussion).

theoretically the pyusb1 interface is supposed to be backward-compatible with pyusb 0.1 using usb.legacy.

theoretically pyusb1 is supposed to be compatible with multiple backends (libusb 0.1, libusb1, openusb, perhaps others)

obviously there is a gap between theory and practice.

we know that the combination of pyusb 0.1 and libusb 0.1 works properly.

we might consider a usb abstraction to make the weewx usb drivers work across different libusb/pyusb implementations.  however, pyusb is supposed to do that for us...

m

[Tryphon Cosinus]

Thank you for clarification.

I installed pyusb-0.1 (is 0.4 the newest ?) : a new file appeared in site-packages folder. Libusb 1.0 seems to keep the priority. Nothing changes. I uninstalled pyusb-1.0 (flushing usb directory only related to this version, in site-packages).

Now weewxd starts without error but nothing is displayed on the screen (even with debug=1) and weewx.sdb is created but is not growing ...

Without error indication, I do not know what to do.

[mwall]

On Sunday, March 8, 2015 at 11:52:03 AM UTC-4, Tryphon Cosinus wrote:

Now weewxd starts without error but nothing is displayed on the screen (even with debug=1) and weewx.sdb is created but is not growing ...

debug=1 affects what is output to the logfile, not what is output to stdout.  output from weewxd goes to stdout, and is typically just LOOP and REC data.

what is in the log file?
 

[Tryphon Cosinus]

I start weewxd in SSH console (with admin rights). I am sorry, there is no syslog file in /var/log; not created ?
Same thing with root rights.

[Tryphon Cosinus]

Perhaps something wrong in the installation. Plugged or unplugged Accurite station result in same behavior of Weewx : nothing on the screen and in /var/log. But when I interrupt the program by Ctrl+C in the two cases :

Traceback (most recent call last):
  File "/share/HDA_DATA/.qpkg/weewx/bin/weewxd", line 63, in <module>
    weewx.engine.main(options, args)
  File "/share/HDA_DATA/.qpkg/weewx/bin/weewx/engine.py", line 836, in main
    engine.run()
  File "/share/HDA_DATA/.qpkg/weewx/bin/weewx/engine.py", line 187, in run
    for packet in self.console.genLoopPackets():

  File "/share/HDA_DATA/.qpkg/weewx/bin/weewx/drivers/acurite.py", line 311, in genLoopPackets
    time.sleep(self.retry_wait)
KeyboardInterrupt

Not sure if pyusb is really found and used.

[mwall]

On Sunday, March 8, 2015 at 7:13:21 PM UTC-4, Tryphon Cosinus wrote:

Perhaps something wrong in the installation. Plugged or unplugged Accurite station result in same behavior of Weewx : nothing on the screen and in /var/log. But when I interrupt the program by Ctrl+C in the two cases :

you need to figure out where the syslog messages go on your system, and you need to figure out how to ensure that debug, info, warning, critical, and error levels are emitted to the log.  this has nothing to do with weewx.

if your system is using rsyslog, then check /etc/rsyslog.conf

on some systems the default is /var/log/syslog, on others it is /var/log/messages

m

[Tryphon Cosinus]

Thank you for this advise. I checked the syslog server capability of my machine. A GUI proposes to add filters for the syslog server. Then I added theses names as applications to log : weewx and weewxd. After this, I opened /etc/rsyslog.conf :

if (($programname == 'weewxd')) then $filter0;SyslogProtocolStructDataFormat
if (($programname == 'weewxd')) then ~
if (($programname == 'Weewx')) then $filter2;SyslogProtocolStructDataFormat
if (($programname == 'Weewx')) then ~

has been added.

The GUI shows the events in real time. I see events from various sources (many are info messages) but nothing from Weewx just after it starts or after a long running time.

[Tryphon Cosinus]

Sorry, forget my previous post (syslogd -m was not started).

Here my log

Mar 14 13:22:14 SERVER user.debug weewx[19306]: engine: Loading service weewx.restx.StdAWEKAS
Mar 14 13:22:14 SERVER user.debug weewx[19306]: restx: AWEKAS: Data will not be posted: Missing option 'username'
Mar 14 13:22:14 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.restx.StdAWEKAS
Mar 14 13:22:14 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdPrint
Mar 14 13:22:14 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdPrint
Mar 14 13:22:14 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdReport
Mar 14 13:22:14 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdReport
Mar 14 13:22:14 SERVER user.info weewx[19306]: engine: Starting up weewx version 3.1.0
Mar 14 13:22:14 SERVER user.debug weewx[19306]: engine: Station does not support reading the time
Mar 14 13:22:14 SERVER user.info weewx[19306]: engine: Starting main packet loop.

Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Using configuration file /share/HDA_DATA/.qpkg/weewx/weewx.conf
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Initializing engine
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Loading station type AcuRite (weewx.drivers.acurite)
Mar 14 13:31:37 SERVER user.info weewx[19306]: acurite: driver version is 0.11
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdTimeSynch
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdTimeSynch
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdConvert
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: StdConvert target unit is 0x1
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdConvert
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdCalibrate
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdCalibrate
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdQC
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdQC
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.wxservices.StdWXCalculate
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.wxservices.StdWXCalculate
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdArchive
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Archive will use data binding wx_binding
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Record generation will be attempted in 'hardware'
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Using archive interval of 300 seconds
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Use LOOP data in hi/low calculations: 1
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Using binding 'wx_binding' to database 'archive/weewx.sdb'
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Starting backfill of daily summaries
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Daily summaries up to date.
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdArchive
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.restx.StdStationRegistry
Mar 14 13:31:37 SERVER user.debug weewx[19306]: restx: StationRegistry: Data will not be posted. Missing option 'station_url'
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.restx.StdStationRegistry
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.restx.StdWunderground
Mar 14 13:31:37 SERVER user.debug weewx[19306]: restx: Wunderground: Data will not be posted: Missing option 'station'
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.restx.StdWunderground
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.restx.StdPWSweather
Mar 14 13:31:37 SERVER user.debug weewx[19306]: restx: PWSWeather: Data will not be posted: Missing option 'station'
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.restx.StdPWSweather
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.restx.StdCWOP
Mar 14 13:31:37 SERVER user.debug weewx[19306]: restx: CWOP: Data will not be posted. Missing option: 'station'
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.restx.StdCWOP
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.restx.StdWOW
Mar 14 13:31:37 SERVER user.debug weewx[19306]: restx: WOW: Data will not be posted: Missing option 'station'
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.restx.StdWOW
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.restx.StdAWEKAS
Mar 14 13:31:37 SERVER user.debug weewx[19306]: restx: AWEKAS: Data will not be posted: Missing option 'username'
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.restx.StdAWEKAS
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdPrint
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdPrint
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Loading service weewx.engine.StdReport
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Finished loading service weewx.engine.StdReport
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Starting up weewx version 3.1.0
Mar 14 13:31:37 SERVER user.debug weewx[19306]: engine: Station does not support reading the time
Mar 14 13:31:37 SERVER user.info weewx[19306]: engine: Starting main packet loop.
Mar 14 13:31:37 SERVER user.debug weewx[19306]: acurite: Found station at bus=003 device=010
Mar 14 13:31:37 SERVER user.crit weewx[19306]: acurite: Unable to claim USB interface 0: Numerical result out of range
Mar 14 13:31:37 SERVER user.err weewx[19306]: acurite: Failed attempt 1 of 10 to get LOOP data: Numerical result out of range
Mar 14 13:31:47 SERVER user.debug weewx[19306]: acurite: Found station at bus=003 device=010
...
Mar 14 13:33:17 SERVER user.err weewx[19306]: acurite: Max retries (10) exceeded for LOOP data
Mar 14 13:33:17 SERVER user.crit weewx[19306]: engine: Caught WeeWxIOError: Max retries (10) exceeded for LOOP data
Mar 14 13:33:17 SERVER user.crit weewx[19306]:     ****  Waiting 60 seconds then retrying...

My station is found but ...

[Tryphon Cosinus]

Hello,

I got more information about libusb-0.1 library on my NAS. It has libusb-1.0 as dependency !! This ressembles to libusb-compat. I compiled libusb-0.1.12 into the NAS.

Now, I am on the same situation described by Rich Falconburg :

Mar 22 20:55:29 SERVER user.debug weewx[13836]: acurite: Found station at bus=003 device=013
Mar 22 20:55:29 SERVER user.crit weewx[13836]: acurite: Unable to claim USB interface 0: could not set alt intf 0/0: Protocol error

I do not know how to interpret this error.

Thank you.

[Dennis Hall]

This link is not working for me.  Is there another source for the driver?

[mwall]

On Monday, April 13, 2015 at 5:11:25 PM UTC-4, Dennis Hall wrote:

This link is not working for me.  Is there another source for the driver?

since february 2015, the latest version of the driver is in the repository at github:

https://github.com/weewx/weewx

more specifically:

https://github.com/weewx/weewx/blob/master/bin/weewx/drivers/acurite.py

as of 13apr2015, the latest acurite driver is v0.15.  beware that code in the repo may not be stable - we try to ensure that master always runs properly, but sometimes we screw up (well, i do more than tom does ;).

m

[Dennis Hall]

Thank you and I have the latest and it shows as having been loaded.  I am still not receiving a pressure reading.  Acurite 1035 and I have tried both USB 3 and 4.  I also have an Acurite Bridge but the IPWX reader does not support version 3.0 and I want to generate clientraw.txt etc.  

http://rathdrumweather.us

[Alex Woo]

Can someone confirm that the Acurite 5-in-1 with remote monitoring that is sold by Costco works with weewx?

Thanks,

Alex

[mwall]

On Saturday, May 9, 2015 at 7:50:22 PM UTC-4, Alex Woo wrote:

Can someone confirm that the Acurite 5-in-1 with remote monitoring that is sold by Costco works with weewx?

alex,

if the console has a usb port then it will probably work.  check the model number to be sure.  these are known to work: 01035, 01036, 02032

weewx will also work with the acurite bridge, but in that case you must add the ipwx driver by george nincehelser.

beware that the 02032 consoles are more flaky than the 01035/01036 consoles. sometimes they emit spurious bad data, and sometimes the usb just stops working.  but the driver is now better at dealing with that flaky behavior.

m

[Andy]

On Saturday, May 9, 2015 at 4:50:22 PM UTC-7, Alex Woo wrote:

Can someone confirm that the Acurite 5-in-1 with remote monitoring that is sold by Costco works with weewx?

Thanks,

Alex

Alex,

My Acurite system from Costco works with weewx.  It is the 02032  

[Jon Kellum]

I am running an 01035 and testing with the latest acurite.py. (v 0.17) I have to comment out the configuration section to get it to load. I have libusb 1.0 and 0.1 installed and connect directly via usb.

I receive "acurite: R2: unknown calibration constants: 02 00 00 45 cb 0e 84 01 01 02 63 7c 6b 17 64 09 c4 07 1b 60 07 7e 2a a6 f3" message in the log and there are no pressure readings.

Thanks for any help....

--Jon

[mwall]

On Tuesday, June 23, 2015 at 6:59:19 PM UTC-4, Jon Kellum wrote:

I am running an 01035 and testing with the latest acurite.py. (v 0.17) I have to comment out the configuration section to get it to load. I have libusb 1.0 and 0.1 installed and connect directly via usb.

I receive "acurite: R2: unknown calibration constants: 02 00 00 45 cb 0e 84 01 01 02 63 7c 6b 17 64 09 c4 07 1b 60 07 7e 2a a6 f3" message in the log and there are no pressure readings.

Thanks for any help....

jon,

please post the stack trace when you leave the configuration section uncomment.

are you getting *any* valid data from the station?

how often do you get the 'unknown calibration constants' message?

here is the logwatch summary from a 01036 console for one day (it is running in mode 4):

   acurite: R1: bogus signal strength                 2
   acurite: R1: ignoring stale data                  18
   acurite: R1: no sensors found                      5

and here are some of the messages from the day before that:

   Jun 21 08:41:27 saga weewx[11518]: acurite: R1: bogus signal strength (ff): 01 0b fa 71 00 08 15 23 ff 00
   Jun 21 13:51:24 saga weewx[11518]: acurite: R1: ignoring stale data: 01 0b fa 71 00 75 15 42 00 00
   Jun 21 16:31:28 saga weewx[11518]: acurite: R1: ignoring stale data: 01 0b fa 78 01 09 05 52 00 00
   Jun 21 16:58:35 saga weewx[11518]: acurite: R1: bogus signal strength (ff): 01 0b fa 78 00 79 ff ff ff 00
   Jun 21 17:00:05 saga weewx[11518]: acurite: R1: bogus signal strength (ff): 01 0b fa 78 00 69 1d 4d ff 00
   Jun 21 17:10:56 saga weewx[11518]: acurite: R1: no sensors found: 01 ff ff ff ff ff ff ff ff 00
   Jun 21 17:10:56 saga weewx[11518]: acurite: R2: unknown calibration constants: 02 00 00 41 ac 0d 1c 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   Jun 21 17:11:57 saga weewx[11518]: acurite: R2: constants changed: old: [02 00 00 41 ac 0d 1c 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff] new: [02 00 00 41 ac 0d 1c 00 d0 02 16 8f e8 15 e7 09 c4 07 16 06 07 90 fd a9 fc]
   Jun 21 17:21:47 saga weewx[11518]: acurite: R1: ignoring stale data: 01 0b fa 71 00 50 15 42 00 00
   Jun 21 17:26:36 saga weewx[11518]: acurite: R1: ignoring stale data: 01 0b fa 71 00 50 15 42 00 00
   Jun 21 22:33:43 saga weewx[11518]: acurite: R1: no sensors found: 01 ff ff ff ff ff ff ff ac 00
   Jun 21 23:56:22 saga weewx[11518]: acurite: R1: bogus message flavor (ff): 01 0b fa ff ff ff ff ff ff 00
   Jun 21 23:56:22 saga weewx[11518]: acurite: R1: bogus signal strength (ff): 01 0b fa ff ff ff ff ff ff 00

as you can see, it is not unusual to get some pretty rubbish output from an acurite station (and not just the 02032 stations).

m

[Jon Kellum]

Here's what I see when running with the configuration section uncommented:

Jun 23 19:42:03 ubuntu weewx[26798]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 536, in open

Jun 23 19:42:03 ubuntu weewx[26798]:     ****      self.handle.setConfiguration(dev.configurations[0])

Jun 23 19:42:03 ubuntu weewx[26798]:     ****    File "/usr/local/lib/python2.7/dist-packages/usb/legacy.py", line 253, in setConfiguration

Jun 23 19:42:03 ubuntu weewx[26798]:     ****      self.dev.set_configuration(configuration)

Jun 23 19:42:03 ubuntu weewx[26798]:     ****    File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 799, in set_configuration

Jun 23 19:42:03 ubuntu weewx[26798]:     ****      self._ctx.managed_set_configuration(self, configuration)

Jun 23 19:42:03 ubuntu weewx[26798]:     ****    File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 128, in managed_set_configuration

Jun 23 19:42:03 ubuntu weewx[26798]:     ****      self.backend.set_configuration(self.handle, cfg.bConfigurationValue)

Jun 23 19:42:03 ubuntu weewx[26798]:     ****  AttributeError: 'NoneType' object has no attribute 'bConfigurationValue'

Jun 23 19:42:03 ubuntu weewx[26798]:     ****  Exiting.

********************************************************

All of the other data 'seems' to be coming in fine. i.e. Outside temp, humidity, wind speed etc.

The unknown calibration constants appear to be occurring at every attempt to read the r2 data.

--Jon

[mwall]

jon,

there are two distinct issues here.  first the usb configuration. apparently pyusb is not being as compatible with libusb backends as it purports to be.

which version of pyusb are you running?

the second issue is your console.  the 'C' parameter is bogus - byte 19 has a value of 0x60, but it must be in [0x01,0x0f] to be valid.  if we tried to calculate temperature and pressure using those calibration constants, we would get bogus results.

you could try resetting the usb on your station (unplug the usb cable, then plug it back in; ok to do this while weewx is running).  if that does not work, then try power cycling the station (turn it off, unplug the usb cable, wait until all capacitors have discharged, power on, then plug in the usb cable; ok to do this while weewx is running).

have you ever gotten an R2 reading that did not say 'unknown calibration constants'?  if not, then either your station has never worked properly, or you have a station that works but it outside of the sensor specifications.  you'd have to ask acurite to find out which it is.

m

[Jon Kellum]

OK Looks like there's something with the station that just isn't working correctly. I've reset the usb as you suggested (both methods) and neither changed the value of byte-19. The station works fine in Windows under WeatherDisplay so I'll stick with that until I can upgrade to a davis vue....thanks for the help.

BTW, i am running 0.4.3-1 of pyusb......

Thanks again and for all your work with weewx.

--Jon

[mwall]

On Tuesday, June 23, 2015 at 8:58:01 PM UTC-4, Jon Kellum wrote:

OK Looks like there's something with the station that just isn't working correctly. I've reset the usb as you suggested (both methods) and neither changed the value of byte-19. The station works fine in Windows under WeatherDisplay so I'll stick with that until I can upgrade to a davis vue....thanks for the help.

well, you could try loosening the restrictions on the temperature/pressure constants.  in acurite.py, change this:

        elif (0x100 <= c1 <= 0xffff and
              0x0 <= c2 <= 0x1fff and
              0x0 <= c3 <= 0x400 and
              0x0 <= c4 <= 0x1000 and
              0x1000 <= c5 <= 0xffff and
              0x0 <= c6 <= 0x4000 and
              0x960 <= c7 <= 0xa28 and
              0x01 <= a <= 0x3f and 0x01 <= b <= 0x3f and
              0x01 <= c <= 0x0f and 0x01 <= d <= 0x0f):

to this:

        elif (0x100 <= c1 <= 0xffff and
              0x0 <= c2 <= 0x1fff and
              0x0 <= c3 <= 0x400 and
              0x0 <= c4 <= 0x1000 and
              0x1000 <= c5 <= 0xffff and
              0x0 <= c6 <= 0x4000 and
              0x960 <= c7 <= 0xa28 and
              0x01 <= a <= 0x3f and 0x01 <= b <= 0x3f and
              0x01 <= c <= 0xff and 0x01 <= d <= 0x0f):

(just change the 0 to f), and leave the setConfiguration commented.

i'm curious to see how that affects the temperature/pressure readings...

m

[Jon Kellum]

Made the change and that got it going. Temperature reading currently looks good. Baro looks reasonable. Here's a link to my WU if that's helpful at all. The first data from weewx was at 10:15 pm.

--Jon

[Jon Kellum]

Sorry, forgot the link....http://www.wunderground.com/personal-weather-station/dashboard?ID=KVAHARTF4

[mwall]

On Tuesday, June 23, 2015 at 10:24:10 PM UTC-4, Jon Kellum wrote:

Made the change and that got it going. Temperature reading currently looks good. Baro looks reasonable. Here's a link to my WU if that's helpful at all. The first data from weewx was at 10:15 pm.

well its nice to know it works, but disconcerting to know that the limits defined by the sensor manufacturer do not really matter.  here is where they are specified:

http://www.hoperf.com/upload/sensor/HP03S.pdf

the usb part still has me baffled.  could you confirm your usb configuration?

dpkg-query -l | grep libusb
dpkg-query -l | grep python-usb
 
this is what i get:

ii  libusb-0.1-4        2:0.1.12-16  userspace USB programming library
ii  libusb-1.0-0        2:1.0.8-2    userspace USB programming library
ii  libusb-1.0-0-dev    2:1.0.8-2    userspace USB programming library development files
ii  libusb-dev          2:0.1.12-16  userspace USB programming library development files
ii  python-usb          0.4.2-2+b2   USB interface for Python

and my system seems to have no problem with the setConfiguration.

does anyone know if setConfiguration is actually necessary?

m

[Jon Kellum]

Here are the results....

ii  libgusb2:i386                           0.1.6-5                         i386         GLib wrapper around libusb1

ii  libusb-0.1-4:i386                      2:0.1.12-23.3ubuntu1    i386         userspace USB programming library

ii  libusb-1.0-0:i386                      2:1.0.17-1ubuntu2        i386         userspace USB programming library

ii  libusb-1.0-0-dbg:i386                2:1.0.17-1ubuntu2       i386         userspace USB programming library development files

ii  libusb-1.0-0-dev:i386                2:1.0.17-1ubuntu2       i386         userspace USB programming library development files

ii  libusb-1.0-doc                         2:1.0.17-1ubuntu2        all           documentation for userspace USB programming

ii  libusb-dev                               2:0.1.12-23.3ubuntu1   i386         userspace USB programming library development files

rc  libusbmuxd1                           1.0.7-2                       i386         USB multiplexor daemon for iPhone and iPod Touch devices - library

ii  libusbmuxd2                            1.0.8-2ubuntu1            i386         USB multiplexor daemon for iPhone and iPod Touch devices - library

ii  python-usb                              0.4.3-1                        i386         USB interface for Python

--
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/ErAUDBQEsDU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mwall]

jon,

please try acurite driver v0.18 from github:

https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/acurite.py

the usb setConfiguration now catches AttributeError, so this should workaround the python-usb/libusb problem.

there is also now a parameter to ignore calibration constant bounds for wonky stations like the 01035 that you have:

[AcuRite]
    ignore_bounds = true

the ignore_bounds option should *only* be used if you have a station that always gets 'unknown calibration constants'.  in your case it is the C constant with a value of 0x60 when the bounds are 0x01 to 0x0f.

these changes retain the driver's check on changes to the calibration constants (changes should never happen - when we see them it is probably due to noisy USB comms or flaky firmware).

thank you for your help with this,

m

[Jon Kellum]

Thanks for the updated driver. I had a problem with it running originally, here is the trace I received:

Jun 24 10:27:05 ubuntu weewx[17933]:     ****    File "/usr/share/weewx/weewx/engine.py", line 187, in run

Jun 24 10:27:05 ubuntu weewx[17933]:     ****      for packet in self.console.genLoopPackets():

Jun 24 10:27:05 ubuntu weewx[17933]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 429, in genLoopPackets

Jun 24 10:27:05 ubuntu weewx[17933]:     ****      packet.update(Station.decode_R2(raw2, self.ignore_bounds))

Jun 24 10:27:05 ubuntu weewx[17933]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 673, in decode_R2

Jun 24 10:27:05 ubuntu weewx[17933]:     ****      data['pressure'], data['inTemp'] = Station.decode_pt(raw, ignore_bounds)

Jun 24 10:27:05 ubuntu weewx[17933]:     ****    File "/usr/share/weewx/weewx/drivers/acurite.py", line 796, in decode_pt

Jun 24 10:27:05 ubuntu weewx[17933]:     ****      return Station.decode_pt_HP03S(c1,c2,c3,c4,c5,c6,c7,a,b,c,d,d1,d2)

Jun 24 10:27:05 ubuntu weewx[17933]:     ****  UnboundLocalError: local variable 'd1' referenced before assignment

Jun 24 10:27:05 ubuntu weewx[17933]:     ****  Exiting.

As a temporary workaround to test I changed the following:

elif (ignore_bounds):

            # some consoles return values outside the specified limits, but

            # their data still seem to be ok.

   d2 = (data[21] << 8) + data[22]

            d1 = (data[23] << 8) + data[24]

            return Station.decode_pt_HP03S(c1,c2,c3,c4,c5,c6,c7,a,b,c,d,d1,d2)

        logerr("R2: unknown calibration constants: %s" % _fmt_bytes(data))

        return None, None

I also notice that the setconfiguration error is logged at every read. I wasn't sure if that was a problem or not. The data looks fine with this but I wasn't sure if the setconfiguration log message should be bypassed.

Thanks again for everything.....

--Jon

--

[mwall]

On Wednesday, June 24, 2015 at 10:47:02 AM UTC-4, Jon Kellum wrote:

Thanks for the updated driver. I had a problem with it running originally, here is the trace I received:

sorry about that jon.  kind of hard to test when my station does not emit wonky R2 constants :)

fixed in driver version 0.19 (commit 2f79cd633de87c026da290663c5d850460da23af)

m 

[Jon Kellum]

Sorry to be so long in getting back to you. I've been busy with some other projects. Got the bulk of my site changed over to WeeWX thanks to you and your efforts with this driver. It's been running overnight and it's working great. We have some rain headed in so I'll get to see if that's working too. Thank you again....

--Jon

--

[Ralph Peters]

Hi,

I am using your driver for an Acurite 2032C that I got as a Christmas gift.  I am running the software on a Raspberry PI 2 (quad-core!).  It has run fine for about 2 weeks and then in the last 2 days, at least 3 different times, I do not get updates to weather-underground as something has failed.  I can restart the raspberry pi, and things work for a while and then it fails again....

I did a dump from syslog

sudo tail --lines 1000 /var/log/syslog 

for the relevant part from before to through the failure at about 9:30.  

It looks to me that the connection between the Raspberry PI and the acurite is failing. I have unplugged and replugged cables multiple times using different ports on the raspberry pi,.... 

The acurite display IS showing data from the outdoor weather station 

throughout.  cpu temp is OK at about 37C.  Wifi signal strength to wunderground and the outside world is good at 85/100 with no noise.

Any bright ideas as to what I should do?

Thanks,

Ralph Peters

Jan 31 09:25:39 raspberrypi weewx[883]: acurite: Found station at bus=001 device=005
Jan 31 09:25:39 raspberrypi weewx[883]: acurite: next read in 18 seconds
Jan 31 09:25:57 raspberrypi weewx[883]: acurite: Found station at bus=001 device=005
Jan 31 09:25:57 raspberrypi weewx[883]: acurite: next read in 18 seconds
Jan 31 09:26:15 raspberrypi weewx[883]: acurite: Found station at bus=001 device=005
Jan 31 09:26:15 raspberrypi weewx[883]: acurite: next read in 6 seconds
Jan 31 09:26:21 raspberrypi weewx[883]: acurite: Found station at bus=001 device=005
Jan 31 09:26:22 raspberrypi weewx[883]: acurite: Failed attempt 1 of 10 to get LOOP data: error sending control message: Connection timed out
Jan 31 09:26:22 raspberrypi kernel: [41437.718664] usb 1-1.5: usbfs: USBDEVFS_CONTROL failed cmd python rqt 161 rq 1 len 25 ret -110
Jan 31 09:26:52 raspberrypi weewx[883]: acurite: Found station at bus=001 device=005
Jan 31 09:26:52 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 09:28:22 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 09:35:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 09:36:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 09:35:01 raspberrypi CRON[2430]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 09:45:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 09:46:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 09:45:01 raspberrypi CRON[2447]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 09:55:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 09:56:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 09:55:01 raspberrypi CRON[2464]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 10:03:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 10:04:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 10:03:01 raspberrypi CRON[2481]: (pi) CMD (/home/pi/Dropbox-Uploader/dropbox_uploader.sh upload /var/www/weewx .)
Jan 31 10:05:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 10:06:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 10:05:01 raspberrypi CRON[4820]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 10:06:21 raspberrypi CRON[2474]: (CRON) info (No MTA installed, discarding output)
Jan 31 10:15:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 10:16:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 10:15:01 raspberrypi CRON[4846]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 10:17:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 10:18:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 10:17:01 raspberrypi CRON[4861]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jan 31 10:25:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 10:26:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 10:25:01 raspberrypi CRON[4885]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 10:35:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 10:36:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 10:35:01 raspberrypi CRON[4902]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 10:45:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 10:46:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 10:45:01 raspberrypi CRON[4919]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 10:55:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 10:56:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 10:55:01 raspberrypi CRON[4935]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 11:03:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 11:04:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 11:03:01 raspberrypi CRON[4952]: (pi) CMD (/home/pi/Dropbox-Uploader/dropbox_uploader.sh upload /var/www/weewx .)
Jan 31 11:05:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 11:06:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 11:05:01 raspberrypi CRON[6428]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 11:05:53 raspberrypi CRON[4945]: (CRON) info (No MTA installed, discarding output)
Jan 31 11:15:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 11:16:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 11:15:01 raspberrypi CRON[6454]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 11:17:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 11:18:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 11:17:01 raspberrypi CRON[6469]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jan 31 11:25:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 11:26:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 11:25:01 raspberrypi CRON[6493]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 11:35:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 11:36:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 11:35:01 raspberrypi CRON[6510]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 11:45:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 11:46:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 11:45:01 raspberrypi CRON[6528]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jan 31 11:55:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 11:56:31 2016 [try http://www.rsyslog.com/e/2007 ]
Jan 31 11:55:01 raspberrypi CRON[6545]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

[Chris Swanda]

I had the same syslog issue on my RPi....

raspberry rsyslogd-2007: action 'action 17' suspended, next retry is Wed Oct  7 02:03:42 2015 [try http://www.rsyslog.com/e/2007 ]

This will fill up your syslogs.  

#daemon.*;mail.*;\
#       news.err;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

Comment out the notice and warm messages from xconsole in /etc/rsyslog.conf so your syslog doesn't fill up.

This will not necessarily fix your issue, but it will keep your logging under control and from filling up.  

[Ralph Peters]

Thanks for the reply!  I found the same solution late yesterday and have made this "fix".  We'll see if it works.

Ralph Peters

--

[mwall]

On Monday, February 1, 2016 at 10:49:02 AM UTC-5, Ralph Peters wrote:

Thanks for the reply!  I found the same solution late yesterday and have made this "fix".  We'll see if it works.

ralph,

this kind of message is not unusual:

Jan 31 09:26:22 raspberrypi weewx[883]: acurite: Failed attempt 1 of 10 to get LOOP data: error sending control message: Connection timed out

it indicates that weewx cannot obtain data via usb.  weewx will retry up to 10 times.  if it fails after 10 attempts, then the driver will be reloaded.

possible root cause of usb issues with acurite stations:
- cheap usb cables
- emf interference near the usb cable
- not enough power on the usb (e.g., older rpi, or *any* rpi with too many devices attached to the bus with no added power)
- flaky 02032 station usb comms (they tend to randomly lock up, much more often than 01035/01036 stations)
- 02032 station in usb mode 3 (use usb mode 4 to greatly reduce the chance of usb lockups)

this gives us a clue:

Jan 31 09:26:22 raspberrypi kernel: [41437.718664] usb 1-1.5: usbfs: USBDEVFS_CONTROL failed cmd python rqt 161 rq 1 len 25 ret -110

and the following message about 'Found station' indicates that retry number 2 actually worked.

unfortunately, there are situations where the acurite station will lock up - the display works fine, but usb communication fails.  the only fix is to unplug the usb plug from the station, then plug it back in.  sometimes you must power cycle the station.

in either case, you should *not* have to restart weewx, and you should not have to reboot the pi.

these messages are not from weewx:

Jan 31 09:26:52 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sun Jan 31 09:28:22 2016 [try http://www.rsyslog.com/e/2007 ]

we *should* be seeing more messages from weewx in your log.

until you fix your syslog daemon, we won't know exactly what weewx is trying to tell you.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742143
http://blog.cagedmonster.net/node/6

m

[Ralph Peters]

Hi,

Thanks for the info on troubleshooting!  I really appreciate it.

I commented out the last 4 lines of /etc/rsyslog.conf last night.  So far, so good ☺

Responses to most of your troubleshooting comments follow.

I am using the USB cables that came with the acurite.  Maybe I should replace them if problems continue.

Nothing electrical is within 3' of the cables, except the acurite display, the Raspberry PI 2 and my small chromebook at about 2', which I use to talk to the raspberry pi 2 most of the time.

I have only the acurite display and a wifi unit plugged into the Raspberry PI 2. 

I have the acurite display in mode 4.

I have attached the file /var/log//syslog.  It starts yesterday at 6:25 pm, which is when I fixed to rsyslog.conf as I mentioned above.  It looks OK to me but maybe you will see something interesting or useful.  I looked for "loop" and "fail" in the file and found no occurences.

The section of the file that starts at something like:
Feb  1 09:56:44 raspberrypi systemd[1]: Starting user-1000.slice.

appears to occur when I "ssh" in from my chromebook.

Thanks for your help!!!

Ralph Peters

--

[Ralph Peters]

Hi,

A quick question for this comment:

Jan 31 09:26:22 raspberrypi weewx[883]: acurite: Failed attempt 1 of 10 to get LOOP data: error sending control message: Connection timed out

it indicates that weewx cannot obtain data via usb.  weewx will retry up to 10 times.  if it fails after 10 attempts, then the 
driver will be reloaded.

Is it usually the case that one needs to restart the acurite display at this point?  Or should one disconnect/reconnect the cables first and then do a restart if necessary.  Possibly  sacrifice a goat to the Acurite gods? ☺

I have been using computers for calculations/communications/.... for over 45 years (remember CDC computers or Symbolics Lisp computers?) and I have seen all sorts of strange stuff.  I have used Linux since the mid 1990s (Redhat 5!)

Thanks for your help!

Ralph Peters

On Mon, Feb 1, 2016 at 9:10 AM, mwall <mw...@users.sourceforge.net> wrote:

--

[Chris Swanda]

Ralph,

I am running an Acurite 01036 and a RPi2, also.

Whenever I need to physically power down my Pi (shutdown -h, not pulling the power as it will corrupt your SD card) and restart it, it can sometimes takes 2 or 3 cycles for it to pick up my Acurite.  ( 2 or 3 cycles of 10 tries).  It can seem like forever, but I generally just tail syslog and walk away, and eventually everything is right in the world. :)  Just give it a bit of time.  I know it can seem like things aren't working.

--Chris

[Joe Morris]

Same here with Acurite 2064 running weewx on top of Ubuntu. I had to power cycle my console due to a wireless signal problem after relocating my sensor. It took weewx about 15-30 minutes to start acquiring data again. You just need to let it runs its course and it will eventually start getting valid data over USB.

[Scott Grayban]

To be clear the driver does NOT report inTemp at all ?

[gjr80]

On Thursday, 27 December 2018 16:15:09 UTC+10, Scott Grayban wrote:

To be clear the driver does NOT report inTemp at all ?

The last sentence below seems fairly clear to me...

On Friday, January 9, 2015 at 8:55:37 PM UTC-8, mwall wrote:

folks,

here is a driver for acurite 5in1 weather stations.  it should work with any of the stations that have a usb port, including models 01025, 01035, 01036, 02032, 01057.

https://svn.code.sf.net/p/weewx/code/trunk/bin/weewx/drivers/acurite.py

many, many thanks to dave at 'desert home' for publishing his work

http://www.desert-home.com/

v0.1 will report outside sensor data: outTemp, outHumidity, rain, windSpeed, windDir

it will *not* report inTemp, inHumidity, or pressure

However, I get a 404 error on that link so I can't actually look at the code to verify that is still the case (the thread is near 4 years old).

It's worth noting though that the AcuRite driver distributed with weeWX (in bin/weewx/drivers/acurite.py) does include code to decode inTemp. Can't say it works as I don't use an AcuRite station, though drivers don't usually get into the distribution without being fairly thoroughly tested.

Gary

[Scott Grayban]

It looks like it does... Guess it never got updated in the logs.

      "insideTemp":"75.8 °F"

[gjr80]

If you mean the change log then yes that's quite likely. Drivers usually start life in a user's repo somewhere and once they are considered good enough (ie complete and stable enough) they may be added to the weeWX distribution if there is a sufficient audience. Quite possibly the January 2015 version (in the now defunct repo) was a work in progress and once good enough (ie included inTemp) for distribution with weeWX it was rolled into the weeWX repo. In this case the AcuRite driver was first distributed with weeWX in v3.1.0 in February 2015, guess it matured enough in that 1 month period.

In any case seems you have a working driver.

Gary