Edge firmware (ESP32)
The edge firmware turns a cheap ESP32 into a Cobblr edge connector: one binary whose behavior is a declarative device profile flashed to the chip. It is the cheapest way to let Cobblr coordinate a physical actuator or sensor (a relay, a valve, a pump, a load cell, an RFID reader) without a Pi, a Docker host, or a Node service. Cobblr makes an HTTP call to the chip, and the chip's firmware drives the pin.
:::warning Status The firmware is a P0 scaffold, authored without a board or toolchain to hand, so it is compile-verified and hardware-verified by nobody yet. It is a faithful implementation of the contract, not a tested binary. Flash it, exercise it on the bench, and fix what the compiler and the hardware find. Treat every claim here as what the code intends to do. :::
Chip or software bridge
Cobblr has two ways to reach a machine on your own network: the software edge bridge (a service you run on a Pi or a host) and this firmware (a service that runs on the microcontroller itself). They serve the same edge-adapter contract, so from Cobblr's side they look alike. Pick by what the thing is:
| Reach for | When |
|---|---|
| This firmware | A discrete actuator or sensor: a relay, a valve, a scale, a break-beam counter, an RFID tap. No OS, no host, a few dollars of hardware. |
| The software bridge | A machine with a real manager to talk to (a printer's OctoPrint, a laser's controller), or a protocol that needs a full runtime (MQTT, a login handshake). The Pi bridge installs drivers on the fly; a chip can't. |
A microcontroller has no Node runtime and can't install a driver package, so its behavior is fixed at flash time by a profile. That is the whole model: one signed firmware that interprets a declarative profile, the same declarative idea as Cobblr's machine-driver manifests, run on the chip.
What it's for, and what it isn't
The chip's ceiling is modest and known: actuate, sense, show a small status display. The lane where a Cobblr-flashed chip is the right tool is narrow and worth stating plainly:
- You don't run Home Assistant. For a user already running Home Assistant, ESPHome does generic sensing and actuation better, and Cobblr reaches those devices through the Home Assistant connection instead. The chip is for the makers and small shops who will never stand up HA.
- The device is bound to a Cobblr entity, not a dashboard. The point is physical I/O wired straight to your Cobblr data: a scale's weight decrements a part's stock, an RFID tap checks out an asset, a valve runs from a plant's own schedule. Getting a reading into a dashboard is a job other tools already do.
A profile that names an unsupported peripheral is rejected when it loads; a new peripheral is a firmware update, not a config change.
The pieces
- Profiles: the declarative profile the firmware interprets: what it declares, the peripheral kinds it supports, and the two directions (commands out, readings in).
- Getting started: build, flash, first boot, and wiring the chip to a Cobblr connection, to the extent the repo documents it.
- The edge-adapter contract: the HTTP the chip serves, and how it fits the contract Cobblr already speaks to a bridge.