A few have decoded that there are two main USB messages, (2) type1 (smaller ~8 bytes) and a larger type 2 ~25 bytes.

Since I can take the USB direct to my Pi and decode the two smaller ones, I’m trying to get the deeper data they have on the larger message (which also has their pressure calculations in Pascal no less).

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.

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?

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.