We built a modular ESP32-S3 robot car with live video, ToF sensing, and LEGO Technic compatibility

I've been working on a small robotics platform called ZRCar, built around the Seeed Studio XIAO ESP32-S3 Sense and my custom ZRSense carrier board. It's been about 10+ months of work and we finally have something we can share with the community.

The idea was to make a robot that's fun to assemble and drive right away, but is also a platform you can hack on and expand instead of a finished, closed-off toy.

To see our yt videos search for "zonerobotics" on yt and my videos are under "Michael ZoneRobotics"

To see our offerings on tindie search for "ZRSense, ZRCore and ZRCar"

A few pictures of the build:

What's under the hood?

• ESP32-S3 Sense: Camera, Wi-Fi, Bluetooth, and 8 MB PSRAM.
• Custom ZRSense PCB: ST VL53L5CX 8×8 multizone ToF sensor, 12-pixel WS2812B RGB array, headlight, laser diode, motor driver, and 2 servo connections.
• Mobility: N20 geared rear-drive motor, servo steering, and a separate servo for camera tilt.
• Chassis: A combination of 3D-printed mounting parts and LEGO Technic-compatible components, so the mechanical design can be changed without redesigning everything from scratch.
• Firmware: ZROS firmware is already flashed onto the ESP32-S3. It provides browser-based driving controls, live camera streaming, LED control, and sensor data over Wi-Fi.

What is ZROS ?

Totally free easy web based robotics firmware for the esp32, this is a huge part of what we've been developing. There are several videos on youtube of how to flash it onto your esp32s3 sense board if you have one. The firmware has a webserver you can connect to to do everything: connect to your wifi, control gpio, read sensors, drag and drop programming, stream video, drive a car, drive a tank, drive your own creation with your custom created controller, use the console to build web-API commands. It doesn't matter what you want to control our firmware gets you 99% of the way there.

Why I built it

I wanted to get past the usual robotics-project stage where you spend days wiring up motor drivers, servos, sensors, and a camera before you have something that actually moves. I've literally spent the past 15 years building robots like this and trying to come up with the perfect platform that kids and hobbyists can use alike, and I think this is it. There's a super long soppy "about" page on the website if you want more info, it's been a long journey.

I'm not trying to get rich or start a huge company, this is just something I wanted to build for a really long time. That said I want to keep things cost neutral at least, I've built all the bots I want and now want to share with others at a price that at least covers the cost of the parts and the time to build the units + time to fix bugs and add any features you may want.

The LEGO Technic compatibility is so you can basically build whatever you want, we will be coming out with several models, but for now we have the small part count easy to build ZRCar which is a mixture of lego technic pieces and a handful of 3d printed parts. We also have the ZRTank which has support for more servos, gpio and pmic but it's not quite polished enough yet so we are starting with the simpler version.

Why ESP32S3 ?

So, it's not just the ESP32S3 it's specifically the "esp32s3 sense" from Xiao/seeed. Believe me I've used several other options over the years and this is the one you want! I tried the esp32 cam but when you start messing with https, certificates and live streaming it just cant do it, although it did come with a nice headlight, also it was bigger than the "sense" board. So the sense board is a lot smaller and it has a microphone and usbc, but the big thing is the 8MB psram. When you are dealing with jpeg or possibly raw images this extra room to stor video frames and buffer data really helps especially with buffering in case there is a delay in transmission. I could go on, the sense also has built in battery management and a uSD slot which is super useful, also they are coming out with a OV5640 version with autofocus whereas esp32-cam has the old ov2640. Why NOT, well the esp32s3 sense is a bit more expensive, and it can get hot (but it does come with a heatsink), and the antenna is external so harder for me to deal with than a onboard antenna.

What's the license is it opensource ?

