Acurite Bridge stopped working yesterday

[Jamie Borget]

I noticed yesterday morning my Pi stopped reporting, upon further inspection I could see that acurite updated their zone file so that hubapi.myacurite.com had an a-record of 127.0.0.1.  Well sure I expected this back in March but for some reason my Pi has been working and sending data up until yesterday.  Since I was running the weewx interceptor in sniff mode I figured this isn't going to work anymore.  I went ahead and updated my DNS mapping on my router to send hubapi.myacurite.com requests directly to my Pi.  However things still aren't working and when running the interceptor with the following values I'm getting data but no specific data from my actual 5n1 weather station.  See output below:

root@raspberrypi:~/weewx-interceptor-master# sudo PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/interceptor.py --device=acurite-bridge --mode=listen --port 80 --debug
identifiers: {'bridge_id': '24C86E077FC', 'sensor_type': 'firmware', 'sensor_id': None}
raw data: id=24C86E077FC&mt=firmware&line=0&count=1
raw packet: {'usUnits..24C86E077FC': 17, 'sensor_type..24C86E077FC': 'firmware', 'dateTime': 1554499979, 'dateTime..24C86E077FC': 1554499979, 'bridge_id..24C86E077FC': '24C86E077FC', 'usUnits': 17}
mapped packet: {'usUnits': 17, 'dateTime': 1554499979}
identifiers: {'bridge_id': '24C86E077FC', 'sensor_type': 'firmware', 'sensor_id': None}
raw data: id=24C86E077FC&mt=firmware&line=0&count=1
raw packet: {'usUnits..24C86E077FC': 17, 'sensor_type..24C86E077FC': 'firmware', 'dateTime': 1554500022, 'dateTime..24C86E077FC': 1554500022, 'bridge_id..24C86E077FC': '24C86E077FC', 'usUnits': 17}
mapped packet: {'usUnits': 17, 'dateTime': 1554500022}
identifiers: {'bridge_id': '24C86E077FC', 'sensor_type': 'firmware', 'sensor_id': None}
raw data: id=24C86E077FC&mt=firmware&line=0&count=1
raw packet: {'usUnits..24C86E077FC': 17, 'sensor_type..24C86E077FC': 'firmware', 'dateTime': 1554500066, 'dateTime..24C86E077FC': 1554500066, 'bridge_id..24C86E077FC': '24C86E077FC', 'usUnits': 17}

I'm hoping I'm just missing something simple, and my bridge didn't actually get bricked by some update acurite sent out to existing users of the old bridge.  Thanks in advance.

[rich T]

No it is not bricked, my hub stopped reporting yesterday.  https://www.wxforum.net/index.php?topic=36552.msg375667;topicseen#msg375667

[Jamie Borget]

Thanks for the reply however I’m still having problems getting this working again.  As I’ve mentioned I’ve updated the dns on my router so the requests/posts all reach my pi but I can’t seem to get my pi to accept the requests and or send the expected reply.  As mentioned in my first post all the received data mentions something with firmware.  Almost like it’s trying to do a firmware check or something. And when trying to use the methods mentioned in the article you mentioned my Apache logs all show a 404 when trying to post to /messages/. Any help would be greatly appreciated. 

--
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/0e2E3F7EG7Y/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]

apparently the smarthub/bridge will not report any sensor data unless it has established a connection with one of the acurite servers (or something that responds like an acurite server).  i tested this behavior with a couple of smarthubs - one still running the old firmware (126) and one running the newer firmware (224).  occasionally i would see a sensor in the smarthub's web interface, but for the most part the devices are useless until they talk to the mothership.

the acurite servers used to reply to the smarthub with a simple string:

{"success":1, "checkversion":"126"}

the newer firmware expects a timestamp - probably to ensure that the smarthub time is ok:

{"localtime":"%H:%M:%S", "checkversion":"224"}

if an older hub gets a version number other than 126, then it tries to update the firmware.  presumably the newer firmware would also try to update if it gets version number other than 224, but i have not tested that.

after that initial response from the server, the smarthub starts sending data (in either wu format or chaney format, depending on the firmware version).  those are the packets that we capture in order to collect data.

the interceptor driver will handle these cases so that any smarthub just thinks that the interceptor is an acurite server.

