Topic: Has the old Hub has been been purposely crippled by Acurite at a firmware level?

[Jack Bowman]

My old hub quit working yesterday and others have reported the same thing. (I knew that they discontinued it and received the notice.) It would appear that none of the 3rd party workarounds are functional anymore. It looks as though they did not want us finding a way to still use the products that we paid for in good faith. Why would you do that to us Acurite? What was it hurting you to have folks try to get just a little more use out of their bought and paid for equipment? I hope this bites you in the butt in the end. I am moving on. The only reason I stayed this long was due to the people who wanted to make this equipment something more powerful than Acurite cared to. Just like a mobile phone company they have eliminated the leakage now. I promise you they will more than likely start charging for a service as well as for the cheap hardware. Now that they have "Your" data locked down with encryption, they can do whatever they want. They have provided inexpensive hardware solutions so more folks can afford to get involved with weather monitoring and data collection. I will give them that, and I do appreciate that aspect of their business. Now it would seem that your data is no longer your data. On a positive note, I would like to thank Kevin Key and all the 3rd party developers who coded such brilliant solutions to our needs over the last several years. Thank You!!!

[DoctorKnow]

Looks like we're screwed over all right. I had mine working really well too. I have spent so much time and money on this, and now I may just find a new hobby...

[daman]

Did you guy's firmware number change??

[DoctorKnow]

Application Version   224
Boot Firmware Version   210

Below status will come and go...Five In One Weather Station
 

Identifier	Battery Status	Signal Strength (low 0--4 highest)
		no devices detected

Five In One Weather Station
 

Identifier	Battery Status	Signal Strength (low 0--4 highest)
2164	nominal	4

[galfert]

Wow that just sounds evil. Unless is it possible that the old hub was somehow still reliant on some Acurite server to have remained online and it was finally decommissioned? Did the firmware change? If the firmware didn't change then it is most likely that something from Acurite's cloud was still keeping it alive. So until we know all these facts then we won't know if Acurite acted deliberately or if it was just consequential of them commissioning infrastructure. Maybe there is no way to tell because we can't look a the code that was running to know what was happening. Unless someone has a very good record of some Wireshark captures to reference and find clues.

[nincehelser]

There's zero evidence for the assertion that the firmware was updated.

No one is talking about it except here.

[Storm017]

My hub went down at 13:15 yesterday after running without any issues for over a year and a half.  Every once in a while I do see only one sensor on the splash screen then it disappears. 

Application Version 224
Boot Firmware Version 210

This is what I'm seeing since yesterday:

