-
-
Notifications
You must be signed in to change notification settings - Fork 656
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
Matter commissioning potentially uses link-local addresses #4528
Comments
While I understand this being logged as a bug, the Play Services Matter SDK hasn't changed since release and doesn't return the discriminator. Alternative APIs would be implementing the entire Matter SDK (not Google's Android interfaces) in the app then? |
Yeah so my hope is that the Play Services Matter SDK eventually gains that feature. I think what would be good is if we can log that as an official bug/feature request. I can also reach out to some folks and reference that issue so we can get this going. An alternative could be to implement a simple mDNS reverse lookup in the App. Essentially just look up all commissionable devices, compare IP addresses, and then extract the Discriminator from there. It feels very hacky though 😢 Implementing the entire Matter SDK ourselfs would be cool, but is really a rather big undertaking. We'd need to make it compile/work with Android, test/validate and certify it. This is no easy feat 😢 |
@jpelgrom what I was wondering, we currently have multiple ways to commission a device:
The problem is only in-App. So the first two methods use a different flow. From what I understand, for that flow we just get a callback. But maybe that flow can be triggered somehow? 🤔 At least the QR code scanner seems to be able to do that... |
I wasn't aware of that, nice find!
After testing it, yes it seems like we can trigger it. The camera sends an intent to view a scanned To test I used: From the Play Services manifest: <activity-alias
android:name="com.google.android.gms.home.SetupDeviceActivityQrCode"
android:enabled="true"
android:exported="true"
android:targetActivity="com.google.android.gms.home.SetupDeviceActivity">
<intent-filter>
<data
android:scheme="MT"
android:pathPattern="[A-Z0-9-.]{19,}"/>
<category
android:name="android.intent.category.DEFAULT"/>
<action
android:name="android.intent.action.VIEW"/>
</intent-filter>
</activity-alias> I guess it would be worth it, now that the app has a native QR code scanner, to see if using this flow improves the commissioning reliability for users? It is undocumented, but if it works reliably that might also be nice so that commissioning with HA Android always works the same. |
Home Assistant Android app version(s):
Android version(s):
Android 14
Device model(s):
Pixel 8 Pro
Home Assistant version:
2024.8.0.dev202407190220
Last working Home Assistant release (if known):
Description of problem, include YAML if issue is related to notifications:
The current Matter commissioning flow simply returns a pin and IP address. The first implementation passed just the pin, which was problematic as it contains no Matter discriminator. This mean, if two devices were commissionable on the network, the Matter Server potentially picked the wrong device, which made the commissioning to fail (see home-assistant-libs/python-matter-server#463).
Since #4069 we pass also the IPv6 address, which makes this work better. However, if the Android Matter commissioning flow returns a link-local IPv6 address, the Server can't reliably determine which network to use. A work around which scopes the link-local IPv6 addresses server side (see home-assistant-libs/python-matter-server#501) makes it work for the common case (single network interface). However, this means that Matter devices can only be reliably commissioned using Android if they are on the primary network. This is tricky for advanced use cases (e.g. dual-home installation with a separate IoT VLAN, which is not the primary network).
Transporting IPv6 link-local addresses to the Server is really a hack. The underlying Matter SDK API to commission a Matter device through an IP address (
ConnectIP
) is also deprecated.The Android App should really communicate a setup code/QR code or a pin code with discriminator to the backend. We should check if there are alternative APIs available, or if we can determine the discriminator somehow using the current API.
Companion App Logs:
Screenshot or video of problem:
Additional information:
The text was updated successfully, but these errors were encountered: