Announcement ESPHome running on Adafruit 52840 over Thread mesh networking using ZephyrRTOS

ESPHome
1

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 abstraction layers in ESPHome (as well as an overall well structured project) I was able to create appropriate shims and project structure builders to make the code produced by ESPHome run on top of ZephyrRTOS, an embedded operating system with its own highly optimized runtime, and low power consumption.

One of the major selling points of Zephyr is that it had native support for using Openthread mesh networking as an L2 transport layer, meaning code sitting “above” could work with a normal network socket system. This means it was possible to make the ESPHome api component “just work” (after many hours of head banging) to communicate with HomeAssistant. The API component can talk using standard sockets which get translated to the L2 thread network, sent across the mesh to a border router (part of the openthread project) which then is visible to the network containing HomeAssistant. The border router also advertises registered services for each microcontroller such that they are discoverable on link local.

Even though I did all this to enable thread networking, it is by no means required. By supporting zephyr as a target platform there are hundreds of boards that can be supported by ESPHome (though of course I have only built and tested against one at the moment).

What Does This look Like

esphome:
  name: zephyrboard

logger:

openthread:
  network_name: NETWORK_NAME
  panID: 0x111
  xpanID: 1111111111111111
  network_channel: 11
  network_key: <NETWORK_KEY>

api:
  password: "example_password"
  reboot_timeout: 0s

zephyr:
  zephyr_base: "<BASE_ZEPHYR_INSTALLATION>"
  board: adafruit_feather_nrf52840
  flash_args: "--runner blackmagicprobe --gdb-serial=/dev/ttyACM0 --elf-file=BUILD_DIR/zephyr/zephyr.signed.hex"


zephyr_ota:

binary_sensor:
  - platform: gpio
    pin:
      number: D9
      mode:
        input: true
        pullup: true
      inverted: true
    name: "zephyr sensor"
    on_press:
      then:
        - switch.turn_on: switch_light
    on_release:
      then:
        - switch.turn_off: switch_light

switch:
  - platform: gpio
    pin: D4
    id: switch_light
    internal: true
    restore_mode: ALWAYS_OFF

zephyr_post
zephyr_post608Ă—503 40.6 KB

How To Use

I’m writing this whole post to see how much interest there is in what I have been working on. I don’t want to spend a long time writing a guide no one will ever look at. Not that there is a lot to it, but I would rather put my time into the code I am going to use if no one else is interested. If there is interest I can do a write up and put it in follow up comments on setting up zephyr, the border router, etc.

The code can be found here.

Who Am I?

Just a person interested in using this for my own projects, I am not associated with ESPHome or Home Assistant, I just enjoy their wonderful work.

Will This Be Upstreamed?

I hope so eventually. I hope to not be sole maintainer for this forever, and I don’t have the energy to keep up tracking upstream development all the time. That said, until more features of ESPHome are supported (devices, interfaces, etc) I dont expect that they will want to pull in partially working project, but I might be wrong.

What Works

Right now I have focused on the basics.

  • Compiling
  • Thread networking
  • GPIO
  • Logging
  • Flashing (locally and OTA)
  • Most standard features not dependent on hardware, such as automations
  • Communication with home assistant

What Doesn’t Work

I am not sure enough to make a list, basically the above list is what I have tried so far. I suspect SPI and I2C probably work in software mode (bit banging), and if they don’t it should be pretty quick to make them. I suspect anything specific to ESP projects (like camera) will take much more time, or not be possible. There is WiFi and Ethernet support support in Zephyr so in principal it should be possible to get the ESPHome components working, but that is not a near term goal for me. Library support is not working, as this is based directly from Zephyr and not platform IO. I can go into reasons if anyone asks.

What Are My Next Plans

I started all this to have some devices around my house, so what I get working next will largely be driven by those projects. I suspect A2D will be high priority so that I can monitor battery levels. Past that I plan on tacking SPI and I2C, as I will need them before long.

What are some drawbacks

The Rom sizes are not as optimized as I would like. Because OTA updates require two slots in memory (one running, and one to update to) sometimes there is a little juggling of space required. This is not so much of a problem with simple ESPHome scripts, but it is difficult to enable some of the features Zephyr provides. Currently Network logging is not working, but should not be hard to get it to.

Long Term Hopes

