...
The discoverDevices action supports the options described in Manual Device Discovery Options below.
The discoverDevices action supports an optional response. The response indicates the completion of the search and provides simple statistics. See Device Discovery Completion Object, below.
Manual Device Discovery Options
Field Name | Type | Description |
|---|---|---|
policy | String | (Optional) Can be either fast or slow. The default is fast. The slow policy can enable more time-consuming but more thorough algorithms, and is recommended when the edge network is expected to yield many discovered devices. |
protocols | List of Strings | (Optional) A list of protocol names where device discovery will be performed. When the protocols list is not provided, or empty, device discovery is attempted by all protocol engines that support this method. |
provisioned | Boolean | (Optional) Indicates whether the search looks for provisioned devices. Can be either true or false. The default is false. |
unprovisioned | Boolean | (Optional) Indicates whether the search includes unprovisioned devices. Can be either true or false. The default is true. |
respond | String | (Optional) Indicates where the device discovery completion object will be published at the end of the discovery process. |
meta | Any valid JSON | (Optional) A correlator. When present, this correlator will be included with the device discovery completion object. |
option | Object | (Optional) An object with protocol-specific options. |
Device Discovery Completion Object
When requested, a device discovery completion object is published to the topic specified with the respond argument, once the process is complete. The device discovery completion object is always published with MQTT options qos: 1, and retain: false.
...
Field Name | Type | Description | |
|---|---|---|---|
cost | Number | An optional cost specified as 0...1, where 0 is best (lowest cost) and 1 is worst. Cost is an abstraction for resources and effort necessary to communicate with the discovered device. The IAP server for a protocol is not required to provide a cost value. For IAP servers that support a cost value, the value may be computed based on the number of networking hops or transmit power required, for example. The value can be used by IAP clients to select the best segment, if more than one segment discovers the same device, by selecting the segment that reports the smallest cost. Example: 0.32 | |
handle | string | A handle for the discovered device. The handle must be unique in the segment. Example: "z3" | |
hops | List | An optional list of LQI (line quality indicator) values for each hop. Values range from 0 to 1, where 1 is best. Can be null. This provides additional information to the "cost" number calculation. The IAP server for a protocol is not required to provide a hops value. For IAP servers that support a hops value, an intelligent algorithm may prefer a higher cost if the LQI across the trip is more leveled, as opposed to one with 2 superb and one poor hop. Example: [ 0.8, 0.7 ] | |
loc | object | An optional location object, if geographical location is known. Can be null. See Location Object for a description. Example:
| |
protocol | string | The device’s Edge Protocol Identifier. See Edge_Protocol_ID in IAP/MQ Topic Syntax. | |
state | string | The device state, as describeddescribed in state in the Device Status Object properties table. Example: "unprovisioned" | |
type | string | Device type, as described in type in the Device Status Object properties table. Example: "8000112345604" | |
unid | string | Unique ID, as described in unid in the Device Status Object properties table. Example: "0503C0123451" |
...