Ben Nuttall, the creator of the gpiozero Python library for Raspberry Pi hardware 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 created by Nuttall in 2015, provides a device-focused API that hides the low-level details of pin channels, voltages, pull-up resistors, and edge detection (the electrical mechanics of reading buttons or driving motors). Instead of working at the electrical level, developers interact with concepts like button presses, sensor detection, and motor direction. The library supports three programming approaches: procedural via polling (repeatedly checking a device's state), event-based via callbacks (functions that run when something happens), and declarative through a source/value linking system.

That declarative layer is the technical foundation for gpiozero flow. The source/value system exposes manipulation functions — including negated, inverted, clamped, scaled, absoluted, booleanized, zipped, and smoothed — that enable data flow between devices without writing explicit step-by-step code. Think of it as a pipeline: a sensor's reading flows through one or more transformations and arrives at an output device, all expressed as relationships rather than instructions. 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 described Node-RED as convoluted and pin-based rather than device-focused, arguing that gpiozero's abstraction model better fits 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 aligns with the project's current stage as a proposed concept with an installable prototype rather than a shipped library feature.

One thing worth noting is the gap between the source/value 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.

The broader context here is 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 is 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 is 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.