Trigger Sensors Aware State - State Change

Aware State and Trigger Sensors

Monnit has two general categories of sensors. These are Interval Sensors and Trigger Sensors. Trigger sensors have an “always listening” operation in which they monitor for a change, where as Interval Sensors take readings in the background and report immediately when a reading is detected outside of the Aware State Threshold on an Assessment (see this article for detailed information on this operation). A trigger sensor still uses the Aware State operation in which an Aware Reading is reported to the gateway, and the gateway immediately transmits the reading to the iMonnit software. Standard readings are not immediately reported to the portal, but rather kept with the gateway until the gateway’s Heartbeat.

In other words, Aware State readings are reported by the gateway to the software immediately when they occur (with “On Aware Message” also known as “Force Transmit on Aware” set to “Trigger Heartbeat”/enabled which is the default configuration for gateways). However, standard non-Aware messages are transmitted to the gateway, and queued for delivery to the software until the gateway’s Heartbeat.

Aware on State Change

Trigger sensors have the ability to change the kind of physical condition that it considers an Aware message. By default, this is Aware on Open/Motion/Water/etc. However, you can configure the Aware State to be Aware on Closed/No Motion/No Water/etc., or State Change. If you configure the sensor to be Aware on State Change, this means all readings where the sensor goes from reading one state to another (example, Open ? Closed or Closed ? Open), the sensor will enter it’s Aware State on the readings where the state has changed. That reading will therefore be transmitted from the gateway to the iMonnit Online portal immediately when it is received by the gateway.

How the Aware State configuration of Trigger Sensors can affect Rules

Since Aware readings are essentially transmitted from sensors to the iMonnit software when the event occurs, but non-Aware readings are queued by the gateway and delivered on the gateway’s Heartbeat, there can be a delay when a non-Aware even occurs and when a corresponding Rule is triggered.

For example, consider an Open/Close sensor which has the default Enter Aware on: Open configuration. This means that any time the sensor has an Open reading, it is an Aware reading, and therefore shows in the iMonnit software immediately when the “open” event is detected. On the other hand, when the sensor detects a “closed” event, that reading is not Aware, and is transmitted by the sensor to the gateway, and the gateway queues the reading for delivery on the gateway’s Heartbeat as demonstrated in the timeline below.

Gateway Configuration

Gateway Type: Alta Ethernet Gateway 4

Heartbeat: 5 minutes

Force transmit on Aware: enabled

Number of sensors: 1 Open/Close

Sensor Configuration

Sensor Heartbeat: 20 minutes

Aware State Heartbeat: 10 minutes

Aware State: Open

Re-arm Time: 5 seconds

Note: Sensor generally reads Open

Rule Configuration: Send email on Closed reading with no Delay, default 60 min Snooze

1:21 PM > (Door is already open) Gateway checks in on Heartbeat (next scheduled check in 1:26 PM)

1:23 PM > Sensor checks in on scheduled Heartbeat reading Open (Aware reading) - No Rule triggered - next scheduled Check in 1:33 PM

1:23 PM > Gateway checks in and transmits Open reading (prior to scheduled Heartbeat since Open is an Aware reading) - next scheduled Check in 1:28 PM

1:28 PM > Gateway checks in on scheduled Heartbeat (no sensor readings to transmit) - next scheduled Check in 1:33 PM

1:33 PM > Sensor checks in on scheduled Heartbeat reading Open (Aware reading) - No Rule triggered - next scheduled Check in 1:43 PM

1:33 PM > Gateway checks in and transmits Open reading - next scheduled Check in 1:38 PM

1:38 PM > Gateway checks in on scheduled check in (no sensor readings to transmit) - next scheduled Check in 1:43 PM

1:40 PM > (Door is physically closed) Sensor checks in with gateway reporting Closed (non-Aware reading, so gateway queues the Closed message) - when reported to software Closed will trigger Rule to be sent - next scheduled check in 2:00 PM

1:43 PM > Gateway checks in on scheduled Heartbeat and transmits Closed reading - Rule is triggered by Closed reading and sent by software - next scheduled check in 1:53 PM

1:48 PM > Gateway checks in on scheduled Heartbeat (no sensor readings to transmit) - next scheduled Check in 1:53 PM

1:53 PM > Gateway checks in on scheduled Heartbeat (no sensor readings to transmit) - next scheduled Check in 1:58 PM

1:58 PM > Gateway checks in on scheduled Heartbeat (no sensor readings to transmit) - next scheduled Check in 2:03 PM

2:00 PM > Sensor checks in on scheduled Heartbeat reading Closed (non-Aware reading) - next scheduled Check in 2:20 PM

2:03 PM > Gateway checks in on scheduled Heartbeat and transmits Closed reading - Rule still alerting on Closed reading (though it will not send until the Snooze timer) - next scheduled check in 2:08 PM

2:07 PM > (Door is physically opened) Sensor checks in with gateway reporting Open (Aware reading) - next scheduled check in 2:17 PM

2:07 PM > Gateway checks in and transmits Open reading (prior to scheduled Heartbeat since Open is an Aware reading) - next scheduled Check in 2:12 PM

2:07 PM > Rule is Disarmed/Rearmed (reset) by software

As you can see in the above example, the Rule notification triggered by the Closed reading was not sent immediately upon the event physically occurring since the gateway queued the reading for delivery upon the gateway’s scheduled Heartbeat. This contrasts with the Open reading which causes the gateway to deliver the reading to the portal immediately since it is an Aware reading. You can see how this configuration is key to triggering Rules promptly based on events in the physical world.

On the other hand, if the Aware State would have been configured as State Change, both the Open and Closed readings would have been transmitted to the portal immediately from the gateway. Therefore the Closed reading would have triggered the Rule notification to send promptly upon the “closed” event occurring physically.

Conclusion

Understanding the State Change configuration of Trigger Sensors is key to seeing data promptly displayed in the software and promptly triggering Rules. When used strategically, this feature can help you manage data points efficiently while still being notified promptly when events occur in the physical world. Feel free to contact support@monnit.com with related questions.