Appearance
Watching gateways and sensors from Zabbix
Your network monitoring system — Zabbix, PRTG, LibreNMS, Nagios — can watch every Omaya gateway and sensor next to the rest of your estate. It asks Omaya once a minute what is up and what is down, and raises its own problem when a gateway drops or a sensor goes quiet.
It reads the same line Omaya alerts on, so the two never disagree: when Omaya tells your admins a gateway is down, Zabbix shows it down too.
What counts as down
A gateway is down when it has not sent anything for 15 minutes. A gateway heard in the last 15 minutes but not the last 5 is still up: that gap is the normal difference between its reporting interval and ours. A gateway that is not reporting inside its quiet hours (set on the gateway, for a site that closes at night or at weekends) reads quiet, not down, and raises nothing.
A sensor is silent once nothing has been heard from it for its silent threshold: the one set on the device, otherwise three days for a tag a person or asset carries, otherwise two hours. It turns critical at three times that. A device with anomaly detection switched off reads not_monitored and never counts as down.
Battery low is 20 % or less, from a reading taken in the last seven days, the same line OAIA uses. Omaya's own nightly battery alert starts below 20 %, so a device at exactly 20 % reads low here but has no battery alert yet.
Setting it up
- Create a key for it. In Omaya, open My Profile (the menu under your name), then API Keys → Add Key. Under Access choose Monitoring only: that key can read up/down status and nothing else, so the copy that sits in your monitoring system's configuration cannot read or change anything in Omaya. Under Allowed IPs enter your Zabbix server's address. Copy the key — it is shown once.
- Import the template. Download omaya_by_http.yaml and import it in Zabbix (Data collection → Templates → Import). It is a Zabbix 7.0 template and imports into 7.0 and later.
- Add a host for your organisation and link the template Omaya by HTTP to it. It needs no interface. On the host's Macros tab set:
| Macro | Value |
|---|---|
{$OMAYA.URL} | Your Omaya address, e.g. https://omaya.example.com |
{$OMAYA.TENANT} | Your organisation ID |
{$OMAYA.API.KEY} | The key from step 1 |
Within a minute, Zabbix discovers every gateway and sensor. Gateways and sensors you add in Omaya later appear on their own; ones you remove go after seven days.
What the template gives you
| Per gateway | Status (up, down, quiet), up as 1/0 for graphs, minutes since its last packet. Problem Gateway … is down (High). |
| Per sensor | Status (up, silent, never_seen, not_monitored), up as 1/0, minutes since its last packet, battery. Problems … is silent and … battery low (Warning). |
| For the organisation | Gateways up, down and in quiet hours; sensors up, silent and low on battery. |
| For the connection | No answer from the monitoring API (High) when Omaya has not answered for 5 minutes — a wrong key, an IP not on the allowed list, or Omaya out of reach. |
Every item carries component, location and floor tags, and sensors a type tag, so problems can be filtered and routed by building or floor.
You can change these on the host:
| Macro | Default | |
|---|---|---|
{$OMAYA.SENSOR.TYPE.NOT_MATCHES} | ^(tag|asset_tag)$ | Device types left out. People's tags are left out by default: a tag that went home with its owner is not a fault. Set it to something that matches nothing, such as ^$, to watch them too. |
{$OMAYA.SENSOR.TYPE.MATCHES} | .* | Device types discovered, for example ^sensor$ for fixed sensors only. |
{$OMAYA.BATTERY.LOW} | 20 | Battery percent that raises battery low. |
{$OMAYA.INTERVAL} | 1m | How often Zabbix asks. |
{$OMAYA.NODATA} | 5m | How long without an answer before No answer from the monitoring API. |
Other monitoring systems
The template is one HTTP request a minute. Any system that can read JSON over HTTPS can do the same:
GET /api/v1/monitoring/status
X-Tenant-ID: yourorg
X-Api-Key: <your monitoring key>The answer has a summary (gateways and sensors up, down, quiet, silent, low on battery) and a gateways and a sensors list. Each entry carries status, up (1 or 0), last_seen_at and minutes_since_seen; sensors add severity, silent_after_minutes and the battery. ?only=problems returns only the gateways that are down and the sensors that are silent or low on battery, with the summary still counting everything; ?include=gateways or ?include=sensors returns one list. Every field is in the API reference under Monitoring.
Once a minute is enough. Omaya keeps the answer for 30 seconds, and a gateway counts as down only after 15 minutes, so polling faster finds nothing sooner.
Polling or being told
Polling suits a monitoring system: it notices when Omaya itself cannot be reached, which a message from Omaya never could. If you would rather Omaya tell you, a rule on Gateway status or Device status can send a webhook the moment it happens — see Being told when something changes. Many sites use both.