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 nRF52840 (nRF52 SoC series SoC from Nordic Semiconductor):
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).
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:
opened 05:50PM - 03 Sep 21 UTC
enhancement
<!-- READ THIS FIRST:
- This is for feature requests only, for issues please g… o to the issues repository.
- Please be as descriptive as possible, especially use-cases that can otherwise not be solved boost the problem's priority.
DO NOT DELETE ANY TEXT from this template! Otherwise the issue may be closed without a comment.
-->
**Describe the problem you have/What new integration you would like**
A new variant 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.
4 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!