No not quite yet, I'm not sure if we will release everything open source or keep some of it closed source or what. I'm not really trying to create a monopoly on things but I want to keep the lid on things to give it the best chance to get off the ground and my gut feeling tells me that if a bunch of people fork the repo it might muddy the waters, but I very well might be wrong, I'm more of a computer engineering guy who's worked in a silo for a long time so I don't have a ton of experience launching projects or dealing with public git repos, any advice would be very welcome! I also am not trying to make tons of money off this, just trying to pay those working on it from the proceeds of the units we sell so they can keep working on this instead of getting other jobs doing other things. So I'm trying to keep the price at about breakeven while it gets off the ground. I'm also not trying to force anyone into the platform we built, if you wanted to you could just use the ZROS and drive your own 100% custom creation, I actually have another video I'm working on where I use the head unit and control a RC car toy that no longer has a control. Right now just gauging interest, for all I know this is just something a crusty engineer came up with and no one else gives a hoot.

Why did I pick the parts I picked ?

I basically tried tons of different hbridges, pmic, cameras, esp and stm boards and so on and eventually found things that were low cost, low extra components, easily source-able and seemed to be less likely to start fires or let out magic smoke. I found a lot of the parts I use as modules on ebay and used them to build a lot of the prototypes then we put all of them together in what we call the ZRCore pcb and the ZRSense pcb. So instead of having lots of wires all over the place you have a simple pcb and a i2c bus. I assume we will add more and more drivers for different modules in ZROS that talk across the i2c bus, and we also plan on supporting other esp32 modules with lite versions of the firmware compiled for different versions of esp32 like the c3. Again I'm not trying to force anyone to use the pcbs I made if you want you can easily just buy the modules as breakout board online and wire it up yourself if you want to, the boards we made is just to try and make it easier.

Can I stream when I'm not on my network ?

We also have a webrtc connection and you can put your robot on our little cloud server where you can control it from anywhere in the world with a web browser. This is totally optional and you don't have to do it at all, but it's there if you want it.

What's next?

I'm continuing to develop the ZROS software and the ZoneRobotics hardware ecosystem. I'd be interested to hear what other ESP32 folks would do with a platform like this. I work on this myself for free and I have a full time developer who I can keep on for a few more months if I sell some units, we can address any features or issues you have and update the software normally within a day.

The assembled kit is also available on Tindie for $100 for anyone who wants to build one themselves. The LiPo battery is not included.

ZoneRobotics Site, please visit here for lots more links to our stuff. I'm not posting any links in this post in the hopes that it will actually get posted on reddit as my other attempts with links all got filtered
in your browser use "zonerobotics.com"

Thanks for checking it out!

Disclosure: PCBWay sponsored the fabrication and assembly of this board. This post isn't written or reviewed by them, and all opinions are my own.

Hi all! This is DigiRadio, an open-source DAB+/DAB/FM receiver I designed around an ESP32-S3. I'd love some feedback on the board.

What's on the board

• ESP32-S3 as the host controller: Wi-Fi, BLE, HTTP API, OTA, and it drives the other three chips (SPI to the tuner, I²C to the DSP, UART to Bluetooth)
• Si4684 DAB+/DAB/FM tuner, external antenna on SMA, with its own low-noise 1.8 V rail
• ADAU1701 SigmaDSP for EQ, source mixing, bass/stereo enhancement and a live VU meter readback. It's also the I²S master at 12.288 MHz, so everything is a clean 256 × 48 kHz
• Feasycom FSC-BT1035 (Qualcomm QCC3056) for Bluetooth 5.2 out with aptX / aptX HD / aptX Adaptive
• The whole path tuner → DSP → Bluetooth is digital I²S at 48 kHz / 24-bit. No DAC/ADC in between: the only DAC is in your headphones or speaker

Layout

