Connected Devices

Connected Devices lets your team bring their own measuring instruments — temperature probes, scales, pH meters, humidity sensors — register them in OPS360, and capture readings straight into your forms. When a reading falls outside the range you set, OPS360 flags it on the record and alerts the right people automatically.

It is capture assistance, not remote monitoring: a person still performs the check. The instrument simply removes transcription errors and records exactly which device produced each number — the evidence an inspector asks for.

Registering a device

Go to Connected devices and select Register device. Each field earns its place:

• Device name — a name your team recognises, e.g. "Walk-in fridge probe".
• Identifier — the serial number or Bluetooth address the instrument itself reports. This is what ties a reading back to the device, so it must match exactly. It cannot be changed later — if you replace the instrument, register the new one and retire the old.
• What is being measured — temperature, humidity, pH, weight, or multi-sensor. This drives units and validation.
• Manufacturer / Model — optional, useful for an audit trail.
• Location — where the device lives. This matters: when a reading drifts, the managers of that location are the people who get alerted.
• Calibration — when it was last calibrated and when it is next due. A reading from an out-of-calibration instrument is not evidence, and OPS360 flags devices that fall due.

Setting drift alerts

In the Drift alerts section of the device, set the acceptable range:

• Expected minimum / maximum — either bound is optional. A fridge usually has a maximum; a process temperature might have both.
• Flag readings outside this range — leave on to raise alerts, or switch off to record excursions quietly without notifying.

Once a range is set, every reading from that device is checked at the moment of capture. An out-of-range reading is recorded on the submission as an excursion, and — if alerts are on — the device's location managers are notified by in-app notification, email, push, and WhatsApp (where enabled), according to each person's notification preferences.

Capturing a reading

On any form with a number field, staff can enter the reading two ways:

• By hand — type the value as usual.
• From the device — in the OPS360 staff app, tap Capture from device on the field, choose the instrument, and the reading is read over Bluetooth and filled in for you, with its provenance attached. Standard Bluetooth instruments (thermometers, scales) are recognised automatically; for others, you pick the value once and the app remembers it.

Getting readings in automatically

Typing readings in is fine for a twice-a-day check. It is no use at all for a freezer that needs watching overnight, which is the point at which you want the instruments to report for themselves. Every automatic route ends at the same place — the same range check, the same alerts, the same history — so it makes no difference to the record which one you use.

Go to Connected devices and select Ingestion keys. Create a key; it is shown once and never again, so put it somewhere safe before closing the dialog. Anything that can send an HTTPS request can then post readings:

POST https://api-uks.ops360.net/api/v1/ingest/readings
x-ops360-key: your-key

{ "readings": [ { "identifier": "FRIDGE-A1", "value": 4.2,
                  "unit": "°C", "taken_at": "2026-09-24T09:00:00Z" } ] }

The identifier must match the one on the registered device exactly — that is what ties the reading to the right instrument. Your key identifies your account, so there is no account name anywhere in the message; a key belongs to one tenant and can write nowhere else. If a key is ever exposed, revoke it and issue another. Revoking keeps the record of what it was and when it last sent something.

In practice this means one of three arrangements:

• Sensors that reach the internet on their own — a SIM-based or Wi-Fi sensor, or a LoRaWAN network server — can post directly. No extra equipment from us and none from you.
• Sensors that live in a provider's cloud can be forwarded to us from that provider's webhook. They will send their own message format rather than ours, which is what the mapping below is for.
• Sensors that reach nothing — Bluetooth probes, Modbus plant, a building management system — need something on the premises to collect from them and send on. That is what the bridge is for.

If your provider sends its own format

The message above is ours. A sensor provider's cloud sends its own, and the two are rarely the same — so rather than asking you to translate between them, you tell us where the fields are in theirs.

Go to Connected devices › Data sources, open the source you created, and choose Message format. Two entries are required:

• Device identifier — where the device's id sits in their message, for example sensor or end_device_ids.device_id.
• Reading value — where the number sits, for example reading or uplink_message.decoded_payload.temperature.

The rest are optional: where the list of readings sits if they send several at once, where the time is, the unit and the kind of measurement (either read from the message or fixed for this source), and a prefix to strip off the identifier. That last one earns its place more often than you would expect — providers commonly send eui-70b3d57ed0 for a device whose case reads 70b3d57ed0, and without stripping it every reading is accepted and then dropped for belonging to no instrument.

