Support of Arduino Matter library

[Humancell]

Related area

Arduino Library

Hardware specification

All Boards

Is your feature request related to a problem?

The Matter specification has been released, and there has been IDF support for quite some time. At one level is would be good to see examples of using these APIs from the Arduino environment. At another level it would be great if there was a higher level Arduino library created that leveraged these APIs and provided examples for both implementing and controlling a Matter device.

Describe the solution you'd like

It would be great if there was a higher level Arduino library created that leveraged the IDF Matter APIs and provided examples for both implementing and controlling a Matter device.

Describe alternatives you've considered

There are some other people outside of this project starting to experiment with this, but they are not fully open source nor sponsored by Espressif.

Additional context

For the Espressif platform to dominate in the market for Matter devices it could be engaging the Arduino developers better.

I have checked existing list of Feature requests and the Contribution Guide

• I confirm I have checked existing list of Feature requests and Contribution Guide.

[lbernstone]

Why does this need to be part of the core? It can be handled in a 3rd party library.

[VojtechBartoska]

Hello @Humancell,

thanks for opening this feature Request.

I'm adding this to next major milestone 3.0.0 and we will evaluate it.

[Humancell]

Hello,

Thank you for considering this!

@lbernstone I can understand your question, but I see this no differently from all of the other libraries that are already a part of core. We already have Bluetooth, HTTP, DNS, Webserver, NetBIOS, RainMaker and many more. Just as many of these are built on the esp-protocols, this - it seems - would be built on https://github.com/espressif/esp-matter .

It is a protocol layer provided by Espressif in the IDF, and besides the technical reasons I believe by exposing it to Arduino developers it could assist the ESP32 in becoming an even more powerful platform for the development of Matter controllers and devices.

[Yacubane]

You can try library I have created few days ago https://github.com/jakubdybczak/esp32-arduino-matter

[Humancell]

Hello,

You can try library I have created few days ago https://github.com/jakubdybczak/esp32-arduino-matter

I did see this library, but from my understanding you have not made this 100% open source, which is a problem for us. We can not use any closed source code in our projects.

If I am incorrect, and this really is 100% open source then we could take a look.

[Yacubane]

@Humancell
Why do you think that this one is not open-source?
arduino-esp32 also contains precompiled libraries and scripts that do this are in esp32-arduino-lib-builder repo.
Same with esp32-arduino-matter, you can find scripts used to build it there esp32-arduino-matter-builder.

[SuGlider]

We will consider this request for next releases in 2023... please be patient.

[SuGlider]

I have done an initial effort to build Matter and Arduino as Component.
The steps are here:

espressif/esp-matter#116 (comment)

[HamzaHajeir]

Hi all

Is there any progress for supporting Matter to the Arduino core?

[SuGlider]

@HamzaHajeir - We are currently working to release OpenThread as an Arduino Library. This shall be done later this month.
Next step is to work on releasing Matter as an Arduino Library.
I believe that it will be done by the end of this year.

[SuGlider]

About Matter Library implementation for Arduino Core 3.0.x:

• We will initially implement it to be supported within WiFi. In the future also within Thread Protocol.
• WiFi Matter will be supported for ESP32, ESP32-C3, ESP32-S3, ESP32-S2 and ESP32-C6. No support for ESP32-H2 and ESP32-P4, which have no WiFi radio. ESP32-S2 has no BLE, it won't have Matter Device BLE advertising service.
• Thread Network Protocol will be supported for the ESP32-C6 and ESP32-H2. Both have also BLE, therefore, BLE Commissionable discovery is also available.
• Commissionable discovery will be done through BLE (whenever available in the SoC), WiFi SoftAP (future feature), DNS-SD for Thread Border Routers (future feature).
• Commissioning will follow Matter standard, including QR Code generated from a URL printed in the log output.
• ESP32 Matter implementation for BLE Commissionable discovery is based on NimBLE. Therefore, it won't be compatible with ESP32 BLE Arduino Library that uses Bluedroid instead. This means that there may be issues when using both together in the same Arduino Sketch. This will be a limitation. We are planning to move ESP32 Arduino BLE Library to use NimBLE as well in the future, which may solve this incompatibility problem.
• ESP32 Matter Arduino implementation will make available all possible Matter 1.0 device types as Arduino Classes: Lighting, Smart Plugs, Switches and Controls, Sensors, Closures and HVACs. Each Device Type Class will have necessary implementation of the device data model, endpoints, roles, clusters, commands and events.
• The current implementation is only for Matter Device. No plans for Matter Controllers or Matter Commissioner library.
• This implementation will use testing and development Matter Vendor ID (0xFFF1..4), therefore valid for CSA for testing purpose only. In case you need your own VID, please follow CSA processes and add certificates as necessary to your code, on your own.

[HamzaHajeir]

About Matter Library implementation for Arduino Core 3.0.x:

• We will initially implement it to be supported within WiFi. In the future also within Thread Protocol.
• WiFi Matter will be supported for ESP32, ESP32-C3, ESP32-S3, ESP32-S2 and ESP32-C6. No support for ESP32-H2 and ESP32-P4, which have no WiFi radio. ESP32-S2 has no BLE, it won't have Matter Device BLE advertising service.
• Thread Network Protocol will be supported for the ESP32-C6 and ESP32-H2. Both have also BLE, therefore, BLE Commissionable discovery is also available.
• Commissionable discovery will be done through BLE (whenever available in the SoC), WiFi SoftAP (future feature), DNS-SD for Thread Border Routers (future feature).
• Commissioning will follow Matter standard, including QR Code generated from a URL printed in the log output.
• ESP32 Matter implementation for BLE Commissionable discovery is based on NimBLE. Therefore, it won't be compatible with ESP32 BLE Arduino Library that uses Bluedroid instead. This means that there may be issues when using both together in the same Arduino Sketch. This will be a limitation. We are planning to move ESP32 Arduino BLE Library to use NimBLE as well in the future, which may solve this incompatibility problem.
• ESP32 Matter Arduino implementation will make available all possible Matter 1.0 device types as Arduino Classes: Lighting, Smart Plugs, Switches and Controls, Sensors, Closures and HVACs. Each Device Type Class will have necessary implementation of the device data model, endpoints, roles, clusters, commands and events.
• The current implementation is only for Matter Device. No plans for Matter Controllers or Matter Commissioner library.
• This implementation will use testing and development Matter Vendor ID (0xFFF1..4), therefore valid for CSA for testing purpose only. In case you need your own VID, please follow CSA processes and add certificates as necessary to your code, on your own.

Glad to hear that's coming support of Matter in the Arduino core. I have just some questions and comments:

• ESP-IDF identifies several tools related to setup Matter device (as esp-matter-mfg-tool), are these included also?
• Per Commissioning, please consider On-Network commisioning method, in which some could have his own device on the network previously, by either Ethernet or custom implementation of WiFi-AP.
• Therefore, I think it's okay to have ESP32-S2 supported with respect to such user responsibility (or even with the feature of WiFiAP commissioning).
• Is it available for some to build a custom device using matter data and interaction model?

With thanks,
Hamza Hajeir

[SuGlider]

@HamzaHajeir - Thanks for the comments.

ESP-IDF identifies several tools related to setup Matter device (as esp-matter-mfg-tool), are these included also?

Not as part of the tools that ESP32 Arduino would provide.
These tools, as the CHIP tools, or any other Python tools, can be used independently of the ESP32 SDK used to build Matter Applications. These tools can be used while using IDF, Rust or Arduino Frameworks for Matter development.

Per Commissioning, please consider On-Network commisioning method, in which some could have his own device on the network previously, by either Ethernet or custom implementation of WiFi-AP.

Commissioning will always be done on-network.
The device must be already on the network and WiFi/Thread credentials shall be already in place.
Ethernet must have the cable connected.
In all cases, the device must have a valid IP address (DHCP or Static IP).

Therefore, On-Network Commissioning method will be included.

Therefore, I think it's okay to have ESP32-S2 supported with respect to such user responsibility (or even with the feature of WiFiAP commissioning).

Yes, correct.

Is it available for some to build a custom device using matter data and interaction model?

We may consider it for future feature. At first, we'll focus on the Matter 1.0 device types as described above.
But given that ESP32 Arduino is based on IDF and ESP-Matter, it is always possible to add code from those two to an Arduino Sketch and We may consider it for future feature. At first, we'll focus on the Matter 1.0 device types as described above.
But given that ESP32 Arduino is based on IDF and ESP-Matter, it is always possible to add code from those two to an Arduino Sketch and create custom devices, as well as custom interaction models.

[HamzaHajeir]

@SuGlider Nice, that explains all, I was mixing between commissioning discovery and commissioning process, seems two different operations.

