Hedda
(Hedda)
February 3, 2024, 2:38pm
1
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):
dev ← tomaszduda23:nrf52
opened 11:17PM - 10 Jan 24 UTC
# What does this implement/fix?
It is possible to buy cheap [nrf52840 module]… (https://github.com/joric/nrfmicro/wiki). It would be very convenience to program it using yaml files.
It is proof of concept for support NRF52 on esphome.
It requires:
- https://github.com/esphome/esphome/pull/7049
## How to upload
There are few options:
1. with stlink `python -m esphome upload tests/test12.2.yaml --device PYOCD`
2. if board have adafruit bootloader image has to build with
```yaml
nrf52:
board: adafruit_itsybitsy_nrf52840
```
to upload `python -m esphome upload tests/test12.3.yaml`
3. if board support UF2
```bash
cp ./tests/.esphome/build/nrf52-test-nrf-adafruit/.pioenvs/nrf52-test-nrf-adafruit/zephyr/zephyr.uf2 /media/0321-5432/
```
4. BLE OTA with mcuboot `python -m esphome upload tests/test12.2.yaml` to specify mac address of BLE device `python -m esphome upload tests/test12.2.yaml --device AA:BB:CC:11:22:33`
## TODO
**Arduino**
moved to https://github.com/esphome/esphome/pull/6228
**Zephyr**
- [x] GPIO
- [x] CDC DFU (0.8.2 is more stable) - adafruit
- [x] CDC logger
- [x] nrf-sdk based
- [x] UART0 logger
- [ ] UART0 logger tested
- [x] BLE OTA - mcuboot
- [ ] ~CDC OTA - mcuboot recover~ (`FLASH' overflowed by 11320 bytes)
- [x] CDC OTA - mcuboot
- [ ] serial OTA - mcuboot recovery
- [x] watchdog
- [x] BLE logger
- [x] preferences for restore mode
- [x] preferences for adafruit
- [ ] disable update of preferences during OTA - why is it done for other platforms?
- [x] fix arm builds
- [x] add pyocd to upload
- [x] move to main branch for smp
- [x] move to main branch for smpclient
- [x] move debug config to separate component
- [ ] validate prj.conf after compilation to make sure that config was applied correctly
- [ ] GPIO interrupts
- [ ] what to do if image cannot be confirmed during OTA?
- [x] implement get mac
- [x] change name for dfu?
- [x] adc
- [ ] pull up does not work for P0.17 and P0.20
- [ ] change voltage (it works only twice without erase)
- [ ] delete files if app.overlay change
- [x] i2c - moved to https://github.com/esphome/esphome/pull/8150
- [x] smpclient do not support serial https://github.com/intercreate/smpclient/issues/22
- [x] ~check why toolchain rebuilds all files even though single file changed https://github.com/tomaszduda23/esphome/pull/2~ prj.conf address is random generated which triggers rebuild
Fix review comments https://github.com/esphome/esphome/pull/6075#issuecomment-2094929824
- [x] fix build with python 3.9
- https://github.com/intercreate/smpclient/issues/16
- [x] move tests to new structure in tests/components/<component>
- [x] check #6459
- [x] move small changes unrelated components to own PRs
- https://github.com/esphome/esphome/pull/6679
- [x] wrapped code with #ifdef USE_ZEPHYR or #ifdef USE_NRF52
How to communicate with HA? Options:
- [ ] BLE serial
- 10KB/s - 2M PHY, interval of 7.5 ms, 247MTU
- [ ] BTHome
- https://github.com/esphome/feature-requests/issues/1862
- sensors only
- [ ] custom BLE service
- https://novelbits.io/bluetooth-5-speed-maximum-throughput/
- [ ] openthread https://openthread.io/codelabs/openthread-hardware#1
- https://github.com/esphome/esphome/pull/8410
- [x] zigbee https://github.com/esphome/esphome/pull/7340
The SoC has only 1MB of memory. All above consume:
```bash
RAM: [= ] 5.9% (used 14736 bytes from 248832 bytes)
Flash: [== ] 17.9% (used 146000 bytes from 815104 bytes)
```
## update adafruit bootloader
```bash
git clone https://github.com/adafruit/Adafruit_nRF52_Bootloader
cd Adafruit_nRF52_Bootloader
make BOARD=nice_nano all
make BOARD=nice_nano SERIAL=/dev/ttyACM0 flash-dfu
```
## Types of changes
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Other
**Related issue or feature (if applicable):** fixes <link to issue>
**Pull request in [esphome-docs](https://github.com/esphome/esphome-docs) with documentation (if applicable):** esphome/esphome-docs#<esphome-docs PR number goes here>
## Test Environment
- [ ] ESP32
- [ ] ESP32 IDF
- [ ] ESP8266
- [ ] RP2040
- [ ] BK72xx
- [ ] RTL87xx
- [x] nrf52840
## Example entry for `config.yaml`:
```yaml
---
nrf52:
# board: adafruit_itsybitsy_nrf52840
board: adafruit_feather_nrf52840
# framework:
# variant: nrf-sdk
# bootloader: adafruit
# bootloader: mcuboot
esphome:
name: nrf52-test-nrf
logger:
level: DEBUG
logs:
switch: NONE
switch:
- platform: gpio
pin:
number: 15
inverted: true
mode:
output: true
id: gpio_15
interval:
- interval: 500ms
then:
- switch.toggle: gpio_15
output:
- platform: gpio
pin:
number: 14
inverted: true
mode:
output: true
id: rest_gpio
ota:
- platform: zephyr_mcumgr
zephyr_ble_server:
```
## Checklist:
- [x] The code change is tested and works locally.
- [x] Tests have been added to verify that the new code works (under `tests/` folder).
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in [esphome-docs](https://github.com/esphome/esphome-docs).
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.
Nordic Semiconductor ASA (formerly known as Nordic VLSI) was founded in 1983 and is a Norwegian fabless technology company with its headquarters in Trondheim, Norway. The company specializes in designing ultra-low-power wireless communication semiconductors and supporting software for engineers developing and manufacturing Internet of Things (IoT) products.
The company's primary SoC and SiP hardware products support wireless technologies, protocols, and standards like Bluetooth LE and BLE mesh, ...
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:
dev ← tomaszduda23:nrf52_zigbee
opened 02:41PM - 22 Aug 24 UTC
# What does this implement/fix?
**Note: for adafruit bootloader check:**
```… yaml
bootloader: adafruit_nrf52_sd140_v6 # for nice nano
```
This requires https://github.com/esphome/esphome/pull/7049. It adds zigbee switch and binary_sensor. Tested with zigbee2mqtt 1.40.0. Up to 8 components is supported due to endpoint limit on nrf52840. Endpoints could be reused but it requires extra implementation. Entities names are auto discovered by home assistant.
https://github.com/user-attachments/assets/45aeb83e-d30c-4b06-9745-1d0036b353c1
Related items:
- https://github.com/zigpy/zha/pull/197 description should work in zha after this is merged
- https://github.com/zigpy/zha/issues/194
- https://github.com/Koenkk/zigbee-herdsman-converters/pull/7913
- https://github.com/luar123/zigbee_esphome/
- https://github.com/ffenix113/zigbee_home
Specification:
https://csa-iot.org/wp-content/uploads/2022/01/07-5123-08-Zigbee-Cluster-Library-1.pdf
## Types of changes
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Other
**Related issue or feature (if applicable):** fixes <link to issue>
https://github.com/esphome/feature-requests/issues/1397
**Pull request in [esphome-docs](https://github.com/esphome/esphome-docs) with documentation (if applicable):** esphome/esphome-docs#<esphome-docs PR number goes here>
## Test Environment
- [ ] ESP32
- [ ] ESP32 IDF
- [ ] ESP8266
- [ ] RP2040
- [ ] BK72xx
- [ ] RTL87xx
- [x] nrf52840
## Example entry for `config.yaml`:
Alternative config: https://github.com/esphome/esphome/pull/7340#issuecomment-2708458620
```yaml
---
# based on adafruit bootloader
external_components:
- source: github://pr#7049
components: [ logger, nrf52, time, zephyr ]
refresh: always
- source: github://pr#7340
components: [ zigbee_ctx, zigbee ]
refresh: always
nrf52:
board: adafruit_itsybitsy_nrf52840
bootloader: adafruit_nrf52_sd140_v6 # for nice nano
esphome:
name: nrf52-test-nrf
logger:
level: DEBUG
switch:
- platform: zigbee
output: output_template
id: zigbee_switch_1
- platform: zigbee
output: output_template
id: zigbee_switch_2
output:
- platform: template
id: output_template
type: binary
write_action:
- binary_sensor.zigbee.publish:
id: zigbee_binary_sensor_1
state: ON
- binary_sensor.zigbee.publish:
id: zigbee_binary_sensor_1
state: OFF
- platform: template
id: output_factory
type: binary
write_action:
- zigbee.factory_reset
binary_sensor:
- platform: zigbee
id: zigbee_binary_sensor_1
- platform: zigbee
id: zigbee_binary_sensor_2
lambda: return true;
zigbee:
on_join:
- switch.zigbee.publish:
id: zigbee_switch_1
state: OFF
- switch.zigbee.publish:
id: zigbee_switch_1
state: ON
time:
- platform: zigbee
id: test_time
---
# based on mcuboot bootloader
external_components:
- source: github://pr#7049
components: [ logger, nrf52, time, zephyr ]
refresh: always
- source: github://pr#7340
components: [ zigbee_ctx, zigbee ]
refresh: always
nrf52:
board: adafruit_feather_nrf52840
esphome:
name: nrf52-test-nrf
logger:
level: DEBUG
switch:
- platform: zigbee
output: output_template
id: zigbee_switch_1
- platform: zigbee
output: output_template
id: zigbee_switch_2
output:
- platform: template
id: output_template
type: binary
write_action:
- binary_sensor.zigbee.publish:
id: zigbee_binary_sensor_1
state: ON
- binary_sensor.zigbee.publish:
id: zigbee_binary_sensor_1
state: OFF
- platform: template
id: output_factory
type: binary
write_action:
- zigbee.factory_reset
binary_sensor:
- platform: zigbee
id: zigbee_binary_sensor_1
- platform: zigbee
id: zigbee_binary_sensor_2
lambda: return true;
zigbee:
on_join:
- switch.zigbee.publish:
id: zigbee_switch_1
state: OFF
- switch.zigbee.publish:
id: zigbee_switch_1
state: ON
time:
- platform: zigbee
id: test_time
```
## Checklist:
- [x] The code change is tested and works locally.
- [x] Tests have been added to verify that the new code works (under `tests/` folder).
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in [esphome-docs](https://github.com/esphome/esphome-docs).
opened 05:50PM - 03 Sep 21 UTC
enhancement
**Describe the problem you have/What new integration you would like**
A new v… ariant of the ESP32 [was announced last month](https://www.espressif.com/en/news/ESP32_H2), the ESP32-H2. It supports 802.15.4 and therefore Zigbee and Thread, as well as BLE, and now runs on a RISC-V architecture which should be a lot more efficient. It also still supports WiFi.
This looks super interesting because it will finally give home users a way to easily build Zigbee/Thread versions instead of WiFi ones. I think ESPHome supporting this would be a brilliant step forward.
**Please describe your use case for this integration and alternatives you've tried:**
There are no alternatives to ESPHome for Zigbee as far as I know? Or really any simple development environments for home users.
**Additional context**
Of course the H2 isn't out yet. But I think it'd be good to get a discussion on this going before it is released. Zigbee is definitely a lot more friendly to larger home installations in many ways.
Support for battery operated end Zigbee devices would also be a huge leap forward. And I would think that should be possible on the new H2.
5 Likes
Hedda
(Hedda)
May 21, 2024, 8:00am
2
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:
esphome:dev ← tomaszduda23:nrf52
opened 11:17PM - 10 Jan 24 UTC
# What does this implement/fix?
It is possible to buy cheap [nrf52840 module]… (https://github.com/joric/nrfmicro/wiki). It would be very convenience to program it using yaml files.
It is proof of concept for support NRF52 on esphome.
## How to upload
There are few options:
1. with stlink `python -m esphome upload tests/test12.2.yaml --device PYOCD`
2. if board have adafruit bootloader image has to build with
```yaml
nrf52:
board: adafruit_itsybitsy_nrf52840
```
to upload `python -m esphome upload tests/test12.3.yaml`
3. if board support UF2
```bash
cp ./tests/.esphome/build/nrf52-test-nrf-adafruit/.pioenvs/nrf52-test-nrf-adafruit/zephyr/zephyr.uf2 /media/0321-5432/
```
4. BLE OTA with mcuboot `python -m esphome upload tests/test12.2.yaml` to specify mac address of BLE device `python -m esphome upload tests/test12.2.yaml --device AA:BB:CC:11:22:33`
## TODO
**Arduino**
moved to https://github.com/esphome/esphome/pull/6228
**Zephyr**
- [x] GPIO
- [x] CDC DFU (0.8.2 is more stable) - adafruit
- [x] CDC logger
- [x] nrf-sdk based
- [x] UART0 logger
- [ ] UART0 logger tested
- [x] BLE OTA - mcuboot
- [ ] ~CDC OTA - mcuboot recover~ (`FLASH' overflowed by 11320 bytes)
- [x] CDC OTA - mcuboot
- [ ] serial OTA - mcuboot recovery
- [x] watchdog
- [x] BLE logger
- [x] preferences for restore mode
- [x] preferences for adafruit
- [ ] disable update of preferences during OTA - why is it done for other platforms?
- [x] fix arm builds
- [x] add pyocd to upload
- [x] move to main branch for smp
- [ ] move to main branch for smpclient
- [x] move debug config to separate component
- [ ] validate prj.conf after compilation to make sure that config was applied correctly
- [ ] GPIO interrupts
- [ ] what to do if image cannot be confirmed during OTA?
- [x] implement get mac
- [x] change name for dfu?
- [x] adc
- [ ] pull up does not work for P0.17 and P0.20
- [ ] change voltage (it works only twice without erase)
- [ ] delete files if app.overlay change
- [x] i2c
Fix review comments https://github.com/esphome/esphome/pull/6075#issuecomment-2094929824
- [x] fix build with python 3.9
- https://github.com/intercreate/smpclient/issues/16
- [x] move tests to new structure in tests/components/<component>
- [x] check #6459
- [x] move small changes unrelated components to own PRs
- https://github.com/esphome/esphome/pull/6679
- [x] wrapped code with #ifdef USE_ZEPHYR or #ifdef USE_NRF52
How to communicate with HA? Options:
- [ ] BLE serial
- 10KB/s - 2M PHY, interval of 7.5 ms, 247MTU
- [ ] BTHome
- https://github.com/esphome/feature-requests/issues/1862
- sensors only
- [ ] custom BLE service
- https://novelbits.io/bluetooth-5-speed-maximum-throughput/
- [ ] openthread https://openthread.io/codelabs/openthread-hardware#1
The SoC has only 1MB of memory. All above consume:
```bash
RAM: [= ] 5.9% (used 14736 bytes from 248832 bytes)
Flash: [== ] 17.9% (used 146000 bytes from 815104 bytes)
```
## update adafruit bootloader
```bash
git clone https://github.com/adafruit/Adafruit_nRF52_Bootloader
cd Adafruit_nRF52_Bootloader
make BOARD=nice_nano all
make BOARD=nice_nano SERIAL=/dev/ttyACM0 flash-dfu
```
## Types of changes
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Other
**Related issue or feature (if applicable):** fixes <link to issue>
**Pull request in [esphome-docs](https://github.com/esphome/esphome-docs) with documentation (if applicable):** esphome/esphome-docs#<esphome-docs PR number goes here>
## Test Environment
- [ ] ESP32
- [ ] ESP32 IDF
- [ ] ESP8266
- [ ] RP2040
- [ ] BK72xx
- [ ] RTL87xx
- [x] nrf52840
## Example entry for `config.yaml`:
<!--
Supplying a configuration snippet, makes it easier for a maintainer to test
your PR. Furthermore, for new integrations, it gives an impression of how
the configuration would look like.
Note: Remove this section if this PR does not have an example entry.
-->
```yaml
---
nrf52:
# board: adafruit_itsybitsy_nrf52840
board: adafruit_feather_nrf52840
# framework:
# variant: nrf-sdk
# bootloader: adafruit
# bootloader: mcuboot
esphome:
name: nrf52-test-nrf
logger:
level: DEBUG
logs:
switch: NONE
switch:
- platform: gpio
pin:
number: 15
inverted: true
mode:
output: true
id: gpio_15
interval:
- interval: 500ms
then:
- switch.toggle: gpio_15
output:
- platform: gpio
pin:
number: 14
inverted: true
mode:
output: true
id: rest_gpio
ota:
- platform: zephyr_mcumgr
zephyr_ble_server:
```
## Checklist:
- [x] The code change is tested and works locally.
- [x] Tests have been added to verify that the new code works (under `tests/` folder).
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in [esphome-docs](https://github.com/esphome/esphome-docs).
Btwy, also wanted to mention missed that @NateLust previous begun porting ESPHome to nRF52840:
TLDR
I ported ESPHome to run on top of ZephyrRTOS. Using this I was able to build against the Adafruit Feather 52840 Express, and create an OpenThread mesh network (not WiFi) which is used to communicate with my Home assistant instance.
Slightly Longer
I have long enjoyed how easy it was to make smart home devices using ESPHome, but was always interested in moving away from Wifi (range issues, congested IPs, power consumption, etc). Because of the fantastic job @OttoWinter did in creating abs…
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(?).
1 Like
Judman13
(Judson)
May 23, 2024, 9:42pm
3
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!
Hedda
(Hedda)
January 24, 2025, 10:18am
4
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:
3 Likes
Hedda
(Hedda)
August 4, 2025, 1:42pm
5
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:
2 Likes
ESPHome now officially supports the Nordic nRF52 platform! Check it out:
3 Likes
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.
1 Like