I recently bought a Fitbit Aria scale to complement mine and my wife’s Fitbit Blaze’s. Plus, IoT is cool, right? IoT all the things, or something like that. What isn’t cool is the difficultly I experienced trying to set these things up with my wireless network.
I thought it’d be a simple case of get it home, follow the instructions, and in no time, I’d be sending my weight and bodyfat percent through to my Fitbit account. I got what seemed to be most the way there. It seemed to log into my Fitbit account and seemed to establish a connection to Fitbit. It would seemingly fail at the final step, showing the dreaded “NO SYNC”. I occasionally got a “WiFi ERR” message, but most often it was the NO SYNC.
I followed the initial setup and everything appeared correct. I’m a modern kind of guy, so I did what all modern people do when they encounter problems, I turned to Google with the phrase “fitbit aria sync problems”. Arriving at the Fitbit Community support forums I found thread after thread of the same problem, and a lot of angry customers. Most threads were marked “Solved” with the final resolution being that after about 20 or 30 or more attempts, it eventually connected. The support from the community “experts” (who seemed to just read from the same script) suggested the following:
- Clear your browsers cache.
- Turn your router off and wait 30 seconds before turning your router back on.
- Place your Aria right beside your router.
- If you were using the native app in windows instead try the web method (at https://www.fitbit.com/au/setup/aria, clicking the text “web based set up”)
- Use only alphanumeric SSID and password.
- Light some incense and pray to your god(s) (ok I may have made this step up, but it seems as useful).
It scares me that clearing the browser cache will allow the thing to connect. Does that mean it will stop syncing when my browser cache gets the wrong data in it? The same seems to apply to step 2. What happens when I move my scales away from my router located in my garage, to you know, my ensuite at the other end of the house?
According to the documentation the Aria requires an 802.11b Access Point, and prefers to not connect through a repeater. It’ll connect using WPA2/PSK.
I checked my router settings. I have a Asus DSL-AC68U dual band router with all the bells and whistles. It should connect to that. I first tried with security enabled (standard settings on my router) so I disabled security and opened my AP. That didn’t work so I disabled all the security (firewalls, anti-virus etc) on my router and hoped I didn’t get attacked while I continued to setup. Still didn’t work.
 |
| Asus DSL-AC68U with 802.11b settings |
I then tried to hotspot it to my iPhone 6, after reading the forums and someone saying they have to do it that way. That worked. This meant there was nothing wrong with the scales or my account. A connection was possible.
The obvious conclusion then was that a setting on my router was incorrect. I checked the router logs and it showed the scales were present on as a previously connected device. It could talk to the router. That is a positive sign. Isn’t it? More googling and started down the rabbit hole of ideal advanced settings on my router for 802.11b compatibility. These were settings I’d not heard about before. I got refreshed on the theory behind channels and frequency, and overlap and interference. I started trying settings one at a time and retry the Aria setup. Still nothing. If anything, when it comes to technology and bug finding I am dogged in my determination, especially when it seemed the product was physically working.
If I had some sort of diagnostic of the connection process, I could troubleshoot more effectively. More forum reading and I found another tech guy said that a log file is produced when you click the “Contact Support” link in the app after connection fails. Brilliant. I went through the app config again. Unfortunately, it was throwing an exception when I clicked any link after it failed setup. Dismissing the exception produced another exception with the only way out closing the app. Not great.
I headed back to the Fitbit website and noticed they list their current version as 1.0.4.171, released 09.08.2015. I had version 1.0.4.166 released in May of that year. Unfortunately, clicking on the big pink Download button downloaded an older version! Version 1.0.4.166. My version. I went hunting for 1.0.4.171 and found it on Softpedia. Unfortunately, that version also crashed. When I finally got the log files working I found that the observable difference was that .171 sends requests over https and not http as .166 was using.
 |
| Download version doesn't match advertised version |
A few forum thread readings later I noticed someone say their scales were V39. My scales were V37. Great, possibly a fix if I can update the firmware version of the scales. Off I went in search of the release notes to find out what may have changed. Here are the release notes. My version, V37 isn’t even mentioned. I would expect there would be release notes for every version, not just sporadic versions (28, 31, 32, 38, 39). Perhaps those missing versions were internal builds and never released? That would make sense except that I have version 37, and it isn’t listed.
Frustrated, I took the scales, my laptop, and my iPhone over to my nearby friend’s house to try his router. Of course, it worked first go! Full connection through, with SYNC, and I was weighing myself and it updated my Fitbit account. Perfect. From that I could deduce there was something wrong with my router settings.
Back home, I checked settings again. In the 2.4Ghz band the router had a setting “b/g protection”, which the manual said was to ensure the slower speeds of b/g specifications would work. That sounds like a good thing. My router also has no setting to explicitly put it in 802.11b mode. It does have a “Wireless Mode” parameter with a possible value of “Legacy”. That sounds like something I wanted.
- “Legacy” mode allows b/g/n devices to connect but n devices only run at 54 Mbps.
- “Tick b/g Protection to allow b/g devices to connect without affecting n devices. This increases your routers workload.
I tried Legacy mode and the scales would not connect. I tried Legacy with and without b/g protection.
I have another router, a TP-Link TL-WA90N1N. After a bit of search for the power cord, I plugged that in and set it up with explicit 802.11b only mode – set to a slow 11Mbps. My plan was to place this router in my bedroom and use it only for the scales. I set this AP to run on channel 13 and my Asus AP to run on channel 1. Something I learned in all this was how channels worked and how to get the least amount of interference.
You probably guessed already that this didn’t work! Frustrated, I emailed Fitbit support and received a couple of form letters, suggesting I try X and Y and blah blah blah. Stuff that any monkey would have tried. I explained what I had done so far, documented in a post on the community forums, you can read here.
They sent me a set a new Aria and I repeated the process again. They then asked me a “how was the support” question. I replied that it wasn’t the best, and they sent me another set of Scales! (after sending the same form questions again. Argh). You guessed it, same results when I received those. Now I had three useless $180 scales (yes that’s $540 worth). All I wanted at this point was my money back. I wonder if I continued, woudl they send me yet another Aria?
Back to troubleshooting and I thought that maybe the exceptions being thrown from setup software might be permissions related (long shot). I copied the file to my temp folder (%TEMP% on my Windows 10 machine). I saw some more files appear. It seemed the exe extracted files to %TEMP% and then ran those extract files. Makes sense. I also saw a log file appear! (and didn’t just get dumped to when I clicked the “Contact Support” link – which still crashed the app).
Log Files:
I went back to my friend’s house and got a log file of a successful setup and came back home to get an unsuccessful log. I made as many settings as consistent as I could (e.g. SSID) and then opened the two files in Beyond Compare, a program that shows differences in text files. I couldn’t see much difference. Frustrated, I sent the log files and my current router settings to Fitbit support again.
Their response was that the AP needed to be 802.11b mode and no more than 54Mbps. They highlighted a line from my logfile that showed the AP was running at 130Mbps and I needed to fix my settings. Unfortunately for me and them, that line was from the successful log file! See the line "[2017-03-08 11:43:45] Connection speed for 24 Tancred Place (Office) is 130 Mb/s. Probably 802.11n WiFi router is used." from the "Successful connection" log linked above. Fitbit support don't even know what they are talking about.
 |
| Email from Fitbit showing "...can only connect with a top wireless speed of 54 Mbps." |
By this time, I bought a wireless card (Asus PCE-AC68 – built for optimum compatibility with my expensive router) so I could continue diagnostics from my developer machine on a big monitor, rather than the 13” laptop screen. I had visions of packet sniffing across the wireless to try and workout just exactly what was being sent (using the old 1.0.4.166 which doesn’t use HTTPS, of course – classic man in the middle attack).
I read another forum post in another failure thread that made me think of one last thing. I set my iPhone’s name to “raggedScales” (the SSID I was using for my TP-Link AP, dedicated to the scales) and I opened it up for hot-spotting. I ran through the connection process again and got the typical successful connection. I then renamed my phone back to “Rob’s iPhone” and named my TP-Link AP “raggedScales”, with the same password as I used on the phone. My thinking here was that the scales would have saved that connection information and would try and connect to the “raggedScales” SSID again. It worked! The scales synced through my AP and not my phone.
 |
| Final settings on my TP-Link TL-WA901N router. |
Something I don’t understand then happened. I tried syncing my other 2 sets through that AP and they both worked too. Obviously I restored all my normal security settings on the WAN router (DSL-AC68U) and tested - successfully. Now I have three scales to weigh myself, just in case my weight changed in the kitchen versus the ensuite.