However, it seems that all Factory Data Providers would be 'custom' in Arduino, correct?

[SuGlider]

However, it seems that all Factory Data Providers would be 'custom' in Arduino, correct?

Arduino will set the Matter Device as a Testing unit using a VIDs allocated by the CSA for testing purposes.
https://developers.home.google.com/matter/get-started#vendor_id
No Real Provider information would be used within Arduino.

Commissioning will happen as defined in the description from https://developers.home.google.com/matter/primer/commissioning

Discovery may be done using BLE and/or WiFi AP, as described here: https://developers.home.google.com/matter/primer/commissionable-and-operational-discovery

[SuGlider]

This is a long term development process.

The main goal of the current effort is to allow users to build Matter Accessories using an ESP32 Arduino Matter Library (to be created). In such case, it will use the native Matter WiFi control layer and the native Matter Thread control layer as the first approach.

Currently I'm working on:

• Making it work using Arduino Core 3.0.x + IDF 5.1 using Arduino + Matter as IDF Components.
• Making it work using Arduino Core 3.1.x + IDF 5.3 also using Arduino + Matter as IDF Components.
• Once it works fine, next step would be building the necessary Arduino pre-compiled libraries using Arduino Lib Builder tools.

I would say that making Arduino WiFi Library and Arduino Matter Library compatible with each other is not in the priority list of the current project. But it can be achieved in the long term.

Yes, now how I can build project with Arduino core 3.x and Matter?

I'll post an example using Arduino + Matter as IDF Component based on Arduino Core 3.0.5 and IDF 5.1.
It shall be placed in this folder:
https://github.com/espressif/arduino-esp32/tree/master/idf_component_examples/

I think I may have it done by the end of the next week.
This example will be based on the this code:
https://github.com/espressif/esp-matter/tree/f4eaa699f0fd8433bc5ca134328934f68f1e1525/examples/managed_component_light

[HamzaHajeir]

@dzungpv - I have tested it. -DESP32=ESP32 solves the issue. I'll add a PR to change it in Arduino repository.

Yes, change it make build sample light matter success, but other problem when I am using Arduino WiFi, the error log:

