messaging.peerSocket.onopen called twice

[adiroiban]

I am using the standard "Settings" project template and I can see that the `messaging.peerSocket.onopen` callback is called twice when I start the simulator.

Does anyone know why? Thanks!

---------------

To reproduce this:

* Go to https://studio.fitbit.com/projects and click "New Project"

* Give it a Name and select "Settings - A project that is configurable with settings" and "Create"

* Now select "Simulator" as the Phone and "Simulator" as the Device

* Click "Run"

* Check the Console logs

* Expected result "Companion Socket Open " is called only once

* Actual result "Companion Socket Open " is called twice as consecutive calls.

```

[3:58:55 PM]App Closed[HOST]

[3:58:56 PM]App Started[HOST]

[3:58:56 PM]Launch complete - durations: foregrounding(271ms), first paint(1ms), total(453ms). app/index.js:18,1

[3:58:57 PM]App Socket Open companion/index.js:6,3

[3:58:57 PM]Companion Socket Open companion/index.js:6,3

[3:58:57 PM]Companion Socket Open companion/index.js:6,3

```

[adiroiban]

I tried to do something like this, but I can still see that each call is done with `false`...so somehow the whole runtime is started twice

let started = false;

// Message socket opens
messaging.peerSocket.onopen = () => {
  if (started) {
    return;
  }
  console.log(`Companion Socket Open ${started}`);
  started = true;
  restoreSettings();
};

[bcrigler]

Yeah experiencing the same issue here... 

[bcrigler · Accepted solution]

I found a solution by just trial and error looking at the docs.

Let me know if this helps you as well.  I wrapped the messaging.peersocket event handlers in a check to see if messaging was in a readyState similar to like jQuery document.ready.  That seemed to prevent the second execution.  Hope that helps.

The next issue I'm having is everything in those event handlers are locally scoped which is why your boolean was never marked true.  That's a whole other issue I haven't quite figured out how to work around yet.

// Import the Companion module
import * as messaging from "messaging";
import { me } from 'companion';

if( messaging.ReadyState == "OPEN" ) { 
  // Message socket opens 
  messaging.peerSocket.onopen = () => { 
    console.log("Companion Socket Opened"); 
  }; 
  // Message socket closes 
  messaging.peerSocket.onclose = () => { 
    console.log("Companion Socket Closed"); 
  }; 
}

[adiroiban]

Thanks. Much appreciated.

This was more like a bug report for the Fitbit team...but it look like Fitbit is busy with other things.

--------

I have stopped using the Fitbit Studio and switched to CLI.

It looks like when I build-and-install the app via the CLI the onopen is not called twice.

The simulator is what it is ...and then Fitbit Studio is just a toy.

I guess that for any serious app, people will use the CLI and will be a non-issue.

onclose is never called in the Simulator, as the communication is always on.

Maybe a future version of the simulator will allow a simple toggle for connect/disconnect.

----------

On the device, the `peerSocket.onopen` and `peerSocket.onclose` have all valid scopes and they have access to the global scope.

I have created this little app to help me undestand how device <-> companion communication works and how the connection is open/closed.

Turned out the communication is VERY unreliable...so I am looking at messaging just as a signaling system and trying the file-transfer API for any data communication.

 https://github.com/adiroiban/fitbit-os-probe

[adiroiban]

hmm... I tried to reply... but my reply was marked as spam...

long story short... I am using the CLI and no longer see this behaviour.

I am using the Messaging API just for non-critical signaling... for any data communication I am trying the file-transfer API.

[bcrigler]

Interesting, I am using the CLI as well because I don't want to work in a browser... not sure why anybody would want to.  They need to update the simulator and CLI to work as well as the browser IDE.  I saw this as a problem with the CLI as of yesterday but I might have outdated packages and maybe a fix was in a newer version of the npm packages?  Are you saying that without my proposed solution you don't see the issue anymore in CLI?  Or are you saying that when using this fix with the CLI it solves the issue?

For me it was the latter.