Via the powers of CircuitPython, and Adafruit WipperSnapper, I have gifted my CNC a new set of features...

V1 avoids altering the CNC firmware or machine at all, because that would be less accessible (or reversible)!

It supports the existing software control system (wifi) by adding an MCP server with safety baked-in (motion rules + human approvals) along with skills for CNC probing, tool setting, roughing and visual feedback. Utilises a directly attached or MQTT based feedback system for the tool-setter and probe.

What hardware you ask?

There's a good old (>3yrs) project called ESP-USB-Bridge. It turns any ESP32-S2 or ESP32-S3 into a fully functional debug probe tool, with JTAG or SWD, UART pass through, and UF2 flashing too.

I'd been meaning to give it a try for ages, and this week I finally had the excuse to debug an uncooperative chip!

 Mainly my reasoning for wanting these is that each PicoProbe costs ~$12, and JLink even more, and I ideally want one debug probe per board in my Hardware Testing farm (bunch of boards in boxes, controlled via SBCs with USB PPPS hubs).

Yes, you can use a Pico (~$6) as a pico probe, but that doesn't cover non SWD targets. Ideally I want to spend <$3 per target to add debugging, and cheap ESP32-S3 nano boards ($2 clones with bad aerial) seem ideal for that.

The firmware I work on (Adafruit WipperSnapper) supports over 40boards, and 100 components/peripherals, so there's quite the combination to debug / support (too expensive for official probes). I also aspire to support as many CircuitPython boards as possible, and at 500 boards that's a tall order!

Suggested Hardware

You'll probably want an SWD/JTAG cable, and maybe an SWD/JTAG breakout board:

For CircuitPython Day 2026 I wanted to create an E-ink CO2 monitoring project for a friend.

They wanted to be able to see how long things were in bad ranges after the fact, mostly not looking at the data until a problem occurred and was rectified, like a post-mortem of their setup. There's no internet over wifi (just phone data), and they prefer / are used to using Bluetooth on the phone with another data logger.

To make it more exciting for me I wanted to play with a few technologies, namely an *ESP-Now data collector, Offline SSL WiFi + Web-BLE control/analysis page, and Web-AI thrown in for local offline model use in the browser!*

_{*Web-AI and the Prompt API are limited to Chrome currently, and Web-MCP is a time restricted origin-trial for now.}

How does it work and what does it do?

So this project is an ESP-Now based communication device (less bandwidth and no real need for WiFi AP dependency although can host one if needed), with it's own offline sensor and SD card, and acts as a data collector for remote sensor nodes.

 The devices are set up with a wifi AP to begin with (and a captive portal) allowing setting of the device name and sensor polling frequency. If the esp-now based host controller cannot be accessed the the nodes create the setup wifi AP again (@tyeth remember to check what happens if host goes offline and returns - they happily resume but more testing worth doing). 

 The main host controller is expected to be powered (ideally with battery backup) and displays it's data along with the remote nodes, compared against high_warn / high_bad / low_warn and low_bad thresholds for each metric (co2, RH, temp, particles, battery).

So how do we view the data on a bigger screen, or historical data?

There's a GitHub Pages site mirrored on the host controllers Wifi AP captive portal. It supports https and http locally, so that web-AI is supported* [https is mandated by Browsers for certain technologies like Web-BLE or phone sensor access].

This is a demo link that prepopulates data files into the page (no syncing from device needed):
https://tyeth.github.io/deepsleep_espnow_wifi_and_ble_env_collector/webapp/?demo=1

 The host has the page available served over the captive wifi portal just in case no internet is around, and the needed plotly.js is stored in flash or on the SD card for easy serving.
   Lastly pyodide is available with access to the data and sqlite3 and numpy, but being 10mb it's an SD or online only option.

The final treat on the page is the use of the experimental Web-AI Prompt API in Google Chrome, allowing the downloading of a model (nano-flash or Gemma4*) and then interrogating your data via the locally run model in the browser.

Offline web page resources (for graphs and AI analysis)

What's clever is that by visiting the webpage from github first, you can get the https support allowing Web-AI, download the Model if needed along with all the JS libraries super quickly.

Then you switch to the Sensors WiFi network (no internet) and the page remains working. It's also possible to just visit the webpage initially, but then the JS files will be slowly served from the ESP32.

