Gateways

A gateway hears what tags and sensors broadcast and forwards it. It is also the anchor positioning is computed against, which is why where you put it matters far more than it looks like it should.

How many

One per area gets you presence: which zone something is in, roughly.

Three or more, spread out gets you a position in metres. Three is the point where trilateration becomes possible at all — below it, Omaya falls back to nearest-gateway presence, and the dots on the Live Monitor get coarse.

But count is not the whole story.

Both rooms have three gateways, and Omaya will happily trilaterate in both. Count is the requirement; spread is what makes the answer worth having. When you can only fit three, put them at the corners of the largest triangle the room allows.

Placement

Spread them, do not line them up. Three across one wall satisfies the counter and produces positions that slide along that wall. Three at the corners of the largest triangle the space allows is the same hardware doing a much better job.

High, clear and out of metal. Ceiling or high wall, away from lift shafts, plant rooms, metal ducting and anything that moves. A gateway behind a metal cabinet hears one side of the room.

Mind the floor above and below. Radio does not respect floors, and a gateway near a lightweight ceiling will hear tags on the next storey. That shows up as devices appearing on the wrong floor, which the floor-spillover filter exists to suppress — but a placement that avoids the problem beats a setting that filters it.

Mains where you can. Gateways are not low-duty devices.

Registering them

Register each gateway on Device → Gateway and assign it to its venue before you place it on the plan: the plan's Gateways panel lists what belongs to the venue so you can position it, and does not create anything.

Then place it — as close to where it physically hangs as you can manage — and, when you have all of them up, walk the space to solve their real positions. Placing by eye gets you close; the walk gets you right, and it is the difference between "somewhere on this floor" and "in this room".

Connecting one to Omaya

Every gateway needs the same four things in Omaya — a connector, the gateway registered by its identity, its place on the floor plan, and the devices it will hear registered — and its own settings on the gateway. Each has a guide:

Gateway	Radio	Guide
Dusun DSGW (DSGW090 and siblings)	Bluetooth	Dusun Bluetooth gateways
Dusun DSGW-200 locator	Bluetooth, angle of arrival	Dusun DSGW-200 locators
MOKO MKGW-mini, MK107, MKGW1/3	Bluetooth	MOKO MKGW Bluetooth gateways
Milesight UG56, UG65	LoRaWAN	Milesight UG56 and UG65
Any LoRaWAN gateway, through ChirpStack	LoRaWAN	ChirpStack
Anything else that speaks MQTT	any	Connecting a gateway over MQTT

Changing sensors' settings from Omaya also goes through a gateway. For Bluetooth sensors that is a Dusun gateway with Accept commands switched on; the other Bluetooth gateways only listen. For LoRaWAN sensors it is your network server: a Milesight UG56 or UG65 with its Downlink data topic set, or ChirpStack's MQTT integration. See Configuring devices from Omaya.

Checking one

The gateway list shows online state and when each last reported. One offline gateway explains an entire floor of missing data, so it is the first page to open when an area goes quiet — before suspecting anything cleverer.

Omaya tells every active administrator when a gateway goes down and again when it comes back, but only on the bell in the admin console and in the Omaya app's Alerts tab. Nobody is emailed or messaged unless a rule says so, so the failure worth guarding against is not "Omaya did not notice" but "nobody was looking at the bell". Being told when a gateway drops sets up a message that reaches someone who is not.

Being told when a gateway drops

At Northwind Tower the Level 3 gateway lost power on a Friday evening and Ravi Kumar, the Operations Lead, found out on Monday. Aisha Rahman, the Facilities Manager, wants the facilities on-call Telegram group told within twenty minutes, and a weekly record she can hold the electrical contractor to.

The alerts follow the change, not the state: one message when the gateway goes offline and one when it comes back, however long it stays down. Stale (heard 5 to 15 minutes ago) counts as up, so a late report is not an outage. The outage log does not depend on the alerts, which is why the Gateway Availability report is still right for an outage nobody was told about.

What Omaya does without being asked

Every minute Omaya works out each gateway's status from when it was last heard. You see it in the Connection column on Device › Gateway (/admin/manage/gateway).