wind_FindEnclosingFunction  -Wl,--wrap=_Unwind_Resume  -Wl,--wrap=_Unwind_RaiseException  -Wl,--wrap=_Unwind_DeleteException  -Wl,--wrap=_Unwind_ForcedUnwind  -Wl,--wrap=_Unwind_Resume_or_Rethrow  -Wl,--wrap=_Unwind_Backtrace  -Wl,--wrap=__cxa_call_unexpected  -Wl,--wrap=__gxx_personality_v0  -u __cxa_guard_dummy  -lstdc++  esp-idf/pthread/libpthread.a  -lgcc  esp-idf/cxx/libcxx.a  -u __cxx_fatal_exception  -u include_esp_phy_override  -lphy  -lrtc  -lphy  -lrtc  esp-idf/esp_phy/libesp_phy.a  -u vfs_include_syscalls_impl  -lbtdm_app  -u ld_include_hli_vectors_bt && :
/Users/vietdzung/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/arduino-esp32/libarduino-esp32.a(WiFiGeneric.cpp.obj):(.literal._Z16wifiLowLevelInitb+0x40): undefined reference to `esp_netif_create_default_wifi_ap'
/Users/vietdzung/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/arduino-esp32/libarduino-esp32.a(WiFiGeneric.cpp.obj): in function `_Z16wifiLowLevelInitb':
/Users/vietdzung/dev/projects/esp32/sdks/5.1.4/arduino-esp32/libraries/WiFi/src/WiFiGeneric.cpp:178: undefined reference to `esp_netif_create_default_wifi_ap'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Undefined reference implies that some sources are not included in the build. I remember I had this one just recently, I just enabled something within WiFi component through esp-idf menuconfig, then it compiles.

Per ESP-Matter and WiFi library coexistence, I believe it's possible through telling Matter that WiFi is controlled by Application.

See: https://github.com/project-chip/connectedhomeip/blob/1912865681cd51790a6619eff633f467cee3b632/src/include/platform/ConnectivityManager.h#L89-L95

And: https://github.com/project-chip/connectedhomeip/blob/1912865681cd51790a6619eff633f467cee3b632/src/platform/ESP32/ConnectivityManagerImpl.h#L112

And, here the source shows not reacting to calls (and wifi events) if so: https://github.com/project-chip/connectedhomeip/blob/master/src/platform/ESP32/ConnectivityManagerImpl_WiFi.cpp [Search for kWiFiStationMode_ApplicationControlled].

I believe that the designers of CHIP just considers this range of use cases, where clients implement their own wifi management code. Consider a product which was in market before adopting Matter and yet have its own wifi management, should the manufacturer deliberately use CHIP wifi management? Nope.

[dzungpv]

@dzungpv - I have tested it. -DESP32=ESP32 solves the issue. I'll add a PR to change it in Arduino repository.

Yes, change it make build sample light matter success, but other problem when I am using Arduino WiFi, the error log:

wind_FindEnclosingFunction  -Wl,--wrap=_Unwind_Resume  -Wl,--wrap=_Unwind_RaiseException  -Wl,--wrap=_Unwind_DeleteException  -Wl,--wrap=_Unwind_ForcedUnwind  -Wl,--wrap=_Unwind_Resume_or_Rethrow  -Wl,--wrap=_Unwind_Backtrace  -Wl,--wrap=__cxa_call_unexpected  -Wl,--wrap=__gxx_personality_v0  -u __cxa_guard_dummy  -lstdc++  esp-idf/pthread/libpthread.a  -lgcc  esp-idf/cxx/libcxx.a  -u __cxx_fatal_exception  -u include_esp_phy_override  -lphy  -lrtc  -lphy  -lrtc  esp-idf/esp_phy/libesp_phy.a  -u vfs_include_syscalls_impl  -lbtdm_app  -u ld_include_hli_vectors_bt && :
/Users/vietdzung/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/arduino-esp32/libarduino-esp32.a(WiFiGeneric.cpp.obj):(.literal._Z16wifiLowLevelInitb+0x40): undefined reference to `esp_netif_create_default_wifi_ap'
/Users/vietdzung/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/arduino-esp32/libarduino-esp32.a(WiFiGeneric.cpp.obj): in function `_Z16wifiLowLevelInitb':
/Users/vietdzung/dev/projects/esp32/sdks/5.1.4/arduino-esp32/libraries/WiFi/src/WiFiGeneric.cpp:178: undefined reference to `esp_netif_create_default_wifi_ap'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Undefined reference implies that some sources are not included in the build. I remember I had this one just recently, I just enabled something within WiFi component through esp-idf menuconfig, then it compiles.

Per ESP-Matter and WiFi library coexistence, I believe it's possible through telling Matter that WiFi is controlled by Application.

See: https://github.com/project-chip/connectedhomeip/blob/1912865681cd51790a6619eff633f467cee3b632/src/include/platform/ConnectivityManager.h#L89-L95

And: https://github.com/project-chip/connectedhomeip/blob/1912865681cd51790a6619eff633f467cee3b632/src/platform/ESP32/ConnectivityManagerImpl.h#L112

And, here the source shows not reacting to calls (and wifi events) if so: https://github.com/project-chip/connectedhomeip/blob/master/src/platform/ESP32/ConnectivityManagerImpl_WiFi.cpp [Search for kWiFiStationMode_ApplicationControlled].

I believe that the designers of CHIP just considers this range of use cases, where clients implement their own wifi management code. Consider a product which was in market before adopting Matter and yet have its own wifi management, should the manufacturer deliberately use CHIP wifi management? Nope.

Follow your hint I was find the config that make Arduino could not build, it is CONFIG_ESP_WIFI_SOFTAP_SUPPORT=n, I enable it then the code can build. Now let play with Wifi part.
@SuGlider It is https://github.com/espressif/esp-matter/blob/f4eaa699f0fd8433bc5ca134328934f68f1e1525/examples/managed_component_light/sdkconfig.defaults#L36 change n to y then it is OK to build

[SuGlider]

I believe that the designers of CHIP just considers this range of use cases, where clients implement their own wifi management code. Consider a product which was in market before adopting Matter and yet have its own wifi management, should the manufacturer deliberately use CHIP wifi management? Nope.

Correct.
When using ESP32 Matter, WiFi is managed by Matter when CONFIG_ENABLE_WIFI_STATION or CONFIG_ENABLE_WIFI_AP are set in thesdkconfig file.
When both are unset, Matter won't manage WiFi. In such case, WiFi provisioning shall be managed by the application.

[HamzaHajeir]

