Acurite 01536 (Costco)

[Marcus Watkins]

For Christmas today I received an Acurite 01536 5-in-1 weather station with USB connection (from Costco). I set it up with weewx and was excited to see it works out of the box for the most part.

One difference from the docs is there's no 'USB Mode' switch on this base, so I'm interested to see if the log fills up over time.

The only real 'issue' is the barometer reads outside the values allowed by weewx by default. I'm also seeing values vary by quite a bit, but it's super windy out right now. I added an adjustment to match the display, we'll see how it lines up over time.

Does anyone know if the display reports barometer or pressure?

All in all, seems to be working great.

-Marcus

[mwall]

marcus,

the 01035/01036 consoles are the older models and have 4 usb modes.  apparently acurite got rid of the usb modes with the 02064 (replacement for the problematic 02032), and now with the 01535 (replacements for the 01035/01036?).

be glad that you have a console with no usb mode - the ones with usb mode default to mode 2 (no comms), so if you ever get a power failure with one of those you must manually punch buttons before you get data again.

the 5-in-1 reports station pressure, then the console applies some algorithm to get barometric pressure.  weewx just uses the value directly from the sensor.  apparently acurite's algorithm can take up to 2 weeks to settle down.  take a look at the comments in bin/weewx/drivers/acurite.py for more details.

m

[Scott Beard]

Marcus,

I have been running one of these units with weewx on a RPI3 since mid October.  The console is telling me the log is full and to connect it to the PC to clear it out.  It has been telling me that since 12 days after I set it up.  But it still works fine with weewx.  From what I can tell, the Acurite 01536 is based on the 02064 but is specific to Costco and has a slightly different screen layout.

Thanks

Scott

[Andy]

1536 on the left and 2064 on the right.  The consoles lock up after 6 or so months of operation.  This year going to hard reset

both consoles at the end of the year, so maybe the rain total will remain correct for at least the spring rain season.  When I get time to get one of the bmp sensors working with the SDR Pi, there will no longer be a USB connection to the 2064.  Maybe the console will have better uptime.  Or maybe an option like "wee_database --update-acurite-console"  :)  

[Jeffrey Forbes]

I got the same unit from Costco and I have been able to get it to work with weewx; however, I am not getting wind speed and direction.
Is that working for you?

Jeff

[Andy]

wind speed and direction work for me.  In weewx no direction is shown if speed is zero.  You getting speed and direction on the console?

[Landon Orr]

I'm also not getting windspeed or direction on my 01536. Currently, I'm seeing a 2mph wind and a SSE direction on the console but Weewx is showing both as 0.

[Marcus Watkins]

My wind speed and direction works with no adjustments...

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

[Landon Orr]

Yea, I'm actually going to have to take my comment back. Windspeed and direction are working fine now. Just setting it up, sorry about the false alarm.

To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[Brian Champion-Wescott]

Marcus,

What hardware are you using for your AcuRite 01536?  I have tried using a few different Linux distros on regular laptops, without any luck.  Are you using a Raspberry Pi?

Thanks,
Brian

On Sunday, December 25, 2016 at 2:17:58 PM UTC-5, Marcus Watkins wrote:

[Marcus Watkins]

I'm using a raspberry pi 2. I did hack together a USB cable power combo and power the unit from that. Why they don't take power over USB out of the box is beyond me...

--
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/_uOEWSOPBQk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Brian Champion-Wescott]

Thanks Marcus.  I finally got mine working today.

I agree.  Power from USB should have been standard.

To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[David Morgan]

I also got a Costco Acurite  01536-RX for Christmas.   Delayed a couple of weeks in setting it up.  I tried weewx first on my Toshiba L355, not successful.  But I was not successful at first, probably my error.  I think I tried installing with the deb package and from the Mint repository both.  I did get to the input screen a couple of times, was not sure what to use for the model number as it is not listed as supported.   Decided to try it on my wifes laptop, a Lenovo, running Mint 17.x or 18.  It worked just fine.  Came back to my computer, finally got it running.  Don't know why, it seems to have a hard time getting started.  I plan to do more looking at that.  I modified acurite.py a little for debugging.  After getting it running, I found I can use Wireshark to look at the serial interface (after enabling a kernel module), would have been nice to know that earlier.

The barometric pressure is way wrong on the console, and there is some disagreement between the console and the WeeWx display.     I am curious if anyone knows yet what sensors are used.  I have resisted peeking so far, but  that may change.  I will admit to being older, and getting confused about what I entered where in getting this going.  But it has been fun, and interesting poking through the Python code to add a couple of debugging outputs to the log file.

[mwall]

On Wednesday, January 18, 2017 at 7:24:16 PM UTC-5, David Morgan wrote:

 After getting it running, I found I can use Wireshark to look at the serial interface (after enabling a kernel module), would have been nice to know that earlier.

there are a few threads in this forum, as well as the weewx-development forum, about sniffing usb, serial, or network traffic in order to figure out what the hardware is doing.