The page still allows accessing the esp32 host controller on a known fixed address (192.168.4.1) via an openly free SSL certificate from 192dot168dot4dot1.gundryconsultancy.com which is updated by LetsEncrypyt every 60days. Of course you can also use BLE instead to transfer the data from host.

Poor forgetful little computer... Keeping Time and new SSL certs updated

Because the Host controller device boots with no time, and maybe an out of date SSL certificate, the phone or PC provide updated time (and optionally SSL certs) simply by connecting to the website and then using web-ble or the wifi REST API to connect to the host controller. At that point all the stored data with <2020 timestamps get synced with the relative offset to current time giving correct dates.
The days of data are also synced to the browser in the same way, over BLE or WiFi API, saved to localstorage.

It would be relatively cheap and easy to include a Real-Time Clock (RTC) as they have battery backups and would retain time after power loss. As it is, the first visit to the portal page syncs time from the browser 🧠

Room for improvement

Alas the phone (android) doesn't support Web-AI yet* (ML-Kit promises in future), and other browsers have so far refused the temptation of the Prompt API (with good reasons), so if no internet exists then a Laptop is required to use the Web-AI model (and have downloaded a model previously or be briefly online).

The Nano-flash model was at times really quick and effective, although pretty inconsistent and at times ran for minutes before a response. Gemma4 model will likely be much better (will update after testing).

Of course as models get better there will eventually be something worth running locally on the esp32.

For kicks pretty early on I wanted to think about this structured output schema and then move onto Tool calls from the agents responses, and it worked surprisingly well (not to spec / hacky).
https://github.com/tyeth/deepsleep_espnow_wifi_and_ble_env_collector/compare/main...ai-tool-loop

Longer term, it would be nice if the agent had access to more tooling (Web-MCP), like the whole of pyodide, and the ability to reuse the graphs to highlight a related region of interest. Sadly it probably wants a sidebar or floating widget so the "Ask" and response summary is always available...

Lastly CircuitPython itself comes with some occasional gotchas, community contributions (esp-now), bleeding edge features (like BLE improvements), and heavy memory usage woes if using graphics and radio, especially when you're a glutton for punishment like myself and attempt an SSL server + BLE + espnow + display!
🪞🔫🦶🤓

I ended up compiling circuitpython with extra flags for memory radio buffer size, adding SSL session tickets for cheaper connection resuming, turning off BLE workflow in settings.toml, and using the new supervisor.unsafe_disable_usb_storage to allow removing MSC write permission from the PC and restoring to the MCU (to save settings changes etc).

 Getting started is easy! You hold the boot button down on the back of the board while tapping the reset button next to it, then afterwards let go. A new USB Drive will then show up on your computer, usually called RP2 or RP2350.

 Download the UF2 installation file from the CircuitPython website for the Pimoroni® Explorer, or from the pull-request on GitHub (requires a free account to access Actions artifacts), then copy the file with the suffix .uf2 over to the USB Drive, using Copy then Paste, or dragging a dropping the file onto the USB drive.

 When it finishes copying over then the device reboots, and CircuitPython should load up after a few seconds (it sets up the filesystem for you), and then it presents a couple of new USB devices to your computer:

The REPL (Read Evaluate Print Loop - an interactive circuitpython terminal) becomes available on a USB Serial Port (COM ports on Windows), and the user filesystem (where the code lives) as a USB Mass Storage device (USB Drive) called CIRCUITPY. 

 The main drive you'll use is the CIRCUITPY drive, which is where the user code (/code.py), extra software libraries (in /lib or the root folder /), and any assets like images or mp3 files reside.

 There can be an extra drive in CircuitPython version 10 for game SAVES (optional), and sometimes also for SD which is when an SD card is attached to your circuitpython board. 

Going further and understanding CircuitPython (and code):

Follow the Getting Started link on the Circuitpython.org website!         I've linked to it here:

more of a personal note to remember some commands that were useful. I figure this is more likely to survive or be found compared to a gist/repo/onenote/whatever.

Currently contains powershell to set environment variables properly, list content of partition table on any device from the esp32 families, and an oEmbed test of a LottieFiles animation (success). See TOC!

