I’m trying to setup a device via MQTT discovery, and part of the options for setting one up is a list of connections…
in the docs, it says:
connections list (Optional)
A list of connections of the device to the outside world as a list of tuples [connection_type, connection_identifier]. For example the MAC address of a network interface: “connections”: [[“mac”, “02:5b:26:a8:dc:12”]].
But, I cant find anywhere where it lists what the potential connection types are.
clearly “mac” is one, but is “ip_addr” (or “ipaddr”, or “ip”?) any others? if I have multiple mac addresses do I list them all?
I’m assuming that I’m just missing it, but I cant seem to find it and when I search, I get lots of references to MQTT connections (i.e. connections between clients and the MQTT server), but none pointing to this field.
It appears to be just asking for a list of tuples.
It would seem to me that means user defined as long as it’s a list of tuples.
What the docs don’t say is usually undefined.
OK, I’d agree that’s probably the case… BUT, if the goal of that field is to allow things to be connected to each other (as with the example of a MAC address, then it seems like there should be at least a list of common strings to use so that everyone uses the same thing.
for example, for an IP address, do I use “IP”, or “ip”, or “IP Address”, or “ip_address”, or “IPADDR”, or… ??? if I select “IP” and say my network switches are reporting a device as “ip”, it wont be connected. (or at least that’s my assumption on all of this).
@dtrott :
My goal here is to allow my device to be linked together with things like the switch port on the network switch. I guess I’m just assuming that is what the connections field is supposed to do (based on the text:
A list of connections of the device to the outside world as a list of tuples [connection_type, connection_identifier]. For example the MAC address of a network interface: “connections”: [[“mac”, “02:5b:26:a8:dc:12”]].
the identifier field seems like its not there for that (again based on the text:)
A list of IDs that uniquely identify the device. For example a serial number.
it’s certainly possible that I’m not understanding the use of these fields as the text is’nt very descriptive in terms of saying HOW they are used in the system or giving examples of why you might put in x verses y.
@Sir_Goodenough So, in the overview page, it only really addresses it in a section that says that you must have at least one identifier OR one connection defined in a device. and in the device specific pages it defines those fields (using the text I copied in my other note(s)), but that doesn’t really answer my question about is there a standard for what things should be called.
I’m guessing that, like what you said earlier, there isn’t any documented standards here, but I’d argue that there should be for this to be useful across different plugin developers. it’s fine if it only pertains to a single vendor, but as soon as one vendor uses “MAC”, and the other uses “mac”, it won’t connect. and it feels like it’s a pretty simple solve here, simply define a set of common strings to use for the most common things you might use to connect things. you dont even have to lock it down to just those, so you dont need an enum or field validation, only a document that defines the common ones.
First I will acknowledge that the documentation for MQTT is far from complete, so I am going to have to speculate a fair bit…
I don’t think connections has anything to do with how devices are physically wired (in the real world) my understanding is that connections is just a way to group components** and devices in the Home Assistant UI.
You can achieve the same result simply by nesting them in your discovery payload (and setting identifiers on each).
My assumption (there’s that word again ) was that it’s figuring out to link the two based on the MAC address, which the switch port would know as well as the camera.
I’ve seen other examples of this where a device will show other related devices from other integrations.
I’m not sure why it would be needed for linking components under a single device since as @Sir_Goodenough noted, just use the same device section, or even better send the discovery with all of the components in one device discovery packet. (which doesn’t mean that’s not exactly what it does, only that it wasn’t what I THOUGHT it would be doing.)
There is the object grouping that has appeared after I did mine, don’t know what that does.
Also I bet there is some combo in the device section that groups like that, I don’t know what it is though.
Okay that is a capability that I was not aware of / doesn’t fit with how I thought it worked. Please disregard my previous point about connections - clearly it does more than I thought.
