Join GitHub today
The identity update system allows metadata to be written to the device firmware remotely. This subsystem is distinct from the parameter updater subsystem: while the parameter updater governs internal behavior of the sensor node, the metadata updater governs the interaction between the device and the server environment. Specifically, the metadata updater provides the following capabilities:
- provisions a unique identifier for each node
- sets authentication information for each node
- specifies the write endpoint for each node.
For devices with over-the-air firmware updates enabled, the metadata updater can also be used to write a firmware binary file directly to the device's flash memory.
The diagram below provides an overview of the metadata updater.
The metadata updater is initiated if any of the following conditions are met:
- the device is powered on for the first time, or powered on after a reset
- the parameter updater sets the 'meta_trigger' parameter to 1
- the device reaches a specified number of connection attempts
Metadata is assigned to each device based on the mobile equipment identifier (MEID) associated with the device's cellular module. The mapping between the MEID and the device metadata is stored in the metadata database.
Upon reaching one of the preceding conditions, the sensor node first reads the MEID of the attached cellular module and stores it in memory. The device then constructs a query to select the most recent metadata associated with the obtained MEID. An example query is shown below:
SELECT last(value) from node_id, node_user, node_pass, node_db WHERE meid='<MEID>'
After constructing the query string, the query is sent to the META database via a HTTP GET request and the response is downloaded into the node's UART buffer. The response is then parsed, and the values for each parameter (node ID, node username, node password and node database) are extracted and assigned to the corresponding variables in device memory. These parameter values will remain in memory until the device is reset, or until the metadata update subroutine is triggered again.
Parameter updates are used to change the long-term behavior of a sensor node by modifying parameters stored in the device's memory. The basic logic for the parameter updater is shown below:
An example query is given below:
SELECT last(value) from <measurement_name> WHERE node_id='<NODE_ID>'
The remote trigger subsystem allows attached devices (like valve actuators) to be triggered remotely. Unlike the parameter updater (which changes the long-term behavior of a sensor node), this system is meant to trigger an instantaneous action on the device.
The diagram below provides an overview of the remote trigger subsystem.
Upon entering the remote triggering subroutine, the device loops through all attached actuator devices and checks to see if the actuator is enabled. If the device is enabled, the device ID is added to a query string. To illustrate, consider two actuator devices: a valve and an autosampler. A completed query string for this setup is shown below:
SELECT last(value) from valve_trigger, autosampler_trigger WHERE node_id='<NODE_ID>'
The query string is sent to the node's HOME database via a HTTP GET request. The response is then downloaded and parsed, assigning the updated trigger values to their corresponding variables in memory. Next, the device loops through all of the attached actuators and activates the device according to the updated trigger value. After all the actuators have been activated, the device resumes its main routine.
Trigger values will be interpreted differently depending on the actuating device in question. Some actuating devices (such as the autosampler) have a binary-valued trigger routine, where an action is taken if the trigger value is 1, and no action is taken when the trigger value is 0. In pseudo-code:
if autosampler_trigger == 1: Take autosampler reading Set autosampler_trigger to 0 in device memory. Write autosampler_trigger to 0 on node's HOME database. else: Do nothing Resume remote trigger routine
Other devices, such as valves, can execute a range of behaviors depending on the trigger value. Some valves can operate only when fully opened or fully-closed. For these devices, it is often not possible to measure the current position of the valve. The trigger behavior for this type of actuator is shown in pseudocode below:
if valve_trigger >= 0: if valve_trigger == 0: Open valve completely else if valve_trigger = 100: Close valve completely Set valve_trigger to -1 in device memory to acknowledge command was received. Write valve_trigger to -1 on node's HOME database. else: Do nothing Resume remote trigger routine
Other valves can maintain a partially-open position. For these valves,
it is possible to measure the current position of the valve, allowing for more
finely tuned discharge control. For the following valve, the position can be specified
directly on a scale from 0-100, with
valve_trigger representing the desired
Let valve_trigger represent the desired valve position if 0 <= valve_trigger <= 100: Measure current valve position and store this number in variable valve_position if valve_position != valve_trigger: Move valve position to desired valve position Set valve_trigger to -1 in device memory to acknowledge command was received. Write valve_trigger to -1 on node's HOME database. else: Do nothing Resume remote trigger routine