mjcheetham/blynclight

Control an Embrava Blynclight Mini over USB.

★ 0Forks 0C#GitHub ↗Compare

README

Blynclight

Tools for controlling the Embrava Blynclight Mini busylight over USB HID, derived from clean-room reverse engineering of the wire protocol used by the official Embrava Connect application.

The repository ships four pieces:

Path What
src/Blynclight/ Blynclight — a small .NET class library.
src/Blynclight.Mcp/ Blynclight.Mcp — a Model Context Protocol server.
src/Blynclight.Cli/ blynclight — a one-shot command-line front-end.
src/Blynclight.Copilot/ A GitHub Copilot CLI plugin bundling the MCP server.
PROTOCOL.md A standalone specification of the wire protocol.

The library is a pure protocol wrapper around HidSharp; the CLI adds per-user state persistence so successive one-shot invocations compose naturally (see State below).

Requirements

  • .NET 10 SDK to build from source.
  • A connected Blynclight Mini (USB VID 0x2C0D, PID 0x000A).

No driver install is required on macOS, Linux, or Windows — the device is a plain HID peripheral.

Building

dotnet build

CLI

dotnet run --project src/blynclight -- <command> [args]

A handful of representative commands:

blynclight on red              # solid red
blynclight rgb 255 128 0       # explicit RGB
blynclight dim                 # halve brightness, keep colour
blynclight flash --speed fast  # flash at full brightness
blynclight off                 # blank, preserve colour for next 'on'
blynclight music 3 --repeat    # play built-in track 3 on repeat
blynclight info                # show device + persisted state
blynclight reset               # force idle and clear persisted state

blynclight --help lists every subcommand; each subcommand also has its own --help.

State

The device protocol is write-only — there is no way to read the current report back. The CLI therefore mirrors the last report it sent to a small file under the platform's per-user application-data directory (8 raw bytes; on macOS that is ~/Library/Application Support/blynclight/state.bin).

Each invocation loads the saved report, applies the requested mutation, sends the result, and writes it back. That makes commands like dim (which only toggles the dim bit) behave the way you'd expect even though the host process is starting from scratch every time.

If no state exists and a "lighting" command is issued without an explicit colour (e.g. a bare on, dim, or flash), the CLI auto-promotes the colour to white so the device actually lights up. Modifier-only commands (off, noflash, nodim, audio) never auto-promote.

blynclight state prints the path and a hex dump of the saved report; blynclight reset clears it.

MCP server

blynclight mcp runs a Model Context Protocol server over stdio that arbitrates between multiple concurrent agents on a single shared Blynclight Mini. Each agent declares its own status via tool calls; the server picks the highest-priority status and renders it on the device.

blynclight mcp                # default: agents-dir under per-user state
blynclight mcp --agents-dir ~/blync-agents

Multiple blynclight mcp instances pointed at the same --agents-dir coordinate via per-agent JSON files in that directory, locked on every update. This means each agent can spawn its own MCP server (the usual stdio model) and still see a unified composite state.

Tools exposed:

Tool Purpose
set_status Declare this agent's status (working, success, needs_input, error, idle). Optional TTL.
clear_status Remove this agent (equivalent to state: "idle").
get_state Diagnostic snapshot of the composite + every active agent.
attention_ping One-shot audio ping (server-side debounced to 30s).

Priority order is error > needs_input > working > success > idle; the idle resting state renders as solid green, working as solid yellow, success as a brief green flash, needs_input blinks cyan briefly then holds solid cyan, and error as a fast red flash.

The MCP server uses the same per-user state.bin as the one-shot CLI, so blynclight info / blynclight state reflect whatever the server most recently rendered.

GitHub Copilot CLI plugin

For Copilot CLI users, the repo doubles as its own plugin marketplace. The plugin in src/Blynclight.Copilot/ bundles the MCP server config and a blynclight-status skill that teaches the agent how to use the tools:

copilot
/plugin marketplace add mjcheetham/blynclight
/plugin install blynclight@blynclight

The plugin assumes the native blynclight binary is already on PATH (see Native publish below).

Native publish

The CLI is configured for NativeAOT, so a published binary is a single native executable with no managed runtime dependency:

dotnet publish src/Blynclight.Cli -c Release -r osx-arm64

Substitute the appropriate RID for other targets. The resulting binary for osx-arm64 is around 4 MB.

Library

using Mjcheetham.Blynclight;

using var device = BlynclightMiniDevice.Open();
device.SetColor(Colors.Red);
device.SetDim(true);

BlynclightReport is a value-type model of the 8-byte HID report; advanced callers can build one explicitly and call device.SendReport(report).

Protocol

PROTOCOL.md documents the report layout, the meaning of every bit and byte, and the host-side conventions for things like idle state and trailers. It is derived purely from observing traffic and from static analysis of the official Embrava Connect application — no Embrava code, headers, or documentation were used.

License

MIT — see LICENSE.

This project is not affiliated with or endorsed by Embrava. "Blynclight" is a trademark of Embrava and is used here only to describe the device this software interacts with.

Contributors

mjcheetham

Issues