9.3 KB of RAM in total, connected. No TLS library.
See inside every ESP32 you ship. In under 10 KB of RAM.
Pinscope gives the web server on your device a secure URL, streams its logs and metrics, reports every crash with a decoded backtrace and updates its firmware. One outbound connection on port 443. One line of code.
Free for one device, with every feature. No card needed.
valve_set, main/valve.c:57of RAM, all of it, while connected
of flash for the whole component
for memory: every buffer is fixed
one outbound connection, like HTTPS
A fraction of the memory TLS needs. Measured, not estimated.
Remote access usually means a TLS session, and a TLS session costs an ESP32 tens of kilobytes. Pinscope speaks the Noise protocol instead, the handshake WireGuard is built on, in a component written to fit.
The first two rows are our measurements on an ESP32-S2 with ESP-IDF 5.5.3: the free heap of the same application built with and without Pinscope. The third is Espressif's own figure for one TLS connection with mbedTLS on an ESP32.
of RAM in total while connected: buffers, log queue, task and socket. Fixed, nothing to tune
of flash. No TLS library: the connection uses the Noise protocol, as WireGuard does
of extra Pinscope buffers when someone opens the device's page: everything is set aside up front
through the tunnel, and 25 ms for a small request
Speed timed on a local network. The component builds for every ESP32 with WiFi; the figures are from the ESP32-S2.
The bench tools you already use, for devices you can no longer reach.
Its web UI, from anywhere
The HTTP server already running on the device gets an HTTPS address of its own. Pages, APIs and WebSockets work unchanged, behind your login, a share link or an API token. No port forwarding, no VPN.
Logs you can go back to
Everything written with ESP_LOG is tailed live and stored. Jump to a date and time, page backwards, search the whole history.
Health at a glance
Heap, WiFi signal, chip temperature, restarts by reason and the free stack of every task are reported with no code; the CPU share of every task with one switch. Add your own numbers with one call.
Crashes, already decoded
When the firmware panics, the reason, the task and the backtrace survive the reboot and arrive on the next connection. Upload the ELF of the build and you read function names and line numbers.
Firmware updates
Send a new image from the dashboard. It is written to the spare slot, verified, and booted; an image that cannot reach the server is rolled back by the bootloader.
Told when it matters
An email or a webhook when a device stays offline or crashes, and again when it is back. Rules that refuse chosen requests before they reach the device.
The device calls out. Nothing listens on your network.
An ESP-IDF component opens one encrypted connection to Pinscope on port 443 and keeps it open. Requests to the device, its logs, its metrics and its updates all travel inside that connection.
Add the component
In your project's main/idf_component.yml.
dependencies:
pinscope:
git: https://github.com/fluxcorelabs/pinscope-esp.gitEnter your project key
In idf.py menuconfig, under Pinscope.
Project key psk_…
Start it
One call, any time after the network stack is up.
#include "pinscope.h" pinscope_start(NULL);
The device registers itself on first connect and shows up in the dashboard with its own address.
Every feature in every plan. You pay for the number of devices.
Nothing is held back for a higher tier. History and tunnel traffic are fair-use allowances that grow with the plan.
Free
One device with everything switched on, for as long as you like.
Included in every plan: remote access to HTTP and WebSocket, live and stored logs, built-in and custom metrics, per-task stack and CPU, crash reports with decoding, firmware updates, alerts by email and webhook, share links, API tokens and request rules.
Prices are per month. Paid plans are not open for purchase yet.
Before you flash it.
Which chips does it run on?
The component is written for ESP-IDF 5.x and 6.x. It builds for every ESP32 with WiFi: ESP32, S2, S3, C2, C3, C5, C6 and C61. It has been run and measured on an ESP32-S2; the others have been compiled but not yet run by us. On RISC-V chips a crash report lists the code addresses found on the stack instead of an exact backtrace.
Do I have to open ports or set up a VPN?
No. The device makes one outbound connection on port 443, the port a browser uses for HTTPS. It works behind NAT and ordinary firewalls. Only firewalls that inspect traffic and let nothing but TLS through that port block it.
Why not TLS?
A TLS session costs an ESP32 20 to 40 KB of RAM and a certificate chain to check, for a device that only ever talks to one server. Pinscope uses the Noise protocol instead (the handshake WireGuard is built on) with X25519 and ChaCha20-Poly1305: the device checks that it reached the real server, its credentials never travel in the clear, and every message is authenticated and cannot be replayed.
Who can reach my device?
Only you, signed in to the dashboard, unless you create a share link (time-limited, revocable) or an API token for a script. Request rules can refuse chosen paths and methods for everyone or only for guests.
What happens to my device when Pinscope is unreachable?
It keeps running your firmware. The component retries in the background with a growing delay, and the most recent logs and metrics wait in a small queue until the connection is back.
How are logs, ELF files and firmware images stored?
Encrypted on the server before they are written to disk, with a key specific to your project. This is encryption at rest, not end-to-end: the server has to read an image to send it and an ELF to decode with it. Uploading either is optional.
Does it replace my update system?
It does not have to. Updates use the standard two-slot esp_ota scheme, and you can switch them off in menuconfig and keep your own. Every kind of reported data has its own switch too.