My edge driver discovers and creates child devices using try_create_device with a parent_device_id. Necessarily, I need to have the parent_device_id of the parent device before I make this call. This makes sense as in real life a parent always comes before its child.
Once the hub is rebooted, the lifecycle init method is called for all my previously created devices. I had assumed that, again, the parent init would come before any child init but, alas, this does not always seem to be the case. Why? This makes no sense to me. Why would a child device ever be born before its parent?
Once you create those devices in the driver, they are not treated specially depending on which is the parent and which are the children.
init lifecycle is called when:
- The device is recently created
- The Hub was rebooted
- The driver was updated (you packaged, assigned, and published a new version)
So, if you need to apply a special configuration in this lifecycle, you would need to use another method of validation to see who’s the parent. Perhaps you could fill us in on what you’re trying to achieve to see if we have any suggestions
A sundial device (parent) supports many solar angle “trippers/switches” (children). The children depend on the parent for all their timing information (which is based on the sundial’s location). When a parent is “discovered”, it is created with a default set of children. Creation of each child necessarily depends on its parent (parent_device_id).
Operation of a tripper/switch (child) always depends on the sundial (parent) it is on. When first created, this dependency can be realized as the parent came first, necessarily. After a hub reboot, I expected the instantiation (init) of a parent to also come before its children. That just seems natural to me. Children depend on their parents. Parents come first.
I have worked around this by maintaining a registry of init’ed (ready) devices. They are added and removed from the ready registry in synchrony with their lifecycle (init and removed). Devices can asynchronously be “acquired” from the registry. This happens through a callback function. This happens immediately if they have already been registered; otherwise, it happens later as soon as they are registered.
This complication would not have to be if the lifecycles of parents and children behaved naturally according to their implied dependencies. Parents should be init’ed before their children. Children should be removed before their parents. That way, a child can always depend on their parent.
Oh, so you already have a workaround, that’s great, thank you for sharing your idea.
I already shared your concern with the engineering team but up to now the order of the
init is not guaranteed, so, you’re on the right path.