Simulator Failed to Start - Connection Refused.

[SunsetRunner]

Installed the simulator yesterday and it worked great.  But today I get "Simulator failed to start: connect ECONREFUSED 127.0.0.1:63981   The studio sees the simulator and says its connected thou, but list new available devices.

[LiamFitbit]

VirtualBox is known not to work due to issues with its virtual graphics driver. Other virtualisation solutions such as VMWare are likely to work better.

[SPLUS1]

I'm getting the same error on Win10 v1809 w/ Intel Chipset & Intel HD Chipset (Video).

[JonFitbit]

---

@SPLUS1 wrote:

I'm getting the same error on Win10 v1809 w/ Intel Chipset & Intel HD Chipset (Video).

---

Can you message me the logs?

OS X: ~/Library/Logs/Fitbit OS Simulator/log.log

Windows: %USERPROFILE%\AppData\Roaming\Fitbit OS Simulator\log.log

[SinEire]

I'm on MacOS.

I get a similar error.

Here's an excerpt from my log.log:

[2019-01-03 18:26:03.861] [warn] 10 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:03.863] [info] companionhost->companion: {"method":"devbridge.status","params":{"status":"initialized"},"jsonrpc":"2.0"}
[2019-01-03 18:26:03.916] [info] Shell Client connected
[2019-01-03 18:26:03.917] [info] shell->companion: {"id":0,"method":"initialize","params":{"capabilities":{"protocol":{"maxMessageSize":536870912}}},"jsonrpc":"2.0"}
[2019-01-03 18:26:03.917] [info] companion->companionhost: {"id":0,"method":"initialize","params":{"capabilities":{"protocol":{"maxMessageSize":536870912}}},"jsonrpc":"2.0"}
[2019-01-03 18:26:03.918] [info] companionhost->companion: {"id":0,"jsonrpc":"2.0","result":{"capabilities":{"protocol":{"maxMessageSize":536870912}}}}
[2019-01-03 18:26:03.919] [info] companion->shell: {"method":"devbridge.status","params":{"status":"initialized"},"jsonrpc":"2.0"}
[2019-01-03 18:26:03.922] [info] companion->shell: {"id":0,"jsonrpc":"2.0","result":{"capabilities":{"protocol":{"maxMessageSize":536870912}}}}
[2019-01-03 18:26:04.853] [warn] 9 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:06.856] [warn] 8 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:09.860] [warn] 7 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:13.868] [warn] 6 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:18.878] [warn] 5 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:24.912] [warn] 4 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:31.925] [warn] 3 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:39.939] [warn] 2 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981
[2019-01-03 18:26:48.953] [warn] 1 retries left: Error: connect ECONNREFUSED 127.0.0.1:63981

[MolliorMerx]

FWIW, I was getting the same error this morning -- Windows 10 / Chrome -- after a fresh reboot. Restarting simulator app did nothing.

I renamed the log file in order to capture new stats and it just started working.

[GooseyVarga]

Has anyone gotten this fixed? I have the same issue with Windows 10. 

[Crazyal01]

Wow this issue still exists.  Did anyone come up with a solution?

[SunsetRunner]

I think it is clear that the fitbit SDK is hopeless. I don't see anyone
actively developing and the gallery contains little to no useful apps. Sad,
really, because it's why I bought the watch. Jon's done his best to support
but it'll take more than one person to engage a developer community.

[prochac]

Not support Linux developers is bad move. And closing Pebble watch... Fitbit doesn't want me to have some smart watch 😄

[JamesUnFit]

Sadly I lost interest in developing for this platform when Fitbit showed
little interest in supporting the developer environment.

-J

[LiamFitbit]

We're definitely interested in making the developer environment awesome.

We've got major updates to the simulator internals coming in the next update, and if people still have issues I'd encourage them to submit logs to us so we can take a look at those issues.

[JamesUnFit]

Whilst posting my previous message I received a popup inviting me to complete a survey. I completed it, albeit with negative responses. I subsequently received the popup ...

"Your survey answers were not submitted because you have already responded."

<sigh>

-J

[Crazyal01]

WHYYYYYYYYYYYYYYYY does that not surprise me?  LOL

Well all I can say is I noted something bizarre when I logged onto the web page thru my tablet, it tried to access the simulator which was on my pc.  If I closed the simulator on my pc, the tablet would show that it was disconnected from the sim.  As soon as I reloaded it on my pc, the web page on my tablet would reconnect to it.  OK that's just WEIRD! 

[SunsetRunner]

No Linux support, a slow app market interface, no direct access to the watch, poor SDK documentation, incomplete TypeScript support, unstable Bluetooth connections, inexplicable double-sending of messages between watch and companion, very basic apps that don't run... This doesn't look like you're trying to make it fun or easy for developers.

