Skip to content

Setting up a site

The order matters more than any single step. Almost every "nothing is showing up" question is one of these done before the thing it depends on.

The Omaya spatial hierarchy Location, then an optional Building, then Venue, then Zone. A floor is a property of a venue rather than a level of its own. Capacity is set on the zone; operating hours and cost per square metre are set on the venue. LocationSite or campusTop of the tree. Everyreport can roll up to it.BuildingOptionalA grouping, nothing more.The UI hides this levelwhen a location has none.VenueThe mapped spaceOwns the floor plan andits coordinate system.Operating hours and costper m² are set here.ZoneA shape on that planCapacity is set here andnowhere else — the meetingroom app reads this value.Gateways live on a venueA floor is not a level of its own.It is two properties of a venue — a label and anorder — because the venue already owns the plan.
Location → [Building] → Venue → Zone. Building is optional and disappears when you have none, so a single-site deployment reads Location → Venue → Zone. Everything that positions, ingests or reports hangs off the venue, which is why the venue — not the building — is where a floor plan and its calibration live.

1. Create the location

Space → Location. A location is a site or campus, and it is the top of the tree — every venue, gateway and report rolls up to one.

Buildings are optional and live inside a location. If you have one building, skip them: the level hides itself and the hierarchy reads Location → Venue → Zone. Add buildings when you have several and need to group venues by which one they are in.

2. Create a venue for each mapped space

Space → Venue. A venue is a space you have a floor plan for — usually one floor of one building. Two floors are two venues, and a floor is expressed here as a label and a level number on the venue rather than as a tier of its own, because the venue already owns the plan every zone is drawn on.

Set these while you are here, because three later features quietly depend on them:

FieldWhat depends on it
Opening and closing time, operating daysUtilisation is a share of operating hours. Without them, a room looks idle all night and every figure is diluted.
Cost per m² per monthThe money column on Space Utilisation — what the underused floor area is costing.
"Every way in and out of this venue is counted"Whether Omaya may use the net of your doorway counters as this venue's occupancy. Leave it off unless it is literally true.
RSSI rangeHow generously gateways are believed. Leave the defaults unless you know why you are changing them.

3. Put the floor plan in, and tell it what a metre is

Open the venue and go to its Floor Plan. This is where a venue stops being a row and becomes a place, and there is a panel for each thing you need to do.

Image. Drop the plan in. Then give it a real-world size — width and height in metres — or, if you only know one distance, use the Calibration panel to draw a line along something you have measured and say how long it is. Either way the panel tells you whether the scale is set.

Do not skip this. Without a scale the plan is a picture. With one, every position, every zone area and every density figure is in metres.

No plan image at all?

The Designer (also on the venue) is a drawing tool for exactly that case: lay out rooms, walls and furniture, then save the result as the venue's floor plan image. What you draw becomes real walls and zones, not a picture of them.

4. Register the hardware

Device → Gateway, then Device → Sensor. This comes before placing anything on the plan, because the plan's Gateways and Sensors panels list what is already assigned to the venue so you can position it — they are not where devices are created.

Do gateways first. A gateway needs a venue before anything it hears can be positioned, and until at least three are online in a venue, devices there fall back to nearest-gateway presence rather than a position. Three is the floor, not a target.

For sensors and tags, the model you pick decides how the packets are decoded and what the device can contribute — Devices and what they report is the list. Rolling out many at once? Device → Bulk Import takes a spreadsheet, which is how two hundred MAC addresses avoid becoming one hundred and ninety-eight.

If your model is not in the list, that is not a dead end — teach Omaya a sensor it has never seen.

5. Back to the plan: zones, hardware, walls

Zones. Draw the areas you would name in conversation — this meeting room, the sales floor, the loading bay — not every architectural subdivision. Zones are what almost everything is reported against, so a zone nobody would mention in a sentence is a row nobody will read.

Set capacity on each zone as you create it. It is set here and nowhere else; the meeting-room app reads this value, and without it "busy" and "over capacity" have nothing to compare against.

Gateways and sensors. Click each one in its panel and place it where it physically is. Position is computed from which gateways hear a tag and how strongly, so a gateway in the wrong place is worse than one that is missing — it pulls every nearby estimate towards a spot nothing is at.

A radar needs one more step of its own: calibrate it from its device page, so what it reports lines up with the plan.

Obstacles. Draw the walls, and the solid furniture if you care about the detail. They are what stops a position estimate placing someone inside a lift shaft.

6. Calibrate the gateway positions

Venue → Calibrate.

Placing gateways by eye gets you close. A calibration walk gets you right: you stand at a handful of marked points holding a tag, Omaya records what each gateway hears from each point, then solves for where the gateways actually are. Review the solved positions and apply them.

Worth doing once, properly, on any venue where you care about position rather than just presence. It is the difference between "somewhere on this floor" and "in this room".

7. Name the things you care about

Entity. A tag is a MAC address; an entity is the forklift, the contractor, the wheelchair. Until a device is attached to an entity, every report about it is a report about hardware rather than about something you would talk about.

An entity can hold more than one tag over time, which is how a vehicle keeps its history when its tag is replaced — see people and assets for what an entity is and how to swap a tag without losing where it has been.

8. Check it, before anyone else does

Three pages, in this order, because it isolates a fault fastest:

  1. Device → Gateway — is every gateway online? One offline gateway explains an entire floor of missing data.
  2. Monitor → Live Monitor — are devices appearing on the plan, roughly where you expect? If the dots are coarse, count the online gateways.
  3. Monitor → Right Now — does each zone report a count, and does the source badge say what you expect?

Linger on the third. A zone reading tags when you fitted a radar means the radar is not reporting; a zone reading zero from tags means nobody in it is carrying one, which is not the same as empty. Occupancy: which number is which is ten minutes well spent before you draw a conclusion from any of it.

What to set up next

  • Capacity on every zone you will ever ask "is this room big enough?" about.
  • Your first rule, for the things you would otherwise have to watch for.
  • A scheduled report, so the weekly figure arrives without anyone remembering to run it.

Last updated:

Omaya platform documentation