Apr  5 09:47:50 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 02 04 02 18 00 00
Apr  5 09:47:52 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: timestamp=1554472072.44 pktlen=60 data=e4 f4 c6 01 c1 f2 24 c8 6e 08 36 07 08 00 45 00 00 2c 00 0d 00 00 64 06 15 a9 c0 a8 01 6d 7f 00 00 01 09 91 00 50 b5 33 60 ad 00 00 00 00 60 02 01 90 39 5a 00 00 02 04 02 18 00 00
Apr  5 09:47:52 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 02 04 02 18 00 00
Apr  5 09:47:53 stormRPI3 interceptor[1249]: interceptor: MainThread: empty queue
Apr  5 09:47:56 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: timestamp=1554472076.44 pktlen=60 data=e4 f4 c6 01 c1 f2 24 c8 6e 08 36 07 08 00 45 00 00 2c 00 0e 00 00 64 06 15 a8 c0 a8 01 6d 7f 00 00 01 09 91 00 50 b5 33 60 ad 00 00 00 00 60 02 01 90 39 5a 00 00 02 04 02 18 00 00
Apr  5 09:47:56 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 02 04 02 18 00 00
Apr  5 09:48:03 stormRPI3 interceptor[1249]: interceptor: MainThread: empty queue
Apr  5 09:48:04 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: timestamp=1554472084.43 pktlen=60 data=e4 f4 c6 01 c1 f2 24 c8 6e 08 36 07 08 00 45 00 00 28 00 0f 00 00 64 06 15 ab c0 a8 01 6d 7f 00 00 01 09 91 00 50 23 ec ae 97 7c 60 90 8c 50 14 01 90 83 d8 00 00 00 00 00 00 00 00
Apr  5 09:48:04 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 00 00 00 00 00 00
Apr  5 09:48:04 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: timestamp=1554472084.45 pktlen=60 data=e4 f4 c6 01 c1 f2 24 c8 6e 08 36 07 08 00 45 00 00 2c 00 11 00 00 64 06 15 a5 c0 a8 01 6d 7f 00 00 01 09 92 00 50 48 88 6f e8 00 00 00 00 60 02 01 90 96 c9 00 00 02 04 02 18 00 00
Apr  5 09:48:04 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 02 04 02 18 00 00
Apr  5 09:48:05 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: timestamp=1554472085.45 pktlen=60 data=e4 f4 c6 01 c1 f2 24 c8 6e 08 36 07 08 00 45 00 00 2c 00 12 00 00 64 06 15 a4 c0 a8 01 6d 7f 00 00 01 09 92 00 50 48 88 6f e8 00 00 00 00 60 02 01 90 96 c9 00 00 02 04 02 18 00 00
Apr  5 09:48:05 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 02 04 02 18 00 00
Apr  5 09:48:07 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: timestamp=1554472087.45 pktlen=60 data=e4 f4 c6 01 c1 f2 24 c8 6e 08 36 07 08 00 45 00 00 2c 00 13 00 00 64 06 15 a3 c0 a8 01 6d 7f 00 00 01 09 92 00 50 48 88 6f e8 00 00 00 00 60 02 01 90 96 c9 00 00 02 04 02 18 00 00
Apr  5 09:48:07 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 02 04 02 18 00 00
Apr  5 09:48:11 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: timestamp=1554472091.45 pktlen=60 data=e4 f4 c6 01 c1 f2 24 c8 6e 08 36 07 08 00 45 00 00 2c 00 14 00 00 64 06 15 a2 c0 a8 01 6d 7f 00 00 01 09 92 00 50 48 88 6f e8 00 00 00 00 60 02 01 90 96 c9 00 00 02 04 02 18 00 00
Apr  5 09:48:11 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 02 04 02 18 00 00
Apr  5 09:48:13 stormRPI3 interceptor[1249]: interceptor: MainThread: empty queue
Apr  5 09:48:19 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: timestamp=1554472099.43 pktlen=60 data=e4 f4 c6 01 c1 f2 24 c8 6e 08 36 07 08 00 45 00 00 28 00 15 00 00 64 06 15 a5 c0 a8 01 6d 7f 00 00 01 09 92 00 50 8d 2c cd 7c 7c 60 90 8c 50 14 01 90 fb b1 00 00 00 00 00 00 00 00
Apr  5 09:48:19 stormRPI3 interceptor[1249]: interceptor: ServerThread: sniff: ignore 00 00 00 00 00 00
Apr  5 09:48:23 stormRPI3 interceptor[1249]: interceptor: MainThread: empty queue

[fastracer]

Same here... Was updating weather underground with no issues until 1:20pm yesterday 😥 Any ideas? Lol

[Jack Bowman]

I concur on the time. No evidence, but if it walks like a duck and quacks like a duck...

[nincehelser]

I concur on the time. No evidence, but if it walks like a duck and quacks like a duck...

More likely it's something like a DNS change. 

[daman]

Application Version   224
Boot Firmware Version   210

Below status will come and go...Five In One Weather Station
 

Identifier	Battery Status	Signal Strength (low 0--4 highest)
		no devices detected

Five In One Weather Station
 

Identifier	Battery Status	Signal Strength (low 0--4 highest)
2164	nominal	4

Sooo...do you remember what it was before, DID it change?

[nincehelser]

If I remember the name right, hubapi.myacurite.com now resolves to 127.0.0.1.  That loops back to the SmartHUB.

That would do it.

[Storm017]

As far as I can tell, the firmware was not updated.

[DoctorKnow]

Is there a fix, or should I just get a hammer and have at it?

[Storm017]

One possible fix; there are several options available. 

https://github.com/matthewwall/weewx-interceptor

[nincehelser]

Quick-and-dirty, try putting the IP number of a minimal web server into your local DNS server for hubapi.myacurite.com.

[Jack Bowman]

To no avail. The hubapi.myacurite.com and the original IP address associated with it are not resolving. I made an entry in the local HOST file and pointed it back at the original IP, and then tried a local IP, and finally another random Google IP. It is looking for a proper response to work.

[nincehelser]

To no avail. The hubapi.myacurite.com and the original IP address associated with it are not resolving. I made an entry in the local HOST file and pointed it back at the original IP, and then tried a local IP, and finally another random Google IP. It is looking for a proper response to work.

