LEGO Boost firmware update 2.0.00.0017 breaks extension functionality

[apple502j]

https://twitter.com/ooba/status/1142967014761254912
According to this tweet, a recent firmware update changed Boost port IDs:
A 0, B 1, C 2, D 3
Therefore old IDs (defined at https://github.com/LLK/scratch-vm/blob/develop/src/extensions/scratch3_boost/index.js#L96 ) won't work. However, if the firmware is not updated, old IDs must be used - so it's hard to define it as constant.

[evhan55]

@apple502j Thank you for alerting us to this tweet! Do you have a LEGO Boost with the latest firmware?

[apple502j]

Nope sorry @evhan55

[evhan55]

@apple502j Okay, thank you for letting us know!

[evhan55]

@ericrosenbaum

I have tested the latest LEGO Boost Firmware 2.0.00.0017 and it seems that the motor ports did indeed change from:

    A: 55,
    B: 56,
    C: 1,
    D: 2

to:

    A: 0,
    B: 1,
    C: 2,
    D: 3

It looks like the Boost connect behavior has changed as well and is not incompatible with the Scratch 3 / Scratch Link connection flow as currently designed for Boost, and other miscellaneous sensor values seem to give errors in the console. It might be best to open a new issue to track all of these changes together (or as separate issues?)...

[evhan55]

@apple502j Thank you! It seems you are correct about this being a critical bug in the Scratch 3 LEGO Boost extension! Thanks for bringing this issue to our attention.

[evhan55]

Some issues I noticed so far in preliminary testing:

1. Connection flow seems broken and behaves like this, in a reproducible way, now:

• Click connect within the extension to connect to Boost
• Press button on Boost
• Scratch says 'connected' but Boost connection light keeps blinking, blocks don't work
• Scratch alert comes up saying 'Boost has disconnected'
• Click connect within the extension to connect to Boost
• Press button on Boost
• Scratch says 'connected' and this time it connects properly
• Blocks now work

2. Motor blocks are not working since internal port IDs got remapped:

• motor A option affects nothing
• motor B option affects nothing
• motor C option affects port B
• motor D option affects port C

3. Setting LED light with set color block works, but it gives a warning in the console about a sensor value not being correct

[evhan55]

@cwillisf @ericrosenbaum To update to the latest Boost firmware:

• Download the LEGO Boost mobile app on the Google Play or iOS App store
• Turn Bluetooth on mobile device
• Open the app
• Run a sample project within the app
• It will prompt to connect to / update firmware on Boost

[knandersen]

Thanks for reporting this @apple502j and for doing some great initial investigation @evhan55!

1. I've been digging into this issue as I wasn't able to connect to the hub using Scratch, but I could connect using a generic BLE debugging app for Mac (using BlueSee). I noticed that with the new firmware, the hub now advertises with two UUIDs rather than just one - let's call them UUID-A and UUID-B.

UUID-A:

• Has no advertisement data.
• Cannot be connected to.
• Shares UUID across physical devices.
• Not the one we want Scratch to connect to.

UUID-B:

• Has advertisement data.
• Can be connected to.
• Unique UUID.
• The one we want Scratch to connect to.

I'm pretty sure what's happening is that Scratch discovers UUID-A before UUID-B and attempts to connect to it, but it won't succeed. This leaves Scratch Link hanging (I tried waiting for a few minutes and it doesn't time out).

I see two different strategies to solve this:

Implement scratchfoundation/scratch-link#120: Since only the functioning UUID-B has advertisement data, this would be a way of filtering. Additionally if the data is available to scratch-vm, this will enable us to detect firmware version since it's exposed in the advertisement data.

Exclude the faulty UUID: UUID-A seems to always be C573261D-EBC8-4A0E-B3C5-1748074583DF, so we could find a way to exclude that.

2. This seems to be correct. The constant could simply be changed to reflect the new mapping.

3. It seems that the LED now gives feedback when commands have been issued to it. We're missing a case for that, so adding a simple case BoostIO.LED in _onMessage() -> BoostMessage.PORT_VALUE should solve that.

[knandersen]

Motor/port-issues fixed in #2215. Closing this issue since the remaining connection-issues are addressed in a separate issue #2230.