• Currently I think one of the "tasks" got "lost", so any writeValue() now fails with: BLE task 6

    Ok, task 6 is BLETASK_CHARACTERISTIC_WRITE, so it sounds like a write got lost somehow as you say. It's an odd one as we've had this bluetooth functionality for a while and this is the first time I've had a complaint about the issue. I'll have to see if I can reproduce it.

    From your previous link though:

    Is there a case where "BLE_GATTC_EVT_WRITE_RSP" does not occur?
    No, but it can be either success or an error.

    So unless I'm mis-reading, we seem to be doing the right thing...

    target BLE device has maintained the connection state

    It really shouldn't have... long-press BTN3 tears down everything (including connection state) and restarts it from scratch, so I'm not really sure what's going on there.

    Why is it catch(reject), not catch(reject()) ?

    You're passing a function into catch which should be called when an error occurs. If you do catch(reject()) then reject() is executed immediately (probably even before the first bit of the promise has executed), and the result of that function call is passed into catch - probably not what you intend :)

  • Why is it catch(reject), not catch(reject()) ?

    You're passing a function into catch which should be called when an error occurs. If you do catch(reject()) then reject() is executed immediately (probably even before the first bit of the promise has executed), and the result of that function call is passed into catch - probably not what you intend :)

    Oh yes, of course, my lack of JS familiarity forgot that I had this in my mind:

    .catch(function() {reject();})
    

    which, I suppose is actually the same thing as

    .catch(reject);
    
About

Avatar for Gordon @Gordon started