the protocol for the acurite hardware is pretty straightforward - the trickiest part was figuring out the temperature/pressure encoding, but george cracked that one when he found the spec sheet for the HP03S sensor they were using.  then it took awhile to figure out the firmware bugs and hardware variants after the initial 01035/01036 models.

if you want to hack on your station, you might try to make reading of history records reliable (the R3 messages).  acurite consoles do not have much memory, and it is rather pointless for older hardware, but could be useful for newer hardware that defaults to having usb comms enabled after power cycling.
 

 

The barometric pressure is way wrong on the console, and there is some disagreement between the console and the WeeWx display.     I am curious if anyone knows yet what sensors are used.  I have resisted peeking so far, but  that may change.

take a look at the comments in the driver file, acurite.py

it explains pretty much everything we know about acurite hardware, including the reason for the console barometer readings.

other driver files contain similar information about their respective hardware.

there have been many contributions from many different people!

m

[David Morgan]

On Wednesday, January 18, 2017 at 4:24:16 PM UTC-8, David Morgan wrote:

The barometric pressure is way wrong on the console, and there is some disagreement between the console and the WeeWx display.     I am curious if anyone knows yet what sensors are used.  I have resisted peeking so far, but  that may change. 

I did take the console apart last night to see what parts were used.   I found the ICs were covered over with a hard black coating so you cannot identify what is there.  I did not find anything that looked like pressure sensor.   I did find what is probably the temp sensor.

I am finding that with my laptop, connecting to the console is not consistent.  Once connected, it seems to do OK.  I am not a programmer, so understanding the python code is not so easy for me.   Makes it hard to understand just where things are not working.  Wireshark is showing the system is having trouble initiating the transfer of data from the console to the host, even though it has already read the initialization data from the console.  Below is a dump from wireshark.   

Frame 595, the host issues a           USB       SET INTERFACE Request

Frame 596, the console responds,   USB       SET INTERFACE Response  :: URB status: Protocol error (-EPROTO) (-71)

Frame 597, the host issues a           USBHID     GET_REPORT Request

Frame 598, the console responds,   USBHID     GET_REPORT Response :: URB status: Success (0)   Console responded with 10 data bytes.

All following messages were successful.   So why did it just start working?  And why was the data request successful when the set interface request failed?  Is it not necessary for the USB interface to be set before a USBHID request?  Who sent the USB request?  Was it Python or the linux kernel?  These are things I have not figured out.

    595 690.183528     host                  5.14.0                USB      64     SET INTERFACE Request

Frame 595: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0

USB URB

    [Source: host]

    [Destination: 5.14.0]

    URB id: 0xffff88011c951300

    URB type: URB_SUBMIT ('S')

    URB transfer type: URB_CONTROL (0x02)

    Endpoint: 0x00, Direction: OUT

    Device: 14

    URB bus id: 5

    Device setup request: relevant (0)

    Data: present (0)

    URB sec: 1484814928

    URB usec: 977890

    URB status: Operation now in progress (-EINPROGRESS) (-115)

    URB length [bytes]: 0

    Data length [bytes]: 0

    [Response in: 596]

    Interval: 0

    Start frame: 0

    Copy of Transfer Flags: 0x00000000

    Number of ISO descriptors: 0

URB setup

0000  00 13 95 1c 01 88 ff ff 53 02 00 0e 05 00 00 00   ........S.......     Submit

0010  50 7a 80 58 00 00 00 00 e2 eb 0e 00 8d ff ff ff   Pz.X............

0020  00 00 00 00 00 00 00 00 01 0b 00 00 00 00 00 00   ................

0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

    596 690.187517     5.14.0                host                  USB      64     SET INTERFACE Response

Frame 596: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0

USB URB

    [Source: 5.14.0]

    [Destination: host]

    URB id: 0xffff88011c951300

    URB type: URB_COMPLETE ('C')

    URB transfer type: URB_CONTROL (0x02)

    Endpoint: 0x00, Direction: OUT

    Device: 14

    URB bus id: 5

    Device setup request: not relevant ('-')

    Data: not present ('>')

    URB sec: 1484814928

    URB usec: 981879

    URB status: Protocol error (-EPROTO) (-71)

    URB length [bytes]: 0

    Data length [bytes]: 0

    [Request in: 595]

    [Time from request: 0.003989000 seconds]

    Unused Setup Header

    Interval: 0

    Start frame: 0

    Copy of Transfer Flags: 0x00000000

    Number of ISO descriptors: 0

0000  00 13 95 1c 01 88 ff ff 43 02 00 0e 05 00 2d 3e   ........C.....->   From 14  05, the console bus address

0010  50 7a 80 58 00 00 00 00 77 fb 0e 00 b9 ff ff ff   Pz.X....w.......  Bold means protocol error

0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

    597 690.187738     host                  5.14.0                USBHID   64     GET_REPORT Request

Frame 597: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0