so if your smarthub is running the older firmware, be sure to set the firmware_version=126 parameter, otherwise your hub will probably hang, trying to install the newer firmware (the interceptor does not know the protocol for sending newer firmware - there's a project for a budding reverse engineer, although the market for using it is now shrinking)

acurite shut down the myacurite.com and acu-link.com servers, and put 127.0.0.1 in as the dns entry.  so any smarthub/bridge that attempts to connect to them will resolve the name(s) to localhost, then fail.

this means that now you MUST run the interceptor in listen mode, not sniff mode.  in sniff mode, the interceptor does not interact with the smarthub, so the smarthub hangs when it tries to contact itself (localhost) since there are no acurite servers.  in listen mode, the interceptor looks like an acurite server, so the smarthub responds and data flows.

so you must make a dns entry for hubapi.myacurite.com and www.acu-link.com that points to the machine running the interceptor, and you must ensure that traffic on port 80 goes to the interceptor.  the easiest way is to put the dns override in your router's configuration, and make the interceptor listen on port 80.  but if you already have a web server running on port 80 on the same computer as the interceptor, then you'll have have to set up a reverse proxy on the web server for the acurite urls, or run the web server on a different port, or one of many other options explained in the interceptor readme.

btw, you can continue to use smarthub with new acurite sensors - until acurite changes their RF protocols, those smarthubs still have a many years of life left in them, even though acurite has abandoned those who purchased them.  acurite is not likely to change the RF protocols, since even the latest wifi consoles still know how to talk to them.  (this is not unlike the situation where open source software has given extended life to those old rt45g routers)

the remote sensors are pretty cheap - i've seen them for as little as $5 each at walmart.  and although you could skip the smarthub altogether by using a usb sdr dongle, in some cases it might be easier/cheaper to use an acurite bridge instead of the sdr.

hope that helps,

m

[mwall]

On Saturday, April 6, 2019 at 11:15:14 AM UTC-4, Jamie Borget wrote:

And when trying to use the methods mentioned in the article you mentioned my Apache logs all show a 404 when trying to post to /messages/. Any help would be greatly appreciated. 

if you must run apache on port 80 on the pi, then you must make apache reverse proxy any request for /messages/ to the port that the interceptor is listening on

if you don't mind running your web server on a different port, then run the interceptor on port 80 and your web server on port 8080 or 8000 or whatever.

another option is to run nginx listening on port 80, with reverse proxy for /messages/ to the port the interceptor is running on, and reverse proxy for everything else to whatever port apache is running on.  (i tend to use a configuration like this for servers that are public-facing, since it provides better control and security when you run multiple web services such as influx or grafana or php-stuff-on-apache)

m 

[Jamie Borget]

Thanks for the information, unfortunately I think my bridge may be in an unrecoverable state.  I tried as you suggested and set the interceptor to respond with both firmware version 224 and 126 (one at a time) and I could see the desired responses when browsing to it on my computer with responses looking like {"success":1, "checkversion":"126"} and {"localtime":"%H:%M:%S", "checkversion":"224"}so it appears the interceptor is working as designed.  But the data captured in the interceptor logs is the same as was originally pasted in my first post.   However I just tried browsing to my acurite smart hub (which I didn't know you could do) and this is the status shown with attached screenshot. Please let me know if you've seen this before or if you know if it's recoverable.  I really appreciate you taking the time to help.  Thanks

--

[mwall]

On Saturday, April 6, 2019 at 9:24:20 PM UTC-4, Jamie Borget wrote:

However I just tried browsing to my acurite smart hub (which I didn't know you could do) and this is the status shown with attached screenshot. Please let me know if you've seen this before or if you know if it's recoverable.

that is the status page for the 224 firmware when it is trying to download firmware.  if you power cycle the bridge it should go back to a normal state.

1) set the interceptor to firmware_version=224 (or just don't set it - it defaults to 224)

2) ensure that the interceptor is responding by putting these urls in a web browser:  

http://hubapi.myacurite.com

http://www.acu-link.com

i am pretty sure that you only need the myacurite mapping for firmware 224 and acu-link mapping for firmware 126, but do them both to be safe

3) remove power from the acurite bridge

4) power on the acurite bridge

5) in a web browser enter http://x.x.x.x where x.x.x.x is the url of the acurite bridge

i have updated the wiki page based on this thread:

https://github.com/weewx/weewx/wiki/acuritebridge

 

[Jamie Borget]

Yeah I’ve tried power cycling the bridge many times (even unplugging for extended periods of time between power cycles)  but unfortunately it just won’t get out of the attempting to download firmware step.  The only packets the bridge sends out do go to the Pi via the dns entry for hubapi.myacurite.com but it only contains the post to /messages/ regarding firmware.  I can see the proper responses when browsing to hubapi.myacurite.com so I don't doubt that the interceptor is doing it's job.  It's sad that my bridge appears to be bricked but I don't have a way to flash firmware nor have I figured out a way to get it out of this state.   Thanks for taking the time to review, let me know if you have any other ideas, but if not I still really appreciate the assistance.

--

[mwall]

On Monday, April 8, 2019 at 6:47:52 PM UTC-4, Jamie Borget wrote:

It's sad that my bridge appears to be bricked but I don't have a way to flash firmware nor have I figured out a way to get it out of this state.

try press and hold of the register button for 12 seconds (power off for 2 minutes is supposed to do the same thing, but who knows?)

check this to see if the blinking light pattern gives you any clue:

https://www.acurite.com/media/manuals/aculink-instructions-2.pdf

[Jamie Borget]

Unfortunately no luck, I had tried that myself earlier hoping to reset things but it seems to be stuck on trying to acquire the firmware. I was able to get another base unit that has the usb out so I was able

to get things up and running again but it looks like this bridge is done. Thanks for all your help mwall and your contributions to weewx you make the community great.