Create Action Properties
- Sacha Parisot (Unlicensed)
The create action supports the following arguments, submitted with the args parameter (described in the Properties table for Device Do Action):
Argument | Type | Description |
|---|---|---|
provision | Boolean | (Optional) If provided and set to true, the device will automatically be provisioned after creation. |
implementation | any | (Optional) All resource types that support explicit creation with a create action also support implementation data. When published, the CMS captures the implementation data and forwards it with the implementation property in a device create action in the event of an edge server replacement. Implementation data object topic: See Edge Server Replacement for more information on implementation data. |
routing | any | (Optional) routing is used to help restore a network following an edge server or edge device replacement. The routing data is an optimization in addition to implementation data. New devices are generally created without the routing argument, or with routing set to null. Over the lifetime of the device, the edge server may update the device’s routing property within its status object in the feedback channel. This update may use any valid JSON type: string, number, boolean, object, or a list of these. The edge server's edge processor publishes routing information in whichever form useful to itself, as explained in the following. When an object is exposed on the routing property, this should contain a type property set to "edge". A routing object without a type property is treated as one with type: “edge”. A CMS can track updates to the routing status property and, in the event of a device replacement or an edge server replacement, can include the same routing data with the replace or create actions. When the edge server's edge processor receives routing data with the device create or replace actions, it can use this “known last good” data to accelerate the process. For example, a device with a long repeat chain may be quicker to replace if the last known good repeat chain can be used as a starting point, compared to starting from scratch. Special devices can require routing objects from the start. For example, a LonWorks remote interface or a LonWorks router require routing objects of type: “rni” or “router”, respectively. Devices may support a corresponding action, route. This action takes the routing object for its arguments and supports runtime routing changes thus. This is typically used with infrastructure devices such as network interfaces or routers, or infrastructure aspects of edge devices such as devices with embedded repeater functionality. |
type | string | (Optional) Application type specification. Devices can be created following a device discovery message. In this case the device type is already known from the discovery process, and the type argument may be omitted. If it is not omitted, it must match the type of the discovered device. Devices can also be created without prior discovery, for example because their unique identifiers are known through a different method such as scanned barcodes or QR codes. To create a device without prior device discovery, set the create action’s type property to the same value as expected from the resulting device’s sts.type property. This must be one of the available application types reported with application meta data in See Data Type Definitions for information on application meta data. Example: “8000010203040506” |
unid | string | unid is optional with create but required with replace. unid is the device’s protocol-specific unique identifier, and has the following usage rules:
Example: "0503C0123451" |