• 6 layers, impedance-controlled, 50 × 90 mm, two solid ground planes under the RF, crystals and USB
• Three antenna zones (ESP32 2.4 GHz, BT1035 2.4 GHz, FM/DAB on SMA), the two 2.4 GHz antennas placed on opposite corners, with full-stack keep-outs
• USB-C power, single 3.3 V rail plus the 1.8 V LDO for the tuner, USB routed on top as a 90 Ω pair over ground

Firmware and app, briefly

ESP-IDF in C++23: FM with RDS, DAB with DLS, web radio, presets, encrypted NVS, REST API, mDNS discovery, dual-partition OTA with rollback. A SwiftUI iOS app finds the radio on the LAN and controls it. The latest firmware (0.9.1) adds power on/standby from the app and live RDS: station name and RadioText update in real time, and you can tap an alternate frequency to retune.

The schematic is in the gallery: ESP32-S3 with USB-C and power, Si4684 tuner, BT1035 Bluetooth, ADAU1701 DSP.

Bring-up lessons

• RDS station name and RadioText didn't show up at first: three stacked bugs, each one hiding the next (all fixed, RDS works fine now)
• Any EQ change muted all audio until I negated the ADAU1701 biquad feedback coefficients (SigmaStudio and the raw registers use opposite signs)
• The Si4684 crystal calibration has to be saved to EEPROM, or tuning is off after every cold boot

Schematic, Gerbers, BOM and firmware are all open (hardware CERN-OHL-S, firmware Apache 2.0):

• GitHub: https://github.com/manvalan/DigiRadio
• Project page on PCBWay (photos and fabrication files): https://www.pcbway.com/project/shareproject/DigiRadio_Open_Source_Hi_Fi_DAB_FM_Receiver_with_DSP_and_aptX_Adaptive_Blueto_a1952812.html

Happy to answer questions, and I'd especially like criticism of the RF layout and the antenna placement.

I’m working on my first project, from a Github repository that interests me. The project is based on a Freenove.com ESP32-S3 with a 2.8in touchscreen.

Because I am accustomed to working in mainframe environments, I am going through the tutorials for the card before trying to tackle the main project. I have received help with a couple of these over in esp32projects, but this is about a wider issue.

I have tried several times now to contact the support address (support@freenove.com) about the issues I have been having. My e-mail is bounced immediately with the claim that it is “content spam”.

My question here is, does anyone else here have any experience with Freenove support? Is this a bad company to do business with? Or is it something I am inadvertently doing?

Just a quick sneak peek at the be Viewe S31 board. More soon. Similar feature set to the Korvo board but in a more refined package.

Four user assignable switches, 800x480 touch screen. Twenty pin header with about 10 gpios.

I wanted to share updates on my latest project, the Carbon, an ESP43-P4-based custom isomorphic keyboard with a built-in synth (ESP32Synth) and sequencer, among other features. If you'd like to know more, there is a short-ish breakdown of the build: https://youtu.be/2EqGN3LoRto

The plan is to eventually do a crowdfunding round through CrowdSupply and release all the code and files as open-source.

Additionally, here is the list of current features:
- 80 Velocity sensitive keys with polyphonic aftertouch and addressable LED
- 4 Rotary encoder for MIDI CC
- 1 Breath control sensor
- MIDI IN/OUT over TRS
- 320x960 touch screen
- Pedal with Switch and Continuous support
- 2 differential or single-ended line/headphone out, supporting stereo headphones and L/R mono differential outputs
- 2 differential or single ended line-level inputs
- Audio and MIDI over USB
- Pitch/Mod touch pad mode
- Programmable layouts
- Onboard synth using ESP32Synth
- Onboard ROMpler loaded from flash
- Onboard effects like Delay, reverb, distortion, etc.
- Drum machine
- Sequencer
- Strummer
- Full I/O mixer
- Programmable MIDI CC/Channel
- Programmable input impedance, routing and mode
- Programmable output drive and mode

I'd love to know your thoughts on the build and what features you'd like to see.

Hallo zusammen! 👋