USB URB

    [Source: host]

    [Destination: 5.14.0]

    URB id: 0xffff88011c951300

    URB type: URB_SUBMIT ('S')

    URB transfer type: URB_CONTROL (0x02)

    Endpoint: 0x80, Direction: IN

    Device: 14

    URB bus id: 5

    Device setup request: relevant (0)

    Data: not present ('<')

    URB sec: 1484814928

    URB usec: 982100

    URB status: Operation now in progress (-EINPROGRESS) (-115)

    URB length [bytes]: 10

    Data length [bytes]: 0

    [Response in: 598]

    Interval: 0

    Start frame: 0

    Copy of Transfer Flags: 0x00000200

    Number of ISO descriptors: 0

    [bInterfaceClass: HID (0x03)]

URB setup

bRequest: GET_REPORT (0x01)

wValue: 0x0101

wIndex: 0

wLength: 10

0000  00 13 95 1c 01 88 ff ff 53 02 80 0e 05 00 00 3c   ........S......<   Submit

0010  50 7a 80 58 00 00 00 00 54 fc 0e 00 8d ff ff ff   Pz.X....T.......

0020  0a 00 00 00 00 00 00 00 a1 01 01 01 00 00 0a 00   ................

0030  00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00   ................

    598 690.194500     5.14.0                host                  USBHID   74     GET_REPORT Response

Frame 598: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0

USB URB

    [Source: 5.14.0]

    [Destination: host]

    URB id: 0xffff88011c951300

    URB type: URB_COMPLETE ('C')

    URB transfer type: URB_CONTROL (0x02)

    Endpoint: 0x80, Direction: IN

    Device: 14

    URB bus id: 5

    Device setup request: not relevant ('-')

    Data: present (0)

    URB sec: 1484814928

    URB usec: 988862

    URB status: Success (0)

    URB length [bytes]: 10

    Data length [bytes]: 10

    [Request in: 597]

    [Time from request: 0.006762000 seconds]

    Unused Setup Header

    Interval: 0

    Start frame: 0

    Copy of Transfer Flags: 0x00000200

    Number of ISO descriptors: 0

    [bInterfaceClass: HID (0x03)]

0000  00 13 95 1c 01 88 ff ff 43 02 80 0e 05 00 2d 00   ........C.....-.

0010  50 7a 80 58 00 00 00 00 be 16 0f 00 00 00 00 00   Pz.X............

0020  0a 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00   ................

0030  00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00   ................

0040  01 cb 57 78 00 45 64 5f 03 ff                     ..Wx.Ed_..                                Data!

So who determines that the protocol error exists?   Did it come from the console, or from the linux kernel?  Was the console flagging that it got a bad message?   I have observed that when the request for data fails, the console responds in 3.5 to 4 mSec.   When it works, it is typically 4.8 mSec for an R1 message.  The first one here took longer, maybe needed to do some housekeeping for the first message.   So when it fails, the console seems to know it is not going to respond, does not try and collect data, and responds more quickly.

[David Morgan]

On Wednesday, January 18, 2017 at 4:24:16 PM UTC-8, David Morgan wrote:

I also got a Costco Acurite  01536-RX for Christmas.   

.     I am curious if anyone knows yet what sensors are used.  I have resisted peeking so far, but  that may change. 

I have been looking I photos I took of the main board.   I now see that it uses a 24C512 EEPROM.   Right next to it appears to be the barometric pressure sensor.  Photo is not good enough to read the part number.   Also, I believe the humidity and temp sensors are on long leads, and stick out to where they are close to the air opening in the upper left side of the unit as you look at it from the front.

[Douglas Krug]

Just got an email that the 01536 will be an upcoming Amazon Prime deal (guess that model's not just for Costco anymore). Can anyone confirm if this is working in every aspect or are there some readings that are not being reported in Weewx? Is it plug and play for the most part? My brief journey into try to sniff data from an Acurite Bridge was not fruitful.

On Sunday, December 25, 2016 at 2:17:58 PM UTC-5, Marcus Watkins wrote:

[Brian Wescott]

Douglas,

I have had zero issues with my AcuRite 01536 and Raspberry Pi 3.  As far as I can tell, it works in every aspect.

Thanks,
Brian

--
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/_uOEWSOPBQk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Douglas Krug]

Thanks so much Brian! Really appreciate the quick feedback.

[rich T]

Douglas

No issues here.  Have my 01536  talking to two RPI 3.  One RPI 3 running weewx and the other running Node-Red via rtl-433.

Rich

To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[Steve2Q]

Rich T..do you have one station simultaneously talking to 2 PI's?
If so, how did you get this working?
Steve

[rich T]

Steve

Yes, I have one station talking to two RPIs. RPI # 1, I have the smart hub patched into one of the ports on a managed switch which I mirrored that port to a second port. The second port is then cabled to the RPI, which the data is being feed into weewx. On RPI # 2, I'm using a RTL-SDR to receive the signal from the 01536 (5 in 1) and decoding the signal with RTL_433 program, outputting the decoded signal in a JSON Format. This signal is then fed into Node-RED via MQTT.  Additionally, I'm decoding 6 additional Temp/Humidity sensors plus Lighting Detector. I'm going to add a BMP280 sensor to that RPI to get the Barometric Pressure.

Rich