GitHub Expand All Diffs

javascript:(function(){document.querySelectorAll('button').forEach(function(button){if(button.textContent.includes('Load Diff')){button.click(); button.click();}});})();

 

Picture in Picture for all videos currently on page, removing the disabled attribute if present:

(Add this as a bookmark then save with a name like 'pip - picture in picture' so it comes up easily in the URL bar)

javascript:document.querySelectorAll("video").forEach(x=>{if(x.networkState!=2)return;x.attributes.getNamedItem("disablepictureinpicture")&&x.attributes.removeNamedItem("disablepictureinpicture");x.focus();x.requestPictureInPicture();})

Powershell for getting the partition table from any esp32/etc based device

*assuming the partition table is at 0x8000, but it can also be at 0x9000 on newer boards.

if you get an error and a board is in bootloader mode attached then change offset to 0x9000 and repeat. You need to have already run .\export from the esp-idf folder (for IDF_PATH).

Should only read 0xc00 bytes instead of 0x1000 but wanted to be sure and read two full blocks, doesn't hurt. Change 0x1000 to 0xc00 if you have sense / or want to google what the frick this does

We do have one product that supports LiFePO4 lithium batteries, which are stable at low temperatures and much much safer generally, but 3.3-3.2v over the usable range instead of 4.2-3.7v for normal lithium ion batteries, so once LiFePO4 is near flat it's too low to power the mcu.  The product we sell always boosts the voltage to 4.5volts so it's near the 5v ideal power level at all times.

 The device is designed for usb/solar/dc-barrel-jack power to charge the battery (and also power the downstream device/board), so uses that incoming DC power when available or the battery (boosted) if not, always outputting 4.5v for the downstream device (the load).

 

Make sure to follow the learn guide, cutting one jumper and soldering another to set LiFePO4 mode.

Product Page: https://www.adafruit.com/product/6091

Learn Guide: https://learn.adafruit.com/adafruit-bq25185-usb-dc-solar-lithium-ion-polymer-charger/pinouts

You'd want some wire or connectors potentially to make life easier (from charger load pins to MCU board either wired as battery in / external power or as usb connector), and to have a receiver for the battery connector.

It's maybe a bit too complex for a beginner's first go, but it's suitable as a level progression project with WipperSnapper (no-code IOT firmware - written in Arduino with open-source contributors). 

Plus you need to "obtain" the LiFePO4 batteries and attach connectors if not already there.

Overview

The TPL5110 (with driven output line) or the TPL5111 (with toggling enable line) allow some really simple low-power projects. Use the zero to sever and supply power, or the one to control enable pins (for LDO/MCU).

Just adjust the potentiometer to tweak the turn-on time, and then with the TPL5111 you send a low high transition to the Done pin to go to sleep. The Enable pin goes low and MCU sleeps until the next cycle.

All of that means you can easily create a no-code low-power project, just by hooking up the TPL5111 to a WipperSnapper compatible board, and combine that with an E-ink display for the ultimate low power setup.

The board wakes up, connects to WiFi and Adafruit IO, get's the latest messages (E-Ink Display) and sends some sensor data. Two small Actions on Adafruit IO switch the Done pin to a high level, and then ten seconds later back to low. A third action updates the screen message with time + weather every 10mins.

Add a third action to update the display or whatever is appropriate (like acting on some sensor data).

Use \n to force a line break when working with Displays on WipperSnapper

WipperSnapper is a firmware (Arduino sketch) that connects boards with Components + Sensors in a no-code way. It's meant to be easy for beginners to start making things online quickly and simply, but sometimes we forget how much knowledge is expected.

It can be a tall order to know how to find the pin names for each board, but doubly so when you want to connect a seemingly easily sandwiched FeatherWing into the mix.

Today I followed this journey to test a newly supported E-ink FeatherWing display with one of our older boards, the Feather ESP32 v2 (Huzzah32), to replicate the MagTag setup which we know works well.

As I looked for the documentation link in the New Components dialog, I realised this was a step too far for many people to take confidently alone and I should probably document the journey.

Breaking it down

Testing the display support recently added to Adafruit IO's no-code Arduino firmware, WipperSnapper, I've come unstuck with my automations a few times due to living over the other side of the pond (🫖) from Adafruit HQ...

