The blink(1) repo became a clearinghouse for the RGB USB LED

A repository that moved its code elsewhere

The most important thing about todbot/blink1 is what it is not. It is not where you find the blink(1) software any more.

The README says it plainly. This repository used to house all blink(1) related code, but is now a clearinghouse and links to the official and supported blink(1) repositories. What it keeps is the connective tissue: the description of what the device is, the list of where each maintained project lives, the API documentation links, and a directory of historical code.

That history is not tidied away. The README states that most code in the repo is deprecated but kept around for historical interest, and the top level shows the spread: chrome/, docs/, freebsd/, go/, hardware/, haskell/, java/, linux/, mac/, nodejs/, openwrt/, processing/, python/, qt/, ruby/ and windows/. Each of those directories is a platform or language that blink(1) once had first class support for, including a chrome/ directory for ChromeOS and an openwrt/ directory for the router firmware.

For a reader, this shape tells you where the project went. It moved from one large multi-platform repository into a set of small ones, each with its own release cycle. That is a healthier arrangement for the libraries, and a worse one for anyone who cloned the old repository and expected it to keep working.

A USB RGB LED that reports state without a screen

The device itself is a small USB peripheral, and the case for it is that it shows you something without needing a window.

The README describes blink(1) as a status light that packs three dimensions of information, color, brightness and pattern, into a single tiny package that fits into any USB port on nearly every device. The stated benefit is being able to connect any data source, in the cloud or on your computer, to a full-color RGB LED so you can know what is happening without checking any windows, going to any websites or typing any commands.

Technically it is a smart LED controller with built-in USB firmware, and the repository topics name the LED technology directly, ws2812 and ws2812b. That matters for anyone building a variation of it, because the addressable RGB LED strips and matrices that carry those parts are what let a single controller drive many pixels with a data line rather than a dedicated wire per colour.

The device also has breadth of support that is unusual for a USB gadget. The README claims a huge range of support from the Linux kernel to Node.js, and the repository table backs that up with a C library, a Python library, a Rust crate, a Node.js library, a Java and Processing library, a Go library, an Android library and WebHID demos for the browser.

One note on naming. blink(1) is open source hardware with the OSHW identifier US000051, and the trademark in the name belongs to ThingM Corporation. Those are separate things, and the distinction matters if you build a device based on the design.

Where the maintained code actually lives

The official repository table in the README is the most useful part of this repository, and the reason most people end up here.

It lists Blink1Control2 as the graphical app for Mac, Windows and Linux, blink1-tool as the command-line tool, simple API server and C-library for all platforms, blink1-python on PyPI, blink1rs on crates.io, node-blink1 on npm, blink1-java for Java and Processing, go-blink1 for Go, blink1-android, blink1-webhid for WebHID demos, blink1mk3 for the hardware and firmware design of the mk3, and the blink1 repository itself for hardware and firmware design plus miscellaneous docs and notes.

Two entries in that list are worth pausing on. blink1-tool is described as C-based and aimed at script-writers, programmers and hackers, and its repository contains three distinct things:

blink1-tool
blink1-tiny-server
blink1control-tool

The first is the command-line program to use in your own scripts, the second is a simple RESTish JSON API server for controlling blink(1) devices, and the third controls a blink(1) through the Blink1Control application as if you were using the command line tool.

Two example projects are also listed separately as instructive examples, electron-blink1-toy and tauri-blink1-toy, each described as the simplest possible application for controlling a blink(1), one in Electron and one in Tauri with Rust. For a first project those are the right shape to copy, because they show the shortest path from a window to a colour change.

Blink1Control2 as an event-driven status system

The primary user-level application is Blink1Control2, and its design tells you what the device is for in practice.

It is an application for controlling blink(1) and hooking events to it, an event-based system for triggering blink(1) colour patterns, and the events can be on your computer or on the net.

The event sources it can receive from are listed explicitly: IFTTT channels, IMAP and GMAIL email services, Skype events, URLs containing text or JSON, and local files or executed scripts.

