Puck disconnecting after running function from the browser without passing a callback.

[espruino-discuss]

Posted at 2016-12-13 by alexjfno1

Hi,

Been playing around with the Web Javascript API and have noticed that if you don't specify a callback on some functions the Puck will disconnect instantly. For example:

Here is what I want to do

let connection;
Puck.connect(conn => {
    conn.write('LED1.set();\n');
    connection = conn;
});

// Use this function later when a button is clicked
const resetLEDOnButtonClick = () => {
    connection.write('LED1.reset();\n')
}

Expect when I call the resetLEDOnButtonClick a while later the Puck has been disconnected.

I've ended up having to pass empty callbacks everywhere just to stop it disconnecting. For example:

let connection;
Puck.connect(conn => {
    conn.write('LED1.set();\n', () => {});
    connection = conn;
});

// Use this function later when a button is clicked
const resetLEDOnButtonClick = () => {
    connection.write('LED1.reset();\n', () => {})
}

Is this expected or am I using the API wrong?

[gfwilliams]

Posted at 2016-12-14 by @gfwilliams

Could you check on the Web Browser's debug console and see if it really is just complaining about trying to call a callback that doesn't exist?

It wouldn't surprise me, and it's an easy fix - the standard Puck.write functions cope with not having callbacks fine, but I have to admit I have always used the connection-based write with a callback, so may not have added a check for when it doesn't exist.

[espruino-discuss]

Posted at 2016-12-14 by alexjfno1

Hi Gordon,

I found the issue in the https://www.puck-js.com/puck.js code I believe. I've made some comments below.

    connection.write = function(data, callback) {

// **** This is pushing callback as null ****
      if (data) txDataQueue.push({data:data,callback:callback});
// ***********************

      if (connection.isOpen && !connection.txInProgress) writeChunk();

      function writeChunk() {
        var chunk;
        if (!txDataQueue.length) return;
        var txItem = txDataQueue[0];
        if (txItem.data.length <= CHUNKSIZE) {
          chunk = txItem.data;
          txItem.data = undefined;
        } else {
          chunk = txItem.data.substr(0,CHUNKSIZE);
          txItem.data = txItem.data.substr(CHUNKSIZE);
        }
        connection.txInProgress = true;
        log("BT> Sending "+ JSON.stringify(chunk));
        txCharacteristic.writeValue(str2ab(chunk)).then(function() {
          log("BT> Sent");
          if (!txItem.data) {
            txDataQueue.shift();

// **** This is calling the null callback function and throwing an Error. ****
            txItem.callback();
// ***************************

          }
          connection.txInProgress = false;
          writeChunk();
        }).catch(function(error) {
         log('BT> SEND ERROR: ' + error);
         txDataQueue = [];

// **** The error is being caught and the connection is being closed. ****
         connection.close();
// ********************

        });
      }
    };

Like you said it's an easy fix to only call the callback if one is passed.

[espruino-discuss]

Posted at 2016-12-14 by alexjfno1

I've also noticed that the connection object doesn't have the eval function?

[gfwilliams]

Posted at 2016-12-14 by @gfwilliams

Just updated!

[espruino-discuss]

Posted at 2016-12-14 by alexjfno1

Great!

[espruino-discuss]

Posted at 2016-12-15 by alexjfno1

@gfwilliams is there a reason why the connection doesn't have an eval function? E.g.

Puck.connect(conn => {
    conn.eval('Puck.getBatteryPercentage()', console.log);
});

When I run this I get conn.eval is not a function. I have tried using Puck.eval but it then asks me to reconnect the Puck again.

[gfwilliams]

Posted at 2016-12-15 by @gfwilliams

It's that Puck.connect is the more 'advanced' way to talk to the Pucks - I'd been assuming that you would want full control of the input and output if you used it.

As a result, it's a bit harder to give you full control of the IO and then to yank it back when eval needs to be executed and then return it afterwards. It's not that bad though.

If you want to add some extra stuff to it, pull requests are welcome :)