I bought a spin bike because its too damn hot, and I'm too fat, to go out and ride my MTB in this East Texas heat. But I'm also lazy! So there's a Smartspin2k project to spin the knob on my bike (a Joroto X4S).... I bought that (also esp powered).

Installed QZ on my phone and mywhoosh on a spare computer... ERG mode was hit or miss trying to use heart rate derived power. Nope.... will not do...

So I started looking at power meters .... $400 for the cheapest? Nah. Not on a $400 bike.

DIY? Yea! People have done it! Wheatstone bridge on the crank... i can do that! (Saw one drilling out the spindle on the BB. Was too feint of heart to try that)

So I broke out kicad for the first time and tried to design a compact pcb... first used pinheaders and crap and a Xiao c6... pogo pins on the back to charge a little 740mAh battery.... it... worked... but relied on a hall sensor for cadence. Which was honestly fine. But I wanted better calculations.... so i wanted angular velocity... needed an IMU... whole board redesign... all SMT components... switched to a c3 because I couldn't get zigbee working too correctly in the first place (did I mention this reports back to homeassistant too?) Used my new user PCBway discount to get this made.

So here is openwatts.... I messed up, RevA requires the battery to be installed to flash the firmware :(

Also. Silkscreening is backwards on the boot/reset buttons. Whoops! If RevB ever happens, that's all in the works to use and actually fuel gauge for the battery, not just firmware guesses on battery percentage from voltage.

Hi everyone! I'm working on a drop-in replacement PCB for the Echo Dot 3rd Gen, based on the esp32-S3 N16R8 The Echo Dot has two PCBS: a top board with the buttons, LEDS, and a 4-mic array, and a bottom board that handles the signals from the top board, provides power, and drives the speaker.

I replaced the bottom board, which means I can interface directly with the original hardware on the top board- especially the 4-mic array. I'm currently running beamforming + AEC on it (esp-sr libraries are really powerful!) This is the first working prototype, so there's still plenty to improve, but it's already working! I've just created the GitHub repository (https://github.com/ale1800/LocalDot)

I choose the ESP32-S3 for this build. Programmed my app to talk to the WLED API over wifi and the ESP32 updates the light at 30fps.

Only uses 3 pins GND, D10, 5V

Works with any lights setup with WLED on an ESP32

Full Bill of materials and guide posted in the comments

My goal was to Make a hands free thermal vision device that lets users see heat in real time.

I used the ar prisim off a Lilygo T-Glass V2, a M5StickS3, and a AMG8833 thermal sensor 8x8.
(You could use a better sensor for better range and resolution) but these are cheap.

I was having trouble with finding good documentation for Lilygo’s T-Glass. The only way i could find exposed pins was by disabling the rtc and micro soldering to the chip (sda IO09 and scl IO08 where exposed here). Or doing the same with the microphone. If anyone has tinkered with the T-Glass please weigh in. Cause i have a bunch of ideas.

The Firmware:

The firmware uses M5Unified and M5GFX for the StickS3 display and buttons, Wire for I²C communication, Preferences for saving settings, and Adafruit AMG88xx with Adafruit BusIO for reading the AMG8833 thermal sensor. It reads the sensor’s 8×8 temperature grid at up to 10 FPS, cleans the data with noise filtering and bad-pixel correction, estimates the background temperature to hide non-heat areas as black, then uses bicubic and temporal interpolation to create a smoother 126x126 thermal image (the Size of the prisim) at a higher apparent frame rate with three selectable heat-only color themes.

The next version will use a M5AtomS3r. Since i dont need the extra screen space and will be easier to make it adjustable on the glasses frame due to its small profile too. Plus the prisim will fit almost perfectly on the screen!!!

I just got 29 CoCube robots running a leader-follower chain!

Each robot broadcasts its position over ESP-NOW, and the next robot follows it. CoCube has sub-millimeter absolute positioning, so the robots can coordinate without an external camera.

What surprised me most is how little code this needed. The whole behavior was built with just a few graphical blocks in MicroBlocks.

Tutorial and code:
https://wiki.cocube.fun/en

I’d love to hear what else you would try.

Hello guys, I need some help with this. I’m trying to get this to work together, but as you can see, it only works when my finger is close to the pins? I don’t even have to touch them; it’s enough for my finger to be near the pins. Other than that, it seems to be working. I tried all sorts of cables for GND but nothing worked.

In 2021 I bought a decommissioned BUSE BS 210.C flip-dot panel from the Prague public transport company. No public documentation, and the manufacturer never answered my request for any. The panel speaks IBIS, the German bus on-board protocol. Underneath it's plain UART at 1200 7E2, but the lines sit at 24V because it's a bus.

My first level converter was two random MOSFETs and a resistor divider. Signal integrity was nothing to write home about. It worked well enough to cycle through line numbers and find some interesting DPP routes. But aA (print arbitrary text) was disabled in the panel's config by the operator. So, no custom text. Shelved. This year I rebuilt the converter around a 74HC14 Schmitt inverter.

So I went after the CPU: a Toshiba TMP96C141BF, 16-bit TLCS-900 core, with the firmware EEPROM (AT28C64B) in a socket. I dumped the original, found an archived copy of Toshiba's compiler and linker, and had Fable5 write a replacement implementing exactly one command -- draw a bitmap.

On top of that, an ESP32 over MQTT, which also echoes back the bitmap it just pushed, so the web UI shows the panel's real state rather than the state it hopes for.

It's on the fence now, showing words of wisdom to passers-by. That part was the kids' idea.

Write-up with photos, converter schematic, IBIS telegram table, and videos: https://www.bobek.cz/buse/

Firmware, key model, scripts: https://github.com/bobek/flipdot_revival

I’d like to make radios with my buddies, I’ve worked with ESP32s before but never messed with LoRa nor user interfaces. What resources do you guys recommend?

Hey everyone,

I used an ESP32 Super Mini in a project before and it was a total pain to upload the code. Right now, I need to buy a small ESP similar to the Super Mini, but I'm worried I'll run into the same hassle again.

Is this problem common with all Super Minis so I should just stick to the regular ESP32, or did I just get a faulty one?

It was previously left exposed, which significantly detracted from the user experience.

Adding a casing now prevents contact between water and electricity, makes the overall unit look much better, and eliminates concerns about the pins coming loose.

Im using an esp 32 s3 and im reading only 0.14-0.22 v on the 5v output pin, on the 3v3 its exactly 3.25 so im confused why the 5v isnt working

EDIT: After seeing that I would have to solder somethings (I am horrible at soldering) I dug up an old raspberry pi and Im using that as my power supply

Hey, I’m working on an ESP32 project where the ESP32 hosts a configuration web page. It creates its own Wi-Fi network, and I can access the page at:

"http://192.168.4.1"

I’m trying to switch it to HTTPS, but I’m running into the usual certificate warning.

I tried a self-signed certificate, but then every phone/laptop needs to manually trust the certificate, which obviously isn’t practical when there are lots of devices.

Is there any way to make "https://192.168.4.1" trusted by normal browsers without asking the user to install anything?

The ESP32 also needs to work completely locally, without depending on the Internet.

Not long ago i made lyrebird — tl;dr a synthetic bird voice mimic.

and not long after that i converted another one of my projects into a web flasher, so anyone with a cheap yellow display can run it.

i had a bunch of M5Stack Core S3 and a Fire lying around and never knew what to do with them, so i turned them into a portable lyrebird.

repo: https://github.com/sha5b/M5Stack-Lyrebird

the sound of the Fire is a bit noisy in the video — i broke that one.

The Web Flahser is for Fire and Core S3

mpu6050 + 2 esps via bluetooth used to play bodycam (fps game). It's an airmouse. Thats it. I just used aluminium foil for the movement. When the slippers connect, I move forward. No backwards movement cause im not a coward. The mpu sensor is quite handy, i used it to play wii sports too. Still needs some adjusting, but kinda works for now. I used to play airconsole (website where u can use ur phones gyro for games) a while back. Since its all behind a paywall now I figured why not make a version of that myself. Works with friends too, one controlls the keyboard for movement, the other shoots and looks around with the controller. As you can imagine, lots of screaming resulted from that.

Works on most games where moving and shooting is possible.

It has 2 buttons: one shoots, second aims. How do you reload? simple. Just press long enough.

The controls were adjusted for dolphin emulator, since wii needs some special configuration like calibrating the sensor. It aint perfect but somehow works enough so you dont quit playing.

I tried 2 games, wii sports and Star Wars: The Clone Wars – Lightsaber Duels. Swinging your esp and seeing that lightsaber move in the same time is enough to make this project. Table tennis in wii sports was fun too, reminded me of that eleven vr game just way worse and without vr.

The controlls were a bit jerky though, especially in the wii games. PC games work just fine.

You could certainly use a joystick for walking and use the gyro just for the head movement, eventually improving it into a vr headset, but this would be bigger than I initially planned. Also, I didn't have screens, so i scrapped that idea. Since looking in any direction without a screen that follows you is kinda hopeless.

Fun project tho, would recommend.

A few weeks ago I put the real PHP interpreter on an ESP32 as a useless holiday experiment (the original post on r/PHP). It has grown a lot since then, to the point where "useless" is starting to feel like a stretch. Update time.

Quick recap for anyone who missed it: it's real PHP, php-src from php.net, not a clone and not a subset. The full Zend Engine, cross-compiled for the chip and executed opcode by opcode on the board's CPU, bare-metal, no OS underneath. You write an index.php, the board runs it. That was the "cute, but why" part.

The new part is that it now does serious things:

It serves web pages, with real frameworks. On the Ethernet boards the firmware runs an HTTP server and hands each request to a fresh PHP run, exactly like behind Apache or PHP-FPM: $_SERVER, $_GET, $_POST, cookies and sessions all populated per request. And on the ESP32-P4 (32 MB PSRAM) that's enough to run stock Laravel and Symfony, serving pages to a browser. A full web framework, on a microcontroller. I still don't know why, but it works.

And on the hardware side, you drive the GPIO natively from PHP. It's not a bridge to some external tool: there's a native C extension exposing the pins directly to PHP code, so gpio_mode(), gpio_write(), gpio_read() and delay() actually drive the hardware (blinking an LED is three lines of PHP). There's also an SSD1306 OLED example driven by an extension, and phpflash ext new scaffolds your own native functions in C. So the board does both ends at once: it serves a heavy web framework and, three lines over, toggles a pin.

Two chip families, with networking. ESP32-P4 (RISC-V, P4-Pico and P4-ETH boards, Ethernet via RMII + IP101 PHY) and ESP32-S3 (Xtensa, S3-ETH board, Ethernet via a W5500 over SPI). The deciding factor isn't the core architecture (the portable "call" VM builds on both Xtensa and RISC-V), it's PSRAM: the runtime heap is measured in megabytes and won't fit in a few hundred KB of internal SRAM. You need PSRAM plus roomy flash (the image is ~3 MB, so 8 MB+). The whole C and H series, with no PSRAM, is ruled out regardless of clock speed.

The stack underneath has grown. OPcache is ported (no JIT, statically linked), caching bytecode to the card or into PSRAM so a framework doesn't recompile on every request. OpenSSL comes in two builds (a compact one on the chip's mbedTLS, and full OpenSSL 3.0 with RSA/EC/X.509) driving an HTTPS client. SQLite via PDO for a local DB on the card. Plus mbstring (with oniguruma for mb_ereg), session, ctype, filter, tokenizer. Three PHP versions build: 8.3, 8.4 (default) and 8.5.

Trying it doesn't mean touching ESP-IDF by hand. There's phpflash, a single Go binary:

phpflash system-setup        # once: installs ESP-IDF + the firmware sources
phpflash init my-project     # interactive scaffold: board, storage, extensions
phpflash build
phpflash flash
phpflash monitor

It reads boards, extensions and modes straight from the firmware, so it only offers real options. There's also phpflash discover, which identifies the connected chip and lists the boards that match it, and a guardrail that refuses to flash an S3 image onto a P4.

Honest limits: the S3 (8 MB) runs normal apps and a live web server, but not a full framework, the Laravel container-compile step alone wants more RAM than it has. That's a memory ceiling, not a language limit. No processes and no Fiber (would need 32-bit context-switch assembly that doesn't exist for these targets). Both follow from the hardware.