I believe that the designers of CHIP just considers this range of use cases, where clients implement their own wifi management code. Consider a product which was in market before adopting Matter and yet have its own wifi management, should the manufacturer deliberately use CHIP wifi management? Nope.

Correct. When using ESP32 Matter, WiFi is managed by Matter when CONFIG_ENABLE_WIFI_STATION or CONFIG_ENABLE_WIFI_AP are set in thesdkconfig file. When both are unset, Matter won't manage WiFi. In such case, WiFi provisioning shall be managed by the application.

Some correction by considering that CONFIG_ENABLE_WIFI_STATION needs to be defined, so Matter can react to change its state onConnect and onDisconnect. Rather the developer needs to set ConnectivityMgrImpl()._SetWiFiStationMode(kWiFiStationMode_ApplicationControlled) if he wants to manage WiFi, if he have solid and reliable implementation of.

[Jason2866]

@SuGlider The PR has a ugly side effect. It causes mass of redefine warnings with pioarduino / Platformio.

Building in release mode
Compiling .pio/build/tasmota32-nspanel/src/tasmota.ino.cpp.o
Building .pio/build/tasmota32-nspanel/bootloader.bin
Generating partitions .pio/build/tasmota32-nspanel/partitions.bin
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
esptool.py v4.7.6
Creating esp32 image...
Merged 2 ELF sections
Successfully created esp32 image.
Compiling .pio/build/tasmota32-nspanel/lib3cf/Wire/Wire.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Compiling .pio/build/tasmota32-nspanel/lib53b/Adafruit_CCS811-1.0.0.14/Adafruit_CCS811.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Compiling .pio/build/tasmota32-nspanel/lib18d/SPI/SPI.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Archiving .pio/build/tasmota32-nspanel/lib3cf/libWire.a
Indexing .pio/build/tasmota32-nspanel/lib3cf/libWire.a
Compiling .pio/build/tasmota32-nspanel/libc70/Adafruit_MAX31865-1.1.0-custom/Adafruit_MAX31865.cpp.o
Archiving .pio/build/tasmota32-nspanel/lib18d/libSPI.a
Archiving .pio/build/tasmota32-nspanel/lib53b/libAdafruit_CCS811-1.0.0.14.a
Indexing .pio/build/tasmota32-nspanel/lib53b/libAdafruit_CCS811-1.0.0.14.a
<command-line>: warning: "ESP32" redefined
Indexing .pio/build/tasmota32-nspanel/lib18d/libSPI.a
<command-line>: note: this is the location of the previous definition
Compiling .pio/build/tasmota32-nspanel/libf9d/Adafruit_MCP9808_Tasmota/Adafruit_MCP9808.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Compiling .pio/build/tasmota32-nspanel/lib2f4/Adafruit_BusIO/Adafruit_BusIO_Register.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Archiving .pio/build/tasmota32-nspanel/libc70/libAdafruit_MAX31865-1.1.0-custom
Indexing .pio/build/tasmota32-nspanel/libc70/libAdafruit_MAX31865-1.1.0-custom
Compiling .pio/build/tasmota32-nspanel/lib2f4/Adafruit_BusIO/Adafruit_I2CDevice.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Archiving .pio/build/tasmota32-nspanel/libf9d/libAdafruit_MCP9808_Tasmota.a
Indexing .pio/build/tasmota32-nspanel/libf9d/libAdafruit_MCP9808_Tasmota.a
Compiling .pio/build/tasmota32-nspanel/lib2f4/Adafruit_BusIO/Adafruit_SPIDevice.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Compiling .pio/build/tasmota32-nspanel/libc3a/Adafruit_PM25AQI-1.0.6/Adafruit_PM25AQI.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Compiling .pio/build/tasmota32-nspanel/lib0ea/Adafruit_SGP30-1.2.0/Adafruit_SGP30.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Archiving .pio/build/tasmota32-nspanel/lib2f4/libAdafruit_BusIO.a
Indexing .pio/build/tasmota32-nspanel/lib2f4/libAdafruit_BusIO.a
Compiling .pio/build/tasmota32-nspanel/libdee/Adafruit_SGP40-1.1.0/Adafruit_SGP40.cpp.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
Archiving .pio/build/tasmota32-nspanel/libc3a/libAdafruit_PM25AQI-1.0.6.a
Indexing .pio/build/tasmota32-nspanel/libc3a/libAdafruit_PM25AQI-1.0.6.a
Compiling .pio/build/tasmota32-nspanel/libdee/Adafruit_SGP40-1.1.0/sensirion_voc_algorithm.c.o
<command-line>: warning: "ESP32" redefined
<command-line>: note: this is the location of the previous definition
...

