Support for Multiple Peripherals per Extension - questions regarding implementation/pull request

Open
  • Is something wrong?
#663 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
javascript
Domain
frontend, networking

Research direction

Start by reviewing the mentioned scratch-vm ble.js and bt.js clients, the scratch-gui scanning-step view, and the Scratch Link session constraint. Before implementation, get maintainer agreement on the connection model, extension flag, runtime API, and modal approach; done would be an approved, scoped design for multi-peripheral support.

Written by the indexing model from the issue text.

Description

Goal

Allow Scratch extensions to discover, connect, and manage multiple peripherals simultaneously instead of limiting connections to a single device.

Motivation

I have multiple Lego WeDo 2.0 hubs (each providing 2 sensor/motor ports). While the official LEGO app allows connecting multiple hubs to one project, Scratch currently limits the extension to a single hub.

Proposed GUI changes
  • Device Connection Modal:
    • While the connection modal is open, Scratch continues discovering devices while displaying currently connected hubs.
    • Users can toggle connection states for individual hubs with a single click.
  • Dynamic Block Menus:
    • Once one or more hubs are connected and the modal is closed, the block dropdown menus dynamically update to display all available motors/sensors across all connected hubs (Plug & Play).
Proof of Concept

I have built a working prototype running on Linux. During development, several architectural questions arose. I would love to get feedback from the Scratch maintainers and community to align my implementation with Scratch's architectural goals for a future Pull Request.

Note on dynamic dropdowns: Scratch already supports dynamic block dropdown menus via callbacks, which works exceptionally well for runtime Plug & Play sensors/motors across hubs.

Technical Bottlenecks & Proposed Solutions
1. Session-Based Communication in ble.js / bt.js & Scratch Link

Currently:

  1. A single BLE/BT JSON-RPC session handles both discovery and connection for a single peripheral.
  2. Scratch Link constraint: WebSocket sessions handling discovery only allow connecting to devices discovered within that same session.

Proposed Solution:
Allow Scratch Link to connect to devices without requiring prior discovery in the exact same WebSocket session (connecting can fail gracefully regardless of this change).

  • Workflow: The client handles discovery in one WebSocket session, then opens separate sessions to manage connections to individual devices.
  • I verified this approach using an open-source Linux implementation of Scratch Link. Adapting Windows/macOS implementations should be doable.
  • bt.js / ble.js clients in scratch-vm would be updated to decouple discovery from connection management and handle multi-device sessions.
2. Extension Definition Flags

Extensions should be able to declare support for multiple devices:

  • Introduce an optional flag (e.g., allowMultiplePeripherals: true) in the peripheral extension configuration.
3. State Tracking in VM / Runtime

The runtime and peripheral management layer need a gateway to track active connections:

  • Proposed API methods: getConnectedPeripherals(extensionId) and setConnectedPeripherals(extensionId, deviceIds).
4. Device Connection Modal Updates

Because auto-connect (existing extension flag) is not suitable for multi-device workflows, we should build on top of the standard connection chooser dialog:

  • Option A: Extend the standard "scanning-step" view to support multi-selection and active connection toggling.
  • Option B: Introduce a dedicated scanning step component (e.g., scanning-step-multi).

What do you think of this?

Note: The initial prototype was developed with the assistance of an AI agent, and I have acquired a solid understanding of the relevant parts of scratch-vm, scratch-gui, and Scratch Link. Also this text was marked-up with help of AI :-) *

Dominant language
JavaScript
Stars
310
Forks
299
Avg merge
19h 41m
Merged PRs (30d)
14

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from scratchfoundation/scratch-editor

All issues in scratchfoundation/scratch-editor

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.