What is the expected behavior when changing the driver for a parent device?
I have a driver with a connected hub and all of its associated children devices. The children devices all set the hub as their parent. I changed the edge driver for the parent device and it appears that all of the children are now using it as well. Is this expected behavior? It’s nice for my use case as it allows me to change the driver for the entire ecosystem and keep it consistent, but I didn’t expect it.
Just curious what we should expect as you are able to change the driver from any device menu. What should happen in these cases:
In type CHILD_EDGE they do not have the driver option in their menu, they go where the parent goes.
In LAN-type secondaries, which do not have parent_device defined, which I use in virtual devices, by default the hub is assigned as parent_device, they behave like individual devices, that is, I can change a secondary to another similar driver and only change that device.
LAN child devices, which have parent_device, switch to another driver and only work if the driver can control them and also contains the parent_device.
If you change the parent_device they all change, and they work if the destination driver knows how to control them
Hi, @blueyetisoftware!
I asked the engineering team about this and they confirmed it is the expected behavior, also if the new driver doesn’t support the parent device and its children, they won’t have the expected functionality until a compatible driver is selected.
That happens for every device (with or without children) when we switch to a driver that doesn’t have a matching functionality.
I didn’t specify, but it is a LAN device. So, to confirm, changing the LAN parent driver will change it for that device and all of its children. Changing it on a child device will change it for only that child. It would not impact the parent or any sibling devices.
Ah, so this means you’re not using the parent-child model, but the creation of extra devices which doesn’t link them to the main device, right?
As @w35l3y mentioned, devices with the type “EDGE_CHILD” don’t have the menu to change their assigned driver.
Yes. I am creating multiple devices, using the parent_device_id when calling driver:try_create_device for the child devices. The connected hub does not have a parent set explicitly. The child devices (lights, buttons, etc.) do have it set. I don’t use EDGE_CHILD which I thought was intended for sub-devices that act more like sub-components.
What is the difference between using only the parent_device_id vs using parent_device_id and EDGE_CHILD? Looks like EDGE_CHILD gives you access to a parent_assigned_child_key
Did some side by side testing. It looks like EDGE_CHILD ignores the model set in the metadata when creating the device, but gives you access to parent_assigned_child_key which is handy. Not being able to use the model is big downside for something like my driver though when you are integrating a whole other hub. It helps to know what devices are connected to that other hub.
EDGE_CHILD looks like it is intended for multi-part devices that are all part of the same physical device, like a single relay in a multi-relay. It looks analogous to a multi-component device, except that it break them up in ST.
Thats how I saw EDGE_CHILD too. I’ve not written a device that needs that yet, still preferring multicomponent devices instead, even with their shortcomings with regards to external integrations like Alexa.
I do wish parent_assigned_child_key was available for “regular” child devices. Would make tracking children much easier and would not require the ID’s to be hub unique.
This would be great. I don’t see any reason it can’t be done. Even considered reworking the driver with EDGE_CHILD to get access to that function. You can still use get_child_list() though and just iterate through it until you find the instance you want. Would really like to see this added though. I would also go the other way and use EDGE_CHILD if the ST team said that was the direction and children could have their own model and manufacturer.
I dug into this a little more and think ST intends to treat a Hub+Connected devices as a parent with EDGE_CHILDren. I’m basing that on their documentation for Matter
They mention using endpoints for multi-component devices (e.g power strip) vs a network device with it’s own children. A connected Hub clearly falls into the second group. Their example uses EDGE_CHILD and get_child_by_parent_assigned_key. This does make some logical sense given that the connected Hub is the only true “network device” and all of its children rely on it to act as a bridge.
They don’t discuss creating children with their own device_network_id, but I assume that would only be intended if they can be separately addressed on the network. Maybe something like Sonos speakers in a Sonos system? I know those have their own IP.