Status	Bluetooth gateway	LoRaWAN gateway (registered by its EUI)	What it means
Online	heard in the last 5 minutes	heard in the last 30 minutes	Working
Stale	last heard 5 to 15 minutes ago	last heard 30 to 60 minutes ago	Late, not lost. Counts as up: nobody is told
Offline	silent for more than 15 minutes	silent for more than 60 minutes	An outage

A LoRaWAN gateway gets longer because it is only heard when one of its sensors sends; it has no heartbeat of its own.

The minute a gateway first shows Offline, four things happen, once:

What	Where it shows	Who
A Gateway offline notification	The bell in the admin console, and the Alerts tab of the Omaya app	Every active administrator of your organisation, whatever their role. There is no per-person opt-out, and it is not emailed
A System row	System › Activity Log, in the System lane and under Needs a look, and in the gateway's History	Anyone whose role can open the Activity Log
Gateway status rules fire	Whatever those rules' actions say: email, Telegram, SMS, a webhook	Only the people the rules name. None exist until you make one
The outage starts in the outage log	Device › Gateway (30 days column) and Reports › Gateway Availability	Anyone whose role can open them

If the floor now has fewer gateways up than positioning needs, and stays that way for 3 minutes, every active administrator also gets Positioning coverage degraded (and Positioning coverage restored once it has been back for 5 minutes). If the gateway is still silent 24 hours after its last packet and the Facility app is switched on, a high-priority work order titled Gateway offline — name (MAC) is opened in it, one per gateway. That last one can be switched off under Apps › Your apps › Facility, Work orders opened automatically, A gateway has been offline too long.

When the gateway is heard again, every active administrator gets Gateway recovered, the Activity Log gets a second System row (and the offline row says back online with how long it was out), the rules watching for Online fire, and the work order closes by itself unless someone has already started on it.