Given the number of apps in the market that also do not work well, I'm inclined to believe that the issue is with Fitbit. Other developers I know that have made some of the greatest apps for Pebble (e.g. NextTrain) have simply given up working on the Fitbit platform, quoting all of the above grievances as their reasons.

The only reason I bought the Ionic was because I liked the idea of developing apps for a watch--not because I'm some sort of health nut :)--but I am disappointed.

[LiamFitbit]

Linux users represent a small fraction of our developer community, so we focus our time on making things work better for the much larger audiences on Windows and Mac. The only piece that isn't supported in Linux is the Simulator, which many folks have had success running under Wine (and we've made patches specifically to improve Wine support, even though we don't officially support it).

Linux has a heavily fragmented ecosystem for installing and updating apps, and generally much more variable-quality graphics driver support, which makes it difficult to support.

I'm the lead for the team that maintains Studio, the CLI SDK Tools and the Simulator, so I'm always happy to listen to feedback on how we can improve these things (and I'll pass on feedback to other teams that maintain the rest of the ecosystem).

If you have suggestions for improvements to the SDK docs, we'd be all ears to hear them. Jon, our developer advocate, looks after those and frequents this community so he can read any specific feedback you have.

TypeScript support is something we're aware people want and we're working on, but some folks in the community have maintained their own types in the meantime which fill this gap quite well.

The latest FW release rolling out now has a completely rewritten comms stack improving performance and reliability. You'll hear more about that in the coming weeks.

Never heard of any issues around double sending of messages, if you have reproduction examples for that we'll look into it!

Not sure what you're referring to by "direct access to the watch" or "very basic apps that don't run" but if you can elaborate I can speak to those too.

[SunsetRunner]

IMHO, Linux support is elementary if you're going to have any dev
community. Maybe I'm surrounded by the wrong friends, but I really don't
know anyone who develops on a Mac unless they're web devs. Everyone else is
on Linux. But YMMV.

With Wine it works, sure, somewhat shoddily and as long as you don't try to
switch between layouts while the program is running. Wasn't the simulator
made with React Native or something? Should be easy-peasy to produce a
native binary then. Graphics support is really a non-issue. This isn't a
video game.

Direct access to the watch: not having to compile and upload my app to
Fitbit which in turn will deliver it over the internet to my watch. Why the
extra step? I understand you want to keep control over what happens on the
watch I bought -- no wait, I don't understand that: I bought it, let me
access it. But most of all it makes it extra difficult because you need a
working internet connection to test your app for things like Bluetooth
connectivity, whose fickleness the Simulator cannot simulate. Why not let
us transfer our apps over a direct Wifi connection (or USB if there's a
data connection?) to the device?

Double sending: I logged whenever my watch received a message from the
companion. Even though I instructed it to send only once, sometimes
duplicates would be received by the watch as evidenced by the log. I hope
the new firmware solves this.

Basic apps not working: almost everything that relies on Bluetooth works
shoddily at best. One out of three times the message comes through. For the
rest you just sit there waiting. We're not control of the comms stack, so
we shouldn't be handling its (mal)function either.

Even Fitbit's own "phone notifications on the watch" works only every so
often, whereas it worked flawlessly with the Pebble.

As an extra: it would also be nice to have access to the internal
temperature sensor. We could probably do interesting things with that.


I'll revisit developing for Fitbit when the new firmware rolls out to mine.
Until then I hope you keep making things easier for developers 🙂

[LiamFitbit]

Switching device types should work in Wine in the next update.

The simulator isn't built with React Native. It is an Electron application yes, but it contains native platform specific binaries, which we must build for Windows + OSX (and more importantly, test every release).

Graphics support is absolutely not a non-issue (I wish it were!). The simulator is built on OpenGL for rendering the simulated watch and so it's reliant on your graphics drivers. We've had many, many crashes in the past we've had to debug due to misbehaving graphics drivers.

I'd encourage you to use the existing Linux feature request thread to discuss that more.

Having the Developer Bridge require an internet connection rather than letting you connect directly to your device is nothing to do with Fitbit not wanting you to do that, it's just because we piggyback off of the same mechanisms on the watch that allow for things like WiFi sync and those are built around the device connecting to a remote server and not your device receiving connections directly.

We prioritised the Developer Relay mechanism rather than a direct connection because of limitations in browsers. Security policy in browsers that Studio must run in dictates you can't make connections to arbitrary local network devices. Even if the watch supported it, Studio could not.

I may be wrong, but I don't think any of our SDK supported devices have a temperature sensor that's intended to measure the ambient air temperature. Some chips do have a sensor, but it's often there to measure the internal temp rather than the air temperature, so it isn't very useful for what you'd probably want it for.