EDIT: Probably fixed with espressif/esp32-arduino-lib-builder#217

[SuGlider]

Yes, espressif/esp32-arduino-lib-builder#217 will fix PIO adding -DESP32=ESP32 to its settings.

[SuGlider]

I believe that the designers of CHIP just considers this range of use cases, where clients implement their own wifi management code. Consider a product which was in market before adopting Matter and yet have its own wifi management, should the manufacturer deliberately use CHIP wifi management? Nope.

Correct. When using ESP32 Matter, WiFi is managed by Matter when CONFIG_ENABLE_WIFI_STATION or CONFIG_ENABLE_WIFI_AP are set in thesdkconfig file. When both are unset, Matter won't manage WiFi. In such case, WiFi provisioning shall be managed by the application.

Some correction by considering that CONFIG_ENABLE_WIFI_STATION needs to be defined, so Matter can react to change its state onConnect and onDisconnect. Rather the developer needs to set ConnectivityMgrImpl()._SetWiFiStationMode(kWiFiStationMode_ApplicationControlled) if he wants to manage WiFi, if he have solid and reliable implementation of.

Thank @HamzaHajeir for the information!

I see that, when both CONFIG_ENABLE_WIFI_STATION and CONFIG_ENABLE_WIFI_AP are disabled in the sdkconfig, the header file ConnectivityManagerImpl.h will use the platform/internal/GenericConnectivityManagerImpl_NoWiFi.h as the Matter Network Manager Implementation.

Therefore, maybe, we can override GenericConnectivityManagerImpl_NoWiFi class to use Arduino WiFi Library calls and achieve its integration with Matter.

Something to dig out.

[HamzaHajeir]

Thank @HamzaHajeir for the information!

I see that, when both CONFIG_ENABLE_WIFI_STATION and CONFIG_ENABLE_WIFI_AP are disabled in the sdkconfig, the header file ConnectivityManagerImpl.h will use the platform/internal/GenericConnectivityManagerImpl_NoWiFi.h as the Matter Network Manager Implementation.

Therefore, maybe, we can override GenericConnectivityManagerImpl_NoWiFi class to use Arduino WiFi Library calls and achieve its integration with Matter.

Something to dig out.

To my understanding, we don't need to override the No_WiFi implementation. we just keep CONFIG_ENABLE_WIFI_STATION defined, and CONFIG_ENABLE_WIFI_AP if needed to activate AP. But telling Matter to not touch WiFi with 'ApplicationControlled' concept.

That way the application should be responsible to manage WiFi (+WiFiAP) machine state by itself. Considering some issues as WiFi AP SSID should comply to Matter's standard, for an example.

Therefore we have something like WiFiManager library. But however I don't know what Arduino WiFi library intersect with that matter, is it something as just managing automatic reconnection? We might consider relying on CHIP's implementation of WiFi management, at least as an available option...

[SuGlider]

Therefore we have something like WiFiManager library. But however I don't know what Arduino WiFi library intersect with that matter, is it something as just managing automatic reconnection? We might consider relying on CHIP's implementation of WiFi management, at least as an available option...

This integration with Arduino WiFi Library will be left for the long run.

As a first approach, the Arduino Matter Library will use CHIP and ESP_Matter as it is now, meaning that ESP_Matter will manage WiFi/Ethernet/Thread directly through ESP-IDF calls.

I also need to understand the implication of using Arduino WiFi Lib instead of CHIP WiFi Manager regarding Network Provisioning and Matter Fabric Commissioning processes.

[SuGlider]

Initial PR for Arduino Matter Library is posted in PR #10467

[SuGlider]

#10467 is merged and Matter Library will be released into Arduino Core 3.1.0-RC2 or into initial release of Core 3.1.0.

Next step is the implementation of more Endpoint profiles as in the list:

• Simple On/Off Light
• Dimmable Light
• Temperature Color (CW/WW) Light
• Color RGB Light
• Enhanced Color (RGB + CW/WW) Light
• Generic Switch (single click smart button)
• Fan
• Temperature Sensor
• Humidity Sensor
• Pressure Sensor
• Contact Sensor
• Occupancy Sensor
• Thermostat