"Why?", you ask? Time-zones!

In case you were unaware, Adafruit HQ runs on New York time, also known as EST (Eastern Standard Time), which is currently 4hours behind UTC (daylight savings can alter this 4hr offset).

Now to make life easier, the schedule block uses a timezone location set in the User account page, meaning my schedules run as expected, yay! The tricky bit comes when you want to start comparing time or timestamp values.

Most things live in server time, which is set to New York, but many other bits and bobs are presented in UTC.
For our purposes we want things in our local time, advancing time back to the future, with a no-code clock!

Setup DST Change-over Actions

1. Create a new feed to store the timezone offset inside if you haven't already got one. Do it on the /feeds page, and then on the new feed page add data manually for the current time-zone offset.
   
   
2. Create a new Action on the /Actions page, called "Start of DST", with a description of when it should run.
   
   
3. Add a schedule trigger block to the diagram. Use the cogs to alter the schedule block for your DST changeover. In my case we don't support "last X in Month" yet so I'm using "Every Sunday in March", followed by a check of a liquid template function if it's the last sunday in the month.
   
   
4. If needed for complex schedules then add a Set Variable block (variable named timezone_offset_hours) with the value set to the timezone offset feed (Get feed block). Otherwise jump to step 7.
   
   
5. Add a set variable block for a new variable called is_last_sunday, then add a template block as the value.
   For the template body, use the following (which adds 7days then compares the month to current)
   Template:
   {%- assign now_s = "now" | date: "%Y-%m-%dT%H:%M:%S" | date: "%s" %}
{%- assign now_z_s = "now" | date: "%Y-%m-%dT%H:%M:%SZ%z" | date: "%s" -%}
{%- assign server_utc_diff = now_z_s | minus: now_s -%}
{%- assign thing = 3600 | times: vars["timezone_offset_hours"] | minus: server_utc_diff  -%}
{%- assign bst_time_s = now_s | plus: thing -%}
{%- assign current_month = bst_time_s | date: "%m" -%}
{%- assign next_week_month = bst_time_s | plus: 604800 | date: "%m" -%}
{%- if current_month != next_week_month -%}1{%- else -%}0{%- endif -%}
   
   
6. Add a logic IF condition block, then place a number comparison block from the maths category (=)
   Inside the number comparison block, add a Get Variable block for is_last_sunday, and compare to 1.
    
7. Add a Set Feed block to the Actions: section of the diagram, and select the timezone offset feed in the dropdown. For the value enter the local UTC offset in hours during the next daylight savings time period.
   
   
8. Save and run the action, enabling if asked.
   
   
9. Create a second action for the end of Daylight savings time, with the appropriate local UTC offset in hours for that next period. Save it and run it, enabling if asked.

Your actions should look similar to this:

https://github.com/tyeth/omron-devhub_d6t-arduino

Brent nerd sniped me this week with his talk of a non-contact thermal sensor for Leaf VPD measurement on WipperSnapper, as I've been wanting VPD measurements of my Banana plant for a very long time.

Limor then came in with some suitable new sensor alternatives (the TMP007 being obsolete), and my mind wandered through the digikey site briefly, stumbling upon the D6T thermal sensor series from Omron.

Conveniently it uses a very similar cable to my favourite sensors, the JST-GH locking cable, but a 4pin variant. No Problem! Cut the 6pin version right through pin 5 (then removing the 5th wire and contact), and a final extra trim of the locking tab, and hey presto an instant fit!

Easy pinout, as it's I2C, but wants 5volt power/logic. The handy StemmaQT 3v to 5v logic level converter (PID 5649) quickly gets you to stemma and voltage compatibility. Then for software Omron have a library on Github.

Sadly it looks unmaintained, or at least incompatible with ESP32. So a quick fix or two (merge some old community PRs -❤️open-source), rebase it, swap the Wire (I2C) to be a passed argument, and now it's hopefully suitable for all!

This is the connector / pinout details:

Huge you say? Not by many peoples standards maybe, but I'm being offered 2.7inches regularly, and have a 2.4" in my hot little hands already. Not content with just that, I also have a couple of 0.49" too. And that's before we get to the official Adafruit ones! Some lovely featherwings and StemmaQT displays...

