I’ve just installed a WiZ lightbulb – via the WiZ integration.
But, for some reason, the Matter integration also was “discovered”. My question is “why”.
I’m guessing that it’s because the lightbulb also supports Matter, so I would be able to manage it be either the WiZ or Matter integration. Anyway, the feature request:
Let the user know “why” an integration is “discovered”: what device triggered the discovery, what will it offer, etc.
I fully support your FR, I constantly see this. However FYI you can find it in the manifest for the integration, eg
contains the line
"zeroconf": ["_matter._tcp.local.", "_matterc._udp.local."]
so it has been discovered by zeroconf detecting one (or both) of those packets.
This is a joke right? Or maybe incorrect lingo?
As for the rest of your FR
I doubt this will ever happen because the device would need to be onboarded to know what functionality it has. It’s a chicken-egg scenario. The system only see’s the device, it doesn’t know what it is so it can’t tell you what it can do.
I usually add emoticons when making jokes over the internetz.
Then it could be “temp-pre-onboarded” behind the scenes, to provide the user with the info.
The device itself triggered the discovery…
How, these devices require auth or additional setup information…
ye, which one? I set up HA, it detects multiple devices that could be added (via multiple integrations), I don’t know what is what, just click everything → I’d rather have the info why a certain integration is recommended (at least: what device triggered the integration recommendation).
My WiZ lightbulbs didn’t require any auth. Do whatever is possible, leave out the impossibles, of course.
which one what? The device itself triggered the discovery… Are you asking which integration? the word device has a different meaning than integration.
So you want it to auto create the entities for you… you realize that in order to generate it’s functionality it literally has to load it. 100% load it, not sugar coating this. The device needs to be loaded in order to know it’s functionality.
That leaves you exactly where you are now.
Hey I found this thing, how about you finish the install so we can see what it is…
Read the first post?
Therefore: the FR is: let the user know “WHY” is HA recommending to install a particular integration (that, let’s say, it discovered a lightbulb WiZ A60 and the integration will allow me to add the device and its entities to HA).
No. I want to see what device triggered HA’s integration recommendation.
If it has to add entities first → that would be a technical detail. Maybe it has to, maybe it doesn’t. Maybe there’s an entirely new mechanism needed, so that it would be possible. Anyway, two different layers of abstraction: user interface and underlying engine inner-workings → I’m talking about the first, and you’re trying to force me to answer how to do the second (clearly not a person to be “asked” that).
I have but you aren’t explaining what you want to know.
Let me be painfully clear: You’ve asked that you want to know what device is creating the discovery.
Let me be painfully clear: The device itself is broadcasting the discovery information.
Let me be painfully clear: I think you really want to know “what integration is creating this discovery?”. But instead you’re insisting that isn’t the case.
Hopefully now you understand what I’m saying.
Devices broadcast their discovery information, that’s how they are discovered. This is done through integrations. There are a series of standards that devices use to broadcast their discovery.
A good example: Xiaomi BLE temperature sensors are Bluetooth BLE devices.
The Bluetooth integration discovers Bluetooth devices. When they get discovered, the Xiaomi integration will show up on the screen in the UI. I.e. 1 integrations is used to find your Bluetooth device: Bluetooth.
In your specific case, the zeroconfig integration is handling discovery for matter devices. And your matter device is what created the discovery.
So, zeroconfig sent out a “Hey what’s on the network” question and your device replied with “Yo I’m a matter device”.
Then HA popped up the Matter integration in the integrations page.
I’m not sure why you like to repeat the painfully world often → I don’t feel forum discussions should be/are painful in any way.
Anyway: YES. I want to to know what device triggered HA offering to install some integration (and probably the device itself later).
Cool, sure, kinda obvious.
Nope, I can see the integration. HA is presenting it to me. Again, screenshot, first post. It’s the matter integration. I know what. What I don’t know, is why is matter offered to me (the answer could be: WiZ A60 lightbulb could integrate via that).
Unfortunately, that’s techno-blah-blah for me at this point.
However “zeroconfig” works, there could be (would be great if there was) a way to see what device “wants to” (or “is available to”) be integrated into my HA instance, before I install some “cryptic” integrations.
I have to say painfully because you aren’t taking the time to understand what I’m saying. It’s like talking to a brick wall. I should just close this FR out because what you want is literally not possible because the tools that provide the discovery do not have the device information other than “it’s a matter device”.
TLDR: The technical mumbu jumbo matters, who would have thought?
Is it really true that a device broadcasting it’s there doesn’t say it’s name, even if it would be a non friendly ID? I mean, this FR seems pretty clear to me, even if I don’t really think it’s needed. You click “configure” and usually it tells you the device name on the very next screen anyway, and you can cancel if you don’t want to add that device to that integration.
Well, I read them at least two times, every time. Maybe I’m just dumb.
Not exactly, u’ve noticed it’s a chicken-egg scenario and I responded it could be bypassed.
I’ve also added that If it has to add entities first → that would be a technical detail. Maybe it has to, maybe it doesn’t. Maybe there’s an entirely new mechanism needed, so that it would be possible..
Hey, in the worst case scenario, HA could duplicate itself into a virtual machine, add the integration, add the device, read what the device it is, remove the virtual machine, and finally give the answer to the user: WiZ A60 lightbulb can be added → do you want to install Matter integration to do that?.
Yep, that would be kinda not ideal, but it would theoretically work and achieve what’s requested in the FR. But that’s worse case scenario, I’d say.
Hopefully, there are better ways. I just don’t think a FR on a forum is a good place to decide upon technical low level details on how to achieve the FR – just if it is desired. But that’s for another discussion…
Go look up the mdns packets and what they contain. Also understand that integrations don’t even know what the device does until the integration talks to it. All of this occurs AFTER you authenticate the device.
So he wants to put in something to show what the device can do before authenticating yet the devices won’t give you any information without authenticating.
So yeah, it’s a ridiculous request.
You responded with what a user would think is possible, not what is possible. If you have to auth the device before setting it up, there’s literally no difference than what we have now. Just a confirmation box that says “Do you want to keep this?”.
Serious???
You are out of control. Are you even reading what you write?
I am out!!!
I completely agree with the underlying problem that DvdNwk is highlighting here: it is often not clear to a user why certain integrations are being offered.
For example:
ANY kind of hint at why this integration is showing up - a device IP address, a Mac address, or similar - would help me work out if there’s something in my home I set up years ago that I forgot about / got recently updated and can now use in automations (wohoo!), or if I can safely ignore the integration as it’s useless to me.
Side Note: @DvdNwk while I really like out-of-the-box thinking 
, sadly I think something like a sandbox environment to auto-add these devices would be very much overkill for the desired goal of giving the user a little bit more clarity…
Also let’s follow this scenario through and say a device requires little or no authentication, so HA goes ahead and auto integrates it for you in this sandbox with no prior user input… it would be a security nightmare - do you really want a virtual HA instance to technically be able to control the energy usage of your heating system - or turn your hot water to scolding - without any user input? What if the integration had bad code and did something like this, or broke a device? It could wreak complete havoc, all without the user providing any specific consent.
So I don’t think such an idea would go anywhere!
HA actually makes it confusing to know the correct terminology to use:
When a new integration is discovered and offered, you get the notification:
Whereas what is actually meant is “new integration offered from a new, or potentially actually already-known-to-HA, device”…
@petro some friendly advice, I would recommend not to be harsh with well-meaning novice users on forums such as these, as for the @DvdNwk to have taken the time to write up this FR, there is clearly an underlying problem that is frustrating him and he’s trying to make the platform better for everyone.
Not everyone will share the same depth of understanding of the technicalities of the platform - or be invested in taking the time to learn these technicalities - and getting hung up on the technical details / simply shutting posts down as “not possible” leaves a bad taste in the mouth and leaves a frustrated users feeling “not heard”.