Test it before you save. Paste one real message from your provider into the panel on the right and press Test. You will see exactly what we would read out of it — and, importantly, any identifiers that match no device you have registered. A mapping that finds nothing still looks like success to the provider sending it, so a minute here saves you discovering the problem a fortnight later from an empty history.

Numbers inside text such as "4.2 C" are understood, and times can be a date or a number of seconds or milliseconds. You do not need to normalise anything before sending it.

If you later move that source to a bridge, remove the mapping and the key goes back to expecting our own format.

Setting up a bridge on site

A bridge is a small always-on computer on the premises — a Raspberry Pi is plenty — running software we provide. It reads the instruments it can see locally and forwards them to your account. It is only needed for instruments that cannot reach the internet themselves.

The person doing the installing is often not the person with an OPS360 login, so the setup deliberately does not need one. From Connected devices, select Connect a bridge and send the link it gives you to whoever is on site. They open it, type the six-character code shown on the bridge, and press the button. Nothing else is asked of them and no password changes hands. The link expires, works once, and can be revoked; a mistyped code simply hands the attempt back.

The bridge keeps readings on disk if the connection drops and sends them when it returns, so a broadband outage costs you the readings' timeliness and not the readings themselves. Removing a bridge from OPS360 revokes its access immediately.

The device record

Opening a device shows its readings over time, not just the last one. That matters when somebody asks what a fridge was doing at four in the morning last Tuesday — a question a single current value cannot answer.

Each reading carries where it came from: typed in, read over Bluetooth, or sent by an integration, and which one. It also carries the band it was judged against at the time, rather than the band set on the device today. If you widen a range next month, last month's excursions remain excursions. Changing a setting must not quietly rewrite history in either direction.

Last reading on the register tells you when each instrument last said anything, and an instrument that has gone quiet is flagged. A sensor that has stopped reporting looks exactly like a sensor reporting good news, and is a very different problem.

When you are told, and when you are not

A device reporting every fifteen minutes turns one propped-open door into four alerts an hour, and a team that has learned to ignore alerts is worse off than one that never had them. The Alert policy section of each device decides what is worth interrupting somebody for:

• Consecutive readings — wait until the reading has been out of range this many times in a row. One reading taken as the door swings shut is not a fault; four in a row is. A reading back inside the range resets the count.
• Quiet hours — a window in which excursions are recorded but nobody is woken. Times are read in the site's own timezone, not the reader's, and a window may cross midnight.
• Alert through quiet hours on trading-critical equipment — off by default. A freezer full of stock is worth a phone call at three in the morning; a meeting-room thermostat is not.
• Escalate after — if nobody acknowledges within this many minutes, tell the next people.

Whatever the policy says, every excursion is recorded. The alerts screen shows the ones that were held back as well as the ones that rang, and says which rule held them. "We were never told" and "we chose not to be told at 3am" are different answers to give an inspector, and only one of them is defensible.

Answering an alert

An alert that was sent to somebody can be acknowledged, which stops it escalating and records who took it on. The first acknowledgement wins. An alert nobody was told about has nothing to acknowledge.

Acknowledging says somebody saw it. For anything you are inspected on, that is not enough — "the fridge reached 11°C" is a measurement, while "we moved the stock, discarded two trays and called the engineer" is a record, and it is the second that an inspection asks for. So a device can require a corrective action form: pick one of your own forms in the device's alert policy, and an excursion on that device cannot be acknowledged until that form has been filled in. The alert names the form and takes you straight to it.

The form required is the one that was required when the alert was raised. Changing the policy next month does not alter what was asked of somebody last week.

Using it efficiently

• Always set an expected range. Without it, a reading is just a number — with it, a bad reading becomes an alert before it becomes an incident.
• Assign each device a location with a manager. Alerts go to that location's managers, so the right person hears about a fridge in their site — not everyone.
• Keep calibration dates current. An in-calibration reading is defensible; an out-of-calibration one is not.
• Prefer Bluetooth capture for critical checks. It removes typos and stamps the exact instrument and time onto the record.
• Set a policy before you turn on automatic readings. An instrument reporting every fifteen minutes with no sustained-breach rule will page somebody four times an hour.
• Require a corrective action form on anything you are inspected on. An acknowledgement proves somebody looked; a completed form proves somebody acted.
• Name devices for humans. "Walk-in fridge probe" beats a serial number when an alert lands on someone's phone.

Connected Devices is a paid add-on, metered by the number of instruments you register. Add a device allowance to your plan to get started.