I would really like to take advantage of Zephyrs real time scheduler and callbacks to eliminate the need to run loop. Events could simply be acted upon as they happen. This could be a big win in terms of power efficiency and responsiveness. Currently all of this happens exactly like it does on an ESP board which helps maintain compatibility, and makes it easier to focus on making other things work.

Is This Code Stable

No it is not. I tried to keep things designed in such a way that it could grow well, but I would classify this code possibly just past “make it work” stage. I suspect there will be refactoring in how all the Zephyr components interact with the configuration and build systems before long. That said it is usable (within what works) right now.

How Can You Help

Well first if you want to play with it, that would be great, bug reports, patches, etc are welcome (just note I have a day job so I might not always be supper prompt).

If you are interested you can donate microcontrollers (or cash to buy them), or run them on your own microcontrollers. I would be happy to support many boards, but I think my partner would give me “a look” If I spent money on many many boards, and I might not be around to keep working on it.

Thumbs up and or likes, knowing people find the work interesting helps with motivation.

Thank You

If you have made it this far in reading THANK YOU. Thank you for your attention and your time reading all of this. I have worked on this for a while and other people showing interest is very heart warming.

30 Likes
2

Well done. I for one am very interested in this.

3

Sorry for not writing anything back sooner, it has been a busy week.

Last night I was able to get I2C running for both the dedicated hardware controller, and software GPIO mode. Unfortunately I don’t have any free SPI hardware lying around, so I will not be able to work on that until I am able to order something. I have started on ADC, and UART, and think I will probably have those up and going over the next week or so.

@xAPPO, thanks for expressing interest in this, if you (or anyone else following along) wants to try and reproduce what I have done I will try and make a complete How-to below. Feel free to ask questions on any part that is not clear, or if something does not work, as it is possible I have forgotten details in all my trial and error. Also note, I am new to this forum, so I can not post many links, so I will do my best.

