FYI: a developer has begun porting ESPHome to nRF52 platform as custom platforms (which in turn will allow support for nRF52840 as a core platform)

FYI; tomaszduda23, an independent developer is working on developing an initial port of ESPHome for nRF5 platform on Zephyr RTOS for nRF52 SoC series based nRF52840 SoC from Nordic Semiconductor (and in theory it should also lay the ground work for the newer nRF54 SoC series):

Summery for those unfamiliar with Nordic Semiconductor and their lines of microcontroller chips; Nordic Semi is a 40+ year-old company that has been making their ARM-based nRF5 family of ultra-low-power wireless MCU SoCs (nRF51, nRF52, and nRF53 series) since 2012 and those have become very popular among developers/manufacturers that make battery-powered devices, especially those requiring ultra low-power wireless communication on the 2.4 GHz ISM bands, like Bluetooth, Thread, and Zigbee. Nordic Semi also makes Wi-Fi SoCs but then we are no longer talking about ultra low-power devices.

Note that I have nothing to do with this project myself, I just stumbled in this project and wanted to spread this news because I got exited by the potential of this could not only bring more developers and thinkers that feel more familiar with the Nordic Semiconductor nRF5 platform to start using and contributing to ESPHome, so it should hopefully help the community grow even faster, but it could possibly make it easier to make running ultra low-power battery-operated devices running ESPHome, as well as add another type of radio MCU hardware for ESPHome that can support Thread/OpenThread and Zigbee.

PS: Off-topic That development effort might be indirectly interesting to another sub-project to follow for those who (like myself) have been asking for native Thread/OpenThread and Zigbee wireless support in ESPHome (and perhaps posted in the feature request tracker) since Nordic Semiconductor nRF52840 do not support WiFi but does support Thread and Zigbee protocols, (similar to the ESP32-H2), with nRF52840 and the newer nRF5340 being ideal for battery-powered devices:

Looks like tomaszduda23’s work on basic support for nRF52840 for ESPHome progressing very nicely and just yesterday he marked his pull request as ready for review and testing by devs/testers:

Btwy, also wanted to mention missed that @NateLust previous begun porting ESPHome to nRF52840:

Looks like @NateLust has not updated his forked esphome repository the last year and seems like the “zephyr-dev” branch there is latest:

There do not seem to be any new posts from @NateLust on this since he posted this zephyrESPHomeGuide in little over 1-year ago:

PS: Noted that @NateLust did also make more progress on Thread/OpenThread for ESPHome than any other have I seen so far(?).

This would be really amazing as it might allow for projects like b-parasite to using esphome instead of the custom firmware that is very difficult for new users to build and install!

I might even try to revive my boards again!

FYI, looks like this is making progress now with ESPHome added support for custom platforms:

That in turn will allow a nrf52 platform core to be used as an external component:

After that still need support for specific SoC models such as:

PS: FYI, Nordic Semi has also released nRF54L Series including a powerful nRF54L15 SoC with a lot more resources:

FYI, the initial pull requests for nrf52 core (based on zephyr) from tomaszduda23 has now been merged into ESPHome dev branch:

plus many more new related nrf52 patches are in development now that the initial support has been added and will soon be in the mainline:

PS: Also interesting and relevant is that the initial pull request for Zigbee support on nrf52 for ESPHome is now also getting close to being merged soon:

PPS: Also noted that luar123 has begun working on an external low-level Zigbee component support for ESPHome on Espressif ESP32 as well:

ESPHome now officially supports the Nordic nRF52 platform! Check it out:

Will these changes natively support the BBC Micro:Bit, which I believe has a NRF51822 chip?

Asking as I have a few lying around, and this would probably revive that ecosystem significantly, breathing new life to sales and utilisation, and allow learners to adopt HomeAssistant into their home style once the novelty of flashing a LED has worn off.

It would possibly appeal to those that do not want dependency on Chinese technology such as the ESP ecosystem, but still want a flexible platform to deploy their projects.

A win-win situation.

