Skip to content

Tips and tricks ​

Short answers to "how do I get Omaya to…". Each links to where it is explained in full.

Rules ​

Count an event once, not once per packet. A PIR's occupied or a door's door_open stays at 1 for the whole visit. Use Becomes (changes to) 1 and the rule fires once when it changes. Greater than or Equal to fires again every time Repeat at most every allows, for as long as the reading stays there. Levels and edges

A door counter's entry uses Changes, not Greater than 0. An edge (Becomes, Changes) is checked on every packet the moment the reading moves; a level (Greater than, Equal to) is checked at most once a minute per sensor, so a counter rule written as a level misses entries. The zero rows Changes also writes add nothing to a sum. Toilet visits by gender

"For at least 10 minutes" is Only after it has held for. Any break restarts the clock. It is not offered for Becomes, Changes or an event, which happen once.

There is no "greater than or equal". For "at least 10 people", write greater than 9.

One rule for forty fridges. Put a label (Cold rooms) on the sensors and write the rule on the label. Repeat at most every then counts for each device on its own, and a new fridge needs only the label, not a new rule.

Overnight windows work. Between 22:00 → 06:00 means overnight, across midnight.

A weekly note, not a daily nag. A scheduled rule with On set to Monday only and Repeat at most every 24 hours.

Put the reading in the message. {{value}} is what the first condition looked at; {{zone.name}}, {{device.name}} and {{entity.name}} say where and who. Placeholders

A new edge rule does not fire on the first reading after you save it, because there is no earlier value to compare with. To test it, make the thing happen: walk through the door, wave at the PIR.

Work orders do not repeat. Raise a work order raises one per rule and place while it is open, and waits 24 hours after it closes. Batteries, anomalies and gateways already raise their own; do not build rules for those.

Is it firing? Rules shows Fired and Last Fired for each rule, and Monitor → Live Monitor → Rules says all sent per rule, and lists any action that was skipped or failed with the reason.

Reports ​

Answer a question no report has. A rule that writes a row to a data table, and a custom report on that table. Any "how many times did X happen" question works this way.

Two numbers in one row. In a custom report, only where on one metric narrows that metric alone: Count (Records) next to Count (Records) only where Gender equals female. Then a calculated column (minus, plus, times, divided by, as % of) gives the difference or the share. The builder

Try a report before the rule has fired. On a data table's rows page, Add a row by hand. It is marked manual.

Wall sensors and pocket tags are different temperatures. Filter Source equals fixed for the room, or a tag in someone's pocket averages into it.

Days are on your organisation's clock, everywhere: reports, rules, data tables.

Custom reports are run, not emailed. Press ▶ and Export CSV. System › Schedule Report emails the built-in reports.

Devices and places ​

Name a device for what it does. Count Sensor – Hallway to Toilet reads well in a rule, a report and an alert; C3:00:00:12:34:56 does not.

A counter or a fixed sensor needs its own zone. Its place comes from its own settings on the Devices page, never from the gateway that heard it, and a door counter with no location writes nothing.

Check a new sensor in ten seconds. Its View panel on the Devices page shows the latest decoded reading by field name. Those names are what Sensor reading (any field) takes: entry for a door counter, occupied for a PIR, door_open, co2, noise_dba.

A device you just moved can take up to 10 minutes to show in its new room.

A tag in the wrong room is almost always a gateway placement or calibration question, not a bug: A tag shows in the wrong room, then The calibration bench.

Faster or steadier room changes. The detection speed setting on System › Config (stable, balanced or responsive) trades how quickly a tag is moved to a new room against how often it flickers between two. Administration

A sensor Omaya does not know yet can be taught from its packets, without waiting for a software update: Teaching Omaya a new sensor.

Asking instead of building ​

OAIA reads the same data you do. Ask it "which toilets were busiest last week" or "why is the training room always over capacity", or ask it to build a rule or a data-table report for you and press Apply. OAIA

Not sure which people number to trust? Footfall, Enter / Exit, People Count, Space Utilisation, Attendance: How many were here.

Last updated:

Omaya platform documentation