How to

  • You will need at least 2 Adafruit Feather nRF52840 Express boards (I am going to look into adding support for other boards soon, but for now this is the only one supported. One board will function as a network coprocessor for the border router (that bridges thread to your wider network). The other will be the board you develop with.

  • You will need some sort of debug programmer segger jlink (the edu edition is way cheaper, but read the disclaimer, you cant use this for professional development), or a blackmagic probe. I have the blackmagic probe because I like to support open hardware where I can. I think there are a few other programmers that work as well.

  • Create a python virtual env (this is not strictly necessary, but you may get conflicts with other packages and you will get conflict with esphome if you do not do this) I recommend python 3.8 for this, as there is something in the zephyr SDK that seems to be linked against python3.8 libraries. I personally have my venv running on python3.9, and was able to still get everything working by installing python3.8 libraries. The actual ABI seems to be stable, the linker is just not happy otherwise [meaning you might be able to fake it with symlinks too, but that is beyond this write up]). Make sure you have activated this environment in the shell you do the later steps in.

  • Follow the zephyr getting started guide ( docs.zephyrproject[.]org/latest/getting_started ) to make sure you have the build per-requisites and install the environment. You can skip the bits about setting up your local/bin path, and don’t have to install with --user, because you are in a venv. If you install the sdk outside of the recommended paths (what I did, follow the link [install the Zephyr Software Development Kit (SDK)] link to get the environment variables you need to export. I added these to my virtual env bin/activate script, so they would automatically be setup anytime my environment is setup.

  • The zephyr build tree has various samples in it, one of which is the network coprocessor sample. This is used to build software to flash on on of your boards such that it can be used as a radio for some computer, such as a raspberry pi. See: /docs.zephyrproject[.]org/2.6.0/samples/net/openthread/coprocessor/README.html . Make sure you build this with support for thread version 1.2, as this is what the border router now requires. Here is the command I used to build the controller. west build -b adafruit_feather_nrf52840 coprocessor/ -- -DOVERLAY_CONFIG="prj.conf overlay-rcp.conf" -DCONFIG_OPENTHREAD_THREAD_VERSION_1_2=y -DCONFIG_USB_DEVICE_STACK=y -DCONFIG_USB_DEVICE_PRODUCT='"TESTING"' -DCONFIG_USB_CDC_ACM=y -DCONFIG_USB_REQUEST_BUFFER_SIZE=2048 -DCONFIG_UART_LINE_CTRL=y Once you have this build, you can use the west command (see getting started guide) to flash this onto your board, with possible modifications for whatever debugger you are using to flash with. The command I used would look like west flash --runner blackmagicprobe -d <path to where build directory was produced from previous step, likely cwd> --gdb-serial=/dev/ttyACM0 on linux, your serial device will be different on other platforms, see getting started guide

  • Plug in the network coprocessor created in the last step. Install the Openthread Border router: openthread[.]io/guides/border-router . This must be on a device local to your network. I installed mine on the same raspberry pi I have my home assistant on, which makes the networking slightly easier. If you have it on a separate host, you will need to make sure whatever device is running your home assistant has an piv6 address and route to the open thread prefix (created when you form a network via the instructions) via whatever hardware the boarder router is running on.

  • Clone the esphomeZephyr repo from my first post. In a shell with your venv setup, run python setup.py install to install esphome with zephyr support.

  • Create a yaml project from scratch (I dont have the wizard supporting zephyr yet). You can model this on what I have in my first post. Make sure you fill in the network details in the open thread block to match those you had when you formed your network in the boarder router step.

  • plug in your second board to your computer

  • run esphome compile <your-project>.yaml then run esphome flash. Currently I don’t have run option implemented so you need to do the steps separately. The first time you build it will compile and flash a bootloader and your application. When flashing ignore the first prompt about selecting your serial device, whatever you choose does not matter, it will only look at your flash_args. I have not gotten around to changing that yet, because it requires a bit of refactoring in esphome. After the first flash (assuming it all goes well with your network and such) you should be able to use network flashing (it will ask if you want to flash over the network if it finds your device). Your computer will need an ipv6 address, and a route to the prefix mentioned above (on linux this can be done with ip route add via ).

  • Enjoy

I’m sure this will need to be fleshed out more, but I am just writing out everything from the top of my head. After I get more working on the project, I hope to spend a bit more time to streamline this a bit. It may seem like a lot, but it should not actually take too long to do. If anyone gives it a shot, let me know how it goes, and maybe keep some notes so we can work on a better guide. If you do try it, thanks for giving it a shot!

Note:
Please forgive any spelling mistakes you may find, feel free to point them out to me, and I will fix them, and thank you for doing it.

5 Likes
4

Sorry it’s bee a few weeks since an update, holidays and all.

I thought I had an old spi device laying around, so I started working on that interface. Turns out I miss remembered, and it was an i2c device. I have everything in place for SPI support it all compiles successfully, but no way to test it. I am going to look into getting something cheap.

I am in the middle of A2D support, I paused it to work on SPI support, but hope to have it finished soon.

I am also adding support for the Nordic nRF25840 USB Dongle. its a smaller device, but it still has a decent number of GPIO pins. Best of all, it is much cheaper at only 10$, so hopefully that will make it easier for others to use this for their projects.

Once the above are done, I am going to clean things up, rebase everything on latest esphome, and try to start a discussion about integrating it upstream. If any devs of the project are reading, I would love to hear from you on what you think, and what you would like to see.

3 Likes
5

I will note I now have 2 devices up and running daily automation tasks running this software, and have been very happy with it so far.

1 Like
6

I just pushed support for the adc component. I it is successfully reading out the battery voltage attached to my adafruit nrf52840 feather express.

This component supports as many channels as the zephyr board supports, which in the case of the adafruit board is 6 channels exposed on a pin, a separate internal channel for the battery, and a channel for an external reference power. To use multiple channels, just declare multiple adc sensors with different pins.

The component supports a few different options than the ESP version. First, there is an option for which voltage should be used as a reference voltage, by default the component will use the internal reference voltage of 0.6 volts. However, 1/2, 1/3, 1/4 vdd and external reference are also supported.

The adc can only read up to slightly higher than whatever voltage is used as a reference, so there is also support for various gains; 1/6, 1/5, 1/4, 1/3. 1/2, 1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 64, 128. Select whatever gain best maps the voltage to be measured to the reference voltage.

Additionally, you can select between 8,10,12,14 bits of resolution when reading the signal.

Using reading out the on board battery connector as an example; Battery is 4.2v at full charge, the board has a 2x dividing resistance built in making voltage 2.1v. I used the internal reference at 0.6v and selected a 1/6 gain so I had a maximum voltage of 0.35v on the battery read out of the possible 0.6v. Sampling does not make much difference when measuring the battery, as I only care about a course %.

Also as a complete aside, I could not find a good formulation for turning voltage into % for a 4.2v lithium polymer battery, if someone knows a good source please let me know, but in case this helps anyone, this is a pretty good approximation I found,

(3.49962210e+01*atan(8.01705286e+00*x - 3.02904337e+01)/exp(x/1.37267273e+08)+4.92184943e+01)*(0.24443444*x)+3.3667718100000004

The variable x here is in the input voltage. This seems accurate to around 2%, but battery age may affect that, especially near fully discharged.

I’m sorry if this has confused anyone when I have been talking about a2d I am referring to the analog digital converter (adc component), the term a2d comes from another life.

Finally, Just an update I am currently refactoring things and should have support for this device soon.

1 Like
7

The project looks awesome!!! I’ve come here looking for information about the new ESP-now protocol, but find out a better one: Thread by Google! Being a real fun of ESPHome, HA and Google, for sure I will be testing your project as soon as I have some spare time.

I started 4 years ago with IoT and got so surprised by ESP8266, that bought tens of them. Soon later I discovered that WiFi its not the best to use for sensors. That way, I moved into MySensors (Arduino + NRF24L01). With your project, I think I can now start creating my sensors with just one MC, even with the ESP8266-01 :wink:

Thanks for your time!!!

8

@jcataluna Thanks for your interest and kind words. I just want to note that Thread communications do no work with ESP devices, you need a micro controller with the correct radio. Currently that means the adafruit 52840, but I am almost done with support for the nordic NRF52840 dongle, which is a bit cheaper.

I hope to be finished up with support for the dongle tonight or over the weekend. I actually have ESPHome produced images running on one right now, but it was a bit hacky to upload the image, and I want to refactor all that code so it is more generic, with an eye to adding support for more boards in the near term. I am also playing around with making images smaller to leave more room for user code.

I just got in the SPI device I ordered, so I hope I get a chance to get that finished up as well. I think the last big piece to support a majority of ESPHome devices will be to get UART working.

A stretch goal will be to get Bluetooth working on the devices, as these boards support both BLE and Thread at the same time, but I have a lot of projects I want to use these boards for, and I dont need BLE anytime soon, so it might take a back seat.

9

Actually a ESP-H2 was announced last year by espressif which includes thread support.

ESP32-H2 combines important connectivity technologies, such as IEEE 802.15.4 radio connectivity, which is vital to mesh architectures with low power consumption. ESP32-H2 also makes the Thread and Zigbee protocols available, thus addressing a variety of cases in application development. Furthermore, Bluetooth LE supports point-to-point, broadcast and mesh communication topologies

Later the same year…

image
image1875Ă—796 112 KB

ESP32-H2 Officially Recognized as a “Thread-Certified Component” and a “Zigbee-Compliant Platform”

But it looks like it’s not yet sold publicly :thinking:

10

Oh I had not seen that, well whenever that IS released, this should be able to support it!

In other news, I am pretty much done re-factoring the code base. I have the NRF52840 dongle able to be a target for ESPHome, it is able to produce images, upload them, and they communicate with Home Assistant etc.

The problem I am having is that they don’t seem to work with OTA updates, which is a pretty big thing. The devices will accept the new images, they just dont seem to swap them successfully on reboot. This may have something to do with the chained bootloader from nordic, or I am just overlooking something who knows.

I am going to keep poking at it today, but I will just push things in whatever state they are tonight in case people want to experiment.

11

Update

Ok, this took longer than I expected, but I am back with an update. Each update I think this gets close and closer to production ready for most people.

Reorganization

First, I refactored the zephyr subsection of this to be better organized and generalized such that different boards have a bit more control over over various aspects.

Support for the nrf52840 dongle is now in, so getting started with this should be easier at about $10 per board.

Image size: support for more code

While working on adding suppport I learned a bit more on how flash partitions and zephyr device firmaware upgrade are handled. Because images were getting a bit tight (openthread library is over 300KB!) I messed with the definitions a bit. This caused some issues with OTA updating that needed to be worked around.

The dongle was already extra constrained because of a non removable boot loader. I expanded the flash partition by an extra 32KB, which should leave plenty of space for most ESPHome applications. The consequence for the dongle is that I had to turn off image swapping. You can do over the air updates, but it will always move the image from the second slot into the first. If the image turns out to be bad, then the device will be left with no image, and you will need to take the device back to a computer to flash it over usb using the bootloader button. In practice this has not been an issue for me, because if the image compiles it runs fine, likely the only time this would be an issue is if you somehow delete and recreate the image signing keys. Normally if it all compiles then everything operates fine.

For the original Adafruit Feather nrf52840 board, I was able to move the secondary image slot (used for OTA update) to a built in “external” flash chip. This leaves LOTS of room for whatever ~400KB of compile code. This process however exposed some issues with the upstream device driver, that I patched and am waiting on hearing back about a PR, so until that is accepted, if you want to try this code, I will need to supply a patch to apply to the zephyr source code.

SPI

Also, I got SPI up and running and am using it on a device now. The caveat is that the device only uses read mode, but the code is very symmetric, so I don’t expect any issues with writing. I purchased an ePaper screen I want to use for a device that uses both read and write for spi, so I should be able to test that soon, however I need to write a new ESPHome component for it so it may take a week or so.

Future work

I have a UART device that I can use to get that IO method working soon, but it will probably be a few weeks, as I want to write the above mentioned ePaper component, and I actually have no need for UART at this moment.

I also realized that I should add support for the preferences persistent storage api, as some devices make use of that, so that will be upcoming as well.

Asking for help

If anyone wants to get involved, an extra pair of hands coding is always welcome. However, I would like to make the barrier of people trying this out lower. I am not really a docker expert (I think its been ~7 years since I last touched it) so if anyone here has the time and expertise I really would appreciate help setting up some sort of container with all the sdks and such that people can just download and get running. I think it would also help for upstream devs when they (I hope!) start to evaluate all these changes.

Thanks

As always, thanks for reading the update

4 Likes
12

Hi @NateLust !

I think your work will prove much more valuable than you get credits for.

Although ESPHome was meant for ESP devices, it becomes clear more chips and devices will be roaming the IOT area around Home Assistant in the near future. It’s only a matter of time that ESPHome is forced to support these devices as well.
And well, let’s be honest, Zaphyr is on its way to become the defacto standard in this area.

But it will be a huge undertaking to map all the config of all components to Zaphyr device overlays. How much (device driver) code in all those ESPHome components can be reused do you think? From the top of my head, a lot of code is talking to the HAL, but a big part is also native to ESP.

13

Thanks for the feedback.

Currently I have been trying to make this a drop in replacement such that you can select ESP or Zephyr to as a target.

To do this I have Mapped ESPHome’s SPI, GPIO, I2C components to run off of zephyr APIs (and emit appropriate DeviceTree modifications when required). This means any of the ESPHome components that talk through these abstractions, just work. They dont need to be native zephyr drivers, device tree entries etc. This of course is not the most efficient, but it is in terms of development time and cross platform features.

So far, I have tried a few sensors / devices while developing, and all have used the appropriate ESPHome abstractions, and not coded directly against any esp/arduino libraries. Are there some? Definitely, and those would need translated, or modified . One thing I have thought to do moving forward is to have a red/green list of known working/ not working components that the zephyr manager would know about and emit appropriate messages (for sure things like the esp32 camera stuff). The other alternative is to put checks in each component that does not work with zephyr to verify that is not the target platform. However there seems to be a number of things directly usable right now with no modifications needed, and so why not use it?

Im currently building a ePaper display, powered by a nrf52840 dongle running on a 2032 battery over thread networking, and it should be able to run for months and months with this setup. Things like this are possible now with no extra code overhead, and a few lines of yaml code :slight_smile:

14

Now that I am approaching I/O completeness I was going to try to bring this up in other spaces (Discord maybe? I dont know where all the cool kids are these days) for more discussion. I’d be happy to chat about my work/experience anytime if you feel like it.

15

Hi @NateLust ,

Very impressive!
If this is indeed a near drop-in replacement, the gains are huge.

The cool kids are on Discord. People like glmnet, ottowinter, and of course Paulus Schoutsen (balloob) are there.
ESPhome was recently aquired by NabuCasa, just to accelerate the development and ensure the future for ESPhome, after a few years of slow development due to OttoWinter not having the time to maintain the stack.

I suspect they will be a little bit sceptic at first. Your work will shake up the whole ecosystem. Can be scary.

Try to arrange for a live demo with the three maintainers over discord, and pitch the project.
Make the current ESP problems visible (communication over wifi), and pitch the mesh-network. Zaphyr itself is huge, and used on devices like lightbulbs and small firmware devices. Right into the alley of IOT.
Let me rephrase that: a new dawn for the Home Assistant IOT ecosystem :wink:

16

@Expaso You’ve got me curious now. Picking some random components (about 10) from the tree, all of them used the abstractions and would work as is with my zephyr platform except addressable lights. I am sure there are others that wont work, or just include other libraries though.

When I get some time I will do an audit of all the components to get a sense for how much would need to be modified.

As you say, people might be a bit hesitant, so I want to go in with as many ducks in a row as I can get. If you know any of them, I would welcome an introduction or something. For sure I could do a demo, as far as the user side, its pretty much the same (after setup, that I hope to smooth out with docker or a script) you just write a yaml (see my first post in this chain for an example), compile and upload. I’m sure that crew would be more interesting the guts though, which I would enjoy talking about a lot!

17

Hmm… I just did a sweep myself also. And indeed, the vast majority of components just build on top of SPI, I2C and GPIO.

There is only a handful of components (some of which I worked on in the past) that use hardware specific stuff, like LEDC, WLED, NeoPixel, AC Dimmers, Touch Sensors, GPS and Bluetooth.
Much, much less then I expected.

Being able to run ESPHome on hundreds of boards instead of just ESP32 and ESP8266 makes this a very exiting project!

1 Like
18

Update

I have been working on making more devices using zephyr, and have been squashing bugs along the way. I have now confirmed that spi works in both send and receive modes.

Adafruit Epaper

I have spending a lot of my time working on an ESPHome display driver for Adafruit EPaper displays. This work is not tied to Zephyr in any way, and may get a separate pull request prior to the zephyr platform.

As of now, I have only tested it on the 2.13 tri-color display, but it is based off the official adafruit driver, and so I suspect with suitable subclasses should work with their other devices.

Working on this has been useful to test the various subsystems I have made changes to, and has exposed a few bugs that are now fixed.

The ePaper screen marries perfectly with a low power thread network as a device running as an end thread node. I can display information, and spend most of the time asleep, allowing this to be powered by a fairly small battery.

Time component

I experimented with the time component and realized it needed some tweaks as well. I have made those, and am in the process of testing it now. One limitation is that there is no local time zone conversion built into zephyr, as so for now everything is reported in the epoch of the timeserver. At some point some standard tz conversion libraries probably need to be included.

Next steps

I am going to start cleaning everything up, removing cruft left in the code, and get it ready for presentation. If anyone is interested in helping to arrange a demonstration, please let me know.

2 Likes
19

Oh wow, it’s big and astounding!
I’m so much impressed by your work here, and that you’ve been driving it alone all this time! :fire:
I agree with what other said above - this indeed sounds like a fundamental game-changer. ESPHome is great, but with your changes it’s just entirely new league.

I have hard time joining new communities, but had to join Discord to discuss few dev-related questions, and then found a link to this HA thread that someone shared.

I’m working now on an ESP32 + eInk + battery setup, which I want to run at lest for a month [or few!], and it was a non-starter on Wi-Fi so I pivoted to BLE Client/Server, and then just to BLE advertisement and scanner. While that worked, it was quite a journey (well, nothing compared to yours, ha-ha), and while it’s working, I got just 31 bytes of payload. Now, with Thread, that problem would be solved as a class. :open_mouth:
Would be curious to learn more about your experiment with eInk. :blush: You got me hooked up there.

Another thing I was curious about - it seems that while ESPHome was tightly coupled with Arduino for a while (AFAIU), it seems that recently there was a change to make it possible using ESP-IDF as a base target. And I even noticed a special flag in the codebase that marks a component as only working with a particular target such as Arduino (e.g., if were not ported yet etc).
So…what am I trying to say here? I hope it’s a sign that ESPHome already has a foundation - both technical and mental - for becoming a wider platform that could support many more devices.
I’d imagine PIO library support not working would mean that some components will be fundamentally incompatible with Zephyr, so the ecosystem of components might diverge to some degree, but if you ask me that’s nothing compared to having a platform that can target much more devices.

I’d love to help - although I’m very shallow on C/C++/Zephyr etc. You mentioned help with Docker? I can easily do that. I wonder what’s the best way to get in touch. I don’t have much preference, but hoping for this initiative to take off… should we try Discord to be closer to the rest of ESPHome community?

20

Any update on this?

I think what is holding people away from this is the steep learning curve and the work that is needed in setting up a border router before this is functional.
Maybe a goog tutorial with setting up a border router and linking your first node will spark the interest of a lot of users.
If this really gives a lot lower power consumption than a esp32 this will be exactly what i’m looking for to create some custom battery powered sensors/actuators.