Read that list as a set of integration points rather than a feature list. Each one maps a thing that happens somewhere else to a light state. An email arriving is a trigger, a webhook URL returning text or JSON is a trigger, a local script finishing is a trigger, and the pattern chosen for each is a visual encoding of that event.

The pattern is the same one the hardware supports and that Blink1Control2 exposes to script writers through the app-url-api documentation, where a URL encodes both the event to listen for and the colour and pattern to show. The docs directory of this repository holds the API documentation, including app-url-api examples and the blink1-tool usage reference.

The practical consequence for an adopter is that Blink1Control2 is the piece that makes the LED a status indicator for your existing infrastructure, and blink1-tool is the piece that makes it controllable from your own code. Most people end up using both.

Deprecated directories are a map, not a dependency

It is worth being precise about what the deprecated directories are for, because they look like an installation guide and are not.

The README lists what is in this repository. The docs directory holds documentation of APIs and tips and tricks. The java directory holds Java and Processing library information, the processing directory holds Processing applications, nodejs/ holds NodeJs library information, python/ holds Python libraries with a couple to choose from, ruby/ holds Ruby APIs and Ruby Tools, and go/ holds the Go library. The mac directory holds Mac OS X details and the old Blink1Control0 app, including a scripts directory of command-line scripts. The windows directory holds Windows and .NET details, the old Blink1Control0 app, a .NET library wrapping blink1-lib, a ManagedBlink1 100% .NET library that the README says is superseded by Sleddog.Blink1, and its own scripts directory. The linux directory holds Linux details and scripts with a contrib directory of contributed Linux scripts. The chrome directory holds ChromeOS info, and hardware/ holds all hardware-related info including firmware, schematic and enclosure.

None of that is the supported path any more. The current generation of blink(1) software is the table of official repositories, and the README even notes that each of those projects includes APIs for languages not mentioned in the table.

So the value of the legacy directories is archival and educational. They show how the platform-specific integrations were once done, they preserve the schematic and firmware background for the hardware, and they give you a working example of the older app approach if you want to see how it used to fit together. They are not a dependency list.

Licence, trademark and the awkward version history

The licence section is short and has three parts that need separating.

blink(1) is open source hardware with the identifier OSHW US000051. The documentation and the code in this repository are under CC BY-SA 3.0, which is a share-alike licence: reuse is allowed with attribution, and derivative works of the documentation have to be shared under the same terms. The copyright is ThingM, 2012 to 2018. Separately, blink(1) is a trademark of ThingM Corporation, so the name itself is not free to use even though the design and documentation are.

The version history is the part that can confuse. The three most recent releases are v1.98b from 2018-10-06, whose note says the repo was updated since blink1-tool is in its own repo, v1.98a from 2017-02-13, and v1.98 from 2015-09-10. Meanwhile the last push to this repository was on 2026-09-26.

The two facts together mean the repository is alive as a document set while the released software is not. The push in September 2026 is to the clearinghouse, not to a new release of the device software. Anyone looking for the current version of the command-line tool should read the release history of blink1-tool itself, not this repository's tags.

The repository also carries VERSIONS.txt at the top level, alongside continuous integration configuration in .travis.yml and appveyor.yml and a .gitmodules file for the submodules, which is another sign of the era when this repository held the code.

Editorial conclusion

todbot/blink1 is the right starting point if you want to understand the blink(1) device or find the maintained library for your language, and the wrong place to look for working code, because most of it there is deprecated and the maintained projects each have their own repository. It suits builders who want to drive an RGB LED from a script and do not care which wrapper they use, since the device has firmware and works from the Linux kernel up to Node.js. Before writing anything, pick the library from the official table rather than the copies in this repo, and confirm you have the vendor permission you need if you intend to redistribute anything derived from the hardware design, because the design is open source hardware while the name remains a ThingM trademark.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. todbot/blink1 on GitHub