People counters and tags

Two more kinds of hardware, and the two numbers most often read as something they are not.

People counters at a doorway

A counter over a doorway counts people crossing it, and which way they went. That is a genuine headcount at a line — it is not a tag count, and it does not care what anyone is carrying.

What it gives you directly is traffic: how busy an entrance was and when.

Getting occupancy out of it

Cover every way in and out of a space, and in-minus-out is that space's occupancy. This is how a great many buildings do it, and it works — but only under two conditions, and both are on you rather than on the sensor.

Every door, with no exceptions. A fire exit people actually use, a loading bay, a connecting door to the next unit, a stairwell — miss one and the net figure is wrong by however many people used it, permanently and in one direction. Partial coverage does not degrade gracefully; it just drifts.

That is what a door reading 32 in and 94 out in a single day looks like. The sensor is fine. Sixty-two people left through a door they never entered, because the way they came in has no counter on it — or that doorway is a corridor thoroughfare, and "the space" it fronts was never a closed volume in the first place.

A daily reset. Every counter miscounts a little: two people abreast, a trolley, someone loitering in the doorway. A net figure accumulates those errors and never recovers from them, so it has to be re-zeroed at a time you know the space is empty — normally overnight. Without a reset, the error is unbounded.

Turning it on

Space → Venue → the venue → "Every way in and out of this venue is counted."

Tick it and Omaya nets the venue's counters itself: in minus out becomes that venue's occupancy, marked doors, and it flows to the Right Now page, the occupancy API, reports and rules like any other source. There is a note field for the caveat you will otherwise forget — "excludes fire exit F2, alarmed" — and a reset time for a venue that never closes.

The tick is an assertion about the building, and Omaya still checks what it can:

• More people leaving than arriving and the figure is refused. With every door counted that cannot happen, so it means a way in that nothing is watching. Without the check the clamp at zero would show it as a quiet building.
• Counters gone quiet during opening hours and the figure is refused rather than frozen.

Fail either and the venue falls back to the sum of its rooms, with the traffic figures still shown so you can see the counters working and the check refusing.

One room, rather than a whole floor

A room can be counted the same way — Space → Zone → "Every door of this room is counted" — with one extra step at install time.

Tell each counter which side faces in. On the device, set the room an enter puts someone into, and where they came from. A lobby or street door faces into the room from nowhere counted; the door between two counted rooms faces into one and out of the other, so the same crossings move people between them instead of inventing a person in each.

Get that mapping right and one counter serves both rooms. Leave it unset and that door is simply missing from the room's number — which the nightly audit reports rather than letting it drift quietly.

What gets checked afterwards

Nobody can verify "every door is counted" at the moment you tick it. What Omaya does instead is watch nightly for the shapes that claim cannot produce:

It reports	Because
A counter in a counted room with no side set	That door is missing from the room's figure
Two counters mapped to the same pair of spaces	Usually one door with two units on it, counting everyone twice
A day with far more arrivals than departures	With every door counted that cannot happen — there is a way out nobody is watching
Doors and an in-room sensor disagreeing	One of them is wrong, and having both tells you there is something to look at

These arrive as alerts on the counter itself, in the same place as every other device problem.

Mounting

Directly over the threshold, at the height the vendor specifies — these are geometry-sensitive in a way most sensors are not. Give it a clean view of the full door width; a counter that sees two thirds of a doorway misses people on the third it cannot see, quietly and consistently, which is exactly the error that accumulates.

Double doors need thinking about: one unit covering both leaves, or two units and the knowledge that someone walking between them may be seen twice.

If you only care about one room

A counter inside the space that reports people-in-area, or a radar, gives you occupancy with no netting, no coverage requirement and no reset. Doorway counting earns its place when you want the traffic figures too, or when the "space" is a whole floor or building with a handful of controlled entrances.

Tags

A tag is a small BLE device that advertises. Omaya hears it through gateways and works out where it is.

What a tag is for. Following a specific thing — a forklift, a wheelchair, a contractor's badge, a piece of test equipment. It answers "where is this", and it answers it well.