Update: pull requests that added initial Zigbee end device support for the nRF52 platform has now been merged into ESPHome:

Several more additional ull requests that will extend that are currently open:

That means that the next upcoming ESPHome release (scheduled for release as ESPHome 2026.1.0 in a couple of weeks from now or if that is delayed then in the 2026.2.0 release) will have have initial Zigbee end device support for the nRF52 platform.

Note that a matching pull request that will add initial Zigbee end device support for the ESP32 platform has not yet merged into ESPHome:

Again, also be ware that both tomaszduda23 and luar123 also still have their previous work and pulls requests open that offer much more extensive and comprehensive Zigbee device types (which also have much more information and better overview of the project scopes), but I guess that if the two pull requests linked above are accepted and merged into ESPHome mainline then each of their comprehensive work (linked below) will be partially rewritten to align with the new agreed upon standard and formatting. See these for more background information:

PS: FYI, tomaszduda23 and luar123 are at least now more aligned and have agreed on how initial Zigbee config with platform/component abstraction should be handled/formatted at a high-level for ESPHome config to be platform-independent, and as such they both each submitted matching pull requests for initial bare-minimum Zigbee support on nRF52 and ESP32 respectively.

FYI, ESPHome 2026.1.0 has now been released with a Zigbee End Device component based on nRF SDK supporting nRF52 platform:

The zigbee component allows exposing supported ESPHome components over a Zigbee network to Home Assistant via Zigbee2MQTT or ZHA. Due to the limitations of the Zigbee protocol, only basic properties are exposed. Additional properties must be configured manually in Home Assistant. Each ESPHome entity consumes one Zigbee endpoint. Because of a limitation in Zigbee2MQTT, at least two endpoints are required. The maximum number of supported endpoints is eight.

So far in ESPHome 2026.1 they added initial support however it already features supports for sensor, binary sensor, and switch functions:

Quote below from the release notes:

Zigbee Support for nRF52

