Ever since Decaid had a different name, there was one problem I knew we would eventually have to solve:

new coffee hardware keeps appearing.

Scales, sensors, grinders and other devices can all add something useful to the workflow. But supporting each new device directly in Decaid does not scale particularly well. Every integration would require changes to Decaid itself, followed by a new release.

More importantly, it would make Decaid the bottleneck for people who already know their hardware best: device manufacturers, tinkerers and developers.

There was a useful precedent here in Decaid's predecessor, De1App.

De1App started as a demo application written in Tcl and somehow ended up becoming production software. One useful property of Tcl is that it is interpreted: new code can be loaded at runtime. That naturally made plugins possible.

Decaid has supported JavaScript plugins for quite some time, but the original implementation was intentionally small. Plugins could react to a handful of machine events, but they did not yet have the plumbing required to become a general extension mechanism.

Over time, we started discussing what a more capable plugin runtime could look like. Could a plugin talk to sensors? Could it connect to other coffee equipment? Could it expose that information to Decaid, its API and its skins?

Those ideas became much more concrete when the Bookoo Motto80 started reaching customers.

The Motto80 exposes a Bluetooth API, including access to its current grind settings. That makes it a particularly useful example of what device integration could provide: recording grind settings automatically with a shot, showing them in the workflow, adjusting grinder parameters from the DE1 tablet, and avoiding the familiar problem of forgetting what setting was used last time.

And it will not be the only grinder taking advantage of this. We have also received driver support for Bentwood grinders, giving the new runtime another real-world integration to grow around.

It also made the larger problem difficult to ignore.

We did not want to add one Bookoo-specific integration. We wanted Decaid to have a way to support devices like this without requiring their drivers to become part of Decaid itself.

That work is now arriving in Decaid 0.9.0.

The release introduces a dynamic device-driver runtime, allowing device support to be implemented in JavaScript and loaded by Decaid without modifying the Decaid core.

And importantly, this is not a grinder-specific system.

Drivers can represent different kinds of devices and expose their capabilities to Decaid. The goal is to make it possible for manufacturers and community developers to build integrations independently, while Decaid provides the common runtime, APIs and user-facing plumbing around them.

Alongside this, 0.9.0 introduces grinder support as a first-class Decaid capability, including a new /grinder API for interacting with connected grinders.

The combination is the part we are most interested in: Decaid can understand grinders as a device category, while the actual hardware support can come from dynamically loaded drivers.

We hope this makes it substantially easier for manufacturers, developers and curious users to experiment with new hardware and connect it to the rest of the Decaid workflow.

There is plenty more we want to build on top of this, but 0.9.0 establishes the foundation.

And, hopefully, the next interesting coffee device does not need to wait for a Decaid release before somebody can start using it.

~vid

photo credit: Soso & Yannick 🙏

p.s.: head to dcamp for the traditional release announcement with more info about plugins.