Zigbee framework #include not found after restart

Using Swift
1

I started playing with Embedded Swift, with irritating help of ChatGPT. Many times I did what he asked for with no understanding. Kind of learning. At the end I had a working environment:
first by hand in Terminal:

export SWIFT_TOOLCHAIN="$HOME/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2025-03-25-a.xctoolchain"
export PATH="$SWIFT_TOOLCHAIN/usr/bin:$PATH"

swiftc -target riscv32-none-none-eabi -print-target-info | grep triple
source ~/esp/esp-idf/export.sh
// I was copied from notes, but I moved to ~/esp, done, no errors
idf.py set-target esp32h2

and

idf.py build flash monitor

Fun. It worked. And it still works for pure esp projects (blink some Led, turn knob etc..., no other frameworks)

And here is a problem: I played with Zigbee, I had two

#include <esp_zigbee_core.h>
....
#include <zcl_utility.h>

which after restart (O! new MacOS!) could not be found anymore.
I tried different zigbee includes, but nothing worked.

I had to put some secret command on Terminal. Something.
No idea what to do.

2

which after restart (O! new MacOS!) could not be found anymore.

I had to put some secret command on Terminal. Something.

Isn't that the ESP IDF's export.sh command? That sets up a lot of paths, environment options, etc., and IIUC you need to run this command in every new terminal window you open:

source ~/EmbeddedSwift/esp/esp-idf/export.sh
3

export.sh worked. (I moved esp)
% . ~/esp/esp_idf/export.sh
Green lines.

Done! You can now compile ESP-IDF projects.
Go to the project directory and run:

  idf.py build

But zigbee headers are still unavailable.

4

For curious people, I put shy repository on Github. Don't judge, I'm a designer

5

Then I would say that your sdkconfig got re-generated with some wrong settings. Can you try creating a sdkconfig.defaults file and putting in

CONFIG_ZB_ENABLED=y
CONFIG_ZB_ZED=y

?

6

Yea! Seems it helped for <esp_zigbbe_core.h> but still was problem with <zcl_utility.h>.
It worked with C example, so it's not so private I think. I can see zcl folder in espressif__esp-zigbee-lib with some stuff inside, but indeed: couldn't find zcl_utilty.h. So I copied folder zcl_utilityfrom **c** example to newcomponents` folder. In CMakeLists.txt I added:

idf_component_register(
    SRCS /dev/null # We don't have any C++ sources
    PRIV_INCLUDE_DIRS "." 
    "../components/zcl_utility/src"  # <- THIS
    "../components/zcl_utility/include"   # <- and THIS
)

How legal is it? Is a better, more elegant way?

There is also strange thing.
idf.py fullclean
throws an error (in red):

ERROR: Some components (espressif__esp-zboss-lib, espressif__esp-zigbee-lib, espressif__led_strip) in the "managed_components" directory were modified on the disk since the last run of the CMake. Content of this directory is managed automatically.

I cleanup manually, remove .component.hash and it's ok only till another cleanup

7

I'll admit that I don't know any of these details, and this is quite outside of the domain expertise of the community on this forum. But, my usual way of figuring things like this out, is literally to search for the file/library name on Github, and observing how do other open source sample projects do it. That seems to work for "zcl_utility.h" too, see e.g. this sample code https://github.com/espressif/esp-zigbee-sdk/blob/main/examples/esp_zigbee_sleep/deep_sleep/main/CMakeLists.txt which uses a similar "../" trick that you have, or this project https://github.com/aizatto/esp-zigbee/blob/main/main/CMakeLists.txt which uses a ${IDF_PATH} variable.

3 Likes