Monnit Assessments Are Not History Points: Verify the Retained Reading Interval
A maintenance team expects a temperature reading every ten minutes because the sensor assesses conditions every ten minutes. Its export contains only one normal reading every forty minutes. Increasing the number of assessments does not necessarily add historical data points: in Monnit’s documented interval-sensor behaviour, normal intermediate assessments can be discarded.
Before treating the sparse export as a radio fault, separate the requirement to detect an excursion from the requirement to retain a routine history. Both matter, but they need different evidence during commissioning. A system can detect a threshold crossing as configured while still providing fewer normal historical readings than the site expected.
Original ProSense engineering illustration. Equipment and plotted relationships are conceptual, not a live installation or software screenshot.
Key takeaways
An assessment and a retained historical record are separate events. Verify normal history in an export and detection in an authorised condition-change test.
Start with what an assessment retains
Monnit’s Assessments per Heartbeat explanation states that intermediate samples check the Aware State threshold. If the sample does not breach that threshold, it is discarded and cannot later be retrieved. An assessment is therefore not a hidden historical record waiting to appear in an export.
The manufacturer separately explains sensor and gateway Heartbeats. A sensor Heartbeat governs routine communication with its gateway, while the gateway has its own upload timing. Use the actual settings and received records to establish the normal history interval; do not substitute the assessment interval.
The pictured Monnit battery-powered wireless temperature sensor is an ALTA ambient temperature device. Its catalogue photograph identifies the equipment being discussed; it does not establish the recording settings, account features or performance of a particular installed system.
Write two separate acceptance requirements
First specify the detection requirement: what change matters, how long it may persist before detection is needed, and how the response will be checked. Then specify the history requirement: the longest acceptable interval between retained normal readings, the export needed and how missing readings will be recognised. Avoid writing only “sample every ten minutes”, because sampling, reporting and retention can describe different operations.
Ask the application owner to approve those requirements before setting intervals. A report intended to explain gradual room-temperature drift may need a different retained history from a simple out-of-range notification. A critical storage application needs an application-specific monitoring and response plan; these illustrative settings are not medical, food-safety or regulatory acceptance criteria.
Original workflow diagram summarising the checks in this guide. It does not establish a device specification or a customer test result.
Worked example: four assessments are not four history points
Hypothetical example: a compatible interval sensor is configured with a forty-minute normal Heartbeat and four assessments per Heartbeat. Its nominal assessment spacing is forty divided by four, or ten minutes. Assume conditions remain normal throughout, communications work and no other reporting trigger applies.
The team should not expect four retrievable normal readings in each forty-minute interval merely because there were four assessments. The intermediate checks can serve threshold detection without becoming saved data. If ten-minute normal history is required, the team must investigate an appropriate routine reporting configuration and verify it in the actual export.
This example describes normal operation. Entry to the Aware State and subsequent reporting have their own settings and behaviour. Do not extend the example into a promise that every assessment during an active excursion will be retained either. Check the exact sensor, firmware and software configuration against the manufacturer’s operating guidance.
Run a history test as well as an alert test
Save the starting configuration and identify the sensor, gateway, software edition and time zone. Confirm which settings are actually available and have reached the sensor. Plan the test in a non-critical application or an approved test arrangement so production stock and equipment are not exposed to an unnecessary excursion.
For the normal-history test, keep conditions within the configured normal range and observe several complete reporting intervals. Export the records. Compare their measurement timestamps, spacing and count with the written retention requirement. Allow for gateway upload timing; an upload that arrives later is different from a measurement that was never retained.
For the detection test, use a controlled, authorised condition change and record when the reference condition crossed the chosen threshold, when the sensor reported and when any notification arrived. Keep this evidence separate from the normal-history test. Passing one does not prove the other.
Interpret gaps before changing the system
A regular sparse history matching the normal Heartbeat is consistent with the intended reporting design. Irregular gaps, missing scheduled transmissions or records arriving in batches call for a different investigation. Review connectivity, upload behaviour and timestamps before drawing conclusions. A smooth chart line also does not prove measurements exist between its plotted points.
Monnit’s combined operating guide distinguishes interval sensors from event sensors and describes account-dependent settings. Check current feature availability rather than assuming every sensor or iMonnit account exposes the same controls. Increasing radio reporting also changes the battery-use trade-off; verify that the chosen configuration suits the maintenance plan.
Retain the final settings, test export and agreed history interval in the handover pack. For support, provide ProSense with the exact device details, existing intervals, a short timestamped export and the required retained-record interval. This makes the next discussion about evidence and requirements rather than an unexplained gap on a graph.
Diagnostic comparison
Observation | Next check |
Normal export is sparse | Compare retained timestamp spacing with the configured normal reporting interval. |
Alert test passes | Run a separate normal-history acceptance test. |
Records arrive in batches | Separate measurement time from upload timing. |
Recommended equipment / related solutions
Review the instrument or gateway discussed in this article. Confirm the exact supplied model and relevant configuration before ordering.
Discuss selection and application scope with ProSense technical services.
Send the model and diagnostic evidence through ProSense Instruments technical enquiries.
Need help with your application?
ProSense Instruments - discuss sensors and logging requirements. ProSense Solutions - plan the monitoring system. ProSight Software - explore dashboards and reporting. Device and gateway integration must be verified separately.
Instrument enquiries: sales@prosenseinstruments.com.au | 1800 560 854. Project enquiries: sales@prosense.com.au. Software enquiries: info@prosightsoftware.com.
Comments