Executes bundles of commands respecting UTC time constraints.
The type bundleType
is:
{start : number, commands : Array.<commandType>}
and the type commandType
is :
{after: number, method: string, args: Array.<jsonType>}
where:
-
start:
time to activate the bundle in msec since January 1, 1970 UTC. -
after:
delay in msec after the previous command.
Only one bundle can be active at any time. If a new one activates, all the pending commands from previous ones are ignored.
Activation is dependent on the bundle arriving before the start
time,
i.e., late bundles are always ignored.
The device can cache non-activated bundles, and this allows pipelining of bundles.
Why bundles and not just separate commands?
Bundles help to provide safety guarantees. For example:
When controlling a drone, we want to ensure that a network disconnect will leave the drone in a safe state.
A typical bundle could command the drone to dive for 3 seconds, and then with another command in the same bundle, gracefully recover.
The first command will not execute until the whole bundle is cached in the drone, and then a network cut-off will not affect the recovery.
Also, we could add a long-term recovery action as the last command, such as get back to the initial position and land. As long as a new bundle activates before that command, the recovery action will get ignored.
Moreover, by pipelining bundles with a CA, the next bundle will reach the drone on time, guaranteeing smooth flying.
- Source:
Extends
Methods
__iot_addBundle__(bundleInfo) → {boolean}
- Source:
Adds a bundle for execution.
Parameters:
Name | Type | Description |
---|---|---|
bundleInfo |
bundleType | A new bundle to schedule. |
Returns:
True if scheduled, false
if too late to schedule.
- Type
- boolean
__iot_stop__()
- Source:
Deletes all cached bundles.
now() → {number}
- Source:
Gets the corrected UTC time.
Equivalent to (new Date()).getTime()
after applying an offset.
Returns:
Number of msec since January 1, 1970 UTC.
- Type
- number