Devices, entities and spaces

Where hardware, people, assets and the shape of the building are set up.

Configure these in this order: spaces, then devices, then the entities to follow. A gateway with no venue has nowhere to report; a zone with no shape cannot contain anything; a tag with no entity is a MAC address with no meaning. A page that shows nothing is most often one of these steps done out of order.

See How your building is described for the structure the space pages build.

NOTE

Most pages in this chapter require a permission. A user who cannot see a page lacks that permission in their role. Roles are edited under System > Roles; see Administration.

Entity

Menu path: Choose Entity (/admin/manage/entity).

The people, vehicles and assets to be followed, each with the tag or tags assigned to it. Binding or unbinding a tag is recorded with the time, so reports about earlier days still credit the person or asset that had the tag then.

Application scenario: Giving a MAC address a name. Until a device is attached to an entity, every report about it is a report about a piece of hardware rather than about a person or asset.

Prerequisites: Registered devices to assign. An entity can hold more than one tag, which is how a vehicle keeps its identity when its tag is replaced.

Label Fields (the button beside Add Entity) defines extra fields once for a label — a Serial No on everything labelled IT Equipment, a Service due date on Forklifts — and every person or asset carrying that label shows them on its form. A field with the same name on two labels shares one value. A rule can watch these fields with Label field (person / asset).

Related documents: People and assets

Device

Gateway

Menu path: Choose Device > Gateway (/admin/manage/gateway).

Every gateway: where it is, whether it is online, what it can hear and when it last spoke.

Application scenario: The first page to open when a whole area goes quiet — one offline gateway explains an entire floor of missing data.

Prerequisites: A gateway must be placed on a venue before anything it hears can be positioned. Three or more online in a venue is what positioning needs; below that, devices fall back to nearest-gateway presence. How often each one has been down, and for how long, is the Gateway Availability report.

Three cards at the top: how many are up now, whether each floor has the three gateways positioning needs, and the outages of the last seven days. Click an outage to see which gateways went silent and when each came back, which ones kept passing data (a power or network cut usually spares those on another circuit), and a link to Gateway Availability on that day.

Where shows the building, with the floor and zone under it. Columns, on the right of the toolbar, hides or shows any column but the status and the name; the choice is kept in this browser.

Related documents: Report glossary

Sensor

Menu path: Choose Device > Sensor (/admin/manage/device).

Every registered sensor, tag and beacon, with whether it is reporting, its model, battery, and where it is or what it last read.

Application scenario: Adding hardware, and checking one device suspected of a fault. The model chosen decides how its packets are decoded and what the device can contribute.

Needs attention says in a sentence what is wrong, worst first — for example 5 tags not heard for days · 3 sensors silent for hours — and opens the list on exactly those devices. When nothing is silent, never seen or low on battery it reads All reporting. Anomalies are on their own page, from the badge at the top.

Tabs by kind: All, Tags (who carries each one and where it is now, from its latest stay), Sensors (its room and latest reading in words), Actuators (its state and a Turn on / Turn off switch in the row), and Beacons & other. The chips under the tabs appear only when something is behind them: Silent, Never seen, Low battery, Not placed (fixed sensors) or Not carried (tags). The list puts what needs attention first; the dot on each row is green when reporting, an amber ring when quiet but still within its expected time, red when silent, a grey ring when never seen. Columns hides or shows any column, remembered per tab.

A device's panel has tabs: Overview, Control (its switches, Configure for the settings Omaya can change, and its own settings where the model reports them), Data (latest reading, button presses) and Calibrate. A tab with nothing for that device is hidden, an actuator opens on Control, and Control is greyed with the reason when Omaya can change nothing on it. Edit is beside the name. Selecting rows shows a bar under the list to move, label, activate, deactivate or delete them together.

Bulk Import (the button at the top of this page) registers many devices at once from a spreadsheet — the way to do a rollout, because typing two hundred MAC addresses by hand is how two of them end up wrong. It needs permission to create devices; see Setting up a site.

Sensor Auto Discovery (the button at the top of this page) lists the Bluetooth devices the gateways hear that are not registered yet. One shows only once it has been heard for long enough, by enough gateways and often enough, and is still active; register it from there instead of typing its address. How long and how often is under Adjust settings on that page.

