.png)
Centralised Multi Site Facility Monitoring with iMonnit for Multiple Gateways and Support
Facility alarms are only useful when the right person sees them, understands them, and can act before a small fault becomes an expensive outage. That gets harder when assets are spread across several locations, each with its own rooms, plant, refrigeration, water systems, access points, and local contacts.
A centralised iMonnit setup brings those sites into one account. Each site can run its own gateway and sensors, while managers, service teams, and authorised users view alarms, histories, and device status from one place.
For organisations with multiple facilities across Australia, this approach can reduce blind spots, make alarm handling more consistent, and keep support easier to manage over time.
Why multi-site monitoring needs a central account
Single-site monitoring is fairly simple. A sensor reports a condition, a gateway sends the data to the cloud, and an alarm goes to the nominated people.
Multi-site monitoring adds more moving parts:
Different sites may have different gateway types or network access.
Local managers may only need visibility for one location.
Maintenance staff may cover several locations.
Alarm rules need to stay consistent across similar assets.
New sensors may be added as facilities change.
Support teams need a clear record of faults, changes, and device health.
Without a central structure, each site can become its own small system. That may work at first, but it creates problems as the network grows. Alarm settings drift. User access becomes messy. Someone leaves the organisation and still has access. A new site gets built differently from the last one. When an issue occurs, the team spends time working out which account, device, or contact list applies.
A centralised iMonnit account helps solve this by giving the whole monitoring system one consistent framework. Each gateway and sensor can still sit at its physical site, but the account structure, alarm templates, users, and support records remain easier to govern.
How gateways fit into a multi-site iMonnit system
In a typical iMonnit layout, sensors send data to a local gateway, and the gateway sends that data to the iMonnit cloud platform. For a multi-site facility network, each location usually has at least one gateway.
That gateway acts as the site’s communication link. It is the point that connects local sensor readings to the central account.
Common gateway planning questions include:
Where will the gateway be installed?
What network connection is available at the site?
Which sensors need to report through that gateway?
Are there areas with thick walls, metal enclosures, cool rooms, or long distances?
Does the site need more than one gateway for coverage?
Who can access the gateway for testing or replacement?
The best gateway plan starts with the physical site. Drawings help, but they rarely tell the full story. Plant rooms, switchboards, freezer panels, tanks, pumps, risers, sheds, and roof spaces can all affect range and access. A short site check before installation can prevent many commissioning problems later.
For facilities spread nationwide, the goal is not to make every site identical. The goal is to make every site consistent where it matters. That means using the same naming rules, alarm logic, user roles, and commissioning checks, while allowing enough flexibility for local conditions.
Standard alarm templates keep sites consistent
Alarm fatigue is a real operational problem. If alarms are too sensitive, people start ignoring them. If alarms are too loose, faults may go unnoticed until damage has occurred.
Standard alarm templates help by giving repeatable alarm rules for common sensor types and asset categories. Instead of building every alarm from scratch, the system can apply agreed templates across similar assets.
For example, a facilities team might use templates for:
Asset or condition | What the template may define | Why it helps |
Cold storage temperature | High and low limits, delay before alarm, escalation contacts | Reduces false alarms during normal door openings |
Plant room water leaks | Alarm when water is detected, immediate notification | Supports fast response to leaks near critical equipment |
Room temperature | Acceptable operating range and alert delay | Helps spot HVAC faults across comparable rooms |
Door activity | Open duration before alarm | Separates normal access from a door left open |
Battery status | Low battery alert rules | Helps schedule maintenance before data is lost |
Gateway offline status | Notification when a site stops reporting | Flags network or power problems early |
Templates should reflect the way the facility actually operates. A freezer, communications room, medical fridge, archive room, pump station, and amenities block do not need the same alarm response.
Good templates answer three questions.
What condition matters
The alarm should relate to a condition that requires action. A reading outside the ideal range is not always an alarm. For instance, a cool room may briefly rise when stock is loaded. A plant room may warm during a hot afternoon but remain within acceptable limits.
The alarm needs to separate normal behaviour from a genuine fault.
How long the condition must last
Time delays can reduce nuisance alarms. A door open for 30 seconds may be normal. A door open for 20 minutes may need a response. A temperature spike that lasts a few minutes may be harmless. A steady rise over a longer period may indicate equipment failure.
Delay settings should be chosen with care. Too short, and the system becomes noisy. Too long, and the warning may arrive late.
Who receives the alarm
A national facilities manager does not need every minor alert from every site. A local supervisor may need site alarms, while an external service provider may need specific equipment faults.
Templates should include escalation thinking, not just thresholds. If the first contact does not respond, the next person or team should know what to do.
User permissions protect the system
Multi-site monitoring creates a clear access challenge. People need enough access to do their work, but not so much that they can accidentally change alarm rules or view sites they do not manage.
A well-planned iMonnit account should use defined user roles. The exact setup will vary, but the principle is simple: give users access based on responsibility.
Common access levels may include:
Full account administration for the system owner or authorised lead.
National visibility for senior facilities or compliance staff.
Site-level visibility for local managers.
Technical access for installers and support teams.
Read-only access for people who only need to check status.
Temporary access for commissioning or project work.
Permissions should be reviewed whenever staff change roles, contractors finish work, or a site changes hands. Access control is not a one-time setup task. It is part of keeping the monitoring system reliable and secure.
Strong user management also helps during support. When an alarm rule changes or a device is moved, the account history and user structure should make it easier to understand what happened.
Installation and commissioning make the monitoring reliable
A solid design can still fail if installation is rushed. Sensor location, mounting method, gateway placement, naming, and alarm testing all matter.
For multi-site work, installation should follow a repeatable process. This helps every site meet the same standard, even when different buildings have different layouts.
A practical installation and commissioning process usually includes the following steps.
Confirm the monitoring scope
Before hardware is installed, the team should confirm what needs to be monitored at each site. This may include temperature, humidity, water leaks, door status, equipment runtime, air movement, or other available sensor types.
The scope should also define what is not being monitored. This avoids confusion later when someone assumes a room, fridge, tank, or plant item is included.
Check gateway location and communication
The gateway needs power and a suitable communications path. It also needs to be positioned so sensors can report reliably.
Commissioning should confirm that the gateway is online and that each sensor reports at expected intervals. If a sensor has weak communication, it is better to fix the placement during commissioning than after the first missed alarm.
Label and name devices clearly
Device names should be readable to someone who has never visited the site.
A weak name might be:
`Temperature Sensor 4`
A useful name might be:
`VIC Geelong Site, Cold Room 2, Return Air Temperature`
Clear naming saves time during alarms. It also helps support teams troubleshoot faults without guessing where a device is installed.
Apply standard alarm templates
Once devices are reporting, the agreed alarm templates can be applied. This keeps rules consistent across similar assets and reduces manual setup errors.
Any site-specific changes should be recorded. If a threshold differs from the standard, the reason should be clear.
Test alarm delivery
Commissioning should include real alarm tests where practical. This confirms that notifications reach the right people and that the recipients understand what action is expected.
Testing should cover more than the sensor reading. It should check the whole path:
Sensor detects condition.
Gateway reports the reading.
iMonnit recognises the alarm state.
Notification is sent.
The correct person receives it.
The response process is understood.
Record the final setup
A commissioning record should include device names, locations, gateway details, alarm settings, user access, and any exceptions.
This record becomes valuable later when hardware is replaced, a site expands, or support is needed.
A clear account structure reduces long-term risk
The more sites you have, the more important structure becomes. A centralised monitoring account should be easy to navigate, even after several years of additions and changes.
Good account structure usually covers:
Site groups by state, region, business unit, or asset type.
Consistent device naming.
Standard alarm templates.
Documented user permissions.
Clear escalation lists.
Support notes for each site.
A change process for adding or removing devices.
This is where a central model performs better than separate unmanaged accounts. If a team needs to compare alarm history across sites, review gateway status, update user access, or roll out a new alarm rule, a central account makes the work easier.
It also supports better governance. For example, if a facilities team decides all water leak sensors should send immediate alerts to both the local manager and after-hours maintenance provider, that rule can be managed as part of a standard approach rather than left to each site to interpret.
Annual support keeps the system useful after handover
Monitoring is not finished on the day the sensors go live. Buildings change. Staff change. Network settings change. Batteries run down. New risks appear. Old alarm rules may need adjustment.
An annual support agreement helps keep the system maintained and useful.
Support can include:
Reviewing gateway and sensor status.
Checking alarm templates and escalation lists.
Updating user permissions.
Helping add or remove sensors.
Assisting with gateway communication issues.
Reviewing recurring alarms.
Supporting replacement devices.
Keeping commissioning records current.
Providing remote guidance for site teams.
For larger networks, an annual review can be especially helpful. It gives the organisation a set point to ask practical questions.
Are all gateways reporting as expected? Are users still current? Are alarm thresholds still right for the assets? Are there sites with repeated nuisance alarms? Are there gaps where new monitoring would reduce risk?
The answer does not always need to be more hardware. Sometimes the best improvement is a cleaner alarm template, a clearer device name, or a corrected escalation path.
What a good multi-site monitoring plan should include
A complete plan for Centralised Multi Site Facility Monitoring with iMonnit for Multiple Gateways and Support should cover both the technology and the operating model.
The hardware matters, but the process matters just as much. A sensor can detect a problem, but people still need a clear path to act.
A practical plan should include:
Planning area | Key decision |
Site structure | How sites, gateways, and sensors will be grouped in iMonnit |
Gateway design | How each location will connect and report data |
Sensor selection | Which conditions need monitoring at each site |
Naming rules | How devices will be labelled and identified |
Alarm templates | Which alarm settings will apply to each asset type |
Escalation paths | Who receives alarms during and after business hours |
User permissions | Who can view, edit, administer, and support the account |
Commissioning | How each site will be tested before handover |
Documentation | What records will be kept for future support |
Annual support | How the system will be reviewed and maintained |
This approach gives the monitoring system a clear foundation. It also makes growth simpler. When a new site comes online, the team does not need to reinvent the setup. They can follow the existing structure, adapt it to the building, commission it properly, and bring it into the central account.
The takeaway
Multi-site facility monitoring works best when it is designed as one managed system, not a collection of separate alarms. iMonnit can support multiple gateways and sensors across different locations, but the value comes from the way the account is built, governed, commissioned, and supported.
A central account, standard alarm templates, clear user permissions, careful installation, and an annual support agreement all work together. They help alarms reach the right people, keep settings consistent, and make the system easier to maintain as facilities change.
For a small number of sites, this structure prevents future disorder. For a large network, it becomes essential.