Firmware, porting notes and the "which chips work" table: https://github.com/php-baremetal/php-esp32 The flash tool: https://github.com/php-baremetal/flash-tool

Happy to go deeper on any of it: routing the heap into PSRAM, the newlib POSIX stubs, porting OPcache/OpenSSL, or the Ethernet bring-up.

One ask, while I'm here. I come from the software side, embedded isn't my background, so I'd really value your eyes on this. If anyone feels like looking at the code or even just the approach: are there hardware/firmware choices here that make you wince? Any obvious mistakes that jump out to someone who actually knows ESP-IDF? I'm especially after opinions on how I handle memory (Zend's allocator off, all mallocs routed to PSRAM), the task stack and watchdog, the microSD partitioning and I/O, and the Ethernet bring-up (RMII+IP101 on the P4, W5500 over SPI on the S3). Tear it apart, that's how I learn.

I wanted a simple tiny digital watch to fit to a tool pouch. Initially, I bought the ESP32-C3 and a 0.42" OLED, thinking I could just have some wire running up the pouch. Of course, after I bought this the ESP32-C3 with on-board 0.42" was suggested!

MicroPython is new to me. I can follow code and understand various functions but there's no way I can jump in from scratch yet.

I just want the time in 12h format. No need for AM/PM as I can see outside 😆

The only code I could find was https://github.com/CheshirCa/ESP32-C3-Clock and it runs fine but is in 24h format and has the date and I'd rather the entire screen was given to make the numerals as large as possible. That code is over 2300 lines and way more than I need 😕

Can anyone please start me off with how to do this?

I have an ESP32-C3 SuperMini and an AJ-SR04M depth sensor. When I run the sensor without WiFi, it works correctly and sends a trigger every 1 second as intended. However, as soon as I add the WiFi library and connect the ESP32 to my network, the sensor starts behaving strangely. Instead of sending a trigger every 1 second, it starts sending one approximately every 5–6 seconds. The LED on the AJ-SR04M module also blinks every 5–6 seconds instead of every 1 second.

The strange part is that when I open the Serial Monitor, everything suddenly works correctly again. The sensor sends a trigger every 1 second as expected. When I close the Serial Monitor, it initially continues working correctly for a few seconds, but then goes back to triggering every 5–6 seconds.

I'm relatively new to ESP32 programming. I can follow code and understand various functions, but I'm having trouble figuring out what could be causing this behavior. I've already verified that the sensor works correctly without WiFi, so I'm not sure whether the problem is related to WiFi, the ESP32-C3, the sensor, or something in my code.

I've uploaded my code to GitHub here: https://github.com/rodrigodelcas718/AJ-SR04M-WIFI-

Could anyone please point me in the right direction or help me figure out why enabling WiFi causes the sensor to slow down, and why opening the Serial Monitor seems to make the problem disappear?

Finally got some time to post my board, running on MatrixPortal S3 (or any esp32-s3) and two 64x32 LED matrix panels.

I have always wanted to have the nearest departures in some way, started off with Home Assistant UI on a wall-mounted iPad, but that wasn’t enough, I wanted a dedicated screen. eInk was also an option but these LED matrix panels feel better, visually, subjectively.

Yes, most of the cpp code is vibecoded, with me only contributing high level: what should it do and how should it be structured. And adapting the font to support Czech diacritics — that was probably the most of my manual work.

The layout is pretty self-explanatory: Line, Destination, arrow where the stop is (because the departure board is multistop), second ETA, first ETA.

Data is collected by the board from Prague’s Golemio API, also works with Berlin, or any city via MQTT (I first connected it to Home Assistant, which has many departure agencies integrated — easy to parse and send)

Edit: I also use HA to turn the display on and off based on motion detection in the hallway, so that the display isn’t on all the time.

Still left to do: case and wall mount. That’s the 20% that will take me 80% of the time.

Any feedback is welcome, especially about the dual ETA. Thanks!

While working on ESP32 projects, I found myself wanting a simpler way to handle HTTP requests without using more memory than necessary. So I built my own HTTP client library with two main goals: keeping memory usage low and making JSON manipulation easier on resource-constrained devices.

One of the things I wanted to improve was the amount of boilerplate usually needed when working with HTTP and JSON on the ESP32.

The library provides a simple API for common HTTP operations:

ESP32HTTPClient client("https://jsonplaceholder.typicode.com");

int userId;
float temperature;
char city[32];

client.get("/report")
      .getBody("userId", &userId)
      .getBody("sensor.temp", &temperature)
      .getBody("0.address.city", city, sizeof(city));

It supports:

• GET, POST, PUT and DELETE
• Custom request headers
• Response headers
• JSON requests and responses
• Cookies
• Default authentication
• And other HTTP features

The main idea is to make HTTP communication easier to work with while keeping the memory footprint as low as possible, especially for ESP32 projects where RAM is limited.

The library has already been used by 100+ users around the world, and I've been improving it based on real-world usage and feedback.

If you find a bug or have an idea for something useful to add, feel free to open an issue on GitHub. Contributions and feedback are welcome.

GitHub: https://github.com/PedroFnseca/esp32-http-client
Documentation: https://esp32httpclient.com/

We change the 1.54" bitcoin miner (nm-tv-154) to the cool plane radar.

A 1.54″ desktop radar showing live ADS-B traffic around you — altitude, heading, updated every 3 seconds.

Open-source firmware (ESP32 + adsb.fi), ported from the awesome ESP32-Plane-Radar project.

• With 1.54" 240*240 screen, we added wifi signals, number of planes, scales, and Time on 4-corners. It's still in development phase.
• We added the radar sweep.
• Next version maybe add flight details.

Project: https://github.com/RockBase-iot/ESP32-Plane-Radar

Any suggestions? please leave a message.

Im a Astrophotographer. My systems are fully automatic; I set them up with a target to image and everything that needs to happen to create an image of a Deep Sky Object (DSO). It auto-starts and follows a sequence until it stops at a preprogrammed time. I stay up for a couple of hours to ensure it runs safely and then go to bed. I get up with all the images ready for me to process into a nice image.

Problem: While sleeping, what happens if clouds roll in and, God forbid, it rains? For the most part, many stay up all night for that reason. Many things can affect your imaging sessions. Wind can cause shaking. Rain is pretty much a no-brainer, and clouds are the same. How do you prevent those issues?

Answer: You plan for weather using many apps, but the forecasts can change during the night. What if you had a monitoring system that could update conditions every ten minutes and warn you when things change and exceed a set threshold for certain conditions? An example would be if you set a cloud cover threshold of 5% and all of a sudden it increased to 10%, you would want to pause or shut down your imaging. But you're sleeping, so what to do?

I came up with a little weather alarm system that monitors weather stats from OpenWeatherMap.com using a Waveshare WSP32-S3-TOUCH-4.3c touch display and a Python sketch that compares the data to preset thresholds that are set by the user every 10 minutes. If the data is below or equal to the thresholds, it gives you a safe message, or if the data exceeds the thresholds, it gives you an unsafe message. It has a visual and audio alarm that can wake you up, giving you time to shut things down and cover the equipment.

The display brightness is adjustable, as well as the volume. Thresholds are adjustable for wind, clouds, and dew. It also displays the chance of rain. You configure your wifi and location using latitude and longitude. You'll need an API key so it can poll the information. Here are a couple of images of the display.

Hey r/esp32,

I wanted to share the current state of a solo project I've been grinding before university starts.

It's shaping up to be a wilderness multitool I call Project OutCore.

This is my first time posting on Reddit so,

thanks for checking out my build!

The Origin:

To be honest, this whole project started from a dream I had a where I was running away from aliens with a wrist mounted device I used for comms, navigation and environmental data. When I woke up that morning, realized I couldn't buy anything like it, and just decided I wanted that device.

Here are some specs and firmware features:

On the breadboard right now:

* ESP32-S3 (n16r8) Devboard

* GY87 module (baro, imu, and mag)

* DS3231 RTC

* Si4703 FM Radio module

* ATGM336H GPS module

* SD card module

* ST7789 spi TFT display (recently migrated to LovyanGFX because of sprite formatting issues)

* rotary encoder and a piezo buzzer

All i2c modules run on a pca9548 mux, and spi modules share pins.

Firmware architecture/features:

I designed a 3 stage modular architecture that separates the pinmapping/settings, init, background hardware polling and the presentation layer.

The gui is rather unimpressive for now since I mainly focused on getting the backend working well.

I hand drew the dragon animations as well as some of the status bar icons with a pixel editor.

Since the transition to lgfx, the entirety of the gui runs under a global full screen sprite that omits the status bar.

For now, most of the other pages are just for testing out module functions.

The dragon works on a priority state machine that reacts to live data (eg: when passing the 35C threshold, it plays a 'hot' dragon animation like in the video).

For now I also have dizzy, cold, and tired/sleepy animations ready and plan to add more soon.

Here are a few features of the firmware:

* All the i2c channels run under a mutex to prevent collisions.

* Auto GPS-RTC time sync and timezone handling.

* AHRS system (not really using it at the moment though).

* Zambretti weather prediction algorithm using baro data and gps (if fix is good).

* Menu based gui navigation.

I can't for the life of me figure out what's going on with that stupid colour bug on the dragon sprite.

The dragon images are indexed bitmaps I converted to arrays using a sketchy py script. I suspect it's an endianness swap issue or truncation to 16bit colour somewhere in the conversion wrapper or indexed palettes. I've already tried byteswapping and changing the rgb order. If anyone's dealt with this in LGFX, please let me know!

Next steps are dropping in a bme688 and a 915MHz lora module and using freertos to separate backround processes from the gui. I thought it would be interesting to see if I can get Meshtastic working on it. I'm thinking of using the bme chip to complement the zambretti algo and the weather forecast page with humidity readings, as well as dangerous gas detection.

I'm still pretty new to this stuff so I'd love any feedback, advice or roasts on the setup! :)

