AcuRite Acu-Link Internet Bridge (09150TRX): Accessing Local Data

AcuRite has been threatening the release of this product for well over a year, and it’s finally out.  Being a bit obsessive about data in and around my home, (check-out my IP Thermostat install and custom interface) I *HAD* to have one of these.

The “idea” is that you buy the Internet Bridge from AcuRite, and either with your existing sensors from their other products (many are compatible), or with the purchase of additional sensors, live data is transmitted to their “MyBackyardWeather” web site and you can view the data while you’re away and track trends etc.  They even offer a “forecasting” widget.

To get started, I ordered the internet bridge, a tower sensor, and a floating pool sensor.   The bridge is 80 bucks, and the sensors are very reasonably priced at ~ $8 for the tower sensor and $20 for the floating sensor.  They’re shipping is a bit slow, but everything arrived well packed and the build quality of all the devices is quite good.  The tower sensor supplies both temperature and humidity data, and honestly 8 bucks for one of these is a great price.   You’d be hard-pressed to buy just the sensors for an arduino or pi build for that money.

The bridge has a flip-up antenna and two connections, one RJ-45 for a network cable, and one jack for the power plug.  Since the protocol and any real info about how the bridge “talks” to their web site is unpublished and unknown, I figured I’d give it the full packet capture and analysis treatment.   To do this, I added a static DHCP IP mapping for the MAC address of the Internet Bridge to my router/firewall so as soon as it came online, I’d know the IP address.  The MAC address of the Internet Bridge can be found right on the bottom of the unit.  This MAC address is also the “ID” that AcuRite uses to associate your data sources with your account on MyBackyardWeather, but I’ll get to that later.  After setting up the static IP mapping, I enabled packet capture for any TCP/UDP connections from that IP out to the net.  Time to plug it in!

Once connected, the Internet Bridge did two things:

1) started sending sensor data to the Acu-Link web app

2) started downloading new firmware line-by-line with a POST for each new line as one completed

I pulled the connection before the firmware update could complete (just in case), and started to take a closer look at the data sent to the Acu-Link web app via the packet capture.  To my surprise, it looked like the sensor data was being sent  cleartext in a simple HTTP POST, one POST for each sensor in range of your Internet Bridge.  Next, I tried reconnecting the bridge, but this time with WAN access blocked, and ran a full port scan.  Only port 80 was open, and a visit to the Bridge’s local IP in a browser yielded a simple status page informing me that a firmware update was in process.   In the hope that more useful data would be presented when not in the “firmware-update” state, I permitted WAN access and let the firmware update complete.

Once the firmware update completed, the simple status page showed the sensors in range, their signal, and the option to send a POST to the bridge to toggle the LED’s on and off, but no actual sensor data was shown, and there’s nothing to click on, save for the LED toggle.  I tried forcing an error that might yield useful information with various POST’s and GET’s to the simple web interface on the Internet Bridge, but never got more than a 404 or the same status page.

Since querying the data directly from the Internet Bridge seemed unlikely without new information, I returned to looking at the data the Internet Bridge POST’s to Acu-Link, which was a little different now after the update.  The actual variables had additional digits and letters, but the values were still cleartext within this group of digits.  Here’s what the HTTP POST looks like when my Internet Bridge sends data for my tower sensor:

id=############&sensor=11423&mt=tower&humidity=A0590&temperature=A018000000&battery=normal&rssi=4

. . . . . let’s break it down and look at each piece:

id=############

I obfuscated the actual value here, but this is the MAC address of your Internet Bridge

sensor=11423

This is the sensor identifier, and appears to be unique for each sensor, though I only have one tower sensor, so I can’t be sure

mt=tower

This is the type of sensor, probably stands for “model type” if I had to guess

humidity=A0590

The 3rd-5th digits are the relevant ones here, with a decimal point required between the 4th and 5th digits, yielding a value of 59.0 for humidity

temperature=A018000000

Again, the 3rd-5th digits are the important ones here, but the 2nd digit serves the role of  denoting a positive or negative reading as well.  If the reading is positive, it’s a “0″, if it’s negative, it’s a “-”.  This value is also in Celsius, so if you want Fahrenheit, you’ll need to convert it.

battery=normal

This one seems fairly obvious, but I didn’t try inserting an older set of batteries to see what it reports when not “normal”

rssi=4

This denotes the received signal level for the specific sensor, and varies from 0-4

All of this data is super-easy to parse in just about any language.  I’m no programmer, but I’m “dangerous” with BASH scripting, so I figured I could probably whip something up, but how do we get the data if you can’t request it?  TCP dumps are nice for post-analysis. but a pain to do anything with real-time.  An HTTP proxy server with some customization would be an option to intercept the data, as well as IDS with some custom rules that took actions like parsing the data and writing out values that could be sucked up from something else, but I had something even “dirtier” in mind.