This is what arrives on the bell (the gateway's name and MAC are your own):

Gateway offline
Gateway "L3 East" (00:00:5E:00:53:2A) has stopped reporting. Last seen 16 minutes ago.

Gateway recovered
Gateway "L3 East" (00:00:5E:00:53:2A) is reporting again. It was flagged offline 2 hours ago.

"Flagged offline 2 hours ago" counts from the notification, which went out about 15 minutes after the last packet, so the outage was longer than that. Gateway Availability has the exact length.

Two kinds of gateway are never announced: one switched off on its row (Active off), and one inside its quiet hours (below).

Quiet hours: silence you expect

A gateway that is switched off with the lights every weekend is not having an outage. Tell Omaya, and it stops announcing it.

1. Open Device › Gateway (/admin/manage/gateway). Saving a change needs the Edit · Gateways permission.
2. Click the gateway's row, then Edit on the toolbar above the list. The edit panel opens on the right.
3. Click Advanced Settings near the bottom of the panel to open it.
4. Under Expected silence (quiet hours), tick the days it is off: for a weekend, Sat and Sun.
5. Set the two times either side of to. They start as 00:00 and 23:59, which is the whole day. For "off every night from 7 in the evening to 7 in the morning", tick every day and set 19:00 to 07:00: a window that ends before it starts runs past midnight, and belongs to the day it starts on. The times are on your organisation's clock.
6. Press Save at the foot of the panel.

Check it worked. Click the row and press View: the panel shows an Expected silence line with the days and times, and, while the window is on, says it is in quiet hours now. The Quiet now tile in the strip above the list counts the gateways that are inside their window at this moment.

Inside the window an offline gateway raises no notification, fires no Gateway status rule, and is left out of its floor's positioning count. If it is still silent when the window ends, it is announced then. The outage log still records it, and Gateway Availability leaves the quiet hours out of the time it counts.

To stop quiet hours, untick every day and save.

Getting an email, Telegram or SMS

The bell only reaches someone looking at it. To reach the on-call group, give the outage a Gateway status rule. For Telegram, WhatsApp or SMS the connector comes first: without an active one for that channel the action is skipped, and says so. Email needs none; with no SMTP connector it goes through Omaya's own mailer.

Step 1: the connector

The example is Telegram. Email and SMS are the same steps with the SMTP (Email) or SMS connector and that connector's own fields.

1. Open Connectors in the menu (/admin/connector). The page needs the View Config permission; setting up Telegram needs Telegram Connector. As shipped, Admin and Manager have both.
2. In Telegram, create a bot with @BotFather and copy the token it gives you. Add the bot to the on-call group and post any message in the group, so the bot has seen it.
3. Back in Omaya, press Add Connector. The panel says Select an integration to configure. Choose Telegram.
4. Leave Active switched on.
5. Name: something you will recognise in a list, such as Facilities on-call.
6. Bot Token: paste the token from @BotFather.
7. Default Chat ID is optional: it only fills in the test dialog, because each rule names its own chat. To find the group's ID, press Find chat IDs beside the box: it lists Chats your bot can see — click one to use it. Group IDs start with a minus sign.
8. Press Save.
9. Press Test Connection. In Send Test Telegram Message, enter the chat ID (or keep the default) and press Send. The group receives This is a test message from Omaya. If you received this message, your Telegram integration is working correctly.

Email without an SMTP connector. An email action goes out through your own SMTP connector when one is enabled, and through Omaya's own mailer when none is, so you can skip this step for email. Set one up when the email should come from your own domain. System › Usage shows which of the two sent each month's email.

Step 2: the rule

1. Open Rules in the menu (/admin/manage/rule) and press Add Rule. Saving a new rule needs the Create · Rules permission. The builder opens on the Flow view with a Watches box on the canvas and its panel open.
2. In the name box at the top, type Gateway offline: Level 3. Click an empty part of the canvas and, under Rule settings on the right, set Priority to High.
3. In the What this rule watches panel, set Watch to Venue and Which one to Level 3. Location covers every gateway on a whole site, and Gateway covers one.
4. Drag Condition from the Nodes palette on the left onto the canvas. In the panel set Check to Gateway status (in the Events group). The rule's Checked setting switches to Real-time and the panel says so. Operator is Equal to. Set Value to Offline.
5. Drag Action onto the canvas. Set Channel to Telegram. Chat ID: the group's ID from step 1. Message: what you want the group to read, for example the message in the table below.
6. Keep an In-App Alert as a second action if you want the firing on the bell with the rule's name (the built-in Gateway offline notification goes out anyway).
7. Click an empty part of the canvas. In the Checked card under Rule settings, leave Days with no day ticked and Hours empty. An outage outside those days or hours is not sent later: it is simply not sent.
8. Set Repeat at most every to 1 min. Each gateway keeps its own clock, so two gateways down together send two messages either way; a long interval here only hides the same gateway's next outage.
9. Check that On at the top is switched on, and press Save.

Field	What Aisha typed
Rule name	Gateway offline: Level 3
Watches	Venue: Level 3
Condition	Gateway status, Equal to, Offline
Action	Telegram, Chat ID -1001234567890, Message {{gateway_name}} on {{venue.name}} stopped reporting. Last heard {{gateway_last_seen}} (UTC).
Checked	Real-time
Repeat at most every	1 min

{{gateway_name}} is the gateway's name (its MAC if it has none), {{gateway_mac}} its MAC, and {{gateway_last_seen}} when it was last heard, in UTC. The group reads:

L3 East on Level 3 stopped reporting. Last heard 2026-10-09 19:42:10 (UTC).

Then make the second rule, for the all-clear: the same steps with the name Gateway back: Level 3, Value set to Online, and a message such as the one below.

{{gateway_name}} on {{venue.name}} is back.

The quick way in. On the builder's Card view, under Ready-made checks, the Gateway offline card sets the condition, Real-time, Repeat at most every 1 min, a name, High priority and an In-App Alert, then opens the Watches panel for you to pick the floor. Change or add the action to Telegram, email or SMS before saving.

Check it worked

1. On the Rules list both rules have On switched on and Checked reads as it happens.
2. On the Gateway back: Level 3 row press Run it now (the play button). It is checked at once against the floor as it is now; with every gateway up, Online is true and the group gets the message, with the gateway placeholder printed as it is, because no single gateway changed. That proves the connector, the chat ID and the rule. Test in the builder cannot help here: it does not replay gateway rules.
3. On Monitor › Live Monitor (/admin/monitor), the Rules tab has a row for that firing; its Telegram action says sent.
4. For the real thing, unplug a spare gateway for 20 minutes. The bell and the group are both told about 15 minutes after its last packet, and again when you plug it back in.

Seeing the history

On the gateway list. Device › Gateway has a 30 days column (outages alerted in the last 30 days), an Outages 7 d tile in the strip above the list, and Recent outages beside it, each with when it started and how long it lasted, or still down. Click a gateway and press View for its own line: N outages in 30 days, N h offline in total, last ….

The Gateway Availability report (/admin/report/gateway-availability) is the record to hold a contractor to. Opening it needs View Sensor Status Report, which all three shipped roles have.

1. Open Reports › Gateway Availability.
2. Date Range: pick last week.
3. Location and Floor: leave on All locations and All floors, or narrow to one.
4. SLA target %: 98 to start with (99 is in the list too). Gateways below it are tagged below target.
5. SLA measured on: Operating hours (the default when your organisation has opening hours) counts only the hours you are open; All hours counts every hour.
6. Press Apply.

A Bluetooth gateway only sends when it hears a sensor or tag, so a closed, empty building at night looks like silence, not a fault. That is why opening hours are the default.

You get one summary card first: the availability of the gateways in service, the all-hours figure beside it, and chips for gateways below target, outages in opening hours, times every gateway went silent together, and the longest outage. Under it are the gateways with Availability, Outages, Longest, Downtime, MTBF, MTTR, Now and Last seen; an hour-by-hour Timeline (red down, amber partly down, grey hatched for silence outside opening hours); and By location and floor. A removed gateway is faded and never flagged. Click a gateway for its outages one by one, each from the last packet to the first packet after. Export CSV saves the table, Outages CSV every outage. An outage marked Every gateway went silent together was the building's network or power, not the gateway.

Emailed every Monday.

1. Open System › Schedule Report (/admin/system/schedule-report). It needs the Schedule Reports permission (Admin and Manager as shipped), and Gateway Availability is offered only if your role also has View Sensor Status Report.
2. Press New schedule.
3. Under What to send: Name Gateway availability, weekly; Report type Gateway Availability; Format PDF; Window (days) 7. Venue appears for this report: leave All venues or pick one floor.
4. Under When to send: Frequency Weekly; Send at (HH:MM) 08:00 (your organisation's clock); Day of week Monday. Leave Active on.
5. Under Who receives: pick people in Recipients (admin users) (hold Ctrl or Cmd for several) and add outside addresses in Extra emails (comma-separated), such as the contractor's. An administrator whose role cannot open the report is left out at send time.
6. Press Preview to see the attachment, then Save.

The schedule's card then has Test, which sends it now to its recipients.

Questions and problems

Nobody was told about an outage last night. Check, in this order: was the gateway inside its quiet hours (the View panel says); is its row Active; was it down for more than 15 minutes (60 for LoRaWAN), or only Stale; and for a rule, was the outage inside its On days and Between hours. The Activity Log's System lane lists every offline and recovery that was announced, and the History at the bottom of the gateway's View panel lists that gateway's own.

The rule's message never arrived, but the bell did. Open Monitor › Live Monitor › Rules. No row means the rule did not fire: check it is Active, watches the floor the gateway is on, and was inside On and Between. A row whose Telegram action is skipped says why on the badge: No active Telegram connector (add it or switch it on under Connectors) or No chat ID set (open the rule). failed carries Telegram's own words, such as Bad Request: chat not found for a wrong chat ID or a bot that is not in the group: press Test Connection on the connector with the same chat ID. Failures are also under System › Usage, Recent failures. sent means Telegram accepted it.

A gateway that flaps on the edge sends a pair of messages every time. That is what one message per change means. Find out why it keeps dropping (power, network, a weak Wi-Fi link) on its View panel, or give the rule a longer Repeat at most every if one message a day per gateway is enough.

Viewers get the gateway alerts too. Yes: they go to every active administrator, whatever the role. To stop someone getting them, switch their account off; there is no per-person setting.

An organisation with no active administrator gets no bell entry, because there is nobody to show it to. Everything else still happens: the System events row, the outage log, and the Gateway status rules, which reach whoever their actions name.

→ Page someone when a gateway drops · Your first rule · Who did what: Activity Log and Usage