Sensor settings (the button at the top of this page) has two tabs. Settings library: the device models in use, grouped by how their settings are changed: what can be changed from Omaya, how the change reaches it, and what is never sent. A device's own settings are on its Configure page, from its panel. Passwords holds the password Bluetooth sensors ask for before they accept a change: one per maker for the organisation, plus the sensors that have their own and whether their last sign-in worked. Set it once, before MOKO sensors are first configured from Omaya, and use it to change the factory password on the sensors themselves (it is published, so anyone nearby with the maker's app could otherwise change them). Passwords are stored encrypted and never shown again. It needs manage-devices (shown in the role editor as Bulk Import Devices); LoRaWAN and Home Assistant devices need no password here.

Related documents: Devices and what they report

Beacon & Wi-Fi Anchors

Menu path: Choose Device > Beacon & Wi-Fi Anchors (/admin/space/anchors).

Bluetooth beacons and Wi-Fi access points that stand in a known zone, for badges and phones that scan rather than broadcast.

Application scenario: Recording which beacon or access point is in which room, assigning the ones scanning devices have heard, and checking where scans placed a device.

Prerequisites: Zones drawn, and a scanning device (such as a MOKO PS101 on a Bluetooth or Wi-Fi fix) reporting what it heard. Gateways and fixed beacons that already have a zone count as Bluetooth anchors on their own.

Related documents: Beacon and Wi-Fi anchors

Panic Buttons

Menu path: Choose Device > Panic Buttons (/admin/manage/device/panic-buttons).

