
Solution · Buildings
BAS - alarms that act.
Escalations, after-hours actions, offline-ready logic.
Facility teams tired of alarms that only make noise after the spike.
The challenge
The site is critical. The link is not.
Towers, shelters and remote plants still need alarms when the WAN drops - cloud-only setups go quiet at the worst time.
- 01
Link down, eyes go dark
When the network fails, the central team is blind and the site has no local alarms.
- 02
Wrong box for a small site
Full platform is overkill for a shelter; a cheap gateway is too weak for a harsh room.
- 03
Catch-up floods the network
When the link returns, raw backlog swamps the WAN and central storage.
Sound familiar?
By the numbers
Remote sites fail when the WAN fails - unless logic lives on-box.
Cloud-only monitoring goes quiet exactly when you need it.
Offline ≠ optional
towers, shelters and plants still need local alarms without WAN
*1
Wrong box
full Core is overkill for many 8–16 channel shelters
*2
Backlog storms
raw catch-up after outages can flood weak links
*3
- *1 Standard requirement in telecom / energy remote monitoring architectures - autonomous edge logic.
- *2 Sizing rationale for Sentrinel Edge-8 / Edge-16 vs Core appliances.
- *3 Store-and-forward with downsampling is the usual mitigation for intermittent cellular/MPLS.
How we solve it
Edge that works offline first.
Local alarms on site, then clean sync when the link returns - sized for 8 or 16 channels.
- 1
Alarms keep firing offline
Local logic on the appliance continues while the WAN is down.
- 2
Sized for the site
Pick 8 or 16 channels for the cameras and inputs you actually need.
- 3
Clean sync when the link returns
Buffer and send what matters - without flooding the network.
This is the simpler path.
ROI conversation
Keep the site honest when the link is not.
Uptime of monitoring - not just uptime of the asset.
Always-on
local decisions
Alarms continue on the appliance while offline.
Right-sized
8 or 16 channels
Buy the acquisition count you need - expand later.
Cleaner
sync after outage
Buffer and downsample instead of flooding the WAN.
Benefits assume Edge appliances are commissioned with local rules tested under simulated WAN loss.
How it works
From shelter to sync
- 01
Size the site
Channels, power, cellular and what must alarm locally.
- 02
Deploy Edge
Appliance, optional IO, local rules.
- 03
Prove offline
Pull the WAN in test - monitoring should continue.
- 04
Sync to Core/cloud
When ready, join the wider estate without re-architecture.
Ready to map step one?
What's in the package
Remote monitoring with a backbone.
Built for weak links - not demo Wi-Fi.
- Alarm rules and multi-step escalations
- After-hours and setpoint action templates
- Edge-local logic when the link is down
- Optional IO for dry contacts and relays
- Operator runbooks at handover
After go-live
What teams notice first
Actions before invoice surprises
Night-shift playbooks that fire
Works through weak WAN
Want outcomes like these on your site?
Keep the remote site honest.
Tell us channel count and link quality. We will recommend Edge-8 or Edge-16.
Built on
FAQ
Remote & edge sites - FAQ.
For portfolios where WAN is thin and trucks are expensive.
What if the link drops?
Store-and-forward and local recording keep the site useful. Events sync when the link returns instead of vanishing.
Power and enclosure?
Hardware choices (IO, Core, Edge) match cabinet reality. Discovery covers power budget, PoE and environmental limits.
How many sites before it pays off?
Even a handful of unmanned sites often justify the pattern once truck rolls or missed alarms are priced. We size from your map.
Can HQ see live video?
Yes within bandwidth policy - proxy and retention rules keep HQ views from crushing the WAN.
Who maintains firmware?
Handover includes update path and ownership. Managed options can be scoped if your team is thin.
Tell us the problem — we'll shape the solution.
A short discussion. No pitch theater. We listen, then compose a clear path.