Understanding Sensor Heartbeats Aware States and Assessments
Updated: 2 days ago
A wireless sensor has two jobs that often compete with each other. It needs to report important changes quickly, and it needs to protect its battery for as long as possible. Monnit Sensors handle that balance through Heartbeats, Aware States, Assessments, and Rearm behavior.
These settings decide when a sensor talks to the gateway, when it stays quiet, and when it is ready to report a condition again. Once those ideas are clear, it becomes much easier to choose the right settings for a door contact, water detector, temperature sensor, motion sensor, or dry contact sensor.
Monnit Sensors do not all communicate the same way
Monnit Sensors use radio communication to send data to a gateway. That radio is one of the main sources of power use inside a battery-operated sensor. If the sensor streamed data nonstop, the battery would drain much faster.
Instead, sensors transmit strategically.
There are two common radio behavior patterns:
Event sensors
Interval sensors, also called reading-type sensors
Both types use Heartbeats, but they use them differently.
Event sensors report a change when it happens
Event sensors are built around a clear state change. They are often best understood as yes or no sensors.
A door is open or closed. Water is detected or not detected. Motion is detected or not detected. A dry contact is open or closed.
Common examples of event sensors include:
Water Detection
Door/Window
Motion
Dry Contact
When an event sensor detects the condition it is watching for, it can report that condition right away. This immediate reporting is tied to the sensor entering what Monnit calls the Aware State.
For example, a door/window sensor does not need to wait until the next scheduled Heartbeat to report that a door has opened. The open condition is the event. The sensor detects it and sends the change.
That immediate message is what makes event sensors useful for security, access monitoring, leak detection, and other situations where timing matters.
Event sensors still use Heartbeats. The Heartbeat tells the system that the sensor is alive and able to report. Without that routine check-in, the platform would have less confidence that the sensor is still online, powered, and in range.
Interval sensors report on a schedule
Interval sensors work differently. They wake up at a set time, take a reading, transmit the data, and then go back to sleep until the next interval.
Common examples of interval sensors include:
Temperature
Humidity
Voltage
Pressure
These sensors are not usually reporting a simple yes or no state. They collect measured values. A temperature sensor may report 71.4°F. A humidity sensor may report 42%. A voltage sensor may report a measured voltage.
The key difference is timing. An interval sensor usually reports based on its configured Heartbeat. It does not constantly stream every tiny change in the measured condition.
That is by design. Most measured conditions do not require second-by-second reporting. In many environments, a reading every 15, 30, 60, or 120 minutes gives enough visibility while protecting battery life.
Heartbeats are the regular check-in
A `Heartbeat` is the scheduled interval at which a sensor sends a transmission to the gateway.
Every sensor has a Heartbeat, even if it is an event sensor that can report immediately. The Heartbeat is the sensor’s routine check-in. It lets the system know the sensor is still active, still has power, and is still communicating.
For interval sensors, the Heartbeat is also when the sensor normally takes and sends a reading.
For event sensors, the Heartbeat is not the main way an event gets reported. The event message happens when the condition is detected. The Heartbeat supports the system by confirming that the sensor is still functioning between events.
Monnit Sensors are assembled with a default Heartbeat of 120 minutes. That setting can be changed, but account type and sensor settings affect how low the Heartbeat can go.
A shorter Heartbeat means the system hears from the sensor more often. That can be helpful when you want closer monitoring or faster confirmation that a sensor is still online.
A longer Heartbeat uses less radio time. That usually helps protect battery life.
The practical tradeoff is simple:
Shorter Heartbeat | Longer Heartbeat |
More frequent check-ins | Fewer transmissions |
Faster routine updates | Lower radio use |
More power consumption | Longer expected battery life |
Better for active monitoring | Better for stable conditions |
The right Heartbeat depends on the sensor’s job. A freezer temperature sensor may need more frequent readings than a room humidity sensor in a stable storage area. A door sensor may not need a short Heartbeat because it can still send the open or close event immediately.
Basic and Premiere accounts affect available Heartbeat settings
iMonnit account type matters when setting Heartbeats.
A free Basic iMonnit subscription requires a minimum Heartbeat of 120 minutes. In practical terms, that means Basic accounts cannot set a sensor to check in more frequently than every 120 minutes.
To use a minimum Heartbeat as frequent as 10 minutes in iMonnit, a paid iMonnit Premiere subscription is required.
iMonnit Premiere also includes Advanced Sensor Settings. These include settings such as:
`Aware State Heartbeat`
`Assessments`
Those advanced settings are not available to iMonnit Basic accounts.
This distinction matters when configuring sensors for higher-risk applications. If a site needs more frequent routine updates or more control over sensor behavior while a condition is active, the account level may determine whether those settings are available.
The Aware State is the sensor’s active condition state
The `Aware State` is the operating state that allows a condition to be reported immediately when it is detected.
Think of it as the sensor saying, “The condition I watch for is happening now.”
For a door/window sensor, the Aware State may be tied to the door opening. For a water detection sensor, it may be tied to the presence of water. For a dry contact sensor, it may be tied to the contact changing to the configured trigger position.
The Aware State matters because it changes how the sensor behaves. Instead of waiting only for routine Heartbeats, the sensor can send a message when the condition occurs.
A common sequence looks like this:
The sensor is in its normal state.
The watched condition occurs.
The sensor enters the Aware State.
The sensor transmits the condition to the gateway.
The system records the event and can process notifications based on account and alert settings.
The sensor remains aware until the condition clears or until its rearm behavior allows it to report again.
The Aware State is one reason event sensors can be useful even with a longer standard Heartbeat. A door opening does not have to wait for the next two-hour check-in if the sensor is configured to report the event as it happens.
Aware State Heartbeats can change reporting while a condition is active
A standard Heartbeat controls the regular reporting interval. An `Aware State Heartbeat` applies while the sensor is in the Aware State.
This setting is useful because an active condition may deserve different reporting behavior than a normal condition.
For example, if a water sensor detects water, a site may want more frequent updates while the sensor remains wet. If a door is left open, the system may need ongoing confirmation that the sensor is still in that state. If a dry contact is tied to equipment status, an active alarm condition may call for closer tracking until the condition clears.
An Aware State Heartbeat does not mean the sensor streams constantly. It still uses timed transmissions. The difference is that the timed behavior can change while the sensor is aware.
That gives more control without sacrificing the battery as quickly as continuous radio use would.
A practical setup might use:
A longer normal Heartbeat during stable operation
A shorter Aware State Heartbeat when a condition is active
Notifications that alert the right people when the condition first occurs
This approach keeps normal power use lower but increases visibility when something needs attention.
Assessments help confirm what the sensor is seeing
`Assessments` are part of the advanced settings available with iMonnit Premiere. In simple terms, an assessment is a check the sensor uses to evaluate the condition it is monitoring.
The value of assessments is confirmation. Some environments create brief changes, electrical noise, vibration, quick movement, or short-lived conditions that may not deserve the same treatment as a confirmed event.
Depending on the sensor type and configuration, assessment behavior can help decide how the sensor evaluates a state before it reports or changes status. More checking can reduce unwanted reports in some applications, but it can also use more power or add delay.
That tradeoff matters.
For a water detection sensor, fast reporting may be the priority. If water is present, the response should usually happen quickly.
For a dry contact tied to noisy equipment, some confirmation may be helpful if the contact can bounce or flicker.
For a motion sensor, the best setting may depend on the space. A busy space and a quiet storage area may not need the same behavior.
Good assessment settings match the risk of the condition and the normal behavior of the environment.
Ask three questions when thinking through assessments:
Is a short-lived condition meaningful, or should it be ignored?
Is speed more important than confirmation?
Will more checking reduce false reports without causing missed events?
The answer is not always the same from one sensor to another.
Rearm controls when the sensor is ready to report again
`Rearm` describes how the sensor becomes ready to report another event after it has already reported one.
This is one of the most useful ideas to understand with event sensors. Without rearm behavior, a sensor could send repeated messages for the same ongoing condition. That would waste battery and could create alert fatigue.
The sensor needs a way to know when the first event is over and when the next event should count as new.
A door/window sensor is easy to picture:
Door is closed.
Door opens.
Sensor reports the event.
Door remains open.
Sensor should not keep reporting “opened” over and over as if each message were a new open event.
Door closes.
Sensor is rearmed.
The next open event can be reported.
A motion sensor may rearm after motion is no longer detected for the needed period. A water detection sensor may rearm once the contacts are dry. A dry contact sensor may rearm when the contact returns to its normal state.
Rearm helps the system separate one long event from multiple separate events.
That distinction matters in real use. A door held open for 20 minutes is one condition that remains active. A door opened and closed five times is five separate events. Rearm behavior helps the sensor treat those cases correctly.
How the settings work together
These settings are easier to understand when viewed as a sequence rather than as separate menu items.
A sensor spends most of its time asleep to save power. Its radio stays quiet until it has a reason to transmit. That reason may be a scheduled Heartbeat, an event, or an active Aware State behavior.
For an interval temperature sensor, the routine may be simple:
Sleep.
Wake at the Heartbeat.
Take a temperature reading.
Send the reading.
Return to sleep.
For an event-based door sensor, the routine may look different:
Sleep while monitoring the door state.
Detect the door opening.
Enter Aware State.
Transmit the event.
Continue reporting as configured while aware.
Rearm after the door closes.
Continue routine Heartbeats to confirm the sensor is active.
For a water detection sensor, the sequence may be urgent:
Monitor for water.
Detect water.
Enter Aware State.
Send the alert condition.
Use Aware State Heartbeats if configured.
Rearm when the sensor is dry again.
Each setting answers a different question:
Setting | The question it answers |
Heartbeat | How often should the sensor check in during normal operation? |
Aware State | What condition should cause immediate reporting? |
Aware State Heartbeat | How often should the sensor report while the condition remains active? |
Assessments | How should the sensor confirm or evaluate what it detects? |
Rearm | When is the sensor ready to report the next separate event? |
How to choose practical settings
Start with the purpose of the sensor. A sensor watching for water under equipment has a different job than a humidity sensor in a storage room.
Use these guidelines as a starting point.
Use shorter Heartbeats when routine readings matter
A shorter Heartbeat makes sense when each reading has value and conditions can change enough between readings to affect decisions.
Good candidates include:
Temperature monitoring for sensitive areas
Voltage readings on equipment
Pressure monitoring where changes matter
Humidity monitoring in controlled storage
Remember that shorter Heartbeats mean more transmissions. More transmissions use more battery.
Use longer Heartbeats when event reporting is the main value
A door/window sensor or water detection sensor may not need a very short standard Heartbeat if it can report the event immediately.
The Heartbeat still matters because it proves the sensor is alive. But the event itself does not have to wait for the Heartbeat.
This is often where users confuse Heartbeats with event reporting. Heartbeats are routine check-ins. Event messages happen because the sensor detects the condition.
Use Aware State Heartbeats for active problems
If a condition deserves closer visibility while it remains active, use the Aware State Heartbeat where available.
This can be useful for:
Water still present
Door still open
Contact still in alarm state
Motion-related monitoring, depending on the application
Set it only as frequent as the situation requires. Very frequent reporting may not add much value if no one is acting on each update.
Use Assessments to balance speed and confirmation
If false reports are costly or common, assessments may help. If immediate reporting is more important, avoid adding unnecessary delay.
A good rule is to match assessments to the environment. Stable environments often need less filtering. Noisy environments may need more confirmation.
Use Rearm to prevent repeat alerts from one condition
Rearm behavior keeps alerts meaningful. It helps prevent one ongoing event from being treated as many new events.
Check rearm behavior carefully for sensors that can stay in an active state for a long time, such as water detection, door open, or dry contact alarm conditions.
The main takeaway
Monnit Sensors save battery by avoiding constant radio transmission. They use Heartbeats for scheduled check-ins, Aware States for immediate condition reporting, Assessments for condition evaluation, and Rearm behavior to decide when a new event can be reported.
For Basic iMonnit accounts, the minimum Heartbeat is 120 minutes. For a minimum Heartbeat as frequent as 10 minutes and access to Advanced Sensor Settings such as Aware State Heartbeats and Assessments, iMonnit Premiere is required.
The best configuration is not always the shortest interval or the most sensitive setting. The best configuration matches the sensor’s job. Use faster reporting where timing matters, use confirmation where false reports are likely, and use rearm behavior so each alert represents a real new event.
Need help with your application?
ProSense Instruments — explore instruments, sensors, data loggers and test equipment.
ProSense Solutions — discuss complete monitoring and automation systems.
ProSight Software — explore cloud dashboards, alarms and reporting. Device integration must be confirmed for your application.
Instrument enquiries: sales@prosenseinstruments.com.au | 1800 560 854
Project enquiries: sales@prosense.com.au. Software enquiries: info@prosightsoftware.com.
Comments