What a tag is not for. Counting people. A tag count is a count of tags. In a building where badges are optional it undercounts by however many people chose not to carry one, and reports zero for a full room with complete honesty.

Assign it to an entity. A tag on its own is a MAC address. Attached to an entity on the Entity page it becomes the forklift, and every report about it starts being about something you would mention in a sentence. An entity can hold several tags over time, so a replacement tag keeps the history.

What it broadcasts, and the button. Which slots to leave on, and how to make a tag's button register a press, is its own page: Beacons and buttons.

Battery. Tags are the devices most likely to go quiet, and a tag that is genuinely not moving looks a lot like a tag that has died — which is why they get a longer silence threshold than a mains-powered sensor. The battery report forecasts replacement from each device's own drain rate; use it to plan one trip rather than five.

Distance sensors (time-of-flight)

A ToF sensor (the MOKO SO2R) measures one thing: how far away the nearest object in front of it is, 40 mm to 3 m, in a narrow cone. On its own that is a number in the Distance report. What makes it useful is telling Omaya what the number means for this installation — which is a one-minute job on the device's page, Distance calibration, once the sensor is registered and has a zone.

Step one is the same for every use: the empty reading. With nothing in front of the sensor — the bay clear, the tank empty, the lane open — press Use now. That distance is the floor, the far wall, the bottom of the tank. Everything else is measured against it.

Then pick what the sensor is watching. For worked scenarios — a parking bay, a bed, a bin, a tank, a vehicle gate — with where to mount it, the settings and the rules to add, see Distance sensors: pick a mode.

Mode	The question	What Omaya does with each reading
Occupancy	Is something there? A parking bay, a bed, a chair, a loading dock.	Nearer than the empty reading by more than the margin → the sensor's zone is occupied, exactly as a PIR would report it. The Meeting Room app uses it (the in-use chip, and releasing a booked room nobody turned up to), and rules can watch the occupied field. Nothing in range means empty.
Level	How full? A tank, a bin, a silo, a stack.	0% at the empty reading, 100% at the full reading (press Use now with it full, or type it), and a band — empty / low / medium / high by default, or your own labels and thresholds. The percentage and the band go to the rule engine as level_percent and level_band, so "band becomes refill" is a rule, and a data table can log every change.
Counter	How many passed? A trolley lane, a vehicle gate, a chute.	One crossing each time the beam goes from clear to blocked, booked as an entry on the traffic reports.

The panel shows the live reading and, beside it, what the current setup makes of it — so you can wave a hand, fill a bucket, or roll a trolley through and watch the verdict change before you save.

Where each mode's reading ends up. Occupancy is both a live state and history: it sits in the zone's occupancy for as long as the sensor keeps reporting — read by the Meeting Room app and by rules — and an hourly record is kept, so Space Utilisation can tell you what share of the day a bay, a desk or a room was in use. It does not change the Right Now number, which counts people; a yes/no is not a count, and that report labels the zone "in use / not (presence sensor)" so nobody reads one as the other.

Rules can also ask for it to have lasted: Only after it has held for 45 minutes turns "someone sat down" into "this table has been occupied for three quarters of an hour". See rules on any sensor reading. Level is the same shape: level_percent and level_band reach rules and, through a rule, a data table if you want the history kept. Counter is the one mode that writes a report of its own — crossings land on the Enter / Exit report as entries (no direction; a beam cannot tell in from out).

Two honest limits. The sensor advertises about once a second, so Counter mode counts slow crossings: a trolley or a car, not a person walking through at pace, who is through the beam between two readings. And the sensor sees the nearest thing in its cone: a bin lid, a hanging cable or a person leaning in all read as "full" or "occupied", because they are — aim it at what you mean.

Environmental sensors

Worth one paragraph, because the mistake is always the same: a reading is per sensor, not per room. A sensor near a vent, a window or a doorway will disagree with the rest of the room, and it is being right about where it is rather than wrong about the room. Mount it where the reading is supposed to represent — at occupant height, away from airflow and direct sun.