Appearance
Reports
Eighteen reports, grouped by the question they answer.
Every report shares the same controls: a date range, a scope (location, venue or zone) and an export. What differs is the unit being counted, and that is where reports go wrong — a crossing is not a person in the room, a stay is not a visitor, a device is not a head.
So start from the question rather than the menu.
Nearly every page below is permission-gated. If a colleague cannot see one, that is their role rather than a fault — Roles is where to look.
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
/admin/report/enter-exit
People crossing a doorway, counted by direction, by day and hour.
When you would open it. How busy an entrance was, and when.
Before it has anything on it. A people counter on the door. It counts crossings, so one person who steps out for coffee is two enters and two exits; in-minus-out becomes an occupancy figure only when every way in and out is counted and the total is re-zeroed while the space is empty.
Devices Detected
/admin/report/total
How many distinct devices were detected, over a period and a scope.
When you would open it. A coarse footfall proxy where you have no counting sensor, and a sanity check that gateways are hearing what you expect.
Before it has anything on it. Read it as devices, not people. Phones with MAC randomisation inflate it; a person carrying two tags counts twice.
People Count
/admin/report/people-count
Occupancy over time per zone: the last reading, the peak and the average for each hour and day.
When you would open it. The report to reach for when someone asks "how busy is this room, really".
Before it has anything on it. Something that counts people in the zone. Read the three figures deliberately — the last reading, the peak and the mean are different questions.
→ Occupancy: which number is which
How long do people stay?
Whether this is somewhere people pass through or somewhere they settle.
Loyalty
/admin/report/loyalty
How often the same registered device comes back — new versus returning per calendar day, how long between visits, and a list of the devices themselves: the regulars, the newcomers, and when each was last here.
When you would open it. Retail and visitor-attraction questions: is this a place people return to? On a badge-carrying workplace it reads as attendance regularity, and the device list is the useful half.
Dwell Time
/admin/report/dwell-time
How long devices stay, bucketed by duration and broken down by zone.
When you would open it. Telling somewhere people pass through from somewhere they settle.
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.
Heatmap
/admin/report/heatmap
Where people spent their time on a floor plan, as intensity over the plan image.
When you would open it. Layout questions — which corner of the showroom nobody walks into.
Before it has anything on it. A venue with a floor plan and enough positioned devices to make a shape rather than a scatter.
Detection Heatmap
/admin/report/heatmap-total
A grid of venues, zones or locations against your 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.
When you would open it. 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.
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.
When you would open it. 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.
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.
When you would open it. Settling an argument about a specific room on a specific afternoon, seeing which end of a room is never used, and checking a radar is seeing what you think it sees. The coverage line says how many of the hours judged the radar was awake for — below 80% the figures are a floor.
Before it has anything on it. A calibrated radar in the room.
Sensor Trail
/admin/report/device-trail
One device’s path over time — every zone it was seen in, in order.
When you would open it. Following an asset, or reconstructing a movement after the fact.
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
/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.
When you would open it. The portfolio question: which rooms are too big, which are too small, and what the underused floor area is costing.
Before it has anything on it. 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
/admin/report/zone-compare
Two or more zones side by side on the same measure and the same period.
When you would open it. Comparing like with like — two meeting rooms, two floors, this quarter against last.
Is it comfortable? Is the hardware alive?
Conditions in the room, and the state of the things measuring them.
Environment
/admin/report/environment
Temperature, humidity and noise from environmental sensors, with breaches against the thresholds you set.
When you would open it. Comfort and compliance. Change a threshold and the history re-reads against it, so a breach count describes your current limits rather than a fixed historical fact.
Before it has anything on it. 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.
Battery
/admin/report/battery
Battery level per device, with the trend and a forecast of when each will need replacing.
When you would open it. Planning one maintenance trip instead of five. Pair it with the battery-forecast webhook if you want the trip booked for you.
Sensor Status
/admin/report/device-status
How reliably each sensor has actually been reporting: the share of hours it was heard in, and a strip of the hours themselves.
When you would open it. 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.
Before it has anything on it. Nothing beyond devices reporting. A sensor with low availability is not necessarily faulty: an asset tag that only moves in working hours is honestly quiet the rest of the time.
What happened, and when?
Discrete events rather than levels — a press, a knock. One row is one occurrence.
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.
When you would open it. 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.
Before it has anything on it. A device with a button, and its trigger enabled. To page anyone, a panic-button routing for it under Devices → Panic Buttons.
Impact Events
/admin/report/impact-events
Before-and-after for something you did — 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.
When you would open it. Did the change move anything? A difference across the boundary is a correlation, not a cause — weather and holidays land in the same window.
Before it has anything on it. An event with dates and a scope, and the Devices Detected and Dwell Time reports having data for it.
None of the above
When the question is not one of the seventeen above.
AI Reporting
/admin/report/ai
Reports written in prose by an AI from your own data, on a schedule or on demand.
When you would open it. When the audience is a person who will not open a dashboard. Ask for a period and a scope and it produces something readable rather than a grid.
Before it has anything on it. An AI provider key for your organisation.
Custom Reports
/admin/report/dynamic
Reports you define yourself: pick a data table (entries and exits, devices detected, loyalty, dwell, temperature and light, distance, battery, device status, people count, noise, air quality, button presses, rule write-records), the metrics and the grouping, and save the result to run again or export as CSV. Groupings are on your clock and name their locations, venues, zones, gateways, devices and rules.
When you would open it. When the question you have is not one of the fixed reports, and you expect to ask it again.
This list is read from the admin menu itself, so it cannot fall behind it.