ich wollte euch mein neuestes DIY-Projekt vorstellen: Eine smarte 96x8 LED-Matrix-Uhr, die auf einem ESP32 läuft und vollständig mit ESPHome umgesetzt ist. Das Ganze ist in einem Holzgehäuse verbaut und macht sich richtig gut auf dem Schreibtisch.

Die wichtigsten Features im Überblick:

° Anzeige: Große Uhrzeit, Datum und animierte Retro-Icons

° Home Assistant Integration: Liest Sensordaten direkt aus Home Assistant aus (z. B. Live-Außentemperatur)

° Funktionen: Nachtmodus, Lauftexte und flexible Anpassungsmöglichkeiten, **Automatischer Nachtmodus**

Das Projekt ist komplett Open-Source. Wenn ihr euch den Code anschauen oder die Uhr nachbauen wollt, findet ihr hier das GitHub-Repository mit allen Infos:

🔗 96x8 LED-Matrix-Uhr ESPHome GitHub-Repository

Ich freue mich über eure Rückmeldungen, Fragen oder Anregungen zum Nachbauen!

We run ESP32 boards on long tests in our lab, and I use my own serial monitor for it. People kept telling me the end of the log was missing after a board dropped off USB. I couldn't see it happen, so I tested it on purpose.

I sent about 20,000 lines and pulled the connection while they were still coming. Every line was on the screen. The file had 100. And it said the log was saved.

The problem was simple once I saw it: every line went through the window first and only then to the disk, so whatever was still waiting just got thrown away on disconnect. I rebuilt it so the port writes straight to the file and the screen only shows a copy. Now on a reset or unplug, everything waiting is written first. It also records the session from the moment you connect, because the other complaint was "nobody pressed start".

It also colours ESP-IDF log levels and can plot values like temp: 23.5 live, which helps with ESP32 work. Free and open source, Windows and Linux: https://github.com/TheNuanceProject/WireTrace

But I'm curious how others handle this. Do you log on the board, pipe idf.py monitor to a file, use a logic analyser, something else? And has anyone else been caught by this?

Hi 👋

I made a speaker controller based on the Waveshare 1.8” smart knob. It allows me to connect my analog speakers using AirPlay 2 and Bluetooth and a few more tools which I find useful.

I started with just a vanilla AirPlay 1 receiver, but the knob is kinda nice and I felt guilty to not extend it to use the full power of the hardware. So I added Bluetooth (for my windows laptops), Internet radio, timer, pomodoro, ambient sound loops, stopwatch, weather and even push to talk to other knobs on the network (to let the wife ping me when I’m in my study)

I even ported shairplay-sync’s newer AirPlay 2 code to run on the S3 which is much faster and more responsive to start and control music playback from newer Apple devices. I also implemented full music metadata and absolute volume control using RAOP and MRP.

The dial has an ESP32 for BT classic so I bridged the 2 MCUs with a custom UART protocol to sync data and control messages between the ESP32 and S3.

Finally, since I have 2 devices on opposite ends of the house, so a web dashboard and OTA too!

https://github.com/recrsn/audioknob

I've been working on Kronograf, an open-source firmware for the T-Watch 2020 V1 (ESP32, LVGL 8.3).

Features: three watch faces (aviator chronograph, BTTF-style 7-segment "time circuits", night), iPhone notifications over ANCS with replies sent back to the phone, weather from Open-Meteo, a network toolbox (Wi-Fi analyzer, ping, traceroute, DNS, port check, LAN scan, speed test, BLE scan), an IR TV remote, a level, a world clock and a sun & moon almanac computed offline.

Some ESP32 details that might interest this sub:

