Apps, rules and connectors

Making the platform do something — on its own, or in somebody else’s system.

Omaya acts on what it knows in three ways. Apps are self-contained products built on the platform, such as room booking, roll call and washroom hygiene; they are enabled per organisation and used directly by staff. Rules watch a value and act when it crosses a threshold. Connectors carry data to and from other systems.

NOTE

Most pages in this chapter require a permission. A user who cannot see a page lacks that permission in their role. Roles are edited under System > Roles; see Administration.

Apps

Your apps

Menu path: Choose Apps > Your apps (/admin/apps/your-apps).

The apps for the organisation: Enabled ones with their settings, and Available ones that can be requested (Contact support on the card). The gear on an enabled app's card opens its settings page (what it watches, who it notifies, the thresholds it works to); apps with no settings of their own have no gear. A tab strip at the top narrows the cards to one category, and a section with no app left in it is hidden while filtering.

Application scenario: Configuring an app already enabled — the booking calendar, roll-call rosters, cleaning schedules. The Facility app's settings also hold Work orders opened automatically: one switch each for a critical battery, a device that stops reporting, a gateway offline too long and a meeting room's people counter going silent. All are on to start with; untick one and the alert still shows, but no work order is raised.

App Users

Menu path: Choose Apps > App Users (/admin/app-users).

Accounts for the people who use an app rather than administer the platform — cleaners, receptionists, guards — and which apps each one may open. They sign in at the organisation's own page — /northwind/login for an organisation whose tenant ID is northwind — or in the phone app.

Application scenario: Giving a staff member their own app screens without giving them the admin console, and getting them in: Copy sign-in link copies a one-time sign-in link (valid for 15 minutes) to the clipboard to paste into a message, Email sign-in link emails one to the person's address, and Set temp password sets a password they must replace at their next sign-in.

Prerequisites: An app enabled that has a staff-facing side, and at least one app granted to the person: an account with no apps cannot sign in at all.

Related documents: Signing in: app users

Rules

All rules

Menu path: Choose Rules > All rules (/admin/manage/rule).

The organisation's rules: watch something, and when it crosses a line or something happens to it, do these things. A rule Watches one thing — a device, a Person / asset (through whichever tag is bound to it now), a Label (every device, person and asset carrying it, each judged on its own), a zone, venue or location, a Gateway, or a geofence. Its conditions are fixed metrics; Sensor reading (any field) for whatever a device's decoder produces, with Becomes and Changes for readings that stay true; Label field (person / asset) for the fields defined on a label; or events: Entered / left a place, Gateway status, Device anomaly detected, Work order opened / resolved, Security Watch incident and Fall / man-down detected.

Application scenario: Turning a number or an event into an action — an alert, a push, an email, a webhook, a light switched off, a work order, a row in a data table, or a badge told to report where it is, sound, or stop its alarm (Locate badge now, Sound badge, Exit badge alarm). Start from New from template, from Describe (the AI drafts a rule from a sentence), or from a Quick start card in the builder. Test checks the rule, saved or not, against the live readings right now and replays it over up to 30 days of tag movements to say how often it would have fired; nothing is sent.

Prerequisites: The metric must have a value for what the rule watches, and the builder offers only the checks that work for it. A sensor-field rule watches the device, its zone or a label it carries. Events are real-time only; footfall and label-field checks are scheduled only. Set Repeat at most every, or a condition that stays true fires every time it is checked — or use an edge, which fires once per change; a Label or Person / asset rule keeps that interval for each device. A dashed-circle mark by Last Fired means a scheduled rule could not be checked today for lack of data; hover for the reason, and see the Rules tab of Monitor > Live Monitor.

The list. Tiles count the rules On, Fired today, those that Need a look (on, but never fired, or today's check could not be made) and Off; a tile opens its tab, and the search and filters narrow by what a rule watches, priority and name. Each row reads the rule as a sentence, names what it watches, how it is checked and when it last fired, with an On switch and Run now (for a rule that is on), Its alerts and Delete on the row. Clicking a row opens the rule in the editor.

The editor. It opens in Flow view, the rule drawn as connected steps; Card view shows the same rule as cards read top to bottom — Watches, When, Then, Checked — each row opening its settings in place. The view chosen last is kept. Test first says whether the rule would fire right now from the live readings, condition by condition, then replays it over past days; nothing is saved or sent.

Badge actions. Locate badge now, Sound badge and Exit badge alarm command a badge that takes commands (the MOKO PS101-M today). The badge is the one the rule watches (a device, or the device that fired a Label or geofence rule) unless another is picked; a rule on a Person / asset, a Gateway, a zone, venue or location has to pick one. Each badge is commanded at most once every two minutes unless the action sets another interval.

Only for. A geofence, zone, venue or location rule fires for any tag that crosses it. Only for, under what the rule watches, narrows that to some devices, some people or assets, the carriers of some labels, or people only or assets only. It applies to conditions about one tag (entered / left, a geofence crossing, a button, a battery); a rule on a room total such as people count cannot take it.

Email, WhatsApp, SMS and alert. An email goes to the ticked admins (by the address on their account) and any addresses typed in, one copy each. Its words, like those of a WhatsApp, SMS or in-app alert, are written on the action or taken from a Message template; the chips under the message insert variables such as {{entity.name}}, {{geofence_name}} or {{map_link}}. WhatsApp and SMS take several numbers separated by commas.

Related documents: Your first rule

Message templates

Menu path: Choose Rules > Message templates (/admin/manage/rule/message-templates).

The words the rules send, written once: an email subject and body, and a short text for WhatsApp, SMS and the in-app alert, with variables such as {{entity.name}}, {{geofence_name}}, {{datetime}}, {{map_link}} and {{recipient.name}}.

Application scenario: Giving every alert of one kind the same clear wording, and changing it in one place: a rule's email, WhatsApp, SMS or alert action picks a template instead of carrying its own words, and editing the template changes every rule that uses it. The preview fills the variables with sample values and shows the email as it arrives, with the organisation's name and logo.

Prerequisites: Nothing, to write one; a rule action that picks it, for anything to be sent. A template a rule still uses cannot be deleted. A variable with nothing behind it for a firing (a map link for a rule with no GPS fix, a person for a tag bound to nobody) comes out blank.

Related documents: Your first rule

Connectors

Menu path: Choose Connectors (/admin/connector).

Everything that carries data in or out: gateways, MQTT, smart-home and Matter bridges, calendars, messaging channels, outbound webhooks, CMMS and storage.

Application scenario: Connecting Omaya to something else, and checking a connection that has gone quiet — each connector records its own last status and last error.

Is it getting through? Tiles count connectors Working (receiving data, or working when last used), Quiet (on, but nothing has arrived for 15 minutes or more), Failing (the last attempt failed) and Off; a tile narrows the list to them. Connectors are grouped as Data in, Alerts out, Business systems and Storage, each row with a live status line and, for connectors that receive data, bars of messages per hour over the last 24 hours. The name or the gear opens its settings.

Test. The Test button on a row runs read-only checks for that connector — whether the broker is reachable, the receiving address and topic, whether messages are arriving, the saved settings, its last use and last error — and shows the result under the row. Nothing is sent or injected.

Related documents: Webhook events

NOTE

This chapter is generated from the admin menu itself, so it lists every menu item.