Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MDNS loopback resolution to the same Matter node (CON-1125) #904

Open
jonsmirl opened this issue Apr 19, 2024 · 3 comments
Open

MDNS loopback resolution to the same Matter node (CON-1125) #904

jonsmirl opened this issue Apr 19, 2024 · 3 comments

Comments

@jonsmirl
Copy link
Contributor

jonsmirl commented Apr 19, 2024

If you have a light bulb and a light switch on the same Matter bridge (or Matter device), you can't bind them to each other because the loopback Matter binding will fail. I just noticed MDNS_SKIP_SUPPRESSING_OWN_QUERIES which is meant for testing ESP MDNS but it might actually allow Matter loopback binding to work.

I think the reason why the loopback binding fails on ESP32 is because when you put your own node ID into the binding list, the Matter stack can't resolve the node ID back to its own IP address. Loopback MDNS resolution would allow this.

Can this get tested, and if it works, can you promote MDNS_SKIP_SUPPRESSING_OWN_QUERIES to a standard option instead of a test one? Maybe rename it to MDNS_SUPPORT_LOOPBACK_QUERIES.

Why do you want this? Because a light switch should be able to bind to any light bulb, not just ones on a different node.

@github-actions github-actions bot changed the title MDNS loopback resolution to the same Matter node MDNS loopback resolution to the same Matter node (CON-1125) Apr 19, 2024
@wqx6
Copy link
Contributor

wqx6 commented May 15, 2024

The question might not be the mDNS loopback resolution. Even if the device can resolve the IP address of its Node ID, can it establish the CASE session with the IP address & port which it resolves? Since the OTA provider and requestor need to use different ports when testing them on a same host(without running then in any dockers). We cannot assume that the initiator and responder of one CASE session are able to use the same IP address and port.

@jonsmirl
Copy link
Contributor Author

This needs to get sorted out with the CHIP people. Every bridge and everything using remote sensors has this problem.

Here is the room air conditioner example. Note the two sensors endpoints.
image
Endpoint 1 has the thermostat cluster which has to have a client cluster for the sensor endpoints. Page 80 of the Device type spec. You then bind the client cluster to the local end points. This has to be a binding because it is also legal to have remote sensors.

And then there is the bridge case, have a light switch and a light bulb on the same bridge and bind them.

I have been filing issues on this for years but they are ignored. Here is the first of many....
project-chip/connectedhomeip#21626

@jonsmirl
Copy link
Contributor Author

Any word from the CHIP people about making loopback bindings work?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants