implement a lightweight Matter over WiFi protocol stack in ESPHome

[lboue]

Describe the problem you have/What new integration you would like

Would it be possible to implement a lightweight Matter over WiFi protocol stack in ESPHome?

Please describe your use case for this integration and alternatives you've tried:

The aim is to be able to control these devices directly via a Matter controller.

Additional context

This could be used for very simple binary sensors. For example, a contact sensor, a presence sensor, etc.

[Hedda]

Duplicate of https://github.com/esphome/feature-requests/issues/1430 as that applies to Matter over IP on both Wi-Fi and Ethernet

[lboue]

Duplicate of #1430 as that applies to Matter over IP on both Wi-Fi and Ethernet

This issue #1430 was opened in 2021 and is becoming a catch-all. There is a discussion about Zigbee, Thread Border Router, etc.

[Hedda]

This issue #1430 was opened in 2021 and is becoming a catch-all. There is a discussion about Zigbee, Thread Border Router, etc.

I disagree.

https://github.com/esphome/feature-requests/issues/1430 is only about connectivity using the Matter application-layer, (it is not really about media-layer, e.g. Thread/OpenThread).

Are you thinking about https://github.com/esphome/feature-requests/issues/1397? That is a discussion about OpenThread media-layer (and Zigbee) on ESP32 (like ESP32-H2)

[lboue]

This issue #1430 was opened in 2021 and is becoming a catch-all. There is a discussion about Zigbee, Thread Border Router, etc.

I disagree.

#1430 is only about connectivity using the Matter application-layer, (it is not really about media-layer, e.g. Thread/OpenThread).

Border Router https://github.com/esphome/feature-requests/issues/1430#issuecomment-1010939789 https://github.com/esphome/feature-requests/issues/1430#issuecomment-1268384267 https://github.com/esphome/feature-requests/issues/1430#issuecomment-1259198292

OpenThread https://github.com/esphome/feature-requests/issues/1430#issuecomment-1268384267 https://github.com/esphome/feature-requests/issues/1430#issuecomment-1259198292 https://github.com/esphome/feature-requests/issues/1430#issuecomment-1435639413

Zigbee https://github.com/esphome/feature-requests/issues/1430#issuecomment-1010939789 https://github.com/esphome/feature-requests/issues/1430#issuecomment-1259284389 https://github.com/esphome/feature-requests/issues/1430#issuecomment-1268384267 https://github.com/esphome/feature-requests/issues/1430#issuecomment-1435639413

Are you thinking about #1397? That is a discussion about OpenThread media-layer (and Zigbee) on ESP32 (like ESP32-H2)

No

[nicx]

waiting for matter support too... is this somehow in development?

[mhalano]

I think we need to finish Thread support first. I know that can be a WI-Fi-only implementation, but that's not the standard.

[nicx]

@mhalano why should Wi-Fi not be the standard? Both protocols are completly standardized with Matter. In addition to these 2 wireless protocols also Ethernet is included in the matter standard.

EDIT: Another point: For supporting Thread, you need new hardware. Using Wi-Fi you could keep all ESP modules, you do not need new modules. So in my opinion this is why matter over wifi should be the first priority ;)

[mhalano]

@mhalano What I mean is: Wi-Fi is part of the standard, but not just Wi-Fi, got it? Implementing Matter just with Wi-Fi is not following the standard completely. But it's not up to me to judge because I'm not developing it.

[Hedda]

Again this is another reason why this is a duplicate of this other request:

• https://github.com/esphome/feature-requests/issues/1430

Anyway, Matter over WiFi alone follows the standard, Matter over Ethernet alone follows the standard, and Matter over Thread alone follows the standard, there is nothing in the standards that you need to support more than one of those transport protocols.

[Apollon77]

Implementing Matter just with Wi-Fi is not following the standard completely.

Hm ... i think thats wrong.

Matter supports Ethernet, Wi-Fi or Thread as operational channels for operational communication. So the normal case is that "a device" decides for one. Devices that support "multiple" in parallel are rare - if existing at all on the market. So have "just WiFi"is completely fine. Allowing users to choose is even better. I have no clue if/how Controllers these days would react if there are multiple and also would need to read the definition

[mhalano]

What I mean, is: ESPHome is not a finished product, like my smartplug that just supports Wi-Fi, but it's a platform. We need to implement Matter with full support because someone want to use Wi-Fi, but other folk will want to use Thread, and a third one will want Ethernet. Said that, I also think we could have a preview implementation just with Wi-Fi, that, I think, is the most used system. But to consider the solution stable and ready, we need all three implemented. Again, ESPHome isn't a finished product, but a platform.

[Hedda]

Hence why this is a duplicate of https://github.com/esphome/feature-requests/issues/1430

[goloveychuk]

Fyi thread is implemented in esphome

[nicx]

Thread is irrelevant for me, I am still waiting for Matter-over-WiFi :)

[Hedda]

Thread or Wi-Fi does not matter (yes a pun), the Matter application layer is independent of the transport protocol, so this is still a duplicate of https://github.com/esphome/feature-requests/issues/1430

Again, the transport layer, network layer, and physical layer are totally separated from the application layer in the Matter stack:

The Matter application layer sits above the other layers of the protocol stack, relying on them for reliable communication.

• Transport Layer: The application layer interacts with the transport layer to send and receive messages over an IP network.

• Connectivity: It can use various network connectivity technologies, such as Wi-Fi, Thread, and Ethernet, to establish communication paths with other devices.

• Security: A security layer ensures that data is authenticated and encrypted before being sent to the transport layer for delivery to the target device.