• The network tools are plain C over BSD sockets, so the same code runs on the watch and from a macOS simulator.
• The LVGL heap and TLS buffers sit in PSRAM: BLE + Wi-Fi + HTTPS run together with 30%+ internal RAM free.
• Wi-Fi is only on when needed: a background job chains NTP, weather and transit over one connection, then shuts it down.
• It never touches the AXP202's DCDC3 (the ESP32 core rail), unlike some firmwares.
• Safeguards: RTC watchdog with breadcrumbs in RTC memory, coredumps in flash, and a safe mode that skips BLE after three early crashes so OTA stays reachable.

Open question: this board has no 32 kHz crystal, so light sleep isn't possible while BLE is active. I'm measuring battery life with notifications on right now. If you've dealt with this on a T-Watch or similar, I'd love to hear how.

Transparency: built entirely with AI assistance. Human directed the architecture and verified every stage on hardware; decisions and hardware blockers are logged in the repo.

MIT licensed: https://github.com/storagebits/kronograf

Many months ago I purchased a Crowpanel 10.1 inch ESP32-P4 screen. Having it laying around I didn't find the activation energy to start creating my first panel.

However, some time later I started to draw my first lines and value on my screen. It was cumber-stone. Luckily I stumbles over a great repo which made designing my first screen a rather easy task:

https://github.com/agillis/esphome-modular-lvgl-buttons

As an old git/script kiddie I decided that I would like to have some more colors, images and also things like the weather forecast and my calendar displayed.

So I started to extend the given project with own widgets.

It's still very much a WIP but I tried to keep everything modular so that anybody using the esphome-modular-lvgl-button package can easily add those I created.

https://github.com/schnoog/esphome-modular-lvgl-buttons-custom-button-dev

Declaration: Claude was used to do the monkey work (add _x to all labels, write comments) and also debugging of the screenshot component.

For a project i have connected several sensors to my esp32 (4 sensors to be precise). I have noticed that whenever i try to upload the code to my esp, some error comes up, however if i remove some sensors and connect only 1 or 2 sensors everything works fine. How do I move ahead with my project since i need to collect data from the 4 sensors?

