Basic GPIO Control

Who it’s for

Anyone driving the pins of a microcontroller or single-board computer from a dashboard — switching a relay, enabling an output, toggling an LED on a prototype. The device exposes its pins over RPC, and the dashboard should look like a bank of switches rather than a form.

What it does

The Basic GPIO Control panel presents a grid of labelled switches, each bound to a pin number, and sends an RPC command whenever one is flipped. It reads the current pin states with getGpioStatus and writes changes with setGpioStatus, sending the pin and the desired state in the request body.

• A switch per pin, positioned by row and column, so the panel can be laid out to match the physical header.
• Pin states are read back from the device rather than assumed, so the panel reflects the hardware.
• The request bodies are templates with {$pin} and {$enabled} placeholders, so the payload can be shaped to whatever the firmware expects.
• A parse function converts the status response into per-pin booleans, so no particular response format is required.
• The panel background color is set directly, which is how several GPIO panels on one dashboard are told apart.
• The Basic GPIO Control requires firmware support: the device has to implement both RPC methods, and nothing works until it does.

How to set up

Data keys

The Basic GPIO Control takes no data keys — it communicates entirely over RPC.

Method	Direction	Parameters	Sent when
getGpioStatus	Two-way (request-response)	{}	On load and refresh, to read every pin’s state
setGpioStatus	Two-way (request-response)	{"pin": "{$pin}", "enabled": "{$enabled}"}	Whenever a switch is flipped

GPIO

Setting	Default	Effect
GPIO switches	Three switches, pins 1–3	Each carries a pin number, a label and a row and column position
GPIO status request	getGpioStatus, body {}	The method that reads the current pin states
GPIO status change request	setGpioStatus, body with {$pin} and {$enabled}	The method that writes a pin
Parse gpio status function	return body[pin] === true;	Turns the status response into a per-pin boolean
RPC request timeout	500	How long each call waits, in milliseconds
Background color	#b71c1c	The panel behind the switches

Implement both RPC methods in the device firmware before configuring the widget. The panel is only as correct as the status response, and a device that accepts setGpioStatus without implementing getGpioStatus gives a panel that switches things and then shows the wrong state.

How to customize

• To match the physical header — edit the GPIO switches list, setting each pin’s number, label, row and column.
• To match the firmware’s API — set the method names and bodies in GPIO status request and GPIO status change request.
• To handle a different response shape — edit the Parse gpio status function, which receives the response body and the pin.
• To distinguish panels — set the Background color.
• To suit a slow device — raise the RPC request timeout from its 500 ms default.

Tips

• Label the switches with what the pin does rather than with its number. Pump relay prevents the mistake that GPIO 17 invites, and the pin number is already in the configuration for anyone who needs it.
• Raise the timeout well above 500 ms on anything not on a local network. That default suits a wired board and produces timeouts on a working cellular or Wi-Fi device, which reads as a hardware fault.