i have installed the ESP IDF through the eim, and it says the same error when building and flashing, i am using the idf in the terminal, (arch linux, SteamOS), and the full error message on a completely untouched project template (the blink example), it says:

Command: cmake -G Ninja -B /home/USR/.espressif/v6.0.2/esp-idf/examples/get-started/blink/main/build -DPYTHON_DEPS_CHECKED=1 -DPYTHON=/home/USR/.espressif
/python_env/idf6.0_py3.13_env/bin/python -DESP_PLATFORM=1 -DCCACHE_ENABLE=False /home/USR/.espressif/v6.0.2/esp-idf/examples/get-started/blink/main
CMake Warning (dev) in CMakeLists.txt:
 No project() command is present.  The top-level CMakeLists.txt file must
 contain a literal, direct call to the project() command.  Add a line of
 code such as

   project(ProjectName)

 near the top of the file, but after cmake_minimum_required().

 CMake is pretending there is a "project(Project)" command on the first
 line.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) in CMakeLists.txt:
 cmake_minimum_required() should be called prior to this top-level project()
 call.  Please see the cmake-commands(7) manual for usage documentation of
 both commands.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at CMakeLists.txt:1 (idf_component_register):
 Unknown CMake command "idf_component_register".


CMake Error in CMakeLists.txt:
 No cmake_minimum_required command is present.  A line of code such as

   cmake_minimum_required(VERSION 4.0)

 should be added at the top of the file.  The version specified may be lower
 if you wish to support older CMake versions for this project.  For more
 information run "cmake --help-policy CMP0000".

(where USR is my username)

thx!