ESPHome now supports Zigbee on nRF52 platforms, bringing a new connectivity option alongside WiFi, Bluetooth, and Thread:

  • Binary sensor support - Expose GPIO states via Zigbee (#11535)
  • Sensor support - Expose ESPHome sensors via Zigbee’s Analog Input cluster with automatic unit mapping ([#12187](https://github.com/esphome/esphome/pull/12187))
  • Switch support - Control ESPHome switches via Zigbee as binary output (#13083)
    wipe_on_boot: once - Wipe network settings only on first boot, preserving connections after OTA updates
  • Framework version support - Configure nRF-SDK version with experimental support for SDK 2.9.2 and 3.2.0 (#12489)

Future

Zigbee support in ESPHome is currently available only on nRF52 platforms but there is an open PR to also add ESP32 support as well:

Also be ware that both tomaszduda23 and luar123 also still have their previous work and and side-development woth pulls requests open as drafts that offer much more extensive and comprehensive Zigbee device types (which also have much more information and better overview of the project scopes), but I guess that if the two pull requests linked above are accepted and merged into ESPHome mainline then each of their comprehensive work (linked below) will be partially rewritten to align with the new agreed upon standard and formatting. See these for more background information:

Thanks Hedda and nice that this is moving on.
The problem with nrf52 is that there’s no documentation in practice. I don’t know what can I do with it and how. Normal gpio i/o, analog input and I2C are the only components that have been even mentioned.

Will there be the ability to tap into the BBC Micro:bit ecosystem using ESPHome? This would bring you a whole lot more opporrunities similar to when the ESP series were added to the Arduino ecosystem.

I just got a set of these NRF52840 dev boards and I'm trying to program the first one with ESPHome and running into problems.

I have found that I can put the device into bootloader mode by holding the RST pin low during power-on (plug in the USB). When this occurs I can see the red light flashing 2-3 times per second. When I just power the device up with USB normally, the red LED pulses slowly. Also, in DFU mode over the USB the device is seen as a "Feather nRF52840 Express" so I think it's working there. However, I tried to define the doc-recommended very simple ESPHome YAML for just evaluating the device but when I try to program it, ESPHome just spins on "Connecting to device..."

esphome:
  name: feather
  friendly_name: Feather
  build_path: ./build/feather

# Example configuration entry
nrf52:
  board: adafruit_feather_nrf52840

logger:
  level: DEBUG

output:
  - platform: gpio
    pin: P0.15
    id: red_led

interval:
  - interval: 1s
    then:
      - output.turn_on: red_led
      - delay: 0.5s
      - output.turn_off: red_led

I also have a serial-to-USB dongle that I have tried hooking up to the P0.06 and P0.08 pins but I can't seem to get that to work for programming the device either.

I have tried using esptool on my local machine to query the device several different ways but I don't even know if esptool is compatible since this isn't really an ESP device.

C:\Users\SpikeyGG\ESPHome\config>esptool flash-id
esptool v5.2.0
Found 1 serial ports...
Serial port COM6:
Connecting......................................
COM6 failed to connect: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

A fatal error occurred: Could not connect to an Espressif device on any of the 1 available serial ports.

C:\Users\SpikeyGG\ESPHome\config>esptool read-flash-status
esptool v5.2.0
Found 1 serial ports...
Serial port COM6:
Connecting......................................
COM6 failed to connect: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

A fatal error occurred: Could not connect to an Espressif device on any of the 1 available serial ports.

C:\Users\SpikeyGG\ESPHome\config>esptool --baud 1200 flash-id
esptool v5.2.0
Found 1 serial ports...
Serial port COM6:
Connecting......................................
COM6 failed to connect: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

A fatal error occurred: Could not connect to an Espressif device on any of the 1 available serial ports.

C:\Users\SpikeyGG\ESPHome\config>esptool --baud 1200 chip-id
esptool v5.2.0
Found 1 serial ports...
Serial port COM6:
Connecting......................................
COM6 failed to connect: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

A fatal error occurred: Could not connect to an Espressif device on any of the 1 available serial ports.

C:\Users\SpikeyGG\ESPHome\config>

I saw on the docs that it stated "Flashing is unstable" and recommended updating the bootloader from Releases · adafruit/Adafruit_nRF52_Bootloader · GitHub. So, I downloaded the latest release and was able to use adafruit-nrfutil.exe --verbose dfu serial -pkg "adm_b_nrf52840_1_bootloader-0.11.0_s140_6.1.1.zip" -p COM8 -b 115200 to flash it. But that still hasn't allowed me to flash it with ESPHome. Now that I'm on the upgraded bootloader, the red LED stays off but when I plug it into USB a ~32MB FAT drive shows up in Windows with a few tiny files on it, so there's that.

Anyone have tips on how I can get my first ESPHome image onto my nRF52840?

Do others guess what these are?

probably that one, but there are many it could be

it seems to be closest to this IstyBitsy board. Looks like this:

Also, trying to compile the nrf52 device yaml on my Windows machine (with esphome compile nrf52.yaml) causes an error because the source sdk file to download doesn't exist at the URL attempted:

Updating files:  97% (8862/9136)
Updating files:  98% (8954/9136)
Updating files:  99% (9045/9136)
Updating files: 100% (9136/9136)
Updating files: 100% (9136/9136), done.
--- setting manifest.path to nrf
=== Initialized. Now run "west update" inside C:\Users\SpikeyGG\.platformio\packages\framework-zephyr.
Running west update (this may take a while) ...
C:\Users\SpikeyGG\AppData\Local\Programs\Python\Python314\python.exe C:\Users\SpikeyGG\.platformio\packages\toolchain-gccarmnoneeabi\install.py
Error downloading sdk or toolchain from https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.17.4/zephyr-sdk-0.17.4_windows-AMD64_minimal.tar.xz C:\Users\SpikeyGG\.platformio\packages\toolchain-gccarmnoneeabi
*** Error 1
========================================================================================== [FAILED] Took 268.05 seconds ==========================================================================================

It's trying to download the Windows version from the wrong URL:

There are two things wrong that I can see, the system type was AMD64 but it should be x86_64. Also, the file extension for the download is 7zip and not tar-zip.

EDIT

BTW, this is with ESPHome version 2026.05

C:\Users\SpikeyGG\ESPHome\config\configs>esphome --version
Version: 2026.5.0

C:\Users\SpikeyGG\ESPHome\config\configs>

That board is Nice!Nano clone, commonly called "ProMicro" or "SuperMini".
It usually comes with Adafruit bootloader. Be careful not to update wrong bootloader, that will soft-brick it.
Here you can get more info about your board.
https://github.com/joric/nrfmicro/wiki/Alternatives#pro-micro-compatible

Is there a way to un-soft-brick it if I happen to put the wrong bootloader on it?

Yes, but you need a J-Link or an ST-Link programmer to flash the bootloader via the SWD pins on the back of the board.

Ok, I got the ST-Link V2 and built a 3D printed a sweet micro probulator setup. This morning, I was able to flash the bootloader back to Nice!nano using the bootloader binary. Now, I'm trying to get ESPHome to upload to the device. The ESPHome docs say that the options for board are:

  • board (Required, string): The board type. Valid options are adafruit_feather_nrf52840, adafruit_itsybitsy_nrf52840, xiao_ble. Other boards should work with those configuration as well.

Which one of these should I use with my board? It looks closest to the itsybitsy but I doubt that's a good reason to choose that board over the others...

I run a compile and it takes a bit of time but eventually succeeds, then when I try to upload it using the recommended --device PYOCD option, it chokes on CMAKE for some reason (CMAKE not found?). I did some Googling and found that most of the time this is due to bad build files and a "clean" fixes it, so I tried that but no dice:

  1. esphome clean-all
  2. esphome compile nicenano.yaml
  3. esphome upload nicenano.yaml --device PYOCD <-- fails
.... bunch of compile messages .... 
RAM:   [==        ]  24.9% (used 62054 bytes from 248832 bytes)
Flash: [===       ]  25.5% (used 208112 bytes from 815104 bytes)
Building .pioenvs/nicenano/firmware.hex
==================================================================================== [SUCCESS] Took 433.86 seconds ====================================================================================
Warning! Unknown upload protocol
INFO Successfully compiled program.
$ esphome upload nicenano.yaml --device PYOCD
INFO ESPHome 2026.5.1
INFO Loaded validated config cache for nicenano.yaml, skipping validation.
Warning! Ignore unknown configuration option `boards_dir` in section [env:nicenano]
Processing nicenano (board: adafruit_feather_nrf52840; framework: zephyr; platform: https://github.com/tomaszduda23/platform-nordicnrf52/archive/refs/tags/v10.3.0-5.zip)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
HARDWARE: 243KB RAM, 796KB Flash
 - framework-zephyr @ 1.20601.0 (2.6.1)
 - tool-adafruit-nrfutil @ 1.503.0 (5.3)
 - tool-cmake @ 3.21.3
 - tool-ninja @ 1.10.2
/public/ESPHome/esphome_venv/bin/python3.11 /home/spikeygg/.platformio/packages/toolchain-gccarmnoneeabi/install.py
No dependencies
Warning! Unknown upload protocol
flash_pyocd(["flash_pyocd"], [])
/public/ESPHome/esphome_venv/bin/python3.11 -m west flash -d /public/ESPHome/dashboard/.esphome/build/nicenano/.pioenvs/nicenano -r pyocd
-- west flash: rebuilding
FATAL ERROR: CMake is not installed or cannot be found; cannot build.
*** Error 1
*** [flash_pyocd] Explicit exit, status 1
====================================================================================== [FAILED] Took 1.87 seconds ======================================================================================
ERROR Upload failed with result: 1
$

(BTW, I moved from my Windows machine to another Linux machine because I couldn't get past the compile problem on Windows trying to fetch the wrong archive filename AMD64 vs. x86_64)