Overview
Child Devices are a general concept on the Xyte platform and can be of many types (Digital Device, Physical Device, Application Device, etc).
This model allows building a hierarchy of a parent-child relationship for a number of cases, for example:
- Control devices that manage a number of directly connected devices and communicate in their name.
- Represent multiple applications running on the same shared physical hardware.
There are two methods to define and implement the parent-child relationship:
- Control parent
- Smart child
Control Parent
Physical Devices use the regular Register Device API to register itself and then the Register Child Device API for each controller child.
The parent device should register its child devices using the following parameters:
- The deviceId in the URL should be the id received by the parent when it registered.
- The Authorization header should be the access_key received by the parent when it is registered.
Once the parent device is claimed, all child devices will be automatically claimed as well, by the same organization and same space.
The child devices will appear as regular devices in the management platform, with their own telemetries, incidents, configurations, etc.
Important notes :
- for child devices, no hardware_key is needed, and you can use the model id of the model that exists in the Info section of each model.
- The hub_url used for telemetry messages will be the parent hub_url.
Smart Child
Physical, Digital or Application devices can pass an additional parent_id parameter during their Register Device API call which will bind them as a child to the parent.
The parent must be a Physical Device and can be from a different model and manufacturer than the child.
The mechanism by which the parent_id (which is the uuid of the parent) is passed to the child device before registration is up to the specific implementation flow. E.g. for Application devices, it can be passed to the installation process by the parent.