esp-matter: Ethernet and Wi-Fi support? (CON-353)

@dhrishi @PSONALl I think I solved the issue. The CASESession timeout should not happen, but it is not the source of the described problem. This error also occurs when using the matter build-in Bluetooth and Wi-Fi commissioning.

Instead, the mistake is here: https://github.com/espressif/esp-matter/blob/85963d2ca8f4ecb49fa3234f5b0273cb2df411b7/components/esp_matter/esp_matter_core.cpp#L899

The mdns server is not reinitialized for Ethernet connections, only for Wi-Fi. I fixed the problem by calling chip::app::DnssdServer::Instance().StartServer(); everytime when device_callback_internal is executed. Please look into this and fix it.

Thank you!

@dhrishi @PSONALl I can confirm Ethernet is working now with google home. As I use the W5500 chipset I already provided the necessary callbacks. Therefore, I cannot verify all of your changes. But the magic line that makes everything work is ESP_ERROR_CHECK(esp_netif_create_ip6_linklocal(eth_netif)); in the ETHERNET_EVENT_CONNECTED event. Thanks!

@PSONALl I know, but this problem is persisting since 3 months now, and we urgently need a fix. If other platforms (ARM, Silabs etc.) manage to be able to matter pair and communicate via Ethernet (see examples on the market such as Philips Hue Bridge) it can not only be Googles fault…

@PSONALl and @mgoeller if I add an empty bridge in the Google Home app via Ethernet everything works fine – the bridge is there and I am able to share the device to my Apple Home using the provided QR code. If I dynamically add bridged endpoints they do not appear in the Google Home app but they do in Apple home. Therefore, the issue is related to bridged endpoints controlled over Ethernet, @PSONALl you maybe share this with Google!

Thanks!

I will confirm Google Home has these issues. I am hitting a similar issue which you will likely encounter too.

I’m using my own app to commission a BLE/wifi device from Android. Google does not want to share the wifi credentials with me, so when I ask Android to commission the device first Google does a hidden commissioning session to the device using its own fabric where sets in the Wifi credentials. That succeeds, it then opens a commissioning window and my commissioning proceeds over wifi (not BLE). If this all works, everything is good.

But, let’s say my app’s commissioning fails for some reason. The device won’t be commissioned in my app. So the user hits the commissioning button again. That calls the Google library which rescans the QRCode. Then the Google library is going to set there three minutes and time out.

Why does it do that? Because the hidden commissioning session has given the device wifi credentials so now it is going to use wifi for commissioning instead of BLE. When you retry commissioning, the retry sits there looking for the device on BLE since that is where the QRCode says it is. But Google has silently moved it onto Wifi.

So now Google is stuck. They have to remember this secret commissioning session and then use it to OpenCommissioningWindow on the device using Wifi. That’s the only way to get back into contact with the device. If they just sit there looking for it on BLE it is never going to be there unless you factory reset the device. And that’s how I am working around this, if my commissioning code gets an error, I have to factory reset the device.

@PSONALI You are right! It works pefectly fine with the Apple Home app. Thank you for reporting to Google issue tracker.

@dhrishi since I pulled the latest changes of esp-matter commissioning via Ethernet works even in the Google Home app (I use ESP-IDF 4.4.4). I disabled Bluetooth completely and initialized the Ethernet driver before. After that I start matter. In order to make this work I had to comment out esp_event_loop_create_default(); and disable the initialization of the Ethernet driver in ConnectivityManagerImpl_Ethernet.cpp.

However, after pairing the bridged endpoints are offline, do you have any ideas why this happens? Comissioning with Bluetooth and controlling the bridged endpoints via Wi-Fi works perfectly… Thanks!

@dhrishi Here you go, thanks for looking into it 😃 chip-tool-log.txt esp-log.txt

Once Matter is up and running it does not care about Wi-Fi, Thread or Ethernet since that is hidden behind IP networking. My desktops functions as a router onto all three and Matter works fine on it. For commissioning you have to pick one, but after you are commissioned you can use all three. To get this telemetry info you’d have to open the correct interface (not covered by the spec). Probably varies with Wifi STA or AP mode too.

Or is this a case of a device with both Wifi and Ethernet support where you have to chose one? I haven’t consider how that case would work. Probably need some code of your own to detect that Ethernet was plugged in and to shutdown BLE/Wifi.