Who gets paged when a button is pressed. Each panic button is a rule — Button pressed on the button, then Page these people — and this page is the short way to make and read them: which button (one device, every device under a label, or every button in a place), which press (any press, single, double, triple, long, or a badge's SOS, Alert or man-down), how soon the same button may page again, and the people with the channels to reach them on. A panic button made here is also listed under Rules; Open as a rule on a row opens it there, where other actions can be added such as a webhook or a work order. Only a device with a button raises a press: moving a tag is never a press.

Application scenario: Set it up before it is needed, and check it after any press. A press is always recorded in the Trigger Event report, but nobody is paged unless a panic button or rule here covers it — so a button nobody set up is a button nobody answers. The send icon on a row pages its people with a message clearly marked as a test.

Prerequisites: The button registered as a device, so its presses reach Omaya at all, and at least one person to page. Admins are paged by email and in-app; app users by email, SMS, WhatsApp and push. SMS and WhatsApp go to the phone number on the app user's account, through the organisation's SMS or WhatsApp connector — admin accounts carry no phone number, so put the people who must be phoned on as app users.

Cellular badges. A badge that raises its own alarms — the PS101-M's SOS, Alert and man-down — is set up like a button: pick the badge, or a label every badge carries, and the press SOS, Alert or Man-down. Each alarm pages once, however many reports the badge sends while it lasts; when the badge ends it, the people on the list get an in-app note. Security Watch raises these without a panic button.

Setting up a worn button does more than page people. Security Watch treats a man-down (inactivity) alarm as an incident only from a button set up here — setting it up is the statement that someone is wearing it. A button left on a desk times out every few minutes and should page nobody, which is exactly what an unregistered button does.

New sensor types

Menu path: Choose Device > New sensor types (/admin/manage/device/onboarding).

Teaching Omaya a sensor it has never seen, in three tabs. Learn a sensor is the guided way: point it at the device, let it collect real packets, and work out what the payload means.

Application scenario: When hardware has been bought that is not in the model list. The result can be saved to the organisation's own library, so the next unit of the same model is recognised immediately.

Prerequisites: The device powered on and within range of the selected gateway, and the page left open while it collects — the capture runs in the browser session, not in the background.

Custom types lists the payload decoders the organisation has defined and the field-by-field specification behind each — for reviewing or hand-editing what Learn a sensor produced, or adding a decoder straight from a datasheet without capturing packets. It needs Manage General Config (manage-config-general).

Test decode shows what any decoder, built-in or the organisation's own, reads from a pasted advertisement.

Related documents: Standard reading names

Tag Power

Menu path: Choose Device > Tag Power (/admin/manage/device/tag-offsets).

How loudly each model of tag transmits, measured against the tag the floor was calibrated with.

Application scenario: A tag with a different antenna or output power is heard louder everywhere, and the distance maths turns that constant difference into a distance wrong by a multiple — six decibels is 1.7x, thirteen is 3x — so one kind of tag positions noticeably worse than another. Measure it once per model with Measure, which opens the calibration bench: the tags lie side by side near one gateway for a few one-minute rounds, turned between rounds, and the bench saves only a result that agrees with itself. A floor walked with a different tag can have its own offset.

Opening a tag shows a one-line Tag Power card under Calibration — Reference model, Not measured, or the offset in force, with a warning when tags of its model advertise different power. Expand it to see where the offset comes from (its own override, its floor, or its model), edit the tag's own offset and carrying height in place, or press Tag Power calibration to open the Tag Power page.

Changing a tag's signal strength. When a tag's Signal strength is changed on its Configure page and the tag confirms it, every reading it gives moves by the same amount, so Omaya moves that tag's own offset by the difference (for example from −12 to 0 dBm adds 12 dB). The tag then has its own offset, which is used in place of its floor's or model's. For a tag that broadcasts several messages at different strengths, the strength most of its messages go out at is the one that counts.

Space

Location

Menu path: Choose Space > Location (/admin/space/location).

The organisation's sites, and the buildings inside them.

Application scenario: The top of the tree. Create a location before anything else; every venue, gateway and report rolls up to one.

Prerequisites: Buildings are optional. If a location has none, the level is hidden entirely and the hierarchy reads Location → Venue → Zone.

Sites (the first tab) shows each location as a card: its address, its buildings, and a row per floor with its zones, how many of its gateways are online, and whether it has a floor plan, with links to that floor's plan, its Venues entry, Right Now and Heatmap. Full hierarchy, folded underneath, is the whole tree with every zone, building edit and delete, and a switch to show the gateways and devices. Add Building and Add Location are at the top of the page; List is the table.

The Map tab shows the locations, buildings and gateways on a street map, and is where geofences are drawn: outlines of outdoor places — a car park, a yard, a client site — that name a GPS tracker’s position. The list beside the map finds, edits, switches off and deletes them. See Indoor and outdoor.

Related documents: How your building is described

Venue

Menu path: Choose Space > Venue (/admin/space/venue).

The mapped spaces: each one holds a floor plan, its scale and calibration, its operating hours and its cost per m².

Application scenario: Uploading a floor plan and setting what the space is worth. A floor is expressed here too — as a label and an ordering on the venue, not as a level of its own.

Prerequisites: A floor plan image with its real-world dimensions set, or nothing positioned inside it will land in the right place.

Floors (the first tab) shows each venue as a card with its floor plan as the picture, its zones and gateways online, and whether it can place tags on the map — a floor needs three gateways up; below that it shows how many it has. Each card links to the floor plan, its details, Right Now, Heatmap and Edit. Ready to place tags at the top counts the floors that can. List is the table.

Zone

Menu path: Choose Space > Zone (/admin/space/zone).

The areas drawn on a venue’s floor plan — rooms, desks, entrances, restricted corners — and their capacity.

Application scenario: Zones are what almost everything is reported against. Draw the areas people name in conversation, not every architectural subdivision.

Prerequisites: Capacity is set here and nowhere else. The meeting-room app reads this value, so there is deliberately no second place to type it.

At a glance. Four tiles count Zones, those Not drawn on the plan (no outline, so nothing can be placed in them), those with No gateway of their own (placed by room estimation, if at all) and the Inactive ones; a tile opens its tab. Above the list, the tabs All, Not drawn, No gateway and Inactive sit beside a search and filters for floor, zone type and label. A row opens the zone's View panel, with links to Right Now, Space Utilisation, Room Usage, Heatmap and Environment for that zone. The plan column's Draw it chip opens the Map Editor for the zone's floor ready to draw its outline; Drawn opens the editor on it.

Zone Type

Menu path: Choose Space > Zone Type (/admin/space/zone-type).

The categories zones can be labelled with — meeting room, workspace, corridor, washroom.

Application scenario: Grouping zones across venues so a report can say "all meeting rooms" without listing them.

The list. Find a type with the search over the list; clicking a type opens it to rename it, switch it off or delete it. Each row counts the zones of that type, and the count opens the Zones list filtered to them.

NOTE

This chapter is generated from the admin menu itself, so it lists every menu item.