feat(multisync): add JBoards controller support - #2787
Closed
pixelpropshop wants to merge 1 commit into
Closed
pixelpropshop wants to merge 1 commit into
pixelpropshop wants to merge 1 commit into
Conversation
pixelpropshop
force-pushed
the
feat/jboards-multisync-support
branch
from
September 26, 2026 19:48
d01c2ff to
b6fc693
Compare
JBoards controllers play FSEQ files locally and follow MultiSync as remotes. This adds them as a known controller type. - Allocate 0xC5 in the other systems block. ControlProtocol.txt also gets the Baldrick (0xC4) and Twinkly (0xFA) rows it was missing. - DetectJBoardsController reads the board's /api/system/summary for its hostname, model, firmware version, UUID, channel ranges and sync role. - A JBoards board in remote mode is a unicast sync target. - The MultiSync page polls JBoards status, uptime and version, and the platform filter has a JBoards entry.
pixelpropshop
force-pushed
the
feat/jboards-multisync-support
branch
from
September 26, 2026 20:13
b6fc693 to
cd05b0e
Compare
Author
|
Closing in favor of #3000, a new PR that adds JBoards to MultiSync using the current async detection and status methods, rebased on current master. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
JBoards controllers play FSEQ files locally and follow MultiSync as remotes. This adds them as a known controller type. Rebased onto current master and redone to match the async detector style.
DetectJBoardsControllerpre-filters on the page, then reads/api/system/summaryfrom the board for hostname, model, firmware version, UUID, channel ranges and sync role. It's one request, and the UUID is the board's own.supportsUnicastincludes JBoards alongside the existing "below 0x80" test, so a JBoards board in remote mode can be a unicast sync target. No existing type changes behavior.api/system/status?type=JBoards), showing the state, playlist/sequence, elapsed time, uptime, model and version. The platform filter has a JBoards entry.Tested with fppd built from this branch in Docker against two boards (PocketBeagle 2 and ESP32-P4): both were discovered over HTTP as 0xC5 with the right mode, version, ranges and UUID, and the status proxy returned their state.
Happy to use a different id if 0xC5 isn't the preferred slot.