Let’s dig into what happens for data to get from the Internet Bridge to Acu-Link’s site from power-on to data.

1) The Internet Bridge powers up and gets an IP, gateway and DNS servers via DHCP (your router typically hands out this info)

2) The Internet Bridge resolves “http://www.acu-link.com” using DNS

3) The Internet Bridge starts making regular HTTP POST’s to the Acu-Link web service at: “http://www.acu-link.com/messages”

4) The Acu-Link web service responds back to each POST from the Internet Bridge with a SUCCESS, and the current firmware version.  (presumably if the FW version is higher than installed on the Internet Bridge, this is what initiates the downloading and install of new firmware).

Knowing the above, I figured the easiest way to get sensor data locally would be to “trick” the Internet Bridge into sending it to me instead of Acu-Link.  To do this, I configured my router/firewall (I use pfSense) to “override” www.acu-link.com by having the local DNS service resolve the hostname to a local IP on my network instead of the “real” IP on Acu-Link’s network.   If you can’t override hostnames or zones on your router/firewall with the local DNS service, or your router/firewall doesn’t offer a local DNS services, there’s several freeware DHCP/DNS software pkgs that you could run on a PC on your network to accomplish that same thing.

Now that I have my Internet Bridge sending it’s data to an IP on my network, I needed something to receive it.  I wrote a simple BASH script to replace the functionality of the “messages” web service at Acu-Link:

#!/bin/sh
echo “Content-type: text/html”
echo

echo “SUCCESS”

POSTDATA=$(cat | tr -d ‘ ‘)

FIELD=1
while [ $FIELD -le 15 ]
do

DATA=$(echo $POSTDATA | cut -d”&” -f$FIELD)
VARIABLE=$(echo $DATA | cut -d”=” -f1)
VALUE=$(echo $DATA | cut -d”=” -f2)

if [ $VARIABLE = id ]
then
ID=$VALUE

elif [ $VARIABLE = sensor ]
then
SENSOR=$VALUE
echo “$VARIABLE=$VALUE” > ../weather_data/”$ID”_$SENSOR.txt

elif [ $VARIABLE = temperature ]
then
WHOLE=$(echo $VALUE | cut -c 2-4)
DECIMAL=$(echo $VALUE | cut -c 5)
CELSIUS=$(echo $WHOLE.$DECIMAL)
VALUE=$(echo “$CELSIUS * 1.8 + 32″ | bc -l)
echo “$VARIABLE=$VALUE” >> ../weather_data/”$ID”_$SENSOR.txt

elif [ $VARIABLE = humidity ]
then
WHOLE=$(echo $VALUE | cut -c 3-4)
DECIMAL=$(echo $VALUE | cut -c 5)
VALUE=$(echo $WHOLE.$DECIMAL)
echo “$VARIABLE=$VALUE” >> ../weather_data/”$ID”_$SENSOR.txt

elif [ $VARIABLE = battery ]
then
echo “$VARIABLE=$VALUE” >> ../weather_data/”$ID”_$SENSOR.txt

elif [ $VARIABLE = rssi ]
then
echo “$VARIABLE=$VALUE” >> ../weather_data/”$ID”_$SENSOR.txt

else
sleep 0
fi

(( FIELD++ ))

done

This reads the raw POST data, then steps through “if” handlers I kludged together to look for each data type.  Grabbing additional data from other sensors would be done just be adding additional handlers for each data type (wind speed, rainfall, etc.).  The script then dumps the data out to files named based on the MAC address and sensor ID’s to a writable directory. I can then query this data from other scripts, or POST it elsewhere (like weather underground, etc.).  Personally, I have a whole web app I’ve written for my IP thermostat that I WAS using external data for the display of outdoor temp/humidity.  Now I’m using ACTUAL data from my AcuLink sensors.   The above script returns just a simple SUCCESS to the Internet Bridge, but the bridge doesn’t seem to care, it just keeps on truckin’ sending more data.  A side-effect to this setup is that your bridge won’t update it’s firmware (possibly breaking any reliance you have on the current behavior) unless you remove your custom DNS entries and let it talk to the “real” Acu-Link web service.

Now, you could stop there and call it a day, but the obvious con to this setup is that Acu-Link’s MyBackyardWeather no longer gets your weather data, and the out-of-the-box graphing, weather forecast’s, mobile apps, etc. are pretty cool.   With a SIMPLE addition to my script, I added the original functionality back in by using curl to POST the data to the “real” web service (in addition to stepping through it locally).  Here’s the addiiton:

