Ben Nuttall, creator of the gpiozero Python library for Raspberry Pi GPIO control, has proposed a web-based visual interface called "gpiozero flow" that lets users drag and drop GPIO devices onto a canvas and draw connections between them. Nuttall announced the concept in a blog post on 25 July 2026, accompanied by an installable Python package and a written MVP specification.

gpiozero, originally conceived by Nuttall in 2015, provides a device-focused API that abstracts away pin channels, voltages, pull-up resistors, and edge detection. Instead of working at the electrical level, developers interact with concepts like button presses, sensor detection, and motor direction. The library supports three programming paradigms: procedural via polling, event-based via callbacks, and declarative through a source/value linking system.

That declarative layer is the technical foundation for gpiozero flow. The source/values system exposes manipulation functions including negated, inverted, clamped, scaled, absoluted, booleanized, zipped, and smoothed, enabling data flow between devices without explicit imperative code. The proposed web UI would let users construct these relationships visually, drawing connections between on-canvas device representations rather than writing Python.

Nuttall drew a direct comparison to Node-RED, the popular flow-based programming tool, but was critical of its approach. He characterized Node-RED as convoluted and pin-based rather than device-focused, arguing that gpiozero's abstraction model is better suited to the kinds of interactions Raspberry Pi users actually want to build. The distinction matters: Node-RED operates on generic message-passing nodes wired together, while gpiozero flow would represent physical components as first-class objects with semantic properties like direction, state, and threshold.

To build the web UI, Nuttall stated he used Claude, Anthropic's AI assistant, noting that the project required significant modern JavaScript knowledge. The published Python package, gpiozero-flow (hyphenated), includes both a websocket agent and a web app that can be installed directly on a Raspberry Pi. Nuttall also wrote a specification for the MVP.

The current gpiozero documentation, hosted at gpiozero.readthedocs.io and versioned across releases including 2.0.1.post1, 2.0.1.post3, and 1.6.0, does not yet include a dedicated feature page or API reference for the flow tool. A site search for "flow" returns no corresponding documentation. This is consistent with the project's current stage as a proposed concept with an installable prototype rather than a shipped library feature.

Worth flagging is the gap between the source/values system's existing maturity in the Python library and the flow UI's early prototype status. The manipulation functions that flow would visualize are already production-tested in gpiozero's current releases. The web UI layer is new, and the MVP specification suggests Nuttall is treating it as exploratory rather than final.

There is also a broader question about where physical-computing tooling sits in 2026. Node-RED has held a strong position in maker and IoT workflows for years, and any challenger needs to offer a genuinely different mental model, not just a different rendering of the same concept. Nuttall's device-focused framing is that differentiator, but whether visual programmers will adopt it over the familiar Node-RED canvas remains an open question that only adoption data can answer.

Nuttall's use of Claude to scaffold the JavaScript frontend reflects a pattern now common across open-source development: contributors with deep domain expertise in one stack (here, Python and hardware abstraction) using AI assistance to cross into adjacent stacks they need but have not mastered. The result was a working prototype, though Nuttall's own acknowledgment of the JavaScript complexity required suggests the generated code needed substantive human oversight rather than functioning as drop-in output.

The gpiozero library itself has been a fixture in Raspberry Pi education and hobbyist projects since its introduction. Version 2.x represents a significant API evolution from the 1.6.x line, and the versioned documentation at Read the Docs tracks that progression. Whether flow eventually ships as a first-party gpiozero feature, a standalone companion package, or remains a proof of concept, it extends the library's core design philosophy, that physical computing should be expressed in the vocabulary of devices and their interactions rather than the vocabulary of pins and electrical signals, into the visual programming space.