Appearance
Reports
Thirty reports, grouped by the question they answer.
All reports share the same controls: a date range, a scope (location, venue or zone) and an export. They differ in the unit counted: a crossing is not a person in the room, a stay is not a visitor, and a device is not a person.
The reports are grouped below by the question they answer.
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.
How busy is it?
Counts — right now, or added up over a period. Read the source before the number: what counts as a "person" differs between these three.
Enter / Exit
Menu path: Choose Reports > Enter / Exit (/admin/report/enter-exit).
People crossing a doorway, counted by direction, by day and hour.
Application scenario: How busy an entrance was, and when.
Prerequisites: A people counter on the door. It counts crossings, so one person who steps out and returns is two entries and two exits. The People inside card turns them into a headcount — entries minus exits, restarted at midnight each day — which is only as complete as the doors that have a counter.
Related documents: Report glossary
Footfall
Menu path: Choose Reports > Footfall (/admin/report/footfall).
How many were in a place each day — the whole organisation, a location, a venue or a zone: the tags people carry, each counted once per place however many rooms they went through (tags on assets such as trolleys are counted apart), beside the door counters' entries and the most inside at once. Per day or per hour, with CSV export. Days counted (Operating / All days) chooses whether closed days count; in Operating they are hidden and noted above the table.
Application scenario: "How many on Level 5 yesterday", "which venue is busiest", a footfall figure for a location. It replaced Devices Detected, whose venue and day totals added up the zones and counted a device once per room it passed through.
Prerequisites: Gateways assigned to zones for the devices; a people counter on the doors for entries and most-inside. Read a tag as a tag, not a head: a person carrying two tags counts twice, one carrying nothing is not counted. A day for which the gateways sent nothing says No data received rather than showing nobody. A venue, location or whole-organisation day from before the once-per-place count began (it reaches back to early September 2026) shows —.
Related documents: How many were here — choosing the right people report
People Count
Menu path: Choose Reports > People Count (/admin/report/people-count).
Occupancy over time per zone: the most people at once and the average, for each hour and day. Head counts only — occupied-or-empty sensors do not appear in it as a count.
Application scenario: The report to reach for when someone asks "how busy is this room, really".
Prerequisites: Something that counts people in the zone: a counting sensor counts everyone in its coverage, the tags present count only people carrying one. Read the peak and the average deliberately — they are different questions — and never add hours together.
Related documents: Occupancy: which number is which
How long do people stay?
Whether this is somewhere people pass through or somewhere they settle.
Loyalty
Menu path: Choose Reports > Loyalty (/admin/report/loyalty).
How often the same registered tag comes back — new versus returning per calendar day, how long between visits, and a list of the tags themselves: the regulars, the newcomers, and when each was last here.
Application scenario: Retail and visitor-attraction questions: is this a place people return to? On a badge-carrying workplace it reads as attendance regularity, and the tag list is the useful half. Filtered to a venue or a zone, a tag counts on every day it was there, judged against its own history in that place.
Related documents: Report glossary
Attendance
Menu path: Choose Reports > Attendance (/admin/report/attendance).
When each person was on site, day by day: first in, last out, time on site, visits, the floors they were on and how long on each, with a team table (person by day, days present out of days counted and the attendance rate), a By day table (present, attendance, late, left early, average time, first in and last out), late and left-early marks against the organisation's opening hours, a Not in today list, a page per person down to every stay, and CSV export. Days counted: Operating counts only the open days of the operating week, All days every calendar day.
Application scenario: A register, a timesheet check, "who came in late this week", "who is not in yet today", "was anyone in on Saturday", "who is still here". Time on site merges a person's stays so two rooms or two tags are never counted twice; a gap shorter than the one chosen (30 minutes by default) is a corridor and still counts, a longer one starts a new visit. GPS time outside is shown separately and never counted as on site. Field staff: pick the label they carry with the Field staff button; for them, GPS time outside within working hours on working days counts as working outside (client visits, driving between sites), never time stopped at home, which is found from where the tag spends the night.
Prerequisites: People on the Entity page with their tags bound — it reads the same stays as Monitor > Entity Tracker. Someone not carrying their tag is not seen; a tag left on a desk overnight keeps its owner on site. The group filter uses the tags on the Entity page.
Related documents: Report glossary
Dwell Time
Menu path: Choose Reports > Dwell Time (/admin/report/dwell-time).
How long devices stay, bucketed by duration and broken down by zone.
Application scenario: Telling somewhere people pass through from somewhere they settle.
Related documents: Report glossary
Where do they go?
Routes through the building, and which parts of it get used. These need a floor plan, and the positioning to go with it.
Asset Utilisation
Menu path: Choose Reports > Asset Utilisation (/admin/report/asset-utilisation).
How much each tracked asset (trolley, wheelchair, forklift) was used and where it spent its time, per asset and per group: hours seen, moves, time in use away from its base, utilisation of opening hours, the places it stood, idle assets (seen, never moved) and missing assets (not seen for 1, 3 or 7 days, with where and when each was last seen). A page per asset down to every stay, and CSV export. In use also counts the minutes an asset was moving where it stood, for tags that report motion (Minew MWC01, MOKO BeaconX with the 3-axis frame, MOKO B2/H8); each asset says whether its figure is from motion or from location.
Application scenario: "Where is the missing trolley", "are six wheelchairs needed or four", "which forklift sits idle". Use is read from location changes, not motion: a stop shorter than the chosen shortest stop is passing through.
Prerequisites: Assets on the Entity page with a tag bound. A tag left in a drawer looks idle; a tag taken off its trolley makes the trolley look missing. The base is the tag's home zone, else where the asset spends most time.
Related documents: Report glossary
Flow
Menu path: Choose Reports > Flow (/admin/report/flow).
Movement between zones on one floor — which zone leads to which, how often, in which direction, and which tags made the trip. A move is two consecutive stays in different zones with the second beginning within ten minutes of the first ending; stays shorter than the minimum are pass-throughs and are dropped. Pick All floors under Venue to follow trips between floors instead: floor to floor or room to room, the typical time between floors, and the most common sequences of places in a day's visit.
Application scenario: Understanding routes through a building: the path people actually take rather than the one the signage assumes. Widen the gap to "any" to see every zone change, including the ones with a long absence in between. Across floors, a short stay on another floor with the same floor either side is usually a gateway through the ceiling, not a trip; Ignore bounces under (two minutes by default) leaves those out.
Prerequisites: Zones with an outline drawn on the floor plan. Moves and trips are counted in tags, so they describe the people and things that carry one.
Related documents: Report glossary
Room Usage Map
Menu path: Choose Reports > Room Usage Map (/admin/report/room-usage).
One radar-equipped room seen from above: a heat map of where people sat or stood over the selected days, peak and average occupancy, hours occupied against the operating hours that have happened, and a replay of any day minute by minute.
Application scenario: Settling an argument about a specific room on a specific afternoon, seeing which end of a room is never used, and checking that a radar sees what it is expected to see. The coverage line says how many of the hours judged the radar was awake for — below 80% the figures are a floor.
Prerequisites: A calibrated radar in the room.
Related documents: Report glossary
Heatmap
Menu path: Choose Reports > Heatmap (/admin/report/heatmap).
Where people spent their time on a floor plan, as intensity over the plan image.
Application scenario: Layout questions — which corner of the showroom nobody walks into.
Prerequisites: A venue with a floor plan and enough positioned devices to make a shape rather than a scatter.
Related documents: Report glossary
Detection Heatmap
Menu path: Choose Reports > Detection Heatmap (/admin/report/heatmap-total).
A grid of venues, zones or locations against calendar days (or hours of the day), each cell shaded by how many distinct BLE devices were detected there — the same device counted in every space it visited.
Application scenario: Spotting the pattern of a week at a glance, and checking coverage: it shows where gateways can hear, which is a different question from where people are.
Related documents: Report glossary
Sensor Trail
Menu path: Choose Reports > Sensor Trail (/admin/report/device-trail).
One tag’s path over time, zone by zone and day by day: tiles for On site, Stays, Zones visited and Avg stay, a Per day table (first and last seen, time on site), then the Indoors tab: where the time went, how each stay was positioned, the zone timeline and every stay. When the tag also reported GPS in the range, an Outside tile and tab appear: time outside, distance travelled, trips and stops, the route on a street map, and the journey stretch by stretch.
Application scenario: Following a person or an asset, or reconstructing a movement after the fact. Per day has one row per date, with each person or tag beneath it when there are several; click a day to see only that day. With several tags outside, the Outside tab has a chip per tag, in the colour of its route on the map, and the journey names the sensor of every stretch. Outside comes from the tag’s own GPS (a tracker’s, or the fixes an Omaya Scout phone relays for it); without it the page is indoors only. Distance adds up the trips, once even when two tags of one person recorded the same trip. Export days and Export trail download what is shown.
Related documents: Report glossary
Outdoor Activity
Menu path: Choose Reports > Outdoor Activity (/admin/report/outdoor-activity).
What people and assets did outside, day by day, from each tag’s GPS (its own tracker, or a phone running Omaya Scout that hears it): time outside, distance, trips, stops away from the organisation's places, and visits to each geofence — per person or tag, and per geofence who came and how long they stayed.
Application scenario: Answering "how far did the field team go this week", "who went to the depot", or "where do they stop that is not one of the organisation's sites" without reading a trail row by row. The same stretches as the Sensor Trail, added up.
Related documents: Indoor and outdoor
GPS Replay
Menu path: Choose Reports > GPS Replay (/admin/report/gps-replay).
One entity’s or sensor’s way outside played back on a street map, fix by fix: each stop and how long it lasted, the trips between, and for a fix an Omaya Scout phone sent, how many phones heard the tag and how far it was from them.
Application scenario: Reconstructing a trip after the fact, or checking where a tag that only phones hear has been. Press play, or click a stop to jump there; the card beside the map says what the fix behind each moment was.
Prerequisites: GPS fixes: a tracker with its own GPS, or tags published to Omaya Scout. Up to 7 days load at once.
Is the space the right size?
The property questions. Both need operating hours on the venue and a capacity on the zone before they mean anything.
Space Utilisation
Menu path: Choose Reports > Space Utilisation (/admin/report/space-utilisation).
Every zone ranked by how much of the venue’s operating hours it was actually occupied, with the cost of the space that was not.
Application scenario: The portfolio question: which rooms are too big, which are too small, and what the underused floor area is costing.
Prerequisites: Operating hours and, for the money column, a cost per m² on the venue. Capacity on each zone turns "occupied" into "at capacity".
Zone compare
Menu path: Choose Reports > Zone compare (/admin/report/zone-compare).
The same figures for two sides, with the change between them: two zones over the same days, or one zone or venue over two periods — this week against last, this month against the same month last year, or any two date ranges of up to a quarter each.
Application scenario: Comparing like with like — two meeting rooms, or one floor before and after a change. Devices a day are registered tags counted once per place, entries come from door counters only, and people present come from a counting sensor where the room has one, else the tags seen there.
Prerequisites: Door counters for entries, and a capacity on the zone for hours at capacity; without them those rows show a dash. A venue has no hours-at-capacity figure.
Related documents: Report glossary
Is it comfortable? Is the hardware alive?
Conditions in the room, and the state of the things measuring them.
Environment
Menu path: Choose Reports > Environment (/admin/report/environment).
Temperature, humidity and noise from environmental sensors, with breaches against the thresholds set for them — and the weather outside the location on the same hours, so inside can be read against outside. Compliance checks each room against its own profile (Office comfort, Cold chain, Frozen, Controlled room, Server room or Custom; set per zone, in bulk on the tab, or as a venue or organisation default) over any dates, and shows hours out of range, hours with no data and, for cold stores, mean kinetic temperature.
Application scenario: Comfort and compliance. Change a threshold and the history re-reads against it, so a breach count describes the current limits rather than a fixed historical fact. The outside line says whether a hot room is the weather or the building.
Prerequisites: Sensors that report those readings. A reading is per sensor, not per room — one near a vent will disagree with the rest of the room, and be right about where it is. Outside needs latitude and longitude on the location (Space > Location, edit the location); it comes from Open-Meteo hourly, a model figure for the area rather than a rooftop sensor.
Related documents: Report glossary
Battery
Menu path: Choose Reports > Battery (/admin/report/battery).
Battery level per device, with the trend and a forecast of when each will need replacing; an Alerts tab of the cells that dipped under 20 %, one alert per episode, closed by the cell coming back.
Application scenario: Planning one maintenance trip instead of five. Pair it with the battery-forecast webhook to have the trip booked automatically. A replaced cell closes its own alert as recovered; a level older than the alert is a device that has gone quiet since. Rechargeable badges and tags (the PS101 and the MWC01) get no replacement forecast; with the Facility app on, a critical one opens a Charge work order rather than a battery job, unless battery work orders are switched off in that app's settings.
Related documents: Report glossary
Distance
Menu path: Choose Reports > Distance (/admin/report/distance).
What the time-of-flight sensors measured, hour by hour: the distance to whatever was in front of each sensor, by device and zone.
Application scenario: Reading a level or a gap over time — how full a bin is, whether a door sat open, how close the nearest object came. One row per sensor per hour.
Prerequisites: A time-of-flight sensor reporting (the MOKO SO2R today) and registered as a device. Each hour holds that hour's last reading, not its average, so a sensor that reports every few minutes shows the state at the end of the hour rather than the busiest moment in it.
Tag Health
Menu path: Choose Reports > Tag Health (/admin/report/tag-health).
The health a tag reports about itself, hour by hour: battery voltage now and at its lowest, how fast it is falling, board temperature, and restarts, with LoRaWAN signal for LoRa devices.
Application scenario: Seeing a battery fade before the percentage moves, and spotting a tag that keeps restarting or runs hot. It can be emailed on a schedule.
Prerequisites: Tags that broadcast their own health. Some, like the MOKO BeaconX Pro family, only do so once Broadcast battery & health is switched on under the device's Configure.
Related documents: Report glossary
Sensor Status
Menu path: Choose Reports > Sensor Status (/admin/report/device-status).
How reliably each sensor has actually been reporting: the share of hours it was heard in, the share it delivered a reading in, and a strip of the hours themselves — amber for heard without a reading.
Application scenario: Telling a sensor that died on Tuesday from one that drops out every night — the two look identical in any figure that only counts the total. "Heard, no readings" is its own fault: the radio is fine and the sensor is not advertising the measurement.
Prerequisites: Nothing beyond devices reporting; hours before a device was registered are not held against it. A sensor with low availability is not necessarily faulty: an asset tag that only moves in working hours is legitimately quiet the rest of the time.
Related documents: Report glossary
Gateway Availability
Menu path: Choose Reports > Gateway Availability (/admin/report/gateway-availability).
How much of the period each gateway was up, against an SLA target set on the page: availability of all hours and of operating hours, outages, longest outage, downtime, MTBF and MTTR, current state and last seen, an hour-by-hour timeline, and totals by location and floor weighted by hours. CSV of gateways and of outages. Outage times are exact (last packet to first packet after) since 6 October 2026, to the hour before; point at a timeline cell for an outage's exact start and end.
Application scenario: An availability figure to hand a customer, finding the gateway that keeps dropping out, and telling a site-wide power or network cut from one failing unit.
Prerequisites: Read in whole hours from the hours each gateway passed on data, so a working gateway with no registered device in range also reads as down. Gateways count only while they existed; quiet hours are left out.
Related documents: Report glossary
Rule & Alert Effectiveness
Menu path: Choose Reports > Rule & Alert Effectiveness (/admin/report/rule-effectiveness).
Per rule over a period: how often it fired, on how many devices, whether its messages were sent, failed or skipped, a day-by-day trend, and the rules that never fired; per kind of alert (device anomalies, battery alerts, Security Watch incidents): how many were acknowledged, the median time to acknowledge, and the ones still waiting.
Application scenario: Tuning: a rule that fires fifty times a day trains people to ignore it, one that never fires may be watching the wrong thing, and an action that keeps failing or is skipped for want of a connector means nobody was told. Each rule links to its edit page.
Prerequisites: Rules that have fired since 4 October 2026, when the rule log began; firings older than 90 days are pruned. Over-capacity breaches have nothing to acknowledge and show how long they lasted instead. Not checked on N days under a rule counts the days it could not be checked for lack of data; those are not firings.
Related documents: Report glossary
What happened, and when?
Discrete events rather than levels — a press, a fall, an incident. One row is one occurrence, and the question is often how it was answered.
Door & State
Menu path: Choose Reports > Door & State (/admin/report/door-state).
How long doors stayed open, leaks lasted, air-con ran, power ran on battery, equipment ran, lights and switches stayed on, and when sensors were tampered with: one row per sensor with how often and how long, the longest stretch, how much fell after hours, and what is still open now. A timeline shows each stretch.
Application scenario: Finding the door that is propped open every afternoon, the leak that came back, or the air-con left running overnight. Pick one kind under What to narrow it. It can be emailed on a schedule.
Prerequisites: Sensors that report a state: door contacts, leak sensors, smart switches and air-con through Home Assistant, and UPS or equipment with a running or on-battery flag. A sensor's first reading is shown as its state, not counted as an opening.
Related documents: Report glossary
Trigger Event
Menu path: Choose Reports > Trigger Event (/admin/report/button-press).
Every button press or panic trigger, with the device, the gateway that heard it, the time, and whether it matched a panic-button routing and paged anyone.
Application scenario: Call-for-service and SOS workflows: how many presses, where, and which of them raised an alarm — a press from a device with no routing is a doorbell nobody is listening to.
Prerequisites: A device with a button, and its trigger enabled. To page anyone, a panic-button routing for it under Device > Panic Buttons.
Related documents: Report glossary
Fall & Man-down
Menu path: Choose Reports > Fall & Man-down (/admin/report/fall-watch).
What the fall and man-down detector flagged, and how much of it was real: flagged events, the ones set aside as habitual rests, the ones that asked a person "Are you OK?", how fast people answered and guards responded, precision once events are labelled (overall, and by where the tag is worn beside the published figures), and a table per tag with whether it looks worn. Events from a tag that looked not worn are marked and left out of precision unless Count tags that looked not worn is switched on. CSV export.
Application scenario: Checking the detector before alerts are switched on, and afterwards finding the tag that keeps raising false alarms, or the one nobody is wearing. Label each event as a real fall, a false alarm or a test with the Real / False / Test toggle on its row (labelling also needs edit-devices); that is what turns the figures into accuracy.
Prerequisites: Tags with an accelerometer Omaya can read (the Tags that can do this list on the Fall detection page names them), Fall detection switched on under System > Configuration (the Fall detection card). A starter pack creates its fall rule paused, so with Watch every supported tag off nothing is watched until that rule is switched on. The guards are told through Security Watch, so that app must be enabled for anyone to be paged; events are recorded either way. With Watch every supported tag off, only the tags a Fall / man-down detected rule covers are watched. Until Alert people is switched on, events are recorded here and nobody is asked or told, which is the time to check the figures. Precision counts only labelled events, and it measures false alarms, not falls the detector missed. The report shares its permission with Panic & Incident Response.
Related documents: Fall and man-down detection
Panic & Incident Response
Menu path: Choose Reports > Panic & Incident Response (/admin/report/incident-response).
How Security Watch incidents and panic presses were answered: by type, place, hour and weekday; how fast a person picked them up and resolved them (median, 90th percentile, worst, share within a few minutes); still open, unattended and reopened; outcomes (genuine, false alarm, expected, test, duplicate) and the false-alarm rate; each guard's workload; each panic button and the person carrying it, with presses nobody picked up. CSV export.
Application scenario: Showing a client or an auditor how fast the guards respond, finding the button or alarm that keeps being a false alarm, and the presses that were never answered. The Security Watch app's Reports tab shows the same figures to supervisors.
Prerequisites: Security Watch switched on. Picked up means a person acknowledged or resolved it — one the sweep closed as unattended was not picked up, which is why Rule & Alert Effectiveness, which counts those, reads higher. The person carrying a button is its current binding.
Related documents: Report glossary
Impact Events
Menu path: Choose Reports > Impact Events (/admin/report/impact-events).
Before-and-after for a change made on site — a promotion, a layout change, a closure: devices per day and average dwell in the seven days before, during, and the seven days after, for the location, venue or zone it applied to.
Application scenario: Did the change move anything? A difference across the boundary is a correlation, not a cause — weather and holidays land in the same window.
Prerequisites: An event with dates and a scope, and Footfall and Dwell Time having data for it. A day from before Footfall's once-per-place count began (early September 2026) has no venue, location or whole-organisation count and is left out of the per-day rate.
Related documents: Report glossary
None of the above
When the question is not one of the twenty-eight above.
AI Reporting
Menu path: Choose Reports > AI Reporting (/admin/report/ai).
Questions about the organisation's data, asked in plain language, answered with a table, a chart and the answer in words: occupancy, footfall, dwell, environment, where someone is — and the data of the apps the organisation has switched on. It can also answer from Attendance, Asset Utilisation, Panic & Incident Response and Gateway Availability, but only for roles that can open those reports.
Application scenario: When the need is a question rather than a report, or the audience will not open a dashboard. The same tools answer from Claude Desktop or another AI client through the reporting MCP endpoint.
Prerequisites: An AI provider key for the organisation. Reading an app's data also needs that app's AI Reporting permission on the user's role (view-report-ai-app-…); Admin has them all.
Related documents: AI in Omaya
Custom Reports
Menu path: Choose Reports > Custom Reports (/admin/report/dynamic).
Reports defined by the user: pick a data table (entries and exits, devices detected, footfall, loyalty, loyalty by place, dwell, temperature and light, distance, battery, device status, people count, noise, air quality, button presses, or one of the organisation's own data tables), the metrics and the grouping, and save the result to run again or export as CSV. Groupings follow the organisation's time zone and name their locations, venues, zones, gateways, devices and rules.
Application scenario: When the question is not answered by a fixed report and will be asked again.
Related documents: Building a custom report
NOTE
This chapter is generated from the admin menu itself, so it lists every menu item.