onInput. The same is true for onEnter and onExit. Any change made to a variable when we enter or exit the state isn't available to other conditions specified in the same onEnter or onExit fields.
Latency when updating a detector model
If you update, delete, and recreate a detector model (see UpdateDetectorModel), there is some delay before all spawned detectors (instances) are deleted and the new model is used to recreate the detectors. They are recreated after the new detector model takes effect and new inputs arrive.
During this time inputs might continue to be processed by the detectors spawned by the previous version of the detector model. During this period, you might continue to receive alerts defined by the previous detector model.
Spaces in input keys
Spaces are allowed in input keys, but references to the key must be enclosed in backticks, both in the definition of the input attribute and when the value of the key is referenced in an expression. For example, given a message payload like the following:
{ "motor id": "A32", "sensorData" {
"motor pressure": 56, "motor temperature": 39 }}
Use the following to define the input.
{ "inputName": "PressureInput",
"inputDescription": "Pressure readings from a motor", "inputDefinition": {
"attributes": [
{ "jsonPath": "sensorData.`motor pressure`" }, { "jsonPath": "`motor id`" }
] }}
In a conditional expression, you must refer to the value of any such key using backticks also.
$input.PressureInput.sensorData.`motor pressure`
A commented example: HVAC temperature control
Some of the following example JSON files have comments inline, which makes them invalid JSON.
Complete versions of these examples, without comments, are available at HVAC temperature control (p. 108).
Background
This example implements a thermostat control model that gives you the ability to do the following.
• Define just one detector model that can be used to monitor and control multiple areas. A detector instance is created for each area.
• Ingest temperature data from multiple sensors in each control area.
• Change the temperature set point for an area.
Background
• Set operational parameters for each area and reset these parameters while the instance is in use.
• Dynamically add or delete sensors from an area.
• Specify a minimum runtime to protect heating and cooling units.
• Reject anomalous sensor readings.
• Define emergency set points that immediately engage heating or cooling if any one sensor reports a temperature above or below a given threshold.
• Report anomalous readings and temperature spikes.
Input definitions
We want to create one detector model that we can use to monitor and control the temperature in several different areas. Each area can have several sensors that report the temperature. We assume each area is served by one heating unit and one cooling unit that can be turned on or off to control the temperature in the area. Each area is controlled by one detector instance.
Because the different areas we monitor and control might have different characteristics that demand different control parameters, we define the 'seedTemperatureInput' to provide those parameters for each area. When we send one of these input messages to AWS IoT Events, a new detector model instance is created that has the parameters we want to use in that area. Here's the definition of that input.
CLI command:
aws iotevents create-input --cli-input-json file://seedInput.json
File: seedInput.json
{ "inputName": "seedTemperatureInput",
"inputDescription": "Temperature seed values.", "inputDefinition": {
"attributes": [
{ "jsonPath": "areaId" },
{ "jsonPath": "desiredTemperature" }, { "jsonPath": "allowedError" }, { "jsonPath": "rangeHigh" }, { "jsonPath": "rangeLow" }, { "jsonPath": "anomalousHigh" }, { "jsonPath": "anomalousLow" }, { "jsonPath": "sensorCount" }, { "jsonPath": "noDelay" } ]
}}
Response:
{ "inputConfiguration": { "status": "ACTIVE",
Background
}
Notes
• A new detector instance is created for each unique 'areaId' received in any message. See the 'key' field in the 'areaDetectorModel' definition.
• The average temperature can vary from the 'desiredTemperature' by the 'allowedError' before the heating or cooling units are activated for the area.
• If any sensor reports a temperature above the 'rangeHigh', the detector reports a spike and immediately starts the cooling unit.
• If any sensor reports a temperature below the 'rangeLow', the detector reports a spike and immediately starts the heating unit.
• If any sensor reports a temperature above the 'anomalousHigh' or below the 'anomalousLow', the detector reports an anomalous sensor reading, but ignores the reported temperature reading.
• The 'sensorCount' tells the detector how many sensors are reporting for the area. The detector calculates the average temperature in the area by giving the appropriate weight factor to each temperature reading it receives. Because of this, the detector won't have to keep track of what each sensor reports, and the number of sensors can be changed dynamically, as needed. However, if an individual sensor goes offline, the detector won't know this or make allowances for it. We recommend that you create another detector model specifically for monitoring the connection status of each sensor. Having two complementary detector models simplifies the design of both.
• The 'noDelay' value can be true or false. After a heating or cooling unit is turned on, it should remain on for a certain minimum time to protect the integrity of the unit and lengthen its operating life. If 'noDelay' is set to false, the detector instance enforces a delay before it turns off the cooling and heating units, to ensure that they are run for the minimum time. The number of seconds of delay has been hardcoded in the detector model definition because we are unable to use a variable value to set a timer.
The 'temperatureInput' is used to transmit sensor data to a detector instance.
CLI command:
aws iotevents create-input --cli-input-json file://temperatureInput.json
File: temperatureInput.json
{ "inputName": "temperatureInput",
"inputDescription": "Temperature sensor unit data.", "inputDefinition": {
"attributes": [
{ "jsonPath": "sensorId" }, { "jsonPath": "areaId" },
{ "jsonPath": "sensorData.temperature" } ]
} }
Response:
{ "inputConfiguration": { "status": "ACTIVE",
"inputArn": "arn:aws:iotevents:us-west-2:123456789012:input/temperatureInput",
Background
"creationTime": 1557519707.399, "inputName": "temperatureInput",
"inputDescription": "Temperature sensor unit data."
} }
Notes
• The 'sensorId' isn't used by an example detector instance to control or monitor a sensor directly.
It's automatically passed into notifications sent by the detector instance. From there, it can be used to identify the sensors that are failing (for example, a sensor that regularly sends anomalous readings might be about to fail), or that have gone offline (when it's used as an input to an additional detector model that monitors the device's heartbeat). The 'sensorId' can also help identify warm or cold zones in an area if its readings regularly differ from the average.
• The 'areaId' is used to route the sensor's data to the appropriate detector instance. A detector instance is created for each unique 'areaId' received in any message. See the 'key' field in the 'areaDetectorModel' definition.