Integrate IoT sensor readings with IFS Cloud

Explore this learning path

Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.

Turn a fictional sensor reading into a validated integration message, send it through a development IFS inbound route, and verify the resulting measurement. Start with a file fixture so transport errors are separable from device/network problems.

Before you start

You need a defined IFS measurement/business API or Connect route, a test equipment record, a restricted integration identity, and a mapping between the device ID and the IFS equipment reference. Confirm the allowed unit and valid measurement range with the business owner.

This lab uses temperature readings between -50 and 150 degrees Celsius. That range is a teaching assumption, not an IFS rule or a specification for your equipment.

1. Save a realistic message

Create reading.json:

{
  "messageId": "LAB-SENSOR-081",
  "deviceId": "LAB-DEVICE-3",
  "observedAt": "2026-09-27T09:15:00Z",
  "value": 21.75,
  "unit": "C"
}

Use a stable message ID from the device/gateway for a single observation. Retransmitting an observation must not invent a new ID. Keep observation time distinct from the time IFS receives it.

2. Validate before authentication or delivery

Save validate-reading.mjs next to the fixture:

import { readFileSync } from 'node:fs';
const reading = JSON.parse(readFileSync(process.argv[2], 'utf8'));
const equipmentByDevice = new Map([['LAB-DEVICE-3', 'LAB-PUMP-04']]);
if (!/^[A-Z0-9-]{1,64}$/.test(reading.messageId ?? '')) {
  throw new Error('Invalid messageId');
}
if (!equipmentByDevice.has(reading.deviceId)) throw new Error('Unknown device');
if (typeof reading.value !== 'number' || !Number.isFinite(reading.value)
    || reading.value < -50 || reading.value > 150 || reading.unit !== 'C') {
  throw new Error('Invalid temperature');
}
if (typeof reading.observedAt !== 'string'
    || !reading.observedAt.endsWith('Z')
    || Number.isNaN(Date.parse(reading.observedAt))) {
  throw new Error('A valid UTC observation time is required');
}
console.log(JSON.stringify({
  ...reading, equipmentReference: equipmentByDevice.get(reading.deviceId)
}));

Run node validate-reading.mjs reading.json. Expected output includes equipmentReference: LAB-PUMP-04. This validates only the teaching contract; the real receiver may require different field names or a stricter timestamp parser.

3. Map to the installed IFS contract

In API Explorer or the Connect interface definition, identify the operation that records the measurement. List each required field beside its source: equipment from the trusted mapping, observation time from the message, value/unit from validation, and correlation reference from messageId.

Do not let an untrusted device select an arbitrary IFS company, equipment object, projection, or endpoint. If the target uses a different unit, implement an explicit, tested conversion and record the source unit separately.

4. Submit a single reading

Use Postman with the approved integration identity to send the mapped payload to the verified endpoint. For Connect, follow gateway testing; for a projection, use its documented action/create operation.

Record HTTP response, message/reference ID, and the IFS business key. Open the equipment/measurement page and verify value, unit, observation time, and record association. Acceptance by a gateway queue is not yet a persisted business measurement.

5. Prove duplicate and offline behavior

Send the same message again. Confirm the receiver rejects it as duplicate or returns the original result. If it creates another measurement, add a durable receiver-side unique key/check before connecting the live device.

Disconnect the test sender after placing a message in its durable queue. Reconnect and confirm replay preserves the original message ID and observation timestamp. For out-of-order readings, decide whether older observations are stored, rejected, or flagged; do not overwrite the newest state purely because a delayed packet arrived last.

6. Test rejection and clean up

Change the fixture to an unknown device, a string value, an invalid unit, and an out-of-range value. Each should fail before delivery. Then test a valid message against a nonexistent IFS equipment reference and confirm an observable business rejection.

Use monitoring to join device message ID, worker attempt, and IFS outcome. Remove lab measurements only through the supported business process, disable test producers, and revoke their integration credential after acceptance testing.

Sources and scope

• IFS integration decision guide
• IFS Connect architecture

Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.