curl -d “$POSTDATA” http://acu-link.com/messages/ > /dev/null

Notice I used “acu-link.com” instead of “www.acu-link.com”.  This means our override of the www hostname won’t affect our scripts ability to reach the “real” web service.  A quick visit to MyBackyardWeather confirmed it was again getting fresh data.

In summary, AcuRite makes some great weather hardware, and their Internet Bridge and associated sensor’s are no exception.  I wish they would have built this system a bit more “open” and permitted a simple GET request to the bridge for sensor data, but this product is also very new, and they are very encouraging to their users to suggest new features, etc.  There is even mention that they may offer the ability to query this data directly in the future, but in the meantime: hack-on :P

  • Vince Rounds

    December 14th, 2012

    Wow…..You could never tell you work in IP!!! Your concise explanation was waaayyyy over my head. I bought a AcuRite 01515 weather station and am thinking of getting one of the bridges. Can I plug in the power, connect to my router, and start getting info from the station over a pc computer AND an iphone/ipad? The reason I ask, and pardon my ignorant questions, is because I have a Foscam camera that we set up to monitor when away from home on an iphone,and I’m always having to keep changing the IP addy on my computer to be able to access it. Will I run into the same problem with this, or is it truly “plug n’ play” ?

  • Rich

    December 15th, 2012

    This actively sends data to the acu-link website by default regardless of NAT/IP, so you won’t have to keep changing your IP like you do for your foscam.

    -Rich H.

  • Spencer

    December 15th, 2012

    I am having trouble getting the bridge to work.
    The lights are both steady. Blinks once maybe every 2 minutes. My Actiontec router GT724WG shows the Mac address as 24:C8:6E:00:00:00 instead of 24:C8:6E:01:0B:54. I can view the web page of the bridge. So far tech support at Acu-Rite has not been that helpful. Any help would be greatly appreciated.

  • Rich

    December 18th, 2012

    Hi Spencer,

    Is the full MAC displayed for other interfaces on your network? It could be a physical network issue, or a faulty bridge if the MAC isn’t showing completely and is showing for other devices.

    -Rich H.

  • Timothy C

    January 9th, 2013

    Thanks for the great info. I have run with your idea and am currently developing a php solution with a database driven front end. I have two questions.

    1. Have you decoded the data values from the bridge. It appears to send 13 different bridge values.

    2. Have you experienced the bridge sending data to your rerouted DNS entry for about 5 minutes and then reverting to sending to the my backyard weather link? I am wondering if they have a hardcoded IP address or Secondary DNS server.

    Thanks! If you are interested in the code I would be happy to share.

  • Rich

    January 10th, 2013

    Hi Timothy,

    I have not decoded the data from the bridge itself. I know at a minimum it’s sending pressure, but when I tried to correlate the known pressure values with the data sent, nothing was immediately obvious. I have not experienced the bridge sending data to a different IP intermittently. Are you sure your bridge is only querying a single recursive DNS server for your override?

    I would love to see the code. Please feel free to link to it in a comment here.

    -Rich H.

  • Timothy C

    January 12th, 2013

    Hi Rich,
    Thanks for the reply. I think I have gotten close with the Barometric Pressure. It is not exactly what their site shows as I think they are making a correction based on region. I emailed the company to see if they would give me the spec for the variables. Long shot but worth a try.

    I also figured out my intermittent problem. It was just a DNS issue.

    Can you send me your email address so I can send you a link to my server to check out the working copy.

  • eas

    January 27th, 2013

    For what it is worth, I think they have some algorithm for calculating the barometer adjustment based on 12-hours to 14-days worth of accumulated data.

  • Bruce

    April 18th, 2013

    Hi!

    Do you know if the bridge posts data for all sensors in range, or just the 3 sensors that you can have configured on your aculink account at any one time?

    Cheers,
    B

  • Bruce

    April 18th, 2013

    PS. My Billion router has a multitude of advance settings, but I’m not sure if any of them is techspeak for “Use this DNS (eg. ISP’s) except for this specified address (ie. aculink.com) which should redirect to this address (ie. my local computer)”. Is there such a thing? :)

  • Rich

    April 19th, 2013

    Hi Bruce,

    I don’t have more than 3 devices, so I’m not sure. Great question though.

    -Rich H.

  • Rich

    April 19th, 2013

    Bruce,

    Depends on the router, as in, it varies from model to model.

    -Rich H.

  • Bruce

    April 20th, 2013

    My router has a whole bunch of settings. They have names including:
    policy routing
    static route
    RIP
    DNS proxy
    Static ARP
    IP filtering
    One-to-One NAT

    But I get the feeling they won’t do the trick…

    From fiddling about with my various sensors, and due to glitches in the aculink dashboard that sometimes end up showing me data from four sensors, I get the feeling the bridge must report all sensors but aculink might only actively store the data for three…

  • George

    May 7th, 2013

    Have you done anything more with this?

    Since I’ve discovered the bridge loses data if the internet goes down during severe weather, I thinking of using a raspberry pi to buffer data until the connection comes back up.

    I assume you execute that script via a web server, or is there a more clever way?

    Thanks!

  • Rich

    May 7th, 2013

    I use a web server to exec the script. Pi would be more than sufficient to buffer the data, but I think the time stamp is on the remote side, so you’d effectively be delivering a whole bunch of different data points all at once. .

    -Rich H.

  • George

    May 14th, 2013

    True.

    I’m figuring I might have to throttle the data once the connection comes back up.

    Another possibility is that I might just “summarize” the data if necessary…. say into 15 minute intervals.

    Heck, I might just bypass MBW and send the data directly to Wunderground in RapidFire format.

    Or both.

    My main goal, though, is just to preserve the amount of rain fallen.

  • George

    May 18th, 2013

    Timothy C was looking for some info about how certain values are calculated.

    This spec sheet might be helpful.

    http://www.weatherequipment.com/assets/images/PDF/Five-in-One-Professional-Weather-Station-Specifications.pdf

  • Bob

    May 24th, 2013

    Has anyone made any more progress on decoding the pressure data?

    I’ve created a PHP script to capture the data from the bridge and the pressure data is really the last piece. I did some searching and the calculations for the EPCOS T5400 look close as does the MS5535C, but neither are quite right.

  • George

    May 25th, 2013

    Bob-

    I haven’t been able to decode the pressure data yet, but I’m interested in the code you’ve got so far for interpreting the data.

    I’ve finished up my Raspberry Pi tonight and it’s putting out great data stripped from the network directly without any trickery. (No DNS, no DHCP, no Web server, no proxy) I just now need to figure out how to interpret everything.

    Here’s a sample of what the Pi currently spits out:

    id=24C86E017A74&mt=pressure&C1=495B&C2=0DCC&C3=011F&C4=0273&C5=85F8&C6=17C0&C7=09C4&A=08&B=22&C=06&D=07&PR=982E&TR=84E0{
    id=24C86E017A74&sensor=09093&mt=tower&humidity=A0570&temperature=A018300000&battery=normal&rssi=2
    id=24C86E017A74&sensor=00770&mt=5N1×38&windspeed=A003730000&humidity=A0610&temperature=A017888888&battery=normal&rssi=1
    id=24C86E017A74&sensor=09093&mt=tower&humidity=A0570&temperature=A018300000&battery=normal&rssi=2
    id=24C86E017A74&sensor=00770&mt=5N1×31&windspeed=A003270000&winddir=C&rainfall=A0000000&battery=normal&rssi=1
    id=24C86E017A74&sensor=09093&mt=tower&humidity=A0570&temperature=A018300000&battery=normal&rssi=2

  • Bob

    May 26th, 2013

    George,

    The decoding of the values is described in the article.

    I cleaned up my PHP scrip and posted it here: http://www.bobshome.net/acu-link/acu-link_parse.zip I’m not really doing anything with the data other than saving it in a file. My goal would be to dump it to a database and also try to feed weather underground directly, but I need the pressure data before I’ll do that.

    Based on information on the T5400, I’m pretty sure the C1 – C7 values are constant calibration information and PR is the raw pressure value from the sensor. However the T5400 has 8 constant calibration values so their calculation doesn’t work. The MS5535C has 6 calibration values so it’s not quite right either.

  • George

    May 26th, 2013

    I’ve got the pressure working. At least absolute pressure that agrees with MBW.

    I used this data sheet for the formulas:
    http://www.hoperf.com/upload/sensor/HP03S.pdf

    I just made an educated guess picking it based on the specs. I’m not sure it’s actually the right data sheet. However, the formulas seem to work.

    What’’s goofy is that they list D1 and D2. These seem to be the values PR and TR coming from the bridge.

    Here’s my code for parsing the data. It’s a mess, but it works. I’m sure there’s probably a better way to do this. Maybe later I’ll clean it up and put in some more comments.

    #!/usr/bin/perl

    $celsius = ‘*’;
    $farenheit = ‘*’;
    $humidity = ‘*’;
    $windspeed = ‘*’;
    $winddir = ‘*’;
    $rainfall = ‘*’;
    $raintotal = ‘0′;
    $pressure = ‘*’;
    $pressure_in = ‘*’;

    while ($line = )

    {

    $index = index ($line, ‘mt=pressure’);
    if ($index != -1)
    {
    $c1 = substr $line, index ($line, ‘C1=’) + 3, 4;
    $c2 = substr $line, index ($line, ‘C2=’) + 3, 4;
    $c3 = substr $line, index ($line, ‘C3=’) + 3, 4;
    $c4 = substr $line, index ($line, ‘C4=’) + 3, 4;
    $c5 = substr $line, index ($line, ‘C5=’) + 3, 4;
    $c6 = substr $line, index ($line, ‘C6=’) + 3, 4;
    $c7 = substr $line, index ($line, ‘C7=’) + 3, 4;
    $a = substr $line, index ($line, ‘A=’) + 2, 2;
    $b = substr $line, index ($line, ‘B=’) + 2, 2;
    $c = substr $line, index ($line, ‘C=’) + 2, 2;
    $d = substr $line, index ($line, ‘D=’) + 2, 2;
    $pr = substr $line, index ($line, ‘PR=’) + 3, 4;
    $tr = substr $line, index ($line, ‘TR=’) + 3, 4;

    $c1 = hex ($c1);
    $c2 = hex ($c2);
    $c3 = hex ($c3);
    $c4 = hex ($c4);
    $c5 = hex ($c5);
    $c6 = hex ($c6);
    $c7 = hex ($c7);
    $a = hex ($a);
    $b = hex ($b);
    $c = hex ($c);
    $d = hex ($d);
    $pr = hex ($pr);
    $tr = hex ($tr);

    $d1 = $pr;
    $d2 = $tr;

    if ($d2 >= $c5)
    {
    $dut = $d2-$c5-(($d2-$c5)/2**7) * (($d2-$c5)/2**7)*$a/2**$c;
    }
    else
    {
    $dut = $d2-$c5-(($d2-$c5)/2**7) * (($d2-$c5)/2**7)*$b/2**$c;
    };

    $off = ($c2 + ($c4 – 1024) * $dut / 2**14) * 4;
    $sens = $c1 + $c3 * $dut / 2**10;
    $x = $sens * ($d1 – 7168) / 2**14 – $off;
    $p = $x * 10 / 2**5 + $c7;

    $t = 250 + $dut*$c6/2**16-$dut/2**$d;

    $pressure = sprintf (“%.0f”, $p / 10);
    $pressure_in = sprintf (“%.2f”, $p / 338.6 );
    };

    #
    # Wind direction is reported as a single hex digit
    #

    $index = index ($line, ‘winddir’);
    if ($index != -1)
    {
    $winddir_frag = substr $line, $index + 8, 1;
    $winddir = hex ($winddir_frag) * 22.5 ;
    };

    $index = index ($line, ‘rainfall’);
    if ($index != -1)
    {
    $rainfall_frag = substr $line, $index + 10, 6;
    $rainfall = $rainfall_frag * 0.0001;
    $raintotal = $raintotal + $rainfall;
    };

    #
    # Wind speed is reported as centimeters per second
    # Convert to miles per hour by dividing by 44.7
    # Rounded to nearest MPH
    #

    $index = index ($line, ‘windspeed’);
    if ($index != -1)
    {
    $wind_frag = substr $line, $index + 11, 5;
    $windspeed = sprintf (“%.0f”, $wind_frag / 44.7);
    };

    if (index ($line, ‘temperature’) != -1)
    {
    $temp_frag = substr $line, index ($line, ‘temperature’) + 13, 4;
    $celsius = $temp_frag / 10;
    $farenheit = $celsius * 9/5 + 32;
    };

    if (index ($line, ‘humidity’) != -1)
    {
    $humid_frag = substr $line, index ($line, ‘humidity’) + 11, 3;
    $humidity = $humid_frag / 10;
    };

    print “33[2J”; #clear the screen
    print “33[0;0H”; #jump to 0,0

    use POSIX qw(strftime);
    print strftime(“%a, %d %b %Y %H:%M:%S %z”, localtime(time())) . “\n”;

    print “\n $line \n”;
    print “temperature F = $farenheit\n”;
    print “humidity % = $humidity\n”;
    print “wind speed MPH = $windspeed\n”;
    print “wind direction degrees = $winddir\n”;
    print “rain in last 36 seconds in inches = $rainfall\n”;
    print “total rain since last restart in inches = $raintotal\n”;
    print “absolute pressure in mmHg = $pressure\n”;
    print “absolute pressure in inHg = $pressure_in\n”;
    };

  • Bob

    May 27th, 2013

    George,

    The image of the HP03S in the datasheet matches the device that is in the display unit I have. I didn’t want to mess with the bridge so I took apart the display unit to see if it had any markings that would identify the part. The others look close, but the HP03S looks exactly like what’s there.

    That formula is working for me too. Great detective work to find the sensor!

  • George

    May 27th, 2013

    Just had a significant rain event. It’s clear my interpretation of the rain data isn’t correct.

    I thought it was the amount received during a 36 second period, but it’s obviously is based over a longer time period.

    I’ve been logging the data from the sensors, so hopefully it will become clear.

  • Bob

    May 27th, 2013

    We might get rain today, but if not, the chances of any rain before Oct/Nov is slim. So I probably won’t be much help with that.

    I’ve noticed that the Acurite corrected pressure is about 81.6mb more than the absolute pressure reported by the bridge. The corrected pressure seems to match well with other sites around me.

  • George

    May 27th, 2013

    My understanding is that the “corrected pressure” is the value “reduced to sea level”, which is the norm for weather station reporting. It takes station altitude out of the picture and allows isobar maps to make sense…. or so I’ve been told.

    AcuRite’s version of corrected pressure uses a patented method with a “learning period” that eliminates the need for a user to enter the station altitude into the device. The formula is outlined in the first data sheet I posted.

    The normal way to get the corrected pressure is to take your station’s altitude into account, but I haven’t looked up the formula for that. Apparently there are different formulas for weather and aviation.

    As for AcuRite’s method, I’ll probably just ignore it. It just seems easier to take station altitude into account than calculating running averages over time for this application.

  • Bob

    May 28th, 2013

    So we did get some rain, not much. I have a few of these logged: A0000254 since it is supposed to tip every .01 inches, that looks like .0254 cm.

    I’m going to try the “Self adjusting” method for pressure compensation, but over a longer period. When I tried some of the altitude corrections it seems backwards and not enough.

    Like I posted above, I need to add about 81.6 mb to my readings to match other local stations. The site I found that would do altitude (and position) adjustments wanted to subtract about 43 mb from my reading.

  • George

    May 28th, 2013

    Yeah. That’s what I’m seeing for rain…multiples of 254.

    That surprises me as I was expecting it just to be the number of bucket tips.

    Have you considered a third-party package for reporting and graphing? I’m looking into the possibility of using weewx, but I’m not sure I fully grasp how to pass the data to the program.

    The author says I can either populate their database and execute their report engine, or write a “driver” to interpret the data stream. Apparently it sounds like a simple to task to him, but he’s using Phython lingo of which I know next to nothing.

  • George

    June 2nd, 2013

    I’ve got the AcuRite bridge data reporting every minute to wunderground. I haven’t implemented rapid-fire yet.

    The experimental station is KNEPERU3

    The “normal” station is KNEPERU2

  • Bob

    June 9th, 2013

    I also now have the bridge reporting to Wunderground at about 1 minute intervals. I have one more change I want to make. Right now I wait until I have all the data I need from the bridge before sending it, but I want to synchronize it with the pressure since that comes from the bridge at 1 minute intervals. KCAELDOR15 is my experimental station.

    One of the big advantages I’m getting with this set up is that I get more correct humidity values. My 4n1 sensor is broken and reports 98% humidity constantly. I have a tower sensor mounted under the 5n1 and can use the humidity value from that.

    Since I’m hijacking the http://www.acu-link.com name with my name server and I also use comcast name servers the bridge does occasionally get the real address and bypasses my hijacking. I’ll need to work on that.

    Next I want to dump the data into a database. I have a local mysql server running so i’ll just add a table to that for weather data. the only charting/graphing I’ve done has been web based and I’ve been using phpgraphlib for that. Right now I just want the weather data as input in my home automation system so charts/graphs aren’t a priority.

  • Bob

    June 14th, 2013

    An update:

    I switched from hi-jacking the the http://www.acu-link.com name to using a Raspberry Pi as a network sniffer between the bridge and my router. I’ve had it running for a bit over 24 hours and so far it’s working great.

    I’ve updated my script to do the follow:

    Write the data to a local (on my network) MySQL database. I’m dumping a record approximately each minute. I’m using the database to collect the data that comes in at various times from the bridge and consolidate it into a single dataset with pressure, temperature, humidity, wind speed/dir, wind gust speed/dir, rainfall (hr, day), and dew point.

    I’m using the pressure data from the bridge as a trigger, when I get the pressure data I send out the previous data set and start collecting a new one.

    I’m sending the data set to Weather Underground and to WeatherBug.

    I’m collecting the uncorrected pressure data in a separate database table and using the correction algorithm to adjust the pressure to local altitude/location. But instead of a 14 day learning period I’m using a 28 day period. I figure more is better, right?

    I’m only seeing one minor problem. Occasionally the bridge fails to send the temp/humidity data from the 5n1 (probably because it doesn’t see the data from the sensor). Since this is supposed to come at 36 second intervals, I should always see at least one report in the 1 minute intervals between pressure readings. I’m only seeing this happen a couple of times a day. This may be a sign that the batteries in the 5n1 are getting weak. They’ve been in there for a year and half I think.

    I think my Raspberry setup is a bit different from George’s so we should probably compare notes and document this so others can duplicate this type of set up.

    I’ve started a web site to document this, but it’s currently short on details and mostly a place where I’ve been collecting some notes. http://www.bobshome.net/weather/

  • Ray Pfaff

    November 9th, 2013

    Hate to necro an old thread, but how exactly did you get your original script to execute? I have Apache on a Linux box running mythtv already and so far I’ve used mod rewrite to change a url with “messages” in it to execute a “messages.sh” script. However, if passed a URL that has the trailing slash (“messages/”), I get a 404 error where messages.sh/ not found. It would _seem_ to be as simple as adding the trailing slash into the rewrite command, but it doesn’t appear to fix the issue. It’s like Apache treats URLs with trailing slashes as directory requests no matter what.

  • Kevin Key

    November 12th, 2013

    Thanks for the very useful info. I’m almost done creating a Windows version of an app that sniffs the bridge data packets and posts to Weather Underground.

    I did find an issue with the logic that translates the wind direction into degrees. Doing the math on the HEX values was working for some directions and not for others. Anyways, I ended up coding a series of CASE statements and I got it working properly.

    L H D
    - - -
    N 5 0
    NNE 7 22.5
    NE 3 45
    ENE 1 67.5
    E 9 90
    ESE B 112.5
    SE F 135
    SSE D 157.5
    S C 180
    SSW E 202.5
    SW A 225
    WSW 8 247.5
    W 0 270
    WNW 2 292.5
    NW 6 315
    NNW 4 337.5

    BTW, I have coded the logic to calculate the dew point – if anyone wants it. VB.NET and “temperature” is in Fahrenheit.

    dewpoint = ((((temperature – 32) / 1.8) – (14.55 + 0.114 * ((temperature – 32) / 1.8)) *
    (1 – (0.01 * humidity)) – ((2.5 + 0.007 * ((temperature – 32) / 1.8)) * (1 – (0.01 * humidity))) ^ 3 -
    (15.9 + 0.117 * ((temperature – 32) / 1.8)) * (1 – (0.01 * humidity)) ^ 14) * 1.8) + 32

    -Kevin

  • Rich

    November 12th, 2013

    Hi Ray,

    I used a ScriptAlias:

    ScriptAlias /messages/ /fullpathhere/toyour/webroot/index.cgi

    and make sure you turn on ExecCGI for that dir as well.

  • Ray Pfaff

    November 12th, 2013

    Doh… Thanks Rich! I was trying to make this too complicated!

  • George D. Nincehelser

    December 4th, 2013

    FYI- I’ve been getting comments about wind direction being wrong from people using the code I posted above.

    The problem is that I assumed “North” was digit “0″. That’s incorrect. North is actually “5″, so all the directions are off.

    The current corrected code can be found here: http://nincehelser.com/ipwx

  • Ray Pfaff

    December 7th, 2013

    I added some code to George’s for windchill and heat index. The idea here is to have one value that’s either windchill, heat index, or temp depending on outside conditions. The formula’s from wikipeda. I may have a perl error in “feelslike” as it’s not a testable condition this time of year in DC. Windchil’s pretty close to what acu-rite has on its webpage

    # temp 3
    if ($farenheit 3) {
    $v = $windspeed**0.16;
    $wc=35.74+(0.6125*$farenheit)-(35.75*$v)+(0.475*$v*$farenheit);
    $windchill = sprintf (“%.2f”, $wc);
    }
    print “wind speed MPH = $windspeed\n”;
    print “winchill F = $windchill\n”;
    # feelslike is when f > 70
    if ($farenheit > 70) {
    $f= $farenheit;
    $h= $humidity;
    $feels= .3634+(.9986*$f)+(4.7711*$h)-(.1140*$f*$h)-(.0009*($f**2))-(.0207*($h**2))+(.0007*$h*($f**2))
    +(.0003*$f*($h**2));
    $feelslike = sprintf(“%.2f”,$feels);
    }

  • Ray Pfaff

    December 7th, 2013

    Hmmm, parts of the top of code block didn’t copy. It should be when temp 3 MPH

  • Ray Pfaff

    December 7th, 2013

    Ah I get it, the post allows embedded html lt 50F, gt 3

  • Mike

    December 25th, 2013

    I have the Acurite 5 in 1 and cannot find the MAC address on the console. Wa it on a sticker that fell off or can I find it somewhere else?

  • Matt

    December 26th, 2013

    I’m curious if you captured the firmware (by way of packet intercept or via the URL the bridge uses)? Perhaps that would reveal some clues? I was curious if it may respond to SNMP requests. I may end up just sniffing the traffic using my Linux box and getting the data as you posted here. This is a great writeup.

    Mike, as far as the MAC address, it should be on the bottom of the Internet bridge. It’s very obvious, on a white sticker on the bottom of the “Acu-Link Internet Bridge”. I doubt there is any way the sticker would fall off.

  • Lakshmi Aiyer

    January 5th, 2014

    Great write-up. Thanks sharing. I am building system similar to Bob’s(Pi based embedded server collecting data)

  • Joseph

    January 15th, 2014

    Interesting thread! Thanks for the report.

    I’ve seen other sites talking about trying to decode the data coming from the sensors. But that of course involves the rf side of things. Seems more complicated, esp if multiple sensors are involved, imho.

    I’m curious about all this because I want to have 5 (or more!) tower sensors running. Acurite said I could simply buy another bridge for another three sensors. This seems expensive and limited, and thus kinda dumb.

    I began to wonder if this limitation to 3 devices per bridge is arbitrary. Esp. after looking at the web interface of the bridge and noticed as you did that it shows every sensor within rf range. It doesn’t matter what sensors you’ve selected on the acu-link monitoring site for a particular bridge. Or even if you are connected to their service. Thus the conclusion that I’ve come to, supported by your research, is that the bridge spews everything it hears up to the server, and Cheney arbitrarily lets you only pick 3 sensors to listen to.

    If the goal is lots of sensors and one bridge, the acu-link site becomes a bit irrelevant, except for firmware updates. Thus maybe the goal would be to build a little server to spoof the whole Cheney end of things, and do whatever with the data.

    I wonder if there are any secret commands in the bridge to request the sensor data as a web page?

    Other thing I wonder is how many sensors a site can endure? Sloppy by-hand observation of the two tower sensors I have seems to show slight differences overall in the transmission intervals of each device, and each device alternates slightly longer and shorter with each successive transmission. So the answer is “probably a lot” since the transmitters are always slowly drifting in and out of sync with each other. Mostly out.

    An interesting aside: Bridges have a pressure sensor in them. I assume this is because the weather stations do not, and the remote displays do. So that function must be duplicated in the bridge. Wonder if the pressure reading needs to take place inside for a fairly consistent temp?

  • Richard

    February 3rd, 2014

    Just put up a 5-in-1 (outside) and a tower on the inside of the cottage. I’m now tracking both the inside and outside temps from home (gotta love it). Next summer I’m going to immerse the tower in a waterproof container and drop it into the lake. So I can track the lake temp.. Before next winter I want to get a 3M-50 so I can turn up the temp before we head up.
    I have a question on the amount of data going back and forth between the bridge and acu-link.. Anyone have any info? Also right now it looks like the bridge is sending data every 12 minutes.. anyone know if that is configurable

  • Bob

    February 27th, 2014

    Just to clear up a couple questions from recent comments.

    Based on having a 5n1 and two tower sensors, the bridge is sending the date for all three. As part of its data packet, it includes the sensor ID number so you can figure out which sensor the data is for. There isn’t any way for the bridge to pick which sensors it’s receiving data from so I would suspect that it just sends packets for however many it sees.

    AFAIK, no one has found any way to query the bridge for sensor data. A few of us have requested that type of feature from Acurite. While it would be a very nice to have feature for those of us that want the data locally, I don’t see it happening. The bridge would probably need additional internal storage and it would be a fairly large feature that would need testing and support for every firmware release. What’s the upside for Acurite to do that investment?

    The bridge also has a temperature sensor in side it (well the pressure sensor chip includes that). That data is needed to convert the raw data from the pressure sensor into a corrected reading. The bridge itself doesn’t do any of the calculations, it just sends the raw data from the pressure sensor. I don’t know what the rated temperature range for the sensor is (but I’m sure it’s probably listed on the datasheet … Yup, -40 to 85 C) So if you keep it dry, it should work fine outside, assuming the other components can handle the temperatures.

    The bridge forwards data immediately to the server. It doesn’t do any processing of it. So how much and how often data gets sent really depends on which sensors are attached. This might be listed in a comment above, but I’m going from memory:

    temp/humdity/wind ~ every 18 seconds
    rainfall ~ every 36 seconds
    pressure ~ every minute

    I just collected the raw sensor data over a 2 minute period and it was 2412 bytes. That’s for the 5n1 and two tower sensors. But it doesn’t include any of the http or tcp protocol overhead. So roughly 2MB of data a day.

  • No trackbacks yet

Leave a Comment

* are Required fields