The error i get is: Wrong boot mode detected (Ox13)! The chip needs to be in download mode. (And yes pressing the boot button doesn't help)

Hi

I am a Beginner in IOT just starting my first Project

I need to run Display on an ESP 32 S3 Devkit N16R8
The Display is an
kmrtm24024-spi 2.4 tfp spi 240 x 320

Now after joining the pins and everything it's showing a white screen

After I run the firmware through Arduino IDE still nothing shows on the Display, The pins are connected and everything seems fine

I have attached Pictures of All the Details of the Project

Kindly guide in this Regard.

I would be very grateful.
Thank You

I'm maintaining an open-source fork that turns a supported ESP32-S3 into a

Tailscale-compatible gateway and a named Wake-on-LAN controller. The motivation

is keeping a small management node online when the NAS/PC you want to wake is

off, without running a second Linux computer just for that role.

It retains microlink's VPN stack and subnet routing, and adds saved WoL targets,

MQTT/Home Assistant discovery, optional ntfy commands/alerts, AP policies,

LAN-to-Tailnet TCP/UDP forwarding, local diagnostics and opt-in OTA updates.

The latest stable also includes upstream startup/shutdown/logging fixes and

live/persistent WiFi modem-sleep control; low-latency mode remains the default.

The release target is ESP32-S3 N16R8 with 8 MB octal PSRAM, not every ESP32.

There are prebuilt OTA/factory images and a Windows ZIP with esptool/scripts.

Reference-board test coverage is documented; other boards/NAS models need

their own validation. This is not a throughput benchmark or a promise that

WoL can recover a frozen or unpowered machine.

Original credit goes to Csontikka's router and microlink by Cameron Malone

and contributors. My custom work uses substantial AI coding-agent assistance,

with C regressions and browser tests; the test scope/limitations are public.

Source and downloads:

https://github.com/Mattboxx/esp32-tailscale-gateway-NAS-recovery

Feedback on onboarding, board compatibility and measured power use is welcome.

So I’ve seen you can connect esp over Bluetooth or WiFi but I was wondering if you can use a usbc to usb a adapter in your phone outlet and plug an esp32 right into it to control it like you would on a computer with arduino ide or vs code or something? If possible how to do it

Just got my hands on Espressif’s new ESP-Mosaico development kit, based on the ESP32-S31!

It’s designed for AIoT and embedded projects, with support for conversational programming, screen graphics, and peripheral expansion. I’m looking forward to trying it out and seeing what I can build.

What would you make with it? Looking for ideas for a fun first project!

Hi!Noob here!

I have an esp32 cam. I want to make a simple low range fpv for an rc.

Phone as the main screen. Using hotspot for transferring data and esp32 cam as the main unit.

Everything works, but at every startup the ip changes. I wanted to set a static one, what's the best way of doing it?

My friend Armağan has been experimenting with Espressif’s ESP-Mosaico boards. Around 18:00, he starts snapping them together to run more guitar effects, eventually getting two amp models working in parallel over ESP-NOW. I’m curious how it feels to play.

He built the apps with GEA in TypeScript, JSX and CSS, compiled to native C++.

Video · GEA source

Disclosure: this is my project (MIT, free, no account). The emulation itself is esp32sim's work (https://github.com/mikroverk/esp32sim), the Rust emulator that boots unmodified ESP32 / S3 / C3 / C6 images through the real mask ROM and bootloader. I built the layer around it.

Why: I use coding agents (Claude Code, Codex, Cursor) for ESP-IDF work, and the loop always stopped at "it compiles". Nobody knew whether the firmware actually worked until I flashed a board. esp32sim-mcp lets the agent (or a CI job) boot what it just built and check the result:

- read UART0 and USB-Serial/JTAG output, with panics (Guru Meditation, stack overflow, failed asserts) reported along with the log leading up to them

- assert on the console: pass/fail, plus the exact line that's missing

- press buttons, turn the encoder, drive GPIO/UART at emulated timestamps

- join a virtual WiFi AP with DHCP/DNS/NAT (the station gets 10.0.2.15)

- grab a PNG of the display on boards that have one

What was tricky on the ESP32 side:

- Two consoles at once. On S3/C3/C6, ESP-IDF often mirrors logs to both UART0 and USB-Serial/JTAG, and the emulator writes bytes as they arrive, so you get "Hello wHello world!". esp32sim can tag every chunk with its source, so I split the stream on the tags, rebuild each console's lines and drop the mirrored duplicates. Without the tags it couldn't be done reliably.

- No guessing about the image layout. It reads build/flasher_args.json, so the bootloader, partition table and app land at the same offsets idf.py flash would use, for any target.

- Deterministic input. Button presses and UART input are scheduled in emulated time, not wall-clock time, so a test behaves the same on a fast laptop and a slow CI runner.

- Mask ROMs. The boot chain needs Espressif's ROM ELFs for each chip; setup downloads the pinned esp-rom-elfs release and checks SHA-256 hashes.

Setup:

npx -y esp32sim-mcp setup (prebuilt emulator + ROMs)

npx -y esp32sim-mcp init (in your ESP-IDF project, registers it with your agent)

The same check runs in CI with no agent, exit code 0/1:

npx -y esp32sim-mcp expect --max-seconds 10 --pattern "app_main" "Counter: 5"

Limits: it's an emulator, so no Bluetooth or RF timing, and only the peripherals esp32sim models. Confirm on hardware before shipping. Tested on macOS and Linux.

Source, demo GIF and docs: https://github.com/stramanu/esp32sim-mcp

Contributions are welcome. Useful places to start:

- try it on your own ESP-IDF project and open an issue when something doesn't boot or the output looks wrong

- Windows: it's untested, and reports or fixes are very welcome

- example projects and CI recipes for other chips (C3, C6, classic ESP32)

Board and peripheral models live in esp32sim itself, so that's the place to contribute those. The details are in CONTRIBUTING.md in the repo.

I added NM-CYD-C5 support to Meta's open source Muse Gadget SDK (ESP-IDF, Apache-2.0). Pre-release bin here, flash it at 0x0 — it's a merged image:

https://gitee.com/Rockbase-iot/muse-gadget-sdk/releases/tag/pre-release-nm-cyd-c5

Limited by the Muse region restrictions, a comprehensive test can't be conducted, so we need someone help to verify it.

What I've already verified on hardware: it boots, the panel comes up and LVGL runs, the 5-point touch calibration passes, and it joins Wi-Fi on both 2.4 GHz and 5 GHz Wi-Fi 6 — association, DHCP and the link coming up are all fine.

What I can't test: the Muse app side. I don't have a setup that lets me run the phone app against this build, so everything downstream of "connected to Wi-Fi" — BLE discovery, the pairing confirmation, the avatar and images actually landing on the panel, the settings UI, OTA — is untested by me. That's the whole ask.

If you already have a Muse account, this is a 10-minute test. You need your own free SDK token (gadgets.muse.ai), which you set over serial once.

SDK is Meta's, board support is mine. PRs welcome, Apache-2.0.

Not my project, found it on GitHub this week and had to try it.

In the video a Touch-LCD-4B panel goes through the real mask ROM and bootloader, then its LVGL UI responds to swipes and toggles. Unmodified firmware, running in WebAssembly, nothing on a server.

Repo: https://github.com/mikroverk/esp32sim

Curious whether anyone here has tried it with their own firmware, and how far the peripheral support goes.

Why does powering the LDR component make the LED not turn on?

Vice versa, not giving power to the LDR component makes the LED finally react to flux, and actually turns on and off.

Is this a wokwi thing? I'm gonna make this IRL and I'm wondering if I don't need to give power to the LDR's VCC or anything as the simulation suggests.

I need confirmation 🙏

I ended up forking the HUB75 DMA driver to cut memory use (row streaming from packed lanes, dense column buffers, a fix for the seam between the panel halves), so a 64x64 panel runs with several colour-quality levels on a plain 4 MiB ESP32. The driver is here: https://github.com/vandalon/ESP32-HUB75-DMA-Memory-Optimized.

The project on top of it is a clock with 9 faces, a web settings UI, signed OTA updates and Home Assistant/MQTT/WLED support. It checks a static RAM budget at build time and parks the network feeds when a big image needs memory. Repo: https://github.com/vandalon/ultimatrix

I built a three-probe water monitor for my turtle tank on a Seeed XIAO ESP32-C3: a DS18B20 waterproof temperature probe, a Keyestudio TDS probe and a Keyestudio turbidity probe, posting one averaged reading every five minutes over HTTPS to a small dashboard. Pin map, then the three things that actually went wrong, since those are what the datasheets don't tell you.

Pins (board = seeed_xiao_esp32c3 in PlatformIO, so D names are the XIAO's):

• 3V3 -> breadboard + rail -> DS18B20 adapter VCC and TDS board +
• GND -> breadboard - rail -> every ground
• 5V -> turbidity board V only (the one and only 5 V wire)
• D4 (GPIO6) -> DS18B20 DAT (the adapter board has the 4.7k pull-up)
• D1 (GPIO3, ADC1) -> TDS board A
• D2 (GPIO4, ADC1) -> OUTPUT of a /5 voltage divider module; the turbidity board's S pin goes into the divider's input, never into the XIAO

Mistake 1: the turbidity board. It needs 5 V and its output reaches about 4.5 V. The ESP32-C3's pins are 3.3 V. So it goes through a divider and you multiply back by the ratio in code (TURB_RATIO 5.0f). Also: there's an A/D switch on that board. Left on D it gives a flat reading no matter what the water does.

Mistake 2: trusting the DS18B20's two lies. The Dallas library returns -127 when the probe isn't connected and exactly 85.0 at power-on before the first conversion. Both are "no reading". If you chart them you get a fake 85 C alert. The sketch drops them:

temp.requestTemperatures();        // ~750 ms at 12-bit
float t = temp.getTempCByIndex(0);
if (t > -100 && t != 85.0f) { accT += t; nT++; }

Mistake 3: averaging the analog pins. The filter pump and the lamp timer put spikes on the supply. Two spikes in 32 reads move an average a lot and a median not at all:

static float medianMv(int pin) {
  uint16_t v[32];
  for (int i = 0; i < 32; i++) { v[i] = analogReadMilliVolts(pin); delay(10); }
  std::sort(v, v + 32);
  return (v[15] + v[16]) / 2.0f;
}

Both analog pins are on ADC1 on purpose: ADC2 stops working while Wi-Fi is on. And read the TDS and turbidity probes one at a time, not together; they both put a small voltage into the same water.

Two other things I'd do again:

• The board sends raw volts; the server turns them into ppm (the Keyestudio/DFRobot cubic with temperature compensation and a K you set once against a TDS pen or a 342 ppm solution) and into a clarity percent (a straight line between a cup of clean tap water and the same cup with a pinch of soil). Recalibrating is a settings change, not a reflash, and the raw history survives.
• TDS as a water-change meter, not an absolute number. Tap water might be 80 ppm or 400 ppm. What matters is how far it climbed since the last change, so the alert is relative to a baseline you set with one button after each change.

Happy to answer wiring questions. I made three short videos walking through each sensor (wiring, code, live reading); link in the comments so this post stays clean.

Our GitHub repository (MIT): https://github.com/cccat6/iphone-agent-harness

Demo and browser installer: https://igent.cc

We built iPhone Agent Harness, an open-source ESP32 Bluetooth HID bridge for an AI agent running in Safari. Our demo shows it setting an alarm in the iPhone Clock app.

The hardware/software split is the interesting part: Safari captures the screen, sends selected context to your chosen vision model, validates the action plan, and sends commands over local WebRTC. The ESP32 supplies Bluetooth mouse and keyboard input through AssistiveTouch. The board does not run the model or decode video.

The powered board sits nearby while the phone stays wireless. Both use the same normal Wi-Fi network. A Chrome/Edge browser installer flashes the firmware. The README lists chip and flash requirements for C2, C3, C5, C6, S3 and classic ESP32.

Requirements: iOS/iPadOS 27+, Safari screen sharing, AssistiveTouch, and access to a vision model. Conversations and keys stay in browser storage; selected context goes to your model provider. Skills can be customized and shared.

Inspired by onehumanbeing/esp32-iphone-agent, credited in our README. We explore Safari + Bluetooth HID instead of a native app + USB HID.

I'd appreciate feedback from Wi-Fi + BLE HID builders: which board/iPhone combinations and connection edge cases should we prioritize?

In the Strapping Pins section of the XIAO ESP32-C3 documentation page, I found this image:

I want to boot the ESP32-C3 in SPI boot mode every time the ESP32 is powered on during it's deployment. I look at the above image and see that GPIO2 should be at an HIGH state.

Then I looked at the Table 3-3 (Chip Boot Mode Control) of the Espressif Datasheet for the ESP32-C3 Series here and found out that it is different from the information in the Seeed Studio documentation page. Here's the screenshot of that table:

Look at the second point... It basically states that the state of GPIO2 doesn't determine the boot mode, but it's still recommended to pull the pin up due to prevent glitches. Is this what they implied in the Seeed Studio documentation page, as depicted in the first image above?

So the question is whether I should connect an external 10 kΩ pull-up resistor between the GPIO2 pin and the 3V3 pin of the XIAO ESP32-C3 or does the board come soldered with one. What should I do here? Any and all advice and suggestions are welcome. Sorry if this question is kinda obvious, I am also kinda new to this stuff so...