scratchfoundation / scratch-link Goto Github PK

Last week, we had to fix a bug in Scratch-Link in order for Scratch-Link to connect to any Vernier godirect devices (#104, already merged). Vernier has scheduled a play test with their new godirect Scratch extension on January 19th, 2019.

Could the next release of Scratch Link come out before January 19th so that they don't have to use custom builds?

Currently when you install Scratch-Desktop on Windows it only installs on one user's account. There should be an option to install for the whole machine so any user can access the program.

Related to scratchfoundation/scratch-desktop#36

Operating System and Browser

Windows

@rschamp was able to crash the Windows version of Scratch Link with something like this:

All LEGO devices running the LEGO Wireless Protocol 3.0 and later, such as LEGO Boost, share the same BLE Service and Characteristic UUIDs. This means that with the current implementation of Scratch Link and Scratch VM, searching for a LEGO device only based on UUIDs will discover (and connect to) all other LEGO devices.

According to the protocol, product distinction is done based on BLE Advertisement Data (ref: https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#advertising).
Examples of LEGO BLE Advertisement Manufacturer Data:

LEGO Boost:
97 03 00 40 07 00 41 00
LEGO System 2 Port Hub (included in City Train set):
97 03 00 41 07 27 63 00

The most significant byte in this case is the 4th byte, which according to the documentation describes the LEGO System Type and Device Number. 40 is LEGO Boost, 41 is the LEGO System 2 Port Hub.

A proposal could be for the Scratch Extension to provide an additional filter when asking Scratch Link to scan for devices. In the LEGO case, asking for devices with a particular Service UUID + a certain byte value at a certain location in the advertisement data. Curious to hear your thoughts on this!

When scanning for EV3s, we had two on the table: EVFREE and EVPEA. A windows machine showed EVBEE in the scan, but never showed EVPEA. Where did EVBEE come from? It's one we've used in the past, but is not currently on. Macs did not see it in their scans.

Crash with this error just happened after a routine connection attempt of BT over OSX

** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[39]'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff5276132b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00007fff79ddbc76 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff527a2634 _CFThrowFormattedException + 202
	3   CoreFoundation                      0x00007fff5265d46e -[__NSPlaceholderArray initWithObjects:count:] + 238
	4   CoreFoundation                      0x00007fff52664e44 +[NSArray arrayWithObjects:count:] + 52
	5   CoreFoundation                      0x00007fff526dd5b9 -[NSDictionary allValues] + 249
	6   IOBluetooth                         0x00007fff54d7a164 +[IOBluetoothObject getAllUniqueObjects] + 68
	7   IOBluetooth                         0x00007fff54d366f3 -[IOBluetoothDevice openRFCOMMChannelAsync:withChannelID:delegate:] + 115
	8   IOBluetooth                         0x00007fff54d365d8 -[IOBluetoothDevice openRFCOMMChannelSync:withChannelID:delegate:] + 248
	9   scratch-link                        0x000000010cc37780 _T012scratch_link9BTSessionC7connectySS8toDevice_yypSg_AA12JSONRPCErrorVSgtc10completiontFyycfU0_ + 240
	10  scratch-link                        0x000000010cc3b259 _T012scratch_link9BTSessionC7connectySS8toDevice_yypSg_AA12JSONRPCErrorVSgtc10completiontFyycfU0_TA + 25
	11  scratch-link                        0x000000010cbb941d _T0Ieg_IeyB_TR + 45
	12  libdispatch.dylib                   0x00007fff7a9c364a _dispatch_call_block_and_release + 12
	13  libdispatch.dylib                   0x00007fff7a9bbe08 _dispatch_client_callout + 8
	14  libdispatch.dylib                   0x00007fff7a9d0267 _dispatch_queue_serial_drain + 635
	15  libdispatch.dylib                   0x00007fff7a9c31b6 _dispatch_queue_invoke + 373
	16  libdispatch.dylib                   0x00007fff7a9d0f5d _dispatch_root_queue_drain_deferred_wlh + 332
	17  libdispatch.dylib                   0x00007fff7a9d4d71 _dispatch_workloop_worker_thread + 880
	18  libsystem_pthread.dylib             0x00007fff7ad0cfd2 _pthread_wqthread + 980
	19  libsystem_pthread.dylib             0x00007fff7ad0cbe9 start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6

Expected Behavior

A GDX-FOR device should be discovered by Scratch Link 1.1.28 on Windows.

Actual Behavior

The device is never discovered.

Steps to Reproduce

1. Run Scratch Link 1.1.28
2. navigate to https://vernierst.github.io/scratch-gui/goforce/
3. click the add extension button
4. add the "GDX-FOR" extension (the last extension listed might being using mircobit image).
5. After adding, the looking for device popup should appear. If the GDX-FOR is on (the red bluetooth LED is flashing) then the device should be discovered, but the searching icon never goes away.

Operating System and Browser

• Scratch Link 1.1.28.0
• Win10 Pro, version 1803
• both Chrome and Firefox

Sending a read request with the startNotifications flag set returns the current value in the direct response (good) but does not actually start sending characteristicDidChange messages to the client (bad).

When using Scratch 3 (latest MacOS+Safari) and Scratch Link (develop or master), if I connect to a device (tested with WeDo 2 and EV3) and then hit refresh on Scratch 3 causing the page to reload and sessions to close, Scratch Link crashes:

Starting server...
[INFO] Starting HTTPS server device-manager.scratch.mit.edu on :::20110
Server started
request path: /scratch/bt
Segmentation fault: 11

Repro:

1. Connect to a device like WeDo 2 or EV3.
2. Refresh Scratch
3. Scratch Link crashes with Segmentation Fault 11

I've tried to do a bit of debugging using lldb and get the following output:

(lldb) r
There is a running process, kill it and restart?: [Y/n] Y
Process 24498 exited with status = 9 (0x00000009) 
Process 24947 launched: '/Users/dkkevian/Dev/scratch-link/macOS/dist/Scratch Link.app/Contents/MacOS/scratch-link' (x86_64)
2018-11-21 12:04:30.463452-0500 scratch-link[24947:5011800] [default] Unable to load Info.plist exceptions (eGPUOverrides)
Starting server...
[INFO] Starting HTTPS server device-manager.scratch.mit.edu on :::20110
Server started
request path: /scratch/ble
Bluetooth is now powered on
Process 24947 stopped
* thread #4, queue = 'NetHandle', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x000000010014df7a scratch-link`x509_verify_param_zero + 90
scratch-link`x509_verify_param_zero:
->  0x10014df7a <+90>: movq   (%rbx), %rdi
    0x10014df7d <+93>: testq  %rdi, %rdi
    0x10014df80 <+96>: je     0x10014df95               ; <+117>
    0x10014df82 <+98>: leaq   0x147(%rip), %rsi         ; str_free
Target 0: (scratch-link) stopped.
(lldb) bt
* thread #4, queue = 'NetHandle', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x000000010014df7a scratch-link`x509_verify_param_zero + 90
    frame #1: 0x0000000100147956 scratch-link`X509_VERIFY_PARAM_free + 22
    frame #2: 0x000000010010cd5d scratch-link`SSL_free + 77
    frame #3: 0x000000010025b270 scratch-link`PerfectNet.NetTCPSSL.close() -> () + 32
    frame #4: 0x000000010026cffe scratch-link`partial apply forwarder for closure #1 () -> () in PerfectWebSockets.WebSocket.close() -> () + 30
    frame #5: 0x0000000100271231 scratch-link`partial apply forwarder for closure #1 (Swift.Int) -> () in PerfectWebSockets.WebSocket.(sendMessage in _0CBBC1EF67015CC10ED91AFD31C801C6)(opcode: PerfectWebSockets.WebSocket.OpcodeType, bytes: Swift.Array<Swift.UInt8>, final: Swift.Bool, completion: () -> ()) -> () + 17
    frame #6: 0x0000000100258650 scratch-link`PerfectNet.NetTCP.write(bytes: Swift.Array<Swift.UInt8>, offsetBy: Swift.Int, count: Swift.Int, completion: (Swift.Int) -> ()) -> () + 304
    frame #7: 0x0000000100257ed2 scratch-link`PerfectNet.NetTCP.write(bytes: Swift.Array<Swift.UInt8>, completion: (Swift.Int) -> ()) -> () + 34
    frame #8: 0x000000010026e28b scratch-link`PerfectWebSockets.WebSocket.(sendMessage in _0CBBC1EF67015CC10ED91AFD31C801C6)(opcode: PerfectWebSockets.WebSocket.OpcodeType, bytes: Swift.Array<Swift.UInt8>, final: Swift.Bool, completion: () -> ()) -> () + 491
    frame #9: 0x000000010026cfb9 scratch-link`PerfectWebSockets.WebSocket.close() -> () + 137
    frame #10: 0x00000001002a6e92 scratch-link`closure #1 (Swift.Optional<Swift.String>, PerfectWebSockets.WebSocket.OpcodeType, Swift.Bool) -> () in scratch_link.Session.handleSession(webSocket: PerfectWebSockets.WebSocket) -> () + 834
    frame #11: 0x00000001002aec1d scratch-link`partial apply forwarder for closure #1 (Swift.Optional<Swift.String>, PerfectWebSockets.WebSocket.OpcodeType, Swift.Bool) -> () in scratch_link.Session.handleSession(webSocket: PerfectWebSockets.WebSocket) -> () + 29
    frame #12: 0x000000010026e38b scratch-link`partial apply forwarder for closure #1 (Swift.Optional<PerfectWebSockets.WebSocket.(Frame in _0CBBC1EF67015CC10ED91AFD31C801C6)>) -> () in PerfectWebSockets.WebSocket.readStringMessage(continuation: (Swift.Optional<Swift.String>, PerfectWebSockets.WebSocket.OpcodeType, Swift.Bool) -> ()) -> () + 139
    frame #13: 0x000000010026d883 scratch-link`closure #2 (Swift.Bool) -> () in PerfectWebSockets.WebSocket.(readFrame in _0CBBC1EF67015CC10ED91AFD31C801C6)(completion: (Swift.Optional<PerfectWebSockets.WebSocket.(Frame in _0CBBC1EF67015CC10ED91AFD31C801C6)>) -> ()) -> () + 259
    frame #14: 0x000000010026e3c5 scratch-link`partial apply forwarder for closure #2 (Swift.Bool) -> () in PerfectWebSockets.WebSocket.(readFrame in _0CBBC1EF67015CC10ED91AFD31C801C6)(completion: (Swift.Optional<PerfectWebSockets.WebSocket.(Frame in _0CBBC1EF67015CC10ED91AFD31C801C6)>) -> ()) -> () + 21
    frame #15: 0x000000010026d48f scratch-link`closure #1 (Swift.Optional<Swift.Array<Swift.UInt8>>) -> () in PerfectWebSockets.WebSocket.fillBuffer(demand: Swift.Int, completion: (Swift.Bool) -> ()) -> () + 143
    frame #16: 0x000000010026e405 scratch-link`partial apply forwarder for closure #1 (Swift.Optional<Swift.Array<Swift.UInt8>>) -> () in PerfectWebSockets.WebSocket.fillBuffer(demand: Swift.Int, completion: (Swift.Bool) -> ()) -> () + 21
    frame #17: 0x0000000100257a03 scratch-link`PerfectNet.NetTCP.readBytesFully(into: PerfectNet.ReferenceBuffer, read: Swift.Int, remaining: Swift.Int, timeoutSeconds: Swift.Double, completion: (Swift.Optional<Swift.Array<Swift.UInt8>>) -> ()) -> () + 467
    frame #18: 0x0000000100257bea scratch-link`PerfectNet.NetTCP.readBytesFully(count: Swift.Int, timeoutSeconds: Swift.Double, completion: (Swift.Optional<Swift.Array<Swift.UInt8>>) -> ()) -> () + 154
    frame #19: 0x000000010026da3c scratch-link`PerfectWebSockets.WebSocket.readStringMessage(continuation: (Swift.Optional<Swift.String>, PerfectWebSockets.WebSocket.OpcodeType, Swift.Bool) -> ()) -> () + 316
    frame #20: 0x00000001002a4ed5 scratch-link`scratch_link.Session.handleSession(webSocket: PerfectWebSockets.WebSocket) -> () + 277
    frame #21: 0x00000001002af380 scratch-link`function signature specialization <Arg[2] = Dead> of scratch_link.SessionManager.handleSession(request: PerfectHTTP.HTTPRequest, socket: PerfectWebSockets.WebSocket) -> () + 512
    frame #22: 0x00000001002aee11 scratch-link`scratch_link.SessionManager.handleSession(request: PerfectHTTP.HTTPRequest, socket: PerfectWebSockets.WebSocket) -> () + 17
    frame #23: 0x00000001002aeef0 scratch-link`protocol witness for PerfectWebSockets.WebSocketSessionHandler.handleSession(request: PerfectHTTP.HTTPRequest, socket: PerfectWebSockets.WebSocket) -> () in conformance scratch_link.SessionManager<A> : PerfectWebSockets.WebSocketSessionHandler in scratch_link + 16
    frame #24: 0x0000000100270986 scratch-link`partial apply forwarder for closure #2 (Swift.Bool) -> () in PerfectWebSockets.WebSocketHandler.handleRequest(request: PerfectHTTP.HTTPRequest, response: PerfectHTTP.HTTPResponse) -> () + 246
    frame #25: 0x00000001001df336 scratch-link`partial apply forwarder for closure #1 () -> () in closure #1 (Swift.Int) -> () in PerfectHTTPServer.HTTP11Response.pushNonStreamed(bytes: Swift.Array<Swift.UInt8>, callback: (Swift.Bool) -> ()) -> () + 22
    frame #26: 0x00000001001f1d00 scratch-link`reabstraction thunk helper from @escaping @callee_guaranteed () -> () to @escaping @callee_unowned @convention(block) () -> () + 32
    frame #27: 0x00007fff6d1f3d4f libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #28: 0x00007fff6d1f4dcb libdispatch.dylib`_dispatch_client_callout + 8
    frame #29: 0x00007fff6d1f75d8 libdispatch.dylib`_dispatch_continuation_pop + 427
    frame #30: 0x00007fff6d1f6c7a libdispatch.dylib`_dispatch_async_redirect_invoke + 718
    frame #31: 0x00007fff6d202d1a libdispatch.dylib`_dispatch_root_queue_drain + 325
    frame #32: 0x00007fff6d2034b1 libdispatch.dylib`_dispatch_worker_thread2 + 90
    frame #33: 0x00007fff6d4346ee libsystem_pthread.dylib`_pthread_wqthread + 619
    frame #34: 0x00007fff6d434415 libsystem_pthread.dylib`start_wqthread + 13

It doesn't happen if I properly disconnect devices using the Scratch connection modal, only when I refresh the site.

Steps to Reproduce:

1. Using these two PR's: scratchfoundation/scratch-gui#2537 and scratchfoundation/scratch-vm#1285
2. Load EV3 extension
3. Click orange 'connect' button at top of extension blocks

Observed

After list of devices scans, an 'EV3' is listed with RSSI value '127' reported

Expected

RSSI value is to spec, something between -70 and 0

Expected Behavior

GDX-FOR stays connected after connection is established

Actual Behavior

GDX-FOR crashes soon after connection is established, seemingly because of an issue with withResponse being set to true on line 339 of BLESession.cs

Once I have connected to an EV3, and then disconnected, and then restarted Scratch Link (due to the crash in #93), when I attempt to connect again, the EV3 never appears in the scan.

The only reliable way I have found to be able to find and connect to the EV3 is to use the Windows Bluetooth settings to unpair the EV3 (i.e. "remove this device"). After I do that, the EV3 appears immediately in the scan, and I am able to connect.

Scratch Link 1.1.9.0
Chrome 70
Windows 10 Pro 1803 build 17134.345

This issue is meant to be a way of opening a discussion relating to the creation a linux version of scratch-link.

From my perspective:

In the near future, we (Raspberry Pi foundation) will need to make some decisions about how to make a future Scratch 3 Raspberry Pi extensions "talk" to the hardware and the presence (or not) of a linux version of scratch-link is a factor.

Current thinking (no more than that, subject to change, etc) is that comms would be via TCP to the pigpiod daemon running on the Pi.

Are there any plans for a scratch-link version for linux? Is it a consideration?

The WebSockets specification includes a mechanism for treating text and binary frames differently: see section 5.2 of RFC 6455 and the treatment of the "opcode" field in particular.

The only concrete difference between a binary frame and a text frame is a flag in the opcode field of the frame, though the specification demands that a text frame's payload must contain text encoded with UTF-8. In fact, the library we're using on macOS right now -- called "Perfect" -- effectively ignores the incoming binary/text flag in favor of returning the payload requested through its API.

We should decide what we want Scratch Link to do. IMO the two most obvious options are below, along with questions that arise if we make that choice:

1. Always send and expect text frames.
   • If a binary frame is received, should we treat it as a text frame, ignore it, or treat it as an error?
2. Attempt to match the client: send a text response to a text request and a binary response to a binary request.
   • What if the client switches between the two?
   • What if we send a request to the client -- that is, not a response to a request? Should we default to text, match the type of the most recent client request, or something else?

Right now this isn't a big deal because all our extensions always use text frames, but we should probably specify the intended behavior at least.

When Scratch Link tries to create a connection, I see this request for keychain access to "privateKey":

Mac OS 10.13.2 Chrome 66.0

Connecting to the micro bit should result in a connected micro bit.

Instead it gives an error on windows and says "Oops, Looks like something went wrong."

We can see the micro bit in the list and try to connect to it, but it fails.

Chrome on Windows

I got this after installing from the Windows Store:

It seems to work no matter what I choose, but still it is (a) a confusing choice i do not understand and (b) seems to suggest a build issue because the "publisher" is "unknown"? That shouldn't be, since it is published with the MIT signed key.

Scratch Link opens its WebSocket server on port 20110.

Expected:

If port 20110 is already occupied, Scratch Link should display an error message and exit gracefully.

Actual:

The WebSocket library throws an exception which is not caught by the application, resulting in a crash.

1. Install Scratch Link 1.18.x
2. Attempt to install Scratch Link 1.1.x

Note that Scratch Link 1.1.x is newer than 1.18.x due to a change in the way version numbers are constructed for this project.

Expected result: Scratch Link 1.1.x is now available to run

Actual result:

• Windows: Scratch Link 1.1.x refuses to install, displaying a message that a newer version is already installed
• Mac: @evhan55 reports "Installing 1.1.2 on Mac didn’t auto-delete 1.18.x and when I launched Scratch Link after install, 1.18.x opened instead. Had to delete 1.18.x to get 1.1.2 to properly install"

Expected

Connecting to a BLE device with the following filter:

filters: [
  {services: ['00001523-1212-efde-1523-785feabcd123']}
],
optionalServices: [
  '00001565-1212-efde-1523-785feabcd123'
]

.... should allow writing to the optional service.

Actual

When trying to write to the optional service, this error comes back:

{"code":-32602,"data":"attempt to access unexpected service: 00001565-1212-efde-1523-785feabcd123","message":"Invalid Params"}

Possible Fix

I believe the fix might be in BLESession.swift line ~ 115:
Instead of params["optionalServices"] as? [String:Any]
the check should be params["optionalServices"] as? [String]

I can scan for and connect to a microbit, but it always disconnects after a few seconds.

This appears to be because no sensor data is coming back, so the 4.5s timeout in the extension triggers a disconnect.

Some users on the forums have reported a similar problem with microbit.

I've noticed that the on this same version of Windows, the WeDo can connect, and I can set the light color, but no sensor data is received by the extension.

Windows 10 version 1703 OS Build 15063.1387
Chrome 70
Scratch Link 1.1.11.0

Expected Behavior

Sending a getServices request over BLE to Scratch Link will send a list of available services advertised by the peripheral, as documented here: https://github.com/LLK/scratch-link/blob/develop/Documentation/BluetoothLE.md#enumerating-services

Actual Behavior

A getServices request returns a Method not found error

Operating System and Browser

Mac, as discovered by @spectranaut

Before we're able to publish Scratch Link onto platform stores, we'll need to create a variety of assets to be shown in those stores. We'll need to come up with an icon/logo design for Scratch Link.

The assets needed include:

• Mac:
  • All images should be PNG format, sRGB color space, layers merged (transparency is OK), non-interlaced.
  • Application icon: 16x16, 32x32, 64x64, 128x128, 256x256, and 512x512, at both single (@1x) and double (@2x) resolution. That is, the largest image will be 1024x1024.
    • It might make sense to just create a 1024x1024 version and I can write a script to scale it to all the other resolutions as part of the build process.
    • See here for details on the app icon.
    • For cleaner scaling, Apple recommends building it on an 8x8 grid in the image size and resolution human interface guidelines.
  • "App preview" and/or "screenshot" images... not sure what to do for these since Scratch Link has no UI...?
• Microsoft Store:
  • Either a single master image from which we can generate all the other tiles, or a separate image for each tile.
  • Note that in many cases, the icon/tile image we provide will be centered, with padding, on a backplate of a color determined by the OS user. See here for details.
  • Sizes:
    • Master image: 400x400
    • Other tiles & icons: small tile, medium tile, wide tile, large tile, app icon, splash screen, badge logo, package logo. Each has 5 different sizes, except the app icon which has 3 types of icon which have 5 sizes each. That's a total of 45 images, but any of them may be customized even if we generate the others.
  • In my opinion, these are the plans that make sense (I recommend option A or B):
    1. Create a 400x400 master image and auto-generate the rest.
    2. Create a 400x400 master image and a splash screen image, then auto-generate the rest.
    3. Create a separate master image for each category (small tile, medium tile, large tile, wide tile, app icon, and splash screen) then auto-generate the alternative sizes in each category.
    4. Hand-generate a separate image for each icon/tile (total ~45 images).

Overall, it may make sense to create one 1024x1024 image with its major features aligned to an 8x8 pixel grid, then write a build script to scale that down for all the necessary images on both Mac and Windows. We'll still need to decide what we're doing for "screenshots" and the like, but I think that one 1024x1024 image might take care of all the logo, icon, and tile requirements.

I am trying to use the Windows development instructions and I believe the following installation instructions are missing:

• dependency: .NET Framework 4.6.2
• dependency: bash (install Cygwin)
• dependency: ImageMagick
• run: generate-images.sh

Once you connect a micro bit it should stay connected.

When I first connected the micro bit it showed the successfully connected message and then became disconnected. An error appeared in the console.

Repro steps:
This project already had the EV3 extension added
I then added the micro bit extension
Then I connected the micro bit
A second or two later it disconnected
I reset the micro bit and reconnected and it worked after that

I couldn't reproduce it, I just wanted to give some info on how it happened the one time I saw it.

This sequence crashes the Mac version of Scratch Link when using the WeDo 2.0 extension:

Talking to @colbygk , he mentioned that the Scratch Link / device manager certificates and bundles may need an update since they expire in 2019.

Also suggested was the idea to update the certificates possibly as part of the software update cycle, since they expire so frequently.

IT administrators are asking for MSI files to install more efficiently in schools. I think we should make one.

Related to scratchfoundation/scratch-desktop#35

Operating System and Browser

Windows

While a BLE socket is open over Scratch Link, it is possible to send multiple 'discover' requests on a single socket session (i.e. during an existing discovery state). While over a BT socket, attempting to do so returns an error: {"code":-32601,"message":"Method Not Found","data":"Cannot call discover in discovery state"}.

The Scratch Link documentation states that Scratch Link automatically handles scan renewal during discovery, and may terminate discovery if too much time has elapsed. This suggests that discovery should only be requested once per Scratch Link session, and that the observed BT behavior is correct.

Therefore, BLE should possibly also return an error when multiple 'discover' requests are sent on a single session.

See scratchfoundation/scratch-vm#1671 (comment)

This was tested with:

Scratch Link 1.1.2 1b61617
macOS Version 10.14 (Build 18A391)

After running this stack for a little while:

The EV3 disconnects, because the websocket has closed with this error:

WebSocket connection to 'wss://device-manager.scratch.mit.edu:20110/scratch/bt' failed: Could not decode a text frame as UTF-8.

Mac OS 10.13.2 Chrome 66.0

I've seen this situation a couple of times now on my mac:

• Everything is working fine for several days- I connect to microbits and EV3s on the beta
• I come back another day, and Link is still running
• I add the microbit extension, it scans and finds my microbit, I click the connect button
• It hangs indefinitely on the "connecting" step in the GUI connection modal
• No errors in the console

After quitting and restarting Link, it works fine again.

I guess we don't have a quick way to reproduce this unfortunately!

Ideally it should say "Scratch Foundation" everywhere.

Perhaps with a button saying "Launch Scratch Link" or "Start Scratch Link"?

I found it a bit confusing after installation to have to go find it in my application folder and run it (but if it's not possible to have automatically launch, we can include this in the instructions)

On Windows, attempting to send a message to a Bluetooth device will cause an error if a previous send has not yet completed. We should queue send requests from the client in order to avoid these errors.

Scratch Link should stay on until you quit it.

Instead it occasionally quits on you.

I will try to get repro steps soon.

Windows

Steps to Reproduce

1. Use these two braches: https://github.com/LLK/scratch-vm/tree/feature/device-connection?files=1 and https://github.com/LLK/scratch-gui/tree/feature/device-connection-modals?files=1
2. Load EV3 extension
3. Connect to an EV3 (with some sensors plugged in) by using the orange status button next to extension header
4. Once connected, sensor values should begin printing in the console

Expected

Sensor values print indefinitely

Observed

It works for some amount of time (a few seconds to several minutes), but then we get this error and the websocket closes: WebSocket connection to 'ws://localhost:20110/scratch/bt' failed: A server must not mask any frames that it sends to the client.

The documentation still refers to "the SDM" throughout, even though we've since renamed the application to "Scratch Link"

Expected:

Running make doesn't give errors.

Observed:

When running make in the macOS directory, it would error out if a folder name in one of the paths containing the repo had a space in the name. Example folder name: git repos.

Workaround:

Changing the folder from git repos to repos lets the make script run to completion, but perhaps this can be fixed to not need that as an enhancement in the future.

After connecting and disconnecting successfully several times, we saw this error on the Scratch Link console: RFCOMM run loop exited,

and this error on the Scratch console:

Uncaught (in promise) code: -32601 data: "Cannot call send in discovery state" message: "Method Not Found" (many times)

this causes Scratch Link to exit, which causes:

BTSession error: {"code":-32500,"data":"Connection process could not start or channel was not found","message":"Server Error"} (once)

The didReceiveMessage notification informs the client (Scratch extension) that data was received from the peripheral. Currently this is handled in an EV3-specific way: the code reads the 16-bit message length, then reads that number of bytes to get the whole message.

Once we have some other Bluetooth device to test with, we should figure out how to generalize the didReceiveMessage functionality to work with other devices.

1. Connect micro:bit to Scratch 3.0
2. Cause computer to sleep, wait a few seconds, and wake it up
   • Scratch should report a connection problem
   • Expected: macOS Bluetooth menu indicates no connection to micro:bit
   • Actual: macOS reports that the micro:bit is still connected
3. Attempt to reconnect Scratch to micro:bit
   • Expected: Scratch reconnects to the micro:bit
   • Actual: Scratch reports no devices found

Original report from @evhan55:

Putting the computer to sleep mode with micro:bit connected…..Turning the computer back on…..Scratch shows a disconnect alert and the status button is orange ✓. However, when I tried to reconnect to the micro:bit, it scanned 3 separate times and could not find the micro:bit (No devices found). However, the OS Bluetooth menu shows that it is still connected. Also, clicking on a micro:bit command block in Scratch does not show an alert anymore.

Expected Behavior

When connection to a BLE device is discovered and established, access to any GATT service named in "service" or "optionalServices" should be allowed.

Actual Behavior

Unable to access any characteristic listed under "optionalServices" unless the service is explicitly part of the advertising packet/advertisement data. In need of a way to access services listed as "optionalServices" that are not explicitly being advertised.

Operating System and Browser

Mac OS 10.13.6 Google Chrome 69.0.3497.100

Moved from scratchfoundation/scratch-vm#1751
/cc @beakutis

On occasion, the macOS Bluetooth stack gets into a broken state where it stops issuing callbacks like didDiscoverServices, and the only workaround I've found is to reboot the computer. In this situation Scratch Link will act as if everything is fine, but connect will never complete. Ideally we should add a timeout to situations like this so that the user can at least get an error message.

While the only example I've run across is on macOS with BLE, we should consider adding timeouts to all situations where a missing callback (or similar) would unrecoverably interrupt the application's regular flow and user feedback.

Scratch Link silently crashes (i.e. disappears from the tray) when I disconnect from an EV3.

I thought I saw this on attempting to reconnect to the EV3 as well, but now that I think about it, probably it had already crashed on the disconnect.

Scratch Link 1.1.9.0
Chrome 70
Windows 10 Pro 1803 build 17134.345

It's possible for a BLE characteristic to allow change notification without allowing a read operation. Scratch Link's current BLE API doesn't allow for that: the only way to request notification is to issue a read with the startNotifications flag set. In the case of a notify-only characteristic, this can lead to an error such as "Reading is not permitted."

For now, one workaround is to catch and ignore that error. However, we should add a way to subscribe to notifications without issuing a read operation.

I see three main options:

1. Add a new flag to the read request which suppresses the actual read, but still allows startNotifications to be processed. This has the advantage that it would be compatible with current builds of Scratch Link, but it's far from intuitive.
2. Add a new request called something like startNotifications. Clients making this request could maintain compatibility with current versions of Scratch Link by checking if startNotifications returns an error indicating that it's an unknown request, then sending a read with startNotifications set instead. The client will likely need to suppress an error from the read request, as it needs to do today.
3. Do nothing: clients who want to receive updates from a notify-only characteristic should issue a read with startNotifications and suppress a "Reading is not permitted" error.

I'm leaning toward option 2. Thoughts?

Requirements:

• Requires the usage of this commit: b7f22a1
• Requires the latest micro:bit firmware: https://github.com/LLK/scratch-microbit-firmware
• Latest micro:bit firmware protocol: https://github.com/LLK/scratch-microbit-firmware/blob/master/protocol.md

Steps To Reproduce:

1. Open playground.html
2. Follow the steps to connect to a discovered micro:bit
3. Click 'Change the LEDs'

Expected:

• As stated in the BluetoothLE documentation, sending a message over BLE should result in a RPC response formatted as:

{
  "jsonrpc": "2.0",
  "id": 5,
  "result": 4
}

Observed:

• Sending a message over BLE does not result in any RPC response at all, nothing prints out in the Log, even though the LEDs do change

I tried to demo Scratch Link using a micro:bit with beta.scratch.mit.edu while on a train, and it kept disconnecting. I've tried testing in other situations and haven't seen similar behavior.

I suspect that it has something to do with the unreliable wifi on the train. If that's the case this may be more general (not just Mac BLE).

Sending a read request with the startNotifications flag set returns the current value in the direct response (good) but does not actually start sending characteristicDidChange messages to the client (bad).

If a WeDo 2.0 goes away unexpectedly, such as by holding the power button to turn it off, Scratch Link does not currently inform the client of an error or close the session. It should do both.

Related to #85