ESP32 OLED Node
A cheap, Wi-Fi-connected sensor node with a small onboard display for local status — it's a satellite that reports to a real device in your fleet, not a fleet member itself.
What this actually is — and isn't
This is the one add-on here that's a real device with a CPU, not a protocol. It's worth being precise about what kind of device, though: the ESP32 is a microcontroller, not a microprocessor. There's no operating system underneath your program — your code (written against Arduino's framework, Espressif's own ESP-IDF, or MicroPython) is the entire running system, with direct access to the chip's Wi-Fi radio, Bluetooth radio, and GPIO. The small OLED display most boards in this class carry is driven over I²C and typically shows local status: a sensor reading, a connection state, a device ID — something useful to see at a glance without pulling up a dashboard.
That architecture is exactly what makes it inexpensive and low-power compared to a Pi or Jetson, and exactly why it can't be a General Infinity fleet member in the same sense those are. There's no shell to SSH into, no package manager, no process supervisor to run the General CLI under.
How this fits into a General Infinity fleet
The ESP32 is a satellite of a real fleet device, not a fleet device itself. The pattern: the ESP32 runs firmware that reads a sensor and pushes the reading somewhere over Wi-Fi — commonly MQTT, or a plain HTTP request — to a Pi or Jetson that is a proper fleet member. That gateway device runs the code General Infinity deployed and supervises, and that code is what receives the ESP32's data and does something with it.
Concretely, you're deploying and managing the gateway side through General Infinity as normal. The ESP32's own firmware is flashed and updated separately, outside General Infinity's fleet mechanism, the same way you'd manage any microcontroller firmware.
Things that bite people
- Brownout resets under Wi-Fi load. The radio draws current in sharp bursts on transmit. A marginal USB cable or underrated supply that's fine at idle can brown out the chip the instant it talks over Wi-Fi — this shows up as random reboots that look like a firmware bug but are really a power problem.
- Deep sleep changes what "running" means. A node that sleeps between readings to save power isn't reachable to push new firmware or read logs whenever you'd like — it has to be awake, which shapes how you design remote updates for it.
- OLED burn-in on static screens. A display left showing the same static readout for months can burn in, same as any OLED. Rotating or dimming the display during idle periods avoids it.