What is this, the latest way to stream media through your microscope into your eye balls? No, not that, unless you're a fan of slow text based games... Welcome to the world of ASCII displays!

To test the theory, I used an LLM to help automate some of the tedium of testing all 200-odd characters (0x00 to 0xFF), by creating a postman collection to test them in groups of four. Each test fired a new value to the feed with four new space and newline separated characters, with a 2second delay between tests, which would effectively cycle through them all.

Wanting to investigate a slightly Heath-Robinson idea to improve my CNC work setup process, I grabbed a digital dial guage (0-25.4mm) for probing things... The device had a cable option which I initially skipped, but the connector was a pain and rather than destroy my device to solder in a socket I bought the cable (for £1.99+tax).

It's supposedly 1.37volt logic, but the cable converts to RS232, and they included a USB-RS232 adapter. The device and cable came with 2x 8cm Compact-Discs (CDs) for software drivers and official software. I do actually still have a DVD/CD combo drive in one laptop, but forget about that. The instructions showed it in Chinese and windows only, and I plan to use a Raspberry Pi, so I went straight to an LLM to make a prototype web-serial demo.

Claude started the project, then I moved to claude-code in the hope claude would read the serial output too, but I/it got distracted with it nearly working for ages. In the end claude-code took it down an alley of insanity, and I switched to vscode in Agent mode to start afresh at the same time. VsCode sorted it right out first time. Then a quick correction for the initial boot messages received, and finally glam it up a bit along with adding scaling to the dial. Of course to use it with the Pi it would need converting to python/node, so I did that and tested via WSL.

Source Code / Readme etc: 

https://github.com/tyeth/digital-dial-gauge-web-serial

Interactive Webpage:

https://tyeth.github.io/digital-dial-gauge-web-serial/

 

Live embedded iframe/oEmbed version:

I'm often wanting to list what's on a device in terms of partition table. There's a handy utility included with the ESP-IDF, but it's python only and it only accepts files so you have to first call esptool to save your partition table data. I've had to do it so often that I've saved the two commands in another playground note, but not any longer!

The other thing is I swear that there used to be some online place to download your devices flash for backup using web serial, but try as I might  I cant find such a place, and my google-fu is usually on point - ignoring my switch to duckduckgo...I digress, introducing my latest possibly needless project, esptool-js "partition edition":

How to use it?

 

Well, the image above shows after I've clicked the Read Partition Table button. The default partition offset of 0x8000 should be fine for most boards, otherwise try 0x9000, although custom partition table offsets are supported. You won't even see those options until you've clicked Connect and selected your boards serial port.

Once your partition table has loaded it shows the expected information, the bit most people are usually interested in is the first app partition, or ota_0 in this case, and the user file system (user_fs), which is a FAT partition in this screenshot. 

The final column in the table has the download button for each partition, clicking it will start reading from the flash memory of the connected device, and once finished will ask the browser to download it. It will be named according to the chip name, partition type, starting offset, and size in bytes, but all the numbers are in hex not decimal.

Blockly has been slowly worming it's way into Adafruit IO, with a first edition replicating the old Action forms.
Now the latest release brings the wealth of features we've been dreaming of, allowing great complexity!

Will you be the first to bring down the house of cards/servers? Let us know in the forums if you do (or run into other issues)! Let's start off with something simple, how to subtract one from a feed value (as a countdown)...

We'll explore a quick yet complex multi-action example, changing LED colour based on air quality, and additionally a Utility Light mode using the onboard button to request 30seconds of Bright White Light (useful in a kitchen).

Setup a Wippersnapper device

Adafruit IO has a devices page, which shows the special "Wippersnapper" devices, these run the arduino firmware that allows wifi connected boards to easily connect and configure components (inputs/outputs/sensors) with no code. Each component then has associated feeds for interacting with, so using the on board button becomes child's play.

Install wippersnapper, you're best off finding the learn guide for your board and then locate the Wippersnapper pages. Alternatively there is a quick start guide, or just do the usual hacky thing and have a go with no prior knowledge...

Visit this link (https://io.adafruit.com/devices/new) when signed in to be taken to the New Device setup page, then select your board and follow the onscreen instructions.
(You need an IO page open when the board first connects to accept the registration request).