Skip to content

Your first rule

A rule watches one number and does something when it crosses a line. This is the whole idea, and the rest is choosing the number well.

The four parts of a rule A rule is a scope, a condition, one or more actions, and how often it is allowed to act. The example shown switches the lights off in the Dev Room once the radar has seen it empty for ten minutes, and will not repeat for an hour. WHEREScopeZone: Dev RoomWHENConditionradar_vacant > 9THENActionshome_assistant: light.dev_room → turn_offHOW OFTENThrottleact at most once an hourRead it as one sentence"In the Dev Room, when the radar has seen it empty forten minutes, switch the lights off — and don't do itagain for an hour."THERE IS NO ≥ — FOR "TEN MINUTES OR MORE", WRITE > 9
The throttle is the part people leave out and then regret. A condition that stays true keeps being true every minute, so a rule with no throttle is a rule that sends the same message sixty times an hour. Set it to the interval at which you would actually want to be told again.

Rules live at Rules in the menu. There are templates for the common ones, and a Describe button that drafts a rule from a sentence — see below. Either way you end up in the same builder, and the four parts above are what you will be adjusting afterwards, so it is worth knowing what they are.

Pick the number before you pick the rule

The most common reason a rule never fires is that its metric has no value for the scope it was pointed at. Two questions settle it:

Does this scope have that metric at all? radar_people needs a zone with a calibrated radar in it. zone_utilisation needs a zone something actually counts people in. enter_count needs a counting sensor on a door. A rule on a metric nothing is producing is a rule that is silent forever, and it looks identical to a rule that is working and has nothing to report.

Is it live, or rolled up? Radar, density and utilisation metrics are computed when the rule runs. Temperature, battery, dwell and the counting metrics are read from tables rebuilt every five minutes, so a rule on them can be up to that far behind. That is fine for "too warm for an hour" and wrong for "someone just opened the server-room door".

Rule metrics lists all twenty, split by exactly that distinction.

Build it

Rules → create.

Name it for the situation, not the mechanism. "Meeting room left empty" will still make sense to whoever inherits it; "radar_vacant > 9" will not.

Scope — the venue, zone or device it applies to. Narrow scope, fewer surprises.

Trigger — three kinds:

TriggerBehaviour
Real-timeEvaluated every minute against the current value. This is what you want almost always.
ScheduledEvaluated on an interval you choose. For questions that only make sense periodically — a weekly utilisation check rather than a minute-by-minute one.
ManualOnly when someone runs it. Useful for testing a rule before arming it.

Conditions — metric, operator, value. Add more with AND / OR when one is not enough. between needs a second value; there is no "greater than or equal", so for "ten minutes or more" write greater than 9.

Actions — one or more of:

ChannelWhat it does
In-app alertRaises it on the dashboard. Needs no configuration, so it is the right first action.
Email, SMS, WhatsApp, TelegramSends to people. Needs the matching connector configured.
Webhook (HTTP POST)Posts to your endpoint — see webhook events.
MQTT publishPublishes to a topic, for your own subscribers.
Home AssistantSwitches a real thing: lights, a switch, air-conditioning, blinds, a scene.
Raise a work orderCreates a job for somebody to do, in the shared work-order queue. Not for batteries, anomalies or gateways — the platform raises those itself.
Write recordStores a row, for building your own history of when something happened.

A rule with three actions fires three events, and each is delivered independently.

Who creates the rule, and who fires it, are two different questions. A person creates it — by hand, from a template, or by accepting a draft from the AI builder or from OAIA. Once it is active, the platform fires it: the work order exists the moment the condition is met, and nobody approves it. OAIA's Autopilot can write a rule itself, but always inactive, and never with a work-order action — a person switches it on, and only a person can give a rule the power to create work.

One of them behaves differently, deliberately. Every channel above except raise a work order is fire-and-forget — send it twice and somebody reads two messages. A work order is something a person has to close, so it raises at most one job per rule per subject: none while one is open, and none for a cool-off period after one is closed, because closing a job does not make the condition false.

Then set the three things people forget

These are what separate a useful rule from one everybody mutes.

Cooldown. How long before the same rule may fire again — 30 seconds to 24 hours. A condition that stays true is true every minute, so a rule with no meaningful cooldown sends the same message sixty times an hour. Set it to the interval at which you would genuinely want telling again.

Time window. A start and stop time, so the "room left empty" rule does not page anyone at three in the morning.

Active days. Which days it may fire at all. Combined with a 24-hour cooldown this is also how you build a weekly note: active on Monday only, cooldown one day. There is no interval longer than a day.

A worked example

"Switch the lights off in the Dev Room ten minutes after the last person leaves."

PartValue
ScopeZone: Dev Room
TriggerReal-time
Conditionradar_vacant greater than 9
ActionHome Assistant → light.dev_room → turn off
Cooldown1 hour
Time window07:00 – 21:00

radar_vacant is minutes the radar has seen the zone continuously empty, so "greater than 9" is "ten minutes or more". The hour-long cooldown stops it re-sending every minute while the room stays empty. The time window keeps it out of the overnight hours when the lights are already off.

Or describe it and let the AI draft it

Rules → create → Describe (the sparkle button). Say what should happen in plain English — the same sentence you would say to a colleague:

Email ops@example.com if the Server Room goes above 30°C after 6pm on weekdays

Tell the guard on Telegram when anyone is in the loading bay between midnight and 5am

The assistant knows this organisation's venues, zones, devices and the twenty metrics, so it will pick temperature on the zone called Server Room rather than guessing. It answers with a card that says, in your own terms, what the rule will watch, where, the line it crosses and what it does — and you can keep talking to it ("make that 28", "also on Saturdays") until the card is right.

Nothing is saved until you press Save as draft & open in builder. The draft lands in the ordinary builder, switched off, with every field editable — so you review it with the real controls and arm it yourself. A rule the assistant drafted cannot fire before a person has looked at it.

Three things to know:

  • It needs AI switched on for your organisation, with a provider key under Configuration → A.I Model. If either is missing, the button says so instead of opening. Drafting counts against the same monthly AI allowance as the reporting assistant.
  • Use the names Omaya uses. "Server Room" works if that is the zone's name; "the cold room at the back" does not. The card will show you which zone it picked — check it.
  • Say the number and the time. "Too warm" becomes a guess; "above 30°C for ten minutes, weekdays after 6pm" becomes the rule you meant, with the cooldown and window filled in.

If the draft is close but not right, fixing it in the builder is usually faster than re-describing it — which is why the four parts above are worth knowing even when you never type a rule by hand.

Test it, then arm it

Save it inactive, or set the trigger to Manual, and run it once. Check the alert feed — Monitor → Central Alerts — to see what it produced.

Then watch the first real day. The two failure modes are opposite and both obvious within a day: it never fires (wrong metric, wrong scope, or a threshold nothing reaches), or it fires constantly (cooldown too short, or a threshold the normal state sits right on top of).

Good first rules

  • A room is left occupied after hoursradar_people greater than 0, outside the time window you would expect anyone.
  • A fridge or server room is drifting warmtemperature greater than your limit, with a cooldown of an hour so it tells you once per drift, not once per minute.
  • A batch of tags is going flatbattery_level less than 20, cooldown of a day, emailed to whoever carries the spares. (A critical battery already raises a work order by itself; this is the earlier, gentler nudge.)
  • A room nobody useszone_utilisation less than 25, active on Mondays only with a one-day cooldown. A weekly note rather than a daily nag.

Last updated:

Omaya platform documentation