How to Commission an iMonnit Alarm Without Accidentally Operating Equipment
An alarm is ready for handover when the intended people can receive it, understand the message and take the agreed action. A rule that looks correct on screen is only part of that chain. For an iMonnit installation, separate the notification test from the wider site acceptance test, and review every action attached to a rule before sending a test.
Start by checking what the test can operate
Monnit documents that a rule test can trigger its configured notification behaviour, including connected control devices and system actions as well as messages. Treat the test as an operational change. Do not use an unreviewed production rule as a convenient way to check an email address.
Before testing, the responsible site representative should identify the rule, its trigger devices, recipients and attached tasks. Check whether an output could affect a pump, valve, heater, audible alarm or another process. Where such actions exist, use the site's approved testing and isolation procedure and a competent person. Do not bypass a safety function to simplify the test.
Write a small acceptance record
Use one record per alarm function. Include the asset name and location, sensor identity, rule name, intended notification channels, primary contact, backup contact and the site-approved response. Record the software and account context so that somebody reviewing the result later knows which installation was tested.
Define the expected result before starting. For example: the designated maintenance contact receives a clearly labelled test email for the correct cold-room sensor, can identify the site and confirms receipt. This is a proposed acceptance criterion, not a manufacturer-guaranteed delivery time or a prescribed temperature limit.
Run the notification test deliberately
Notify affected recipients that an authorised test is about to occur. In iMonnit, open Rules, select the relevant rule and use Send Test in its Rule Information panel. A trigger device and recipient must be assigned. Inspect Rule History and its status results, then obtain confirmation from the receiving person. Follow Monnit's current instructions if the test reports an error.
Record both the portal result and the recipient's result. A message reported as sent is not the same evidence as a person receiving and correctly interpreting it. Check junk folders, mailbox rules and recipient details when those two results differ. Avoid repeatedly pressing the test control while investigating, because that can make the event history and recipient feedback difficult to interpret.
Prove the response separately
The site's acceptance plan may also require evidence that an actual measured condition activates the intended rule. Plan that as a separate controlled test. Use a permitted simulator or a safe, documented process agreed by the site; do not warm valuable stock, remove protection from operating machinery or create a hazardous condition merely to produce an alarm.
Use a simple table in the handover record: test identifier, expected condition, observed event, recipient confirmation, response owner, result and corrective action. If an alarm reaches the wrong contact or describes the wrong asset, record a failed test and correct the configuration before signing off.
Leave the installation ready for the next event
After the test, review whether the rule needs to be disarmed and rearmed under Monnit's documented procedure. Verify the required final state rather than assuming that acknowledging a test leaves every rule ready for a new escalation. Remove temporary recipients and test-only changes through the site's change process, then retain the successful test record.
Revisit this record when recipients, shifts, equipment or rules change. These are commissioning recommendations, not a statement that an installation meets a particular safety, food, pharmaceutical or quality standard. Those requirements need a separate assessment against the actual application.
For help defining an alarm test, send ProSense Instruments the sensor model, rule purpose, recipient arrangement and any connected control actions. Keep account passwords and device security keys out of ordinary enquiry emails.
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