The host file on your PC?  Is that the machine acting as the DNS server for the SmartHUB?

[Storm017]

To no avail. The hubapi.myacurite.com and the original IP address associated with it are not resolving. I made an entry in the local HOST file and pointed it back at the original IP, and then tried a local IP, and finally another random Google IP. It is looking for a proper response to work.

Try this address: www.acu-link.com   It is one of the addresses from the weewx-interceptor driver.  Don't know if it will work.

[Jack Bowman]

Yes, the Windows operating system can map dns entries and IP address at a local level. They have simply entered the loopback IP number in the hub 127.0.0.1. I tried countering that by directing it back to the correct IP at a software level in the HOST file. I got the original IP for hubapi.myacurite.com from archived information at the online Registrars.

[Jack Bowman]

To no avail. The hubapi.myacurite.com and the original IP address associated with it are not resolving. I made an entry in the local HOST file and pointed it back at the original IP, and then tried a local IP, and finally another random Google IP. It is looking for a proper response to work.

Try this address: www.acu-link.com   It is one of the addresses from the weewx-interceptor driver.  Don't know if it will work.

That web site is now missing

[nincehelser]

Yes, the Windows operating system can map dns entries and IP address at a local level. They have simply entered the loopback IP number in the hub 127.0.0.1. I tried countering that by directing it back to the correct IP at a software level in the HOST file. I got the original IP for hubapi.myacurite.com from archived information at the online Registrars.

For that PC, yes, but the SmartHUB?  Is the PC working as the SmartHUBs DNS and DHCP server? 

[alanb]

It is possible that Acurite could brick the Smarthubs without issuing a new update. They could have included some suicide code with a date trigger in their most recent firmware even if that was released some time ago. I have heard of this in other types of devices where the manufacturer wanted a drop dead date or wanted to disable the device for some other reason. I don't even own an Acurite system, so I definitely don't know and am not accusing Acurite of doing this … just offering it as a possible explanation.

[Jack Bowman]

I can assign an IP via the bridged connection or let my local router give it an IP. Each device on a network can specify its own DNS if capable. It would go to the router for the DNS if nothing is specified on the device. The HOSTS file on a windows PC is checked by local IP traffic first. Because the hub is routed through this configuration before getting out to the internet you can control its Domain name resolution as well. The PC in effect becomes a router of sorts. It is not acting as a DNS but it has the ability to modify Domain Name resolution on the fly.
[/quote]

For that PC, yes, but the SmartHUB?  Is the PC working as the SmartHUBs DNS and DHCP server?
[/quote]

[Jstx]

Yeow! The 'Massacre at AcuRite Gulch'... 

I sprung for a 5in1 Pro bundle with the Access, it probably awaits the same fate in a couple of years   .

A very similar tech parallel with the Smarthub was a Seagate "Lyve Drive" (that I bought) that is/was basically a self-contained local-cloud storage microsystem (like an Intel NUC, bigger than a Pi, an OS w/a 2TB hard drive/WiFi/display/etc).
It was marketed as a local-cloud storage system. Seagate decided after a couple of years that it wasn't worth supporting, so they just gave a kill notice and later pulled the necessary cloud IP connection, bricking all of the Lyve devices.
Seagate was decent enough to give a long warning period, provide a migration exit path, and they sent out free 2Tb external drives as compensation. I'm still trying to hack my Lyve and turn it into a standalone system, failing that I'll just extract its' internal 2.5" 2Tb HD.

This kind of technological obsolescence is becoming increasingly common. Maybe the most prolific example are the millions (or billions) of cell phones made useless in many cases by tech changes.
Another cell phone scrapper-factor is the use of non-replaceable Li batteries (in many cases, sometimes you can unsolder one and replace it). I now have several of these damned swollen fire traps that lasted about a year or two when the battery died. The phones themselves are still quite functional, what a waste.

I hope y'all work out yet another work around with this latest AcuRite FUBAR.
This kind of stuff sucks. I think that most of us are...errrm...'senior types', we usually have an appreciation for durable stuff, keeping it running, classic cars and whatever. This rapid product scrap cycle is galling. Computer systems too. How many are running the latest absolute 'state-of-art' computers with the latest $1K+ Intel procs, etc? Why? Mine are all 1 or 2 gens behind (mostly HP biz-class), but do OK.