Appearance
Report glossary
What each report answers, and the terms on it that are easy to misread.
Read out of the platform
This page is generated from the code that runs your instance, so it cannot drift from what the platform actually does.
Nearly every figure on a report page has a unit that reads like something slightly different from what it is, and the misreadings are the expensive kind: a "move" is not a person, a dwell row is a stay and not a visitor, a tag-day is neither.
This is the same text as the What this report is panel at the foot of each report page, collected in one place so you can search it — and so you can read it before you open the report rather than after you have already drawn a conclusion from it.
Central Alerts
/admin/report/alerts
Every alert the platform raises, in one feed: device anomalies, battery warnings, button presses, gateway outages and positioning coverage, rule triggers and emergencies, Toilet Hygiene and Security Watch incidents, connector failures, Data Centre and Warehouse alerts, rooms over capacity, OAIA findings, compliance findings, radar reflections, maintenance requests past their SLA and failed webhook deliveries.
Needs a look — An alert that is still open (not acknowledged, cleared or resolved), or one with nothing to close it (a rule trigger, a press, a gateway going offline) raised in the last 24 hours. Recoveries (a gateway back, a connector working again) are counted as done.
Repeating — The same alert from the same place three times or more folds into one row, with how often, since when, why it usually repeats and where to change it. A rule that fires every time something crosses a door is usually one situation, not many; raise its repeat at most every.
What can be done from here — Anomalies and battery alerts can be acknowledged and deleted; button presses and dead webhook deliveries deleted. Everything else is handled where it was raised, which each row links to.
Rules that only email — A rule fires into this feed through its in-app alert action. A rule whose only actions are email, SMS or a webhook leaves no row here; its rule page shows when it last fired.
Quiet is not always good — Alerts depend on rules existing and sensors reporting. An empty feed can mean nothing is wrong, or that nothing is watching.
Enter / Exit
/admin/report/enter-exit
Counts of people crossing a doorway, as recorded by the sensor watching it, for a date range and location. It answers how busy an entrance was and when.
Enter / Exit — People crossing the doorway, by direction — not how many are inside. One person who steps out for coffee and comes back is two enters and two exits.
People inside — How many people are inside the doors you filtered to: entries minus exits, running hour by hour, starting from 0 at midnight each day and never going below 0. When the range includes today the card reads People Inside Now; otherwise it shows the busiest moment of the range and when it was. The chart draws it as a line — per hour on Hourly, each day's peak on Daily. It is only as complete as the doors: a way in or out with no counter on it is invisible to it. A counter that counted only one direction in the range (an entry-only distance sensor, say) is left out, and the card names it; tag-based gateway rows are left out whenever door counters exist, because they count different people.
Balance (in minus out) — A check on the counters, not a headcount. Over a whole range the two directions should roughly agree; a gap of more than a tenth means a counter is missing one direction (a beam mounted so people cluster on the way out, say), and the counter strip marks which. Over several days every missed exit is carried forward, which is why People inside restarts each day instead.
Net — The table's last column and in the exports: entries minus exits for that one counter and hour.
Counter — The counts belong to the door counter that saw them, so a doorway covered by two counters reports under both. The strip under the cards names each counter behind the range and says whether it is still counting.
Source — A door counter (sensor) counts everyone who crosses. Older rows marked gateway were inferred from tags moving between zones and count only tag carriers; filter by source when comparing like with like.
Where the numbers come from. Each counter's crossings are added to its hourly row as the packets arrive, so the current hour is live to within a few minutes; hours are shown on your clock. There is no daily rebuild — a day is its hours. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.
Footfall
/admin/report/footfall
How many were in a place, counted two ways side by side. Use it for "how many on Level 5 yesterday", "which venue is busiest", or a footfall figure for a location you can put in front of a landlord.
People heard — each counted once per place — Every tag people carry that a gateway heard — a registered tag that was not bound to an asset at the time (the same rule as the TV Dashboard's "People seen today"); tags on assets such as trolleys are counted separately and shown as "+ N asset tags". Each is put in the zone of the gateway that heard it best each hour. A tag that went through four rooms of a venue counts once for the venue and once for the location — it is not the zones added up. Fixed installations (sensors, door counters, wall switches) are left out. A Bluetooth device you have not registered is not kept when it is heard, so it is never counted here: a visitor without a tag shows only in the door counts. A tag is a radio, not a person: a person carrying two tags counts twice, a person carrying nothing is not counted.
Staff, visitors and unassigned tags — Once your organisation picks the label that marks staff (the Staff label button at the top), people are split three ways by who held each tag at the time: staff — a person carrying that label; visitors — any other person holding a tag, such as a badge handed out at visitor check-in; unassigned — a registered tag bound to nobody. The three add up to people. The label is read as it is today, and changing it recounts the last 30 days (the raw data kept); days before that show people as one figure. A visitor without a tag is in the door counts only.
Came in, and left — Crossings counted by the people counters on the doors of the place — everyone, tagged or not, but only at doors that have a counter. One person who steps out and back in is two entries.
Most inside at once — Door entries minus exits, running hour by hour, reset at midnight, never below zero — the same rule as Entry / Exit. A counter that only counted one direction in the range is left out of it, and named above the table.
Per hour — Hours do not add up to the day: a device here all afternoon is in every one of those hours, and once in the day.
Comparing places of different sizes — In the totals, a place with a known floor area also shows its devices a day per 100 m², and "most inside" as a share of its capacity, so a large floor and a small one can be compared fairly. A zone's area is its set area or the outline drawn on the floor plan, a venue's is its scaled floor size, and a location's is its venues added up; a location's capacity is its venues' added up.
No data received — A day the gateways of a place sent nothing at all (usually power or network at the site) is marked no data received instead of being read as nobody there, and a day with data for less than half its hours carries a "data for N of 24 h" mark. Whether data arrived is taken from the gateways' hourly reports, which include fixed sensors, so an empty building still counts as reporting.
Against capacity — Where a venue or zone has a capacity, "most inside" also shows as a share of it. A venue uses its own capacity (set on the venue), else its zones' added up; a location holds what its venues hold, added up; the whole organisation has none.
Time here — How long a tag spent in the place that day, on average: its stays there joined up, so walking between two rooms of a floor is one stretch on that floor. Registered tags only, and a tag left on a desk overnight counts as here all night.
Per device heard — Door crossings for every device the gateways heard. It goes up when people without a tag come in, so it is a rough sign of how many visitors carry nothing the system can hear.
Compare with, and a typical week — The period before is the same number of days just before your range; same dates last year is a year earlier. A typical week averages each weekday and hour over the days of that weekday in your range.
Days counted — When your organisation has an operating week (System › Configuration › Organisation, or a venue's own opening days — the venue in the filter uses its own), Operating counts only the open days: the chart and table hide the closed days, and people a day, visits, the busiest day, per 100 m², the typical week and the comparison leave them out. What the closed days held is not lost: a note above the table says how many people-days (and door entries) were on them. All days counts every calendar day. The choice is only for this view and changes no setting.
Older days — The once-per-place count is taken each day while that day's device list still exists, and kept from then on like any report. It started on 5 October 2026 and was filled in back to 5 September 2026 (the device list is kept 30 days). Before that a zone's own figure and any hour are still exact, but a venue, location or whole-organisation day shows — rather than a sum that would count people several times.
Where the numbers come from. Gateways' sightings are rolled up every few minutes; a day is final the night after, and today is refreshed every 15 minutes. Door counts are the counters' own readings. Times are in your organisation's time zone.
Loyalty
/admin/report/loyalty
Whether the tags you are seeing are new or coming back, and how long since each was last here. The question behind it is retention: is the same population returning, or is it a different crowd each day?
The unit is a tag-day — One tag on one day, wherever in the venue it went. A tag here on three days counts three times across the range, once per day.
New — No earlier sighting on record. A tag the platform has simply not seen before will read as new even if the person is a regular.
Returning — Seen before, bucketed by how long ago: recent is within three days, then one, two, three and four-or-more weeks since the last visit. Short buckets are your regulars; long ones are people coming back after a gap.
Who is counted — Tags registered under Device › Sensor and heard by your gateways — badges, beacons and trackers that come and go with a person or an asset, not passing phones. On a workplace where everyone carries a badge this reads as attendance regularity rather than customer loyalty; the table at the bottom names the tags, which is usually the more useful view there.
Where the numbers come from. Once an hour the sensor trail is re-read and every tag's first sighting on each of your calendar days is classified against its own history, so today's figures are up to an hour behind. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.
Attendance
/admin/report/attendance
When each person with a tag was on site — first in, last out and the time in between that they were actually here — for a register, a timesheet check or a "was anyone in on Saturday". Click a name for that person's days and every stay behind them.
Who is counted — Every person on the Entity page (not assets), through the tags bound to them. Someone not carrying their tag is not seen; a tag left on a desk overnight keeps its owner "on site" — a day that starts at 00:00 or ends at 24:00 is carried over midnight, marked ↤ or ↦.
Time on site — The stays the Entity Tracker records (one per room) are merged, so two rooms, or two tags on one person, are never counted twice. A gap shorter than the gap that ends a visit (30 min by default) is a walk down a corridor no gateway hears and counts as on site; a longer gap starts a new visit. Time per floor is only the time actually heard on that floor, so the floors can add up to a little less than the day.
Outside — A tag with GPS (its own tracker, or a phone running Omaya Scout) reports time outside separately. It is never counted as on site, and a gap with GPS in it always ends the visit.
Field staff and working outside — Pick the label your field staff carry with the Field staff button. For them, time outside within working hours (your opening hours, else 08:00–18:00) on working days (your operating week, else Monday to Friday) counts as working outside — visits to clients, driving between sites — and with time on site makes their working time. A field day spent only outside counts as a day present. Time stopped at home never counts: home is the place their tag spends the night on 3 or more of the last 30 nights, worked out on its own and never shown. Until a home is known (a few nights after they start using GPS), time at home within working hours is counted, and their row says home not known yet.
Days counted — When your organisation has an operating week (System › Configuration › Organisation, or a floor's own opening days), Operating counts only the open days: days present, total and average time, the attendance rate and the By day table leave the closed days out, and their columns are hidden. A visit on a closed day is not lost: it shows as "+ N closed days" beside the person and in their days. All days counts every calendar day. The choice is only for this view and changes no setting.
Attendance rate — Days present out of the days counted that have begun and on which the gateways sent data — a day the site sent nothing is not held against anyone. Across the team it is person-days present out of people × those days.
Office days by team — For a return-to-office or hybrid policy. A team is a label on the person; someone with two labels counts in both, someone with none under No label. Office days a week is the counted days a person was on site divided by the calendar weeks in the range so far; Meet counts the people at or above the policy you pick (the choice is only for this view). The weekday columns are how many of the team were in on that weekday on average. Only people with a tag bound in the range are measured; the others are shown as "no tag", never as absent.
Late and left early — With opening hours set (System › Configuration › Organisation, or on the floor), a day on your operating week is late when the first in is more than the chosen margin after opening, and left early when the last out is more than it before closing. Not marked for a day carried over midnight, someone still here, an overnight site, or a stretch the gateways were not sending — after an outage everyone "arrives" when the data comes back.
Not in today — When the range includes today and today is an open day with data: the people not seen yet, and when they were last seen. Someone with no tag bound on the Entity page at any time in the range can never be seen, and is listed apart.
Here now — The tag was heard in the last five minutes. Their last out is the latest sighting so far.
Earliest arrival and latest leave — The earliest first-in and latest last-out clock time across the range, leaving out days carried over midnight and people still here.
Location and floor filters — Count only the time spent there — "attendance on Level 4". The group filter uses the tags on the Entity page (a department, a shift, a contractor firm).
Where the numbers come from. The entity trail (one row per stay, the same rows as Monitor › Entity and its replay). A stay that ended the moment it began is dropped, as the Entity Tracker drops it. Days are your organisation's time zone.
Asset Utilisation
/admin/report/asset-utilisation
How hard each tracked asset works — a trolley, a wheelchair, a forklift — where it spends its time, which ones sit idle, and which have gone missing. Click an asset for its days and every stay behind them.
Which assets — Every asset on the Entity page (not people), through the tags bound to it during the range — a tag moved to another asset since still counts for the time it was on this one. An asset with no tag bound in the range can never be seen; it is counted under Assets tracked as "no tag". Only an asset with a tag bound now can be missing.
Hours seen — The time its tag was heard anywhere, from the stays the Entity Tracker records. Gaps under 30 minutes are bridged (a corridor no gateway hears).
Moves and the shortest stop — A move is the asset arriving somewhere else and staying there at least the shortest stop (5 minutes by default). Shorter stops are passing through a room on the way, or the positioning flickering between two neighbouring rooms, and are not moves. Moves are read from where the asset was: a trolley pushed up and down one ward makes no move — that shows under Moving instead.
Base — Where the asset lives: the home zone of its tag (Devices) when one is set, otherwise the place it spent most time in over the range. Set a home zone for a steadier figure.
In use and utilisation — In use is time at a stop away from its base, plus the time on its way between two stops, plus — when its tag reports motion — every minute its accelerometer said it was moving, wherever it was. A minute that is both away and moving counts once. Each asset says where its figure comes from: from motion (location and accelerometer) or from location (where it was only — its tag model sends no motion, or none was recorded in the range). Utilisation is the in-use time inside opening hours, out of those opening hours on the days counted — leaving out hours the gateways sent nothing, and the time before the asset was added. For an asset from location, being used at its own base (a forklift working its home bay) reads 0 %: that figure measures being away, not working.
Moving — Minutes in which the tag's accelerometer said the asset was moving, counted while that tag was heard for this asset. Recorded for tags bound to assets only (never for people), a minute at a time, since 6 October 2026. A tag that sends a reading only now and then can miss short pushes, so this is a floor, not an exact count. Which tags report motion: Minew MWC01-type tags (their accelerometer, or the motion counter in Minew's own frame), MOKO BeaconX tags with the axis frame, and MOKO B2 / H8 buttons; Eddystone TLM and plain iBeacon tags do not.
Idle — Seen in the range, never moved, and — when its tag reports motion — never moving either. A tag left in a drawer, or on a trolley parked for good, looks the same.
Missing — Not seen anywhere for longer than the chosen days, as of now, whatever the date range — with where and when it was last seen, which is where to start looking. A tag that was taken off its trolley, or whose battery died, looks missing too; and if the gateways were down, everything does (the By day table shows no-data days).
Top places — Share of the hours seen spent in each room and floor. Only time actually heard there counts, so the places can add up to a little less than 100 %. Outside is the time a tag with GPS (a tracker, or a phone running Omaya Scout) spent outdoors.
Tag motion — When the tag's own accelerometer last reported movement, for tags that report it — the latest reading, as of now, whatever the date range. The figures use the minute-by-minute history (Moving) instead.
Days counted — With an operating week set (System › Configuration › Organisation, or a floor's own days and hours), Operating counts only open days and opening hours; a stay on a closed day shows in the asset's days but not in the totals. All days counts every hour of every day. The choice is only for this view.
Location and floor filters — Count only the time spent there. Missing and last seen always look everywhere.
Where the numbers come from. The entity trail (one row per stay, the same rows as Monitor › Entity and Attendance), and the asset tags' motion history (moving minutes per hour). A stay that ended the moment it began is dropped, as the Entity Tracker drops it. Days are your organisation's time zone.
Dwell Time
/admin/report/dwell-time
How long devices stay, bucketed by duration and broken down by zone. It answers whether a space is somewhere people pass through or somewhere they settle.
The unit is a stay — One registered sensor's continuous presence in one zone — not a person, and not a visit to the building. A device that crosses three zones produces three stays. Passing phones are not counted: only tags and sensors registered on the Devices page leave a trail.
Pass-by, visit, engaged — A stay of zero minutes — heard once, then gone — is a pass-by. A stay shorter than the venue's engaged threshold (dwell time on the venue, 5 minutes unless changed) is a visit; at or over it, engaged. The strip above names the threshold in force.
Buckets — Stays are grouped by length rather than averaged, because an average hides the shape: a zone with many brief stays and a few long ones averages to a number that describes neither.
Short stays — A zone beside a doorway collects a lot of very short stays from people walking past. Read the shortest bucket as traffic, not occupancy.
Where the numbers come from. Each stay is a row in the sensor trail, closed when the sensor is next heard somewhere else or falls silent. Once an hour those stays are bucketed into one row per zone per day — the day the stay began, on your calendar. A stay still in progress is counted with its length so far and moves up a bucket as it grows, so the newest hour's figures settle on the next run. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.
Flow
/admin/report/flow
Every tracked device leaves a trail of stays — “in this zone from this time to that time”. When two consecutive stays are in different zones and the second began soon after the first ended, the device moved — that is one move, and this report counts them for one floor over a date range. It answers where people go after they arrive somewhere: which rooms feed which, which corridor is actually used, and whether a route runs one way or both.
Moves — Zone-to-zone changes, not people. One device pacing between two rooms all afternoon produces many moves.
Devices — How many distinct devices produced those moves. Moves high and devices low means one tag is doing all the walking.
Return trips — The same route counted backwards. A route with almost none is a one-way door, a queue, or an exit; a route with roughly as many is an ordinary corridor.
Direction — Mostly one way when a direction beats its reverse by 1.5× or more, otherwise both ways. On the plan each pair of rooms is one line: an arrowhead at one end for mostly one way, at both ends for both ways, and its number is the moves in both directions together.
Min stay — Moves where the device was in the first zone for less than this are dropped — measured on the stay itself, from when it was placed there to when it was last heard there. Without it a zone next to a doorway collects a large number of moves from people who only passed through.
Max gap — How long the device may be out of sight between leaving the first zone and appearing in the second. A tag last seen in Sales at 10:15 and next seen in the Director Room at 18:22 did not walk between them; it left the floor and came back, and counting that as a route says the wrong thing about the corridor. Ten minutes by default; set it to any to see every zone change regardless.
All floors — pick it under Venue to follow people between floors. A trip is the same kind of move as above, except the two stays are on different floors. Choose a location, or All locations for the whole organisation.
Floors / Zones across floors — Floors counts trips from one floor to another. Zones across floors shows the same trips by the room they left and the room they arrived in, written as “Level 4 › Pantry”.
Typical time between — The middle value of the time between the device last being heard on the first floor and first being placed on the second — roughly how long the lift or the stairs took. Half the trips were quicker, half slower.
Ignore bounces under — A tag placed on another floor for a minute and then straight back on its own floor most likely never left — a gateway through the ceiling heard it for a moment. Any stay shorter than this with the same floor (or the same room) on both sides of it is ignored, and the stays either side are joined back up. Two minutes by default, the same line the positioning health check draws between a flicker and a real round trip. Set it to 0 to count everything.
Most common visits — One device over one day (your local day) is one visit: the places it stayed in, in order, with a place left out when the stay was shorter than Min stay and repeats run together. The list shows which sequences happened most often — “Level 4 → Level 5 → Level 4” is a trip upstairs and back. A tag that stayed on one floor all day is a visit to one place. Visits are counted in tags, so they describe the tracked people and things, not everyone in the building.
Zones need an outline drawn on the floor plan to be part of the picture — a zone with no outline has no place to put an arrow. Devices the positioning engine could not place are counted separately and are not in any route. Floors are drawn top floor first, using each floor's level number.
People Count
/admin/report/people-count
How many people were in each space, hour by hour. Unlike the device counts elsewhere in Reports, this is an occupancy figure: how many were present at a time, not how many passed through in total.
Occupancy, not visits — Twenty people for the whole afternoon and twenty different people passing through both read as twenty. Pair it with Dwell Time to tell those apart.
Source — Two kinds of count, never added together. A counting sensor — a radar or time-of-flight counter in the room — counts every person it sees, tagged or not, and only the ones inside its calibrated coverage. Tags present counts the registered tags the gateways placed in the zone, so a person without a tag is invisible to it. A tag fixed to an asset is left out: it is not a person. They will disagree wherever not everyone carries a tag; pick Exclude tags or Tags only under Data before comparing spaces.
Peak, not average — Each hour's figure is the most people seen at once in that hour. A room that held ten for a minute and two for the rest reads as ten — the number a capacity question needs; the hour's average is shown beside it in the per-space view. A tag figure is different: the tags heard in the room at some point in the hour, so it reads tags in the hour, not people at once. The Busiest hour card counts each tag once, however many rooms it passed in that hour.
Wi-Fi — With Wi-Fi switched on (System › Config › Wi-Fi) and a Kiwire Wi-Fi connector, Wi-Fi under Data shows the devices on the guest Wi-Fi in each zone, per hour. It is a count of devices, not people: a visitor with a phone and a laptop is two, someone who never joins the Wi-Fi is none, and a phone that changes its Wi-Fi address can count twice. It is shown on its own, never added to the sensor or tag figures. A Kiwire zone counts only once it is mapped to an Omaya zone on the connector.
Per hour, per space — Each cell is its own measurement. Do not add hours together to get a daily total; that counts the same people once an hour.
Where the numbers come from. Counting-sensor rows are updated on every reading the sensor sends, so the current hour is live to within a minute. Tags-present rows are recomputed every fifteen minutes from where the gateways last placed each tag. A day's peak and average are read straight from its hours — nothing is rebuilt overnight. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.
Room Usage Map
/admin/report/room-usage
Where people actually are inside a room, from a radar that reports each person's position. The heat map is the room seen from above: darker cells are where people spent more time over the selected days. A meeting room whose far end never lights up is a room that could be smaller; a desk area with two dark spots and six empty ones is two desks in use.
Only people inside the room's counting area count — the radar sees through glass, and the calibration on the device page tells it where the walls are. Peak occupancy is the most people inside at one moment; average group is the mean while somebody was there; hours occupied are hours with anyone inside, shown against the venue's operating hours that have already happened (a range ending today does not count this afternoon against the room). Time in use counts each radar sighting for the gap to the radar's next reading — it reads every few seconds, not every second, so counting sightings alone would show a full hour as a few minutes.
A radar writes a position only while it sees somebody, so an empty hour and an hour the radar was off look the same in the positions. The coverage line under the heat map uses the radar's own count rows — written on every reading, zero included — to say how many of the hours judged it was actually awake for; when that is under 80%, the usage figures are a floor, not a verdict.
Rooms appear here only once their radar has been calibrated. The radar places up to five people per frame (ten when paged), so a very full room is sampled rather than counted exactly.
Space Utilisation
/admin/report/space-utilisation
Every zone side by side: how much of its operating time it was occupied, how many people it typically held, whether it ever ran at capacity, and — where the venue has a cost per m² — what the empty hours cost. The portfolio question: which rooms are too big, which too small, and what the underused floor area is buying.
Occupied — An operating hour in which at least one person was seen. The share is taken over the operating hours that have already happened, so a range that ends today does not count this afternoon against a room. The full count of operating hours in range is in the Hours column's tooltip.
Who is counted — Where a zone has a radar or counting sensor, everyone in its coverage. Elsewhere, only people carrying a registered BLE tag — those zones under-report wherever not everyone is tagged, and the seat-planning confidence column says how many zones in a venue count everyone.
Sensor gap — A counting sensor that fell silent leaves hours that are unknown, not empty. A zone whose sensor reported in under 80% of the elapsed operating hours is marked with a warning and a ? on its verdict: its occupancy is a floor. The row names the sensor and when it was last heard; the Devices page has the rest.
Typical and peak — Typical is the 90th-percentile hourly peak among occupied hours — the headcount the room needs to fit on a normal busy hour. Peak is the single highest. Both are shown against capacity when one is set.
Verdict — Unused: never occupied. Underused: occupied under 25% of operating hours. Busy: 70% or more. In use: between. A room used for one long meeting a day and a room used for eight short ones can share a verdict; the hour-of-day profile tells them apart.
Days counted — When your organisation has an operating week (System › Configuration › Organisation, or a venue's own opening days — each venue uses its own), Operating counts only the open days: a room empty all weekend is not marked down for it. All days counts every calendar day inside the same opening hours. Nothing that happened on a closed day is lost: a note above the table says how many occupied hours fell on closed days and in how many zones. The hour-of-day profile and the peak count every hour either way. The choice is only for this view and changes no setting.
Buildings — A floor is the unit a lease can hand back, so savings are counted in whole floors. Each floor's need is its typical busy hour plus 10% headroom; the floors with the smallest need are moved, one at a time, into the spare seats on the building's other floors, and a floor whose people all fit elsewhere is counted as one that could be given back — its full floor area and rent. Per used m² is the venue's cost per m² divided by the occupied share: a floor at 100 per m² used a quarter of the time costs 400 per used m². Areas and costs are shown in the organisation's area unit (Configuration → General → Area Unit). Opportunity: a floor could go, or a quarter of seats are spare. Alert: rooms occupied under 25% of opening hours and nothing to consolidate. Resilient: seats match need. A building needs seat capacities and 20 measured opening hours to be scored; where rooms count only tagged people, need is a floor and the row says so. Seats are workplace seats only: the capacity of zones whose kind is work room, open area or desk (a desk with no capacity is one seat); meeting rooms, toilets and pantries are not counted. Floor area is the venue's rented area when set, else the scaled floor plan (a rectangle round the whole floor, often larger than what the lease charges for), else the rooms added up.
Idle cost — The zone's floor area (set on the zone, or taken from the polygon drawn on the floor plan) times the venue's cost per m² per month, times the empty share of operating hours. Only shown when the venue has a cost.
Where the numbers come from. The hourly People Count rows — a counting sensor's rows are updated on every reading, tag rows every fifteen minutes — bucketed into tenant-local days and hours against the venue's operating hours and days. Operating hours come from the venue (or the tenant default); capacity, area and cost from the zone and venue under Spaces. Nothing is rebuilt overnight: the current hour is live.
Heatmap
/admin/report/heatmap
Where activity concentrated, drawn on the venue's floor plan. Use it to see at a glance which parts of a floor carried the traffic over a date range. The three overlays answer different questions and come from different data, so pick by the question, not by which looks busiest.
Zone presence (dwell) — the default — Zones tinted by how much time registered sensors spent in them, straight from the sensor trail. The best answer to "where were people", because it uses every sighting rather than only doorway crossings — but it counts tags, not phones: a person without a tag leaves no presence.
Zone traffic (enter/exit) — Zones tinted by door-counter crossings, which count everyone who passes the counter, tagged or not. Only zones with a counter on them can ever light up, so a dark zone here may simply have no sensor; most crossings on a floor without zone-mapped counters fall to the venue rather than a zone.
Gateways — Intensity around each gateway's position rather than by room. Useful for judging sensor coverage, not for reading room occupancy.
Zones need an outline — A zone with no polygon drawn on the floor plan cannot be shaded. It is listed under the map instead so its activity is not silently lost.
Where the numbers come from. Presence reads the sensor trail directly — a stay is written when a sensor is placed in a zone and closed within a minute of it leaving or falling silent, so this overlay is current to about a minute. Traffic and the gateway overlay read the enter/exit rollup, rebuilt every five minutes from door-counter and gateway packets. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.
Detection Heatmap
/admin/report/heatmap-total
A grid of venues, zones or locations against days (or hours of the day), each cell shaded by how many distinct BLE devices were detected there. Brighter is busier. Good for spotting the pattern of a week at a glance — which days, which spaces — and for seeing where the gateways can hear at all, which is a different question from where people are.
Devices, not people — Registered tags a gateway heard (a device you have not registered is not kept, so it is never counted); fixed sensors and actuators are left out. By zone, a tag is counted once in every zone it was seen in, so a person walking through four zones adds one to each. By venue or location, each tag counts once for the place however many rooms it went through (the Footfall figure). A person carrying two tags counts twice.
Distinct per cell — Within one cell a device counts once however many times it was seen. Cells do not add up across the grid: the same device is in every cell it visited.
Daily and hourly — Daily cells are your calendar days, midnight to midnight on your clock. Hourly cells are the hour of the day on your clock, summed across every day in the range — a device seen at 10:00 on five days adds five.
Where the numbers come from. The hourly rows are rolled up from packets every five minutes, so the hourly view is current to about five minutes. The daily row for a day is built once, just after that day ends on your clock, from every packet of the day — so today has no daily cell yet, and yesterday's appears in the morning. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.
Environment
/admin/report/environment
Temperature, humidity, noise, light and air pressure from environmental sensors, hour by hour and per room, with a Compliance tab that measures rooms against a spec range. Light and pressure cards appear only when something in the range measured them.
Readings are per sensor, not per room — A sensor measures its own position. One near a vent or a window will disagree with the rest of the room, and that is the sensor being right about where it is rather than wrong about the room.
Thresholds and alerts — This page sets no thresholds. A limit on a metric is a rule — set one under Rules on temperature, humidity or noise and it alerts when crossed; the strip under the cards shows what fired in the last 30 days, or says that nothing is set. The Compliance tab is different: it re-reads the history against each room's compliance profile, so changing a profile changes the past figures too; it is a statement about the limits in force now.
Fixed sensor or tag — A wall or ceiling sensor measures the room; a roaming tag measures its own case, in a pocket or on a desk. The two are never averaged together — the card takes the fixed reading where the scope has one, and says "tag-derived" when it does not. Temperature shows in the unit set on the organisation.
Temperature — Air temperature from a sensor with a thermometer — an FP300, a Minew S1, a Moko H4 Pro, a Milesight AM, a LoRaWAN or Home Assistant temperature entity. A sensor reads its own spot: on a sunlit wall it reads the wall, by the supply grille it reads the air-con. The strip under the chart counts room-hours over-cooled (under 23 °C — set-points below the band cost energy), comfortable (23–26 °C, the MS 1525 / ASHRAE 55 band for a cooled building), warm and hot (over 28 °C), with the longest hot run, from fixed sensors only — a roaming tag measures its own case and ran +2.56 °C over the wall sensor in the same room. An air conditioner bridged from Home Assistant is not a room sensor either: what it reports as "temperature" is its own idea of the room (the return-grille thermistor, or a fixed placeholder on an IR controller), and it is carried as the AC's own reading beside its set-point and on/off for rules, never as the room. The hour is the average of every reading in it; a rule reads the latest. Shown in the unit set on the organisation.
Humidity — Relative humidity in % from a sensor with a hygrometer — most temperature sensors have one (FP300, Minew S1, Moko H4 Pro, Milesight AM, a Home Assistant humidity entity). Relative means relative to the temperature: the same air reads wetter as it cools, so a room's humidity climbs overnight when the air-con stops without a drop of water entering it. 40–60 % is the comfort band; under 40 % is dry (static, dry eyes); over 60 % is damp and at or above 70 % sustained, mould takes hold — the strip under the chart counts the room-hours in each and the longest run at mould risk, from fixed sensors only. The dew point is the temperature at which the air's water condenses: a surface colder than it — a window at night, a duct off the chiller — runs wet. The hour is the average of every reading in it; a rule reads the latest reading.
Noise — Sound level in dBA from a sensor with a microphone — a Moko H4 Pro with the microphone option, a LoRaWAN sound sensor, a Home Assistant sound entity, or a sensor you onboarded with a noise_dba field. A microphone hears its own spot: one by the door hears the corridor. Each hour's figure is the average of every reading in the hour, with the hour's quietest and loudest reading as min and max — the peak is what matters for noise, and a reading taken at five to the hour is not the hour. The strip under the chart counts room-hours quiet (under 45 dBA, the WHO background for offices and classrooms), moderate (45–55, a working office), loud (55–70, voices raised to be heard) and very loud (over 70), with the longest loud run and the single loudest reading — the one a complaint is about. A rule on noise reads the latest reading, not the hour.
Light — Illuminance in lux from a sensor with a light meter — a Milesight AM-series or FP300, a Home Assistant illuminance entity, a LoRaWAN sensor, or one you onboarded with an illuminance field. The meter reads the light falling on it: face it at the desk, not the window or the lamp. As a guide, a corridor is 100 lux, an office desk 300–500, detailed work 750 and above; a room that reads under 10 lux is dark, and a sensor that never moves off one figure (3 lux, all day) is covered or facing a wall. The hour is the average of every reading in it with the darkest and brightest — a room lit for fifty minutes and switched off at five to is a lit hour, not a dark one. A rule reads the latest reading (illuminance), and the Meeting Room app shows the room's latest reading as a chip.
Pressure — Air pressure in hPa from a sensor with a barometer — a Milesight AM300 series, a LoRaWAN or Home Assistant pressure entity, or one you onboarded with a pressure field (a sensor reporting in Pa, kPa, inHg or psi is converted). Indoors and outdoors read the same pressure: a building does not hold the air in, so the number is the weather's, not the room's, and the barometer is really a weather instrument in the room. What matters is its direction — falling more than 1 hPa in three hours means rain is coming, rising means it is clearing — so the Outside strip shows the trend, and the chart draws the outside pressure from Open-Meteo under the room's as a dashed line. A room that reads more than 5 hPa off outside has a sensor that needs calibrating (a lift of 8 m reads about 1 hPa lower, no more). The hour is the average of every reading in it; a rule reads the latest.
Air quality — CO₂, PM2.5, PM10, TVOC and other pollutants from a sensor that measures them — a Home Assistant air-quality entity, a LoRaWAN sensor, or one you onboarded. Each pollutant the range holds gets a card of its own, in the sensor's unit; a range with none shows none. The hour is the average of every reading in it with its lowest and highest, and a fixed sensor is the room. As a guide: CO₂ under 800 ppm is fresh, over 1,000 ppm a room needs more air; PM2.5 over 25 µg/m³ over a day is poor. A rule reads the latest reading by the pollutant's name (co2, pm25 …).
Outside — The weather at the location, hour by hour, from Open-Meteo at the location's latitude and longitude (set under Locations). It is a weather model's figure for the few kilometres around the building, not a sensor on the roof — right for "was it hot outside", not for tenths of a degree. The trend chart draws it as a dashed line beside the inside reading for temperature and humidity, and the strip above compares the two over the same hours using fixed sensors only. With several locations, pick one (or a venue or zone in it) to see its outside.
Gaps — A flat line is not the same as a stable room. A sensor that stopped reporting leaves a gap, so check the battery report if a series goes suspiciously quiet.
Compliance tab — Each room is checked against its own compliance profile: limits per reading (temperature, humidity, CO₂, noise — a reading the room has no fixed sensor for is not checked), the hours they apply to, and how an hour is judged. Office comfort is 23–26 °C and 40–60 %RH (the Live tab's own comfort bands), CO₂ up to 1000 ppm and noise up to 55 dBA, in opening hours, judged on each hour's average — so its hours out match the Live tab's hours outside comfort. Cold chain (2–8 °C), Frozen (−18 °C or colder) and Controlled room (15–25 °C) are checked every hour on every reading: a door left open for ten minutes at 12 °C puts the hour out although it averaged 6. Server room uses the Data Centre app's ASHRAE envelope (18–27 °C, up to 70 %RH), every hour. Custom takes your own limits.
Which profile a room has — The room's own (Space › Zones, or Set profiles on the tab), else its venue's default, else the organisation's, else Office comfort — and the tab names the rooms on that last default, because nobody chose it for them.
Compliance figures — Rooms that stayed in range: rooms with readings and no checked hour out of range. Days in range: room-days with readings and no hour out, over room-days with readings. Hours out of range: checked hours with any reading outside its limit, with the longest unbroken run per room. Hours with no data: checked hours with no reading at all — never a breach and never in range; a day with none is a day with no data. Hours checked: each room's profile, or all day / operating hours for every room. Days counted (above) decides whether closed days count for rooms checked in opening hours; a room checked every hour counts every day. Any date range up to a year, in the organisation's time zone; today counts the hours that have ended. Only fixed sensors count; a room with only tags shows as No fixed sensor. Mean kinetic temperature (USP <1079>) is shown for cold-store profiles only. The CSV carries the same rows, every day out of range by reading, and every day with no data.
Zone compare
/admin/report/zone-compare
The same figures for two sides, with the change between them. Either two zones over the same days, or one zone or venue over two periods — this week against last week, this month against the same month last year, or any two date ranges. Days and hours are on your site's clock.
Devices a day — Distinct registered tags seen in the place each day, averaged over the days of the period. A device that came back three times in a day counts once. Visits is the same figure added up over the period: one device on five days is five visits, not five people.
Entries — Counted by door counters only, a day on average and in total. A place with no door counter shows a dash — tags seen in a room are not entries.
Most people at once, average people present — From the room's counting sensor when it has one; otherwise from the tags the gateways saw there, which misses anyone without a tag ("People counted by" says which). The average is over the hours the place reported, nights included. Occupied/vacant sensors only say whether a room is in use, not how many are in it, so they are not used here. For a venue the zones are added up hour by hour, so its "most at once" is an upper bound.
Hours at or over capacity — The share of hours whose busiest moment reached the capacity set on the zone. A zone with no capacity recorded shows a dash.
Busiest hour and busiest weekday — The hour of the day, and the day of the week, with the most people present on average over the period.
Anomalies, low-battery readings, work orders — Counted for the devices that belong to the place now, over the whole period.
Days counted — When your organisation has an operating week (System › Configuration › Organisation, or a venue's own opening days — each place uses its venue's week), Operating counts only the open days: devices and entries a day, visits, people present, busiest hour and weekday, and the day-by-day charts leave the closed days out, so a weekend does not pull a weekday office down. What the closed days held is not lost: a note under the table says how many visits and door entries fell on them. All days counts every calendar day. Anomalies, low-battery readings and work orders are counted over the whole period either way. The choice is only for this view and changes no setting.
The change column — How much higher or lower the first side is than the second, in percent. With two periods it is the change against the earlier one. Red marks the side with more capacity breaches, anomalies, battery warnings or work orders; for the rest a difference is not a verdict — higher occupancy is good in a shop and bad in a fire escape.
Battery
/admin/report/battery
Battery levels reported by BLE devices over time, so you can find the units that will need attention before they go quiet.
Levels are self-reported — The figure is whatever the device says, and different models estimate differently. Compare a device against its own history rather than against another model.
The shape matters more than the number — A steady decline is normal ageing. A cliff usually means cold, a bad battery, or a device transmitting far more often than it should.
A device that stops reporting — ...stops reporting its battery too. The last known level is the last thing it said, not its level now. Some models send the battery in its own frame less often than the rest, so a level can be days old on a device heard this morning — the card says how old.
Alerts — The nightly check raises low under 20 % and critical under 10 %, once per episode: a cell that stays low is one alert until someone acknowledges it or the device comes back above 25 %, when the alert closes itself as recovered. A low that worsens becomes one critical alert (and a work order, unless that is switched off in the Facility app's settings), not a fresh row every day. The Battery column shows the level the alert was raised at and, when it differs, what the device says now.
The forecast — "~N d to replace" is the nightly battery check's estimate: a straight line through the last fourteen days of daily minimums, run down to the 20 % alert threshold. It is not given when the level is already below 20 % (the alert applies instead), when there are fewer than five days of readings, or when the level is not falling — which on a mains- or USB-powered sensor is the normal state, and on a tag means a fresh cell. Levels are self-reported and step in whole percents, so a slope under 0.1 %/day is treated as flat.
Where the numbers come from. Every packet that carries a battery level updates the device's current level and its hourly row in the battery report, so the history is current to the last packet. The forecast on each device is recomputed once a night. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.
Distance
/admin/report/distance
What the time-of-flight sensors measured: the distance, in millimetres, from each sensor to the nearest thing in front of it. Use it to see whether a bay, bed, bin or doorway was occupied or clear through the day, and to check a sensor is aimed at what you meant.
One cell is one hour, showing the last reading in it — The sensor broadcasts several times a minute. The cell shows the hour's last reading; a cell with a dot underneath changed during the hour — hover it for the hour's range. Min and max on each sensor and day cover every reading, so a bay occupied at ten past and empty at five to still shows its closest reading. Hours before 23 October 2026 kept only the last reading.
Blank is "nothing in range", or silence — The sensor reports no distance when nothing is within its reach (about 3 m for the SO2R) — an empty corridor is blank, and so is a sensor that is switched off. The battery report tells the two apart.
Occupied, how full, or a crossing — that is calibration, not this page — The device's page has a Distance calibration panel: teach the sensor its empty reading and pick a mode. Occupancy then reaches Right Now like a PIR, level reaches the rule engine as a percentage and a band, and crossings reach the traffic reports. This page keeps showing the raw distance either way.
Range — 40 mm to 3,000 mm, in a 27° cone. Anything the sensor cannot physically measure is dropped before it reaches this page rather than clipped to the limit.
Two gateways, one reading — A sensor heard by more than one gateway is recorded once per gateway; this page shows each sensor once.
Where the numbers come from. Written the moment each packet is decoded, into an hourly slot per sensor. Times are in your organisation's time zone. Old monthly partitions are dropped on your tenant's retention setting.
Door & State
/admin/report/door-state
What door, leak, power and air-con sensors reported, as stretches of time: when each door opened and closed, how long it stayed open, and which ones are open now. Use it to find doors left open, cold rooms opened too often, a leak and when it started, or air-conditioning left running.
Times opened — Openings that began inside the range. A door already open when the range starts adds its time but not an opening.
After hours — Openings outside your opening days and hours (System › Configuration › Opening hours). Shown only once those are set.
Air-con mode — For air-cons read through Home Assistant: the mode (cool, dry, fan only…) and fan speed while it was on, under the air-con's row and beside each time it was on. Recorded since 24 October 2026.
Recorded since 23 October 2026 — Before that only the latest state was kept. A sensor's first row after that date says "first reading": its state before it is not known.
Where the numbers come from. One row each time a sensor's state changes, written the moment the packet is decoded, once however many gateways relay it. Times are in your organisation's time zone.
Tag Health
/admin/report/tag-health
What each tag says about itself: its battery voltage, how fast that is falling, how warm its electronics run, and how often it restarted. Use it to change batteries before tags go quiet, and to find tags that keep restarting (a loose battery, a failing cell, a tag in the cold).
Change soon — Below the low-voltage line set for its model, or on course to cross it within 30 days at the rate it fell over the range. Lines are set per model under System › Configuration › IoT, "Tag batteries".
Falling — The day's lowest reading, first day against last, per day. Needs three days or more; voltage also sags in the cold and recovers, so read it over a week.
Restarts — Counted when the tag's own uptime counter goes backwards: a battery change, a brown-out, or a crash. Only tags that broadcast their uptime (Eddystone TLM) can show them.
LoRa signal — For LoRaWAN devices: the average signal-to-noise ratio (SNR) the gateways heard, the worst hour, and the spreading factor (SF) the device used. Each SF has an SNR below which a gateway can no longer decode it (−7.5 dB at SF7 down to −20 dB at SF12). Strong means the worst hour stayed 10 dB or more above that floor, fair 5 dB or more, weak less: some messages are likely lost. A high SF on its own also means the device is far from its gateway. Recorded since 24 October 2026.
Recorded since 23 October 2026 — Before that only the latest reading was kept.
Where the numbers come from. One row per tag per hour, holding the hour's latest, lowest and highest reading. Times are in your organisation's time zone.
Trigger Event
/admin/report/button-press
Trigger events raised by devices — double-click, triple-click, motion, and any other press type registered for the hardware you run. Use it to see what was pressed, where, and when.
Presses and other events — Total Presses, the peak hour, the most common type and the venue cards count presses only. A tag being picked up (motion) and a worn button that has lain still too long (inactivity alarm) are written to the same table but are not presses: they are counted apart under Total Presses, labelled "not a press" in the breakdown and the Events table, and marked in the CSV. Rules see them the same way — "Button pressed" does not fire on either.
One row is one event — Not one person and not one incident. A panic button held down or pressed repeatedly produces several rows.
Press types depend on the device — What counts as a double-click is decided by the hardware and its decoder, so two models can report the same physical action differently.
Absence is not silence — No events for a device could mean nothing happened, or that the device is flat or out of range. Cross-check against the battery report.
Raised — A press pages people only when it matches a panic-button routing (Devices → Panic Buttons: by the device, by press type, or by the button's id). The Events table marks the presses that did and names the routing; a press from a device not registered on the Devices page can never match one.
Where the numbers come from. Every press is written as its own row the moment the packet arrives — nothing is rolled up or rebuilt. A button advertises the same press for several seconds and more than one gateway may hear it; the decoder keeps one row per press, credited to the gateway that reported it first. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.
Sensor Status
/admin/report/device-status
Every hour a registered sensor is heard by a gateway is written to the device-status table, with a note of whether anything it sent that hour decoded to a reading. This report reads those hours back for the range you pick and shows, per sensor, the share of hours it was heard in — availability — and a strip of the hours themselves, so a sensor that drops out every night looks different from one that died on Tuesday.
Fixed sensors, tags, actuators — The page opens on fixed sensors, the ones expected every hour, and the bar at the top is their health. Tags and trackers move on and off site, so they have their own tab and are measured only while on site. Actuators report on change only and are listed without a score.
Heard is not the same as delivering — A green hour carried a reading, a count or an event. An amber hour means the gateway heard the sensor's radio but nothing it sent could be decoded — a temperature sensor advertising only its device-info frame, a switch whose state is not a measurement. A sensor that is amber all range long is alive and not reporting: look at the sensor's model and advertising settings, not at the gateway. Hours before 15 Sep 2026 were recorded on decode only, so older history has no amber.
Availability is against the sensor's own expectations — A fixed sensor is expected every hour from the hour it was registered — a sensor added mid-range is not marked absent for the days before it existed. A tag is expected only while it is on site; its hours off site are not counted against it, so its availability is measured over the hours from its first to its last sighting in the range. In the strip, a pale red hour was expected and missed; an outlined hour was not expected (before registration, or still to come).
Which gateway heard it — A sensor heard by one gateway only is a sensor that goes dark when that gateway does, and is flagged. Hover the gateway count for the list and the hours each one heard it. A sensor behind the Home Assistant bridge lists the bridge.
Now — The state on the Devices page's rule: reporting within the last hour, late inside its own silence threshold, silent past it. It can say reporting next to a low availability — that is a sensor that is heard now but was not for much of the range, or one heard without readings.
Gateway Availability
/admin/report/gateway-availability
How much of the chosen period each gateway was up, as a figure you can hand to a customer or hold a contractor to. Click a gateway for its outages one by one.
Up and down — Since the outage log started (the date is shown above the table), every outage is recorded as it happens: it runs from the gateway's last packet to the first packet after, to the minute, and downtime is exactly that long. A gateway counts as down once it has been silent for 15 minutes (a LoRaWAN gateway, which is only heard when a sensor sends, after 60), so shorter gaps are not outages; when they do become one, the time counts from the last packet, not from when it was noticed. Before the log started the figures are to the hour: a gateway was up for an hour when it passed on at least one packet from a registered sensor or tag in that hour, and down when it passed on nothing, so an outage shorter than an hour that does not empty a whole hour is not seen and an outage is shown from the start of its first silent hour to the end of its last. A range that spans the start mixes the two, adding up minutes either way.
Silent is not always down — A BLE gateway passes on data only when it hears a sensor or tag. In an empty building at night or on a closed day it may hear nothing, and that looks exactly like a gateway that is switched off. So when your organisation has opening hours, the report measures on them by default, the timeline shows silence outside them in grey rather than red, and the outage count and longest outage at the top count only the hours inside them. Fixed beacons or sensors near a gateway keep it heard around the clock. Removed gateways stay in the table, faded, but are left out of the figure at the top.
Timeline — One cell per hour. Red is down for the whole hour, amber is down for part of it (exact period only); point at a cell to see the outage's exact start and end.
Which hours count — Only finished hours while the gateway existed: a gateway added during the period counts from the first whole hour after it was added, and one removed counts until the last whole hour before it was removed. Hours before the platform has any record are not counted, nor is the hour in progress. A disabled gateway is left out. The gateway's quiet hours (expected silence, set on the Gateways page) are left out too, as they are for the offline alerts; there is no separate planned-maintenance setting.
Availability, all hours — Time up out of the time counted.
Availability, operating hours — The same, counting only the hours inside the opening hours (System › Configuration › Organisation, or the floor's own) on the open days. Days counted switches the open days off for this view (every day, still within the opening hours). Shown when your organisation has an operating schedule.
Outages, longest, downtime — An outage is one silence from last packet to first packet after (to the hour before the log started: an unbroken run of down hours, which quiet hours inside it do not end). Downtime is the time down inside the hours counted, added up, so an outage that runs into quiet hours or past the period counts only its part inside. An outage marked ongoing was still on at the end of the period, and one marked from the start was already on at the first hour counted, so it began earlier. Every gateway went silent together marks an outage where all of the site's gateways stopped within the same 15 minutes: usually the building's network or power, not the gateway.
Keeps dropping — A gateway with three or more outages of its own a week (the same line as the OAIA finding), counted from the exact outage log. Outages it shared, when another gateway went down within 15 minutes or the whole site did, are left out and shown as with other gateways: those point at the building's power or network, not the gateway. A gateway that keeps dropping on its own usually needs its power, Wi-Fi or placement looked at.
Clock — How far the gateway's clock is off right now, from its messages in the last five minutes. Shown only when the range runs to today. A gateway whose clock is off by more than the limit under System › Configuration has its messages left out of positioning while still showing online; admins are told once it has been out for 15 minutes.
MTBF and MTTR — Mean time between failures: time up divided by the number of outages. Mean time to repair: time down divided by the number of outages. Shown only when there was at least one outage.
SLA target — Gateways whose availability (opening hours by default where you have them, or all hours) is below the target carry a below target tag and a red edge. Changing the target re-checks at once.
By location and floor — Every gateway's hours added together, so a gateway in service for a week weighs a quarter of one in service all month. Never an average of the gateways' percentages.
Current state and last seen — Live, from the Gateways page: online, stale (quiet for a few minutes) or offline now, and the last packet.
Where the numbers come from. Since the outage log started (6 Oct 2026, or when the gateway was added): the gateway outage log, written every minute from each gateway's last-seen time. Before that: the hourly sensor-status record (the same rows as Sensor Status), one row per device, gateway and hour heard; before 15 Sep 2026 a row was written only when a packet decoded, so a gateway hearing only undecodable frames looked silent then. Times are your organisation's time zone. The offline alerts themselves are not used: they are left out in quiet hours and raised about 15 minutes after the last packet.
Sensor Trail
/admin/report/device-trail
Where a registered tag went and how long it stayed — indoors zone by zone, and outside from the tag's own GPS, with the time on site, the time outside and the distance travelled each day. Pick an entity instead of a sensor to follow a person or asset across every tag bound to them.
Registered sensors only — This follows tags you have registered, not passing phones. If a device is not in your list it has no trail here.
A zone change needs a position fix — The trail is built from positions the engine could resolve. Where coverage is thin the device may appear to jump, or to sit still while it was moving. The How column says what each stay rests on: triangulated, fused or bounded fixes are positions; presence is only "the nearest gateway is in this zone". "How it was positioned" totals that up for the range.
Stays that cross the range — A stay belongs to the range if any part of it falls inside — a tag that settled somewhere last night and is still there is where that tag is today. Such a stay is marked ← before range; the time tiles and "Where the time went" count only the part inside the range, the Dwell column shows the whole stay.
Still here — A device's latest stay, last seen within the last ten minutes, has not ended. Its Left says so instead of showing the last sighting as if the device had gone.
One stay, several pieces — The engine writes a new piece each time it places the device in a different zone. Pieces on the same floor less than five minutes apart are shown as one stay — a tag drifting between two adjacent zones is one visit to that floor — and the row then names the zones with the time in each. "Where the time went" and "How it was positioned" are counted on the pieces, so a floor-level stay still credits each zone with its own time. Leaving a floor and coming back is two stays.
A stay marked "overlaps later stays" — The engine reopened an old stay when the device came back to that zone, stretching it over hours the device spent elsewhere. Rows written before 15 Sep 2026 can carry this; the "Where the time went" total credits that zone with more than its share for such rows. Fixed at the writer since.
On site, outside and distance — Indoors is where the gateways placed the tag; outside is the tag's own GPS (a tracker's, or the fixes a phone running Omaya Scout relays for it). On site, first in and last out are counted as on Attendance: stays joined into visits, a gap of up to 30 minutes with no time outside in it (a corridor no gateway hears) still on site. Trips and stops count on the day they start; distance is trips only. Distance adds up the trips; a trip across midnight is shared between the two days by its time, and the same trip recorded by two tags of one person counts once. A long stretch outside is real when its fixes keep coming: a tag at home overnight is outside all night.
Per day, and the Outside tab — Click a day to show only that day in the tiles, the tabs and the map; click it again, or Show every day, to go back. Indoors is the zone trail; Outside appears only when the tag reported GPS in the range, with the route, the journey stretch by stretch, and where the time outside went.
Entity mode — Follows the person or asset rather than the hardware, stitching together every tag bound to them — so replacing a tag does not break the history.
Outdoor Activity
/admin/report/outdoor-activity
What your people and assets did while they were outside — a field worker, a van, a container. A tag has GPS from its own receiver (a tracker) or from a phone running Omaya Scout that hears it. Use it to see who was out, for how long and how far they went, which of your places they visited, and where they stopped that is not one of them.
Three kinds of stretch — Geofence visit — time inside a geofence you drew on the Location page. Stop — the tag stayed put outside every geofence for at least the stop time in Configuration › Outdoor & GPS; it is named after the nearest place when one is close. Trip — moving between them.
Time outside is time on GPS — From a tag's first fix outside to the last one before it went indoors (a BLE gateway heard it) or fell silent. Indoor time is on the Sensor Trail and the presence reports, not here.
Distance is the straight line between fixes — Counted on trips only (GPS wobble while stopped is not travel), summed fix to fix, so it is a little shorter than the road on a winding route and depends on how often the tag reports (a tracker, or the Scout phone carrying it). A trip that crosses midnight, or the edge of the range, is split by time and its distance with it.
The same stretches as the Sensor Trail — Open a person or tag on the Sensor Trail to see the stretches on a map, or replay them from Monitor › Entity.
Where they went — Every stop and geofence visit on a map and as a list, longest first. Stops within 150 m of each other are one spot. A spot outside your geofences is named by its distance and direction from your nearest site or geofence — "1.2 km north-east of Setiawalk Block C1" — worked out here from your own places, and by default the coordinates are not sent anywhere to be named. Turn on Street names in System › Config › Outdoor & GPS to show the street as well, looked up on OpenStreetMap (which then receives those coordinates; answers are cached for 30 days). The dashed line joins the stretches in order in a straight line; Replay shows the road actually taken.
Many stops in the same unnamed spot? — The Location page lists frequent stops and turns one into a geofence in a click, so it is named here from then on.
Where the numbers come from. Every GPS fix is kept in the location reports; the trail holds one row per visit, trip or stop. Times are in your organisation's time zone. GPS fixes follow your data retention setting and are pruned nightly; a stretch older than that keeps its times but loses its distance.
GPS Replay
/admin/report/gps-replay
Every GPS fix of a tag in the range, in order — from the tracker's own GPS, or from an Omaya Scout phone that heard the tag over Bluetooth and sent its own position. Press play to watch the tag move; the card beside the map says where it was at that moment and what the fix behind it was.
Stop — The tag stayed within the stop radius for at least the stop time in Configuration › Outdoor & GPS. It is named after the geofence it was in; otherwise by its distance and direction from your nearest site, and by its street when Street names is on in that configuration. Its length runs from its first fix to its last.
Journey — The stops and trips beside the map, in order. The one under the playhead is highlighted; click any to jump there. Fix details under the clock and Signal details at the bottom hold the radio side: which phone or tracker sent each fix, how many phones heard it, how accurate it was.
Travelling and not heard — Between two stops the tag was travelling; the distance is the straight line from fix to fix. When no fix came for longer than New trip after silence, the way it went is not known and the bar shows it hatched.
Phones — For Scout fixes: how many different phones heard the tag. Many phones near one tag send one fix per window — the one from the phone with the best position — so a crowd does not crowd the map.
Tag ↔ phone — How far the tag was from the phone that placed it, estimated from the Bluetooth signal (about 1–60 m). The circle on the map is the whole uncertainty: the phone's own GPS accuracy plus that distance.
Where the numbers come from. The GPS fixes in the location reports and, for Scout, the phone sightings. Up to 5000 fixes and 7 days load at once. Times are in your organisation's time zone.
Rule & Alert Effectiveness
/admin/report/rule-effectiveness
Whether your rules and alerts are doing their job: a rule that fires fifty times a day trains people to ignore it, a rule that never fires may be watching the wrong thing, and an alert nobody acknowledges is an alert nobody saw.
Firings — One per time a rule's conditions were met and its actions were sent — a rule fires at most once per its cooldown ("act every"), and a tag rule once per cooldown per device. Devices is how many different devices set it off (zone and venue rules are not about one device and show —).
Did anyone hear about it — Each firing is counted once, by its messages — an in-app alert, a push, an e-mail, a chat or SMS message, a webhook, a page. Notified — at least one message was handed to its channel. Failed — none went out and one failed after three attempts; the error is on the row. Skipped — none went out because the channel needs a connector (SMS, WhatsApp…) or a recipient your organisation has not set up. Queued — not sent yet, or the queue lost it. No message — the rule only does things (adds a data-table row, publishes MQTT, switches a device, raises a work order), so there was nobody to tell. The five add up to the firings. "Notified" means handed over: a mail server that later rejects an address still reads notified.
Deleted rules — Left out, as in every other report. If a deleted rule fired in the range, the Rules card says how many firings were left out.
Never fired — Active rules with no firing in the range. Some are meant to be rare (a fire alarm); most should be looked at. The ever column is the rule's own last-fired time, which goes back further than the log.
Acknowledged and time to acknowledge — Device anomalies and battery alerts count as acknowledged when someone pressed Acknowledge (here, on Central Alerts or on the Anomalies page); a Security Watch incident when a person picked it up — acknowledged it, or resolved it, whichever came first — the same count as Panic & Incident Response, which has the detail. One the sweep closed as unattended was not picked up. The time is from the alert being raised to that moment; the median is the middle one, so one alert left for a week does not hide that most were picked up in minutes. Over-capacity breaches have nothing to acknowledge and show how long they lasted instead.
Waiting longest — Alerts raised in the range and still not acknowledged after the time you chose.
Where the numbers come from. Rule firings are the rule log, kept since 4 October 2026 and pruned after 90 days, so a range before either shows no firings even if rules fired. Alerts are the anomaly, battery-alert, Security Watch incident and zone over-capacity tables. Days are your organisation's time zone.
Fall & Man-down
/admin/report/fall-watch
What the fall and man-down detector flagged from the accelerometer in worn tags, how people answered, and how much of it was real. Fall detection is switched on, and its alerts set up, under System > Config > Fall detection.
Flagged — Every suspected fall or man-down in the range, whether or not anyone was told. A fall is a tag that was moving, then turned sharply and stayed still for about a minute in a posture unlike the one it is carried in. A man-down (no movement) is a tag that was moving and then did not move at all for 15 minutes.
Habitual and unfamiliar rests — Each tag learns the ways it usually comes to rest, such as a badge put down on its desk. A rest in one of those is habitual: kept here, never alerted. Everything else is unfamiliar, and those are the events that ask a person "Are you OK?" when alerts are on.
Rest places — Zones set as places where lying down is normal (a sick bay, a rest room). An event there waits, or is only recorded, before anyone is asked. Shown as rest place.
Alerted, answered, guards told — Alerted: the person was asked, or the guards were told. Cleared by the person: they answered "I'm OK". Guards told: nobody answered in time, they asked for help, or nobody could be asked. Answer and pick-up times are medians.
Precision — Real falls divided by real falls plus false alarms, among events someone labelled: the person's "I'm OK" (a false alarm), a guard closing it, or an admin with the buttons on this page. Tests are left out. It measures false alarms, not falls the detector missed: a fall nobody flagged cannot appear here.
Worn on — Lanyard, waist clip, on the body (either), wrist, or carried and not worn, as set for each tag on the Config page. "Looks worn?" comes from how often the tag lay still during working hours over the last two weeks. Events from a tag that looked not worn at the time are marked and left out of precision unless you include them: a tag that is not worn cannot feel a fall.
Where the numbers come from. The fall events Omaya keeps: one row per suspected event, with the detector's evidence, every answer, and what the guard did with its Security Watch incident. Events raised by an older version of the detector are marked. Days and hours are your organisation's time zone.
Panic & Incident Response
/admin/report/incident-response
How Security Watch incidents were answered. An incident is what the guard app raises — a panic button press, after-hours activity, someone in a restricted zone, a gateway going dark… The question here is not whether things happened but whether somebody responded, how quickly, and whether the alarm was real. The Security Watch app's Reports page shows the same figures from the same calculation.
Incidents raised — Incidents first detected in the range (by your organisation's time zone). A panic button pressed again while its incident is still open adds a press to that incident rather than a new one.
Picked up, and time to pick up — An incident is picked up when someone acknowledged it, took it, was sent to it, or resolved it — whichever came first: a guard who resolves straight away never presses Acknowledge. The time runs from detection to that moment. Median is the middle one; 90th percentile — nine in ten were picked up faster; worst is the slowest. Within 2 / 5 / 15 min is a share of every incident raised, so one nobody picked up counts as missed. Rule & Alert Effectiveness uses the same definition for its Security Watch row.
Resolved, and time to resolve — Resolved by a person, with an outcome. The time runs from detection to the final resolution (after a reopen, the last one). Shares within 15 / 60 / 240 min are again of every incident raised.
Unattended — Closed by the sweep because it was no longer detected and nobody acted on it for the time set in Security Watch settings. That is not a response, so it counts neither as picked up nor as resolved. (Rule & Alert Effectiveness does count it as acknowledged, so its Security Watch figure is higher than this page's by these.)
Outcomes and the false-alarm rate — The outcome the guard chose when resolving: genuine, false alarm or expected (a known person or routine — it also whitelists it). The false-alarm rate is false alarms divided by incidents a person resolved with one of those three; unattended and still-open incidents are left out. Not recorded is a resolved incident without an outcome. Test (a test press or drill) and duplicate (already handled as another incident) are neither genuine nor false, so they are left out of the rate too.
Still open and reopened — Still open: raised in the range and not resolved now. Reopened: resolved and then reopened at least once.
Guards — Per person (guards in the app, and admins acting from the panel or the mobile app): incidents they picked up first, incidents they took or were sent to, and incidents they resolved, with the median times of those. The Guard filter keeps incidents that person picked up, took or resolved.
Panic buttons — Per button: incidents, presses (every press read, including repeats folded into one incident), man-down alarms (a worn button that stopped moving), times and false alarms. Only panic buttons are counted: a device listed under Devices › Panic Buttons or covered by a switched-on panic rule for that kind of press, or a badge's own SOS — the same test Security Watch makes when the press arrives, which raises a critical panic. A press on any other device (a button nobody registered, a sensor, a tag) raises a warning only and is counted apart under the summary, not listed as a button. Carried by is the person or asset the button's device was bound to at the moment of the press, from the binding history — a button handed over later was not theirs then, and one handed on since still names whoever had it (an entity deleted since shows as "Removed entity"). Presses nobody picked up are panic button incidents with no acknowledgement and no person's resolution.
No data — Striped days are days the gateways sent nothing (an outage). Security Watch cannot detect anything without data, so a quiet striped day is not a quiet day.
Where the numbers come from. The Security Watch incident table and each incident's timeline. The CSV has one line per incident with its times in seconds, outcome and who picked it up, took it and resolved it. Days and hours are your organisation's time zone.
Custom Reports
/admin/report/dynamic
Build your own report: choose a data table, pick the metrics and the dimensions to group by, and save it to run again. For the questions the fixed reports do not answer.
You are querying the same data — These read the same tables as the reports beside them, so the same units apply — a device is still a radio, a stay is still not a person.
Group by changes the meaning of a count — The same metric grouped by zone and by venue will not sum to the same number, because a device seen in three zones counts in each.
Saved reports re-run, they do not snapshot — Opening a saved report runs it again over its date range, so a relative range moves with time.
Times are your clock — Date and hour groupings are on the organisation's time zone, and the date range is applied on that clock too — the same days the fixed reports show.
Devices Detected has two kinds of row — One per hour and one per day, both counting distinct devices. Group by hour and you read the hourly rows; otherwise the daily rollup — never both, which would count every device twice.
Footfall and Loyalty by place: one level at a time — These hold a row for every zone, venue and location a device was in, and one for the whole site, each counting the device once. A run reads one level: the finest place it is grouped or filtered by, the whole site when it names no place. Group or filter by Level to choose. Footfall also has day rows and hour rows, read the same way as Devices Detected. Loyalty by place counts a tag-day in every room it was in; Loyalty / Repeat credits it only to the first room of the day.
People Count: peak and average, never the last reading — People (the hour's peak) is the highest reading in each hour; People (average) averages every reading, whatever function is picked. Presence sensors only say whether anyone was in, so they are left out unless the report is grouped or filtered by Source. Tags present counts registered tags, not everyone in the room.
Two sources, never added — Temperature and People Count carry a source: a fixed sensor in the room, or a roaming tag / the tags present. Group by source before summing or averaging across it, or a wall sensor and a tag in a pocket blend into a number that is neither.
Names, not ids — A location, venue, zone, gateway, device or rule in a grouping shows its name; the CSV keeps the id underneath.
Your data tables — A table you made under System → Data tables appears here as a source. Its number columns are metrics, its other columns groupings, and every row also carries when it was written, the rule that wrote it and the zone or device the rule is scoped to. One row is one firing of a rule, so the count of rows is the count of times the thing happened — as often as the rule's throttle let it fire.
Impact Events
/admin/report/impact-events
Record something that happened — a promotion, a layout change, a closure — and compare the period after it against the period before, for the locations, venues or zones it applied to.
Before and after, not cause and effect — A difference across the boundary is a correlation. Weather, holidays and anything else you did that week land in the same window.
Scope decides the comparison — An event scoped to one zone is measured on that zone only. Scope it wider than it really applied and the effect gets diluted by spaces it never touched.
Give it comparable periods — A week against a week reads cleanly; a week against a long weekend does not. The comparison is on the per-day rate, so a three-day event is not measured against a seven-day week as if both were totals.
What is measured — Device-days: distinct BLE devices seen in the scope on each day, each counted once for the scope however many rooms it went through (the Footfall figure, on your calendar days), and the average of that per day. Avg dwell: from the Dwell Time buckets, each stay counted at its bucket's midpoint. A window still running is rated on the days that have happened, and says so.
Days counted — When your organisation has an operating week (System › Configuration › Organisation, or a venue's own opening days — an event on a venue or zone uses that venue's week), the analysis rates each window on its Operating days only: a weekend inside the week before does not pull its per-day rate down. The windows stay seven calendar days before and after the event; what their closed days held is noted under each window, never dropped. All days counts every calendar day. The choice is only for that view (and its CSV) and changes no setting.
Meeting Room
/admin/report/meeting-room
How the meeting rooms are actually being used over the selected window — how much they are booked, how often a booking goes unused, and how much of the booked time is real.
Booked is not used — The gap between the two is the point of this report. A room booked solid and empty half the time is the most expensive room you have.
No-show — A booking with no presence detected in the room. A room whose sensor is flat or missing will look like nothing but no-shows.
Utilization — Occupied time against available time. Read it next to booking volume — low utilization with low bookings is a room nobody wants, low utilization with high bookings is a booking habit.