Korea Electronics Technology Institute

Service overview

What is KETI?

peaqOS exposes a building’s oneM2M resources through a native adapter. The building runs Mobius — KETI’s open-source oneM2M server — with its occupancy sensors, environmental sensors, and smart doors registered as labeled devices. peaqOS holds the CSE connection in its server environment, so no CSE credential or resource path ever travels in a request. A paired Machine Agent lists the building’s devices, reads their latest values, subscribes to live updates over an authenticated event stream, and orders a door to open — reported as applied only once the door acknowledges that exact command and its state reads OPEN. Every call needs the machine’s current signed pairing and delegation policy, nothing is paid, and peaqOS records the run, outcome, and audit trail. KETI, the Korea Electronics Technology Institute, develops Mobius as an open-source server platform for the oneM2M IoT standard. The adapter is in development: all five operations are implemented, and compatibility with deployed buildings is still being validated.

How it works

1. Step 1

   Prepare the building

   The infrastructure owner runs a Mobius CSE that verifies subscription callbacks, and registers each sensor and door as a labeled device with a peaqos.onem2m.device.v1 descriptor.

2. Step 2

   Connect peaqOS

   The peaqOS operator configures the CSE origin, originator, and callback trust in the server environment — never in a request.

3. Step 3

   Pair and call

   With a current signed pairing, the agent reads devices directly and places free orders to subscribe or open a door; peaqOS stores the run, outcome, and audit trail.

Adapter operations

Behind peaqOS — the paired agent calls peaqOS, peaqOS calls the building’s Mobius CSE with server-held configuration. Reads run directly; subscriptions and door actions run as free orders.

• GETlist-devices

  List the building’s labeled sensors and doors as opaque device IDs; a building with more than 100 discovered resources returns a discovery-limit error.

• GETget-device-info

  Read a device’s name, type, location, readable resources with schemas and units, and supported actions.

• GETget-latest-data

  Read a resource’s latest sample — occupancy, temperature and humidity, or door state; an empty container returns an explicit empty result.

• POSTsubscribe-events

  Open a finite subscription to one resource (60–3600 s, 1800 by default); returns an initial snapshot and an authenticated event stream.

• POSTexecute-action

  Order a smart door to OPEN under a stable commandId; applied only on a correlated acknowledgement and a fresh OPEN state.

Integration fields

Wire KETI into peaqOS

providerKey

onem2m

serviceType

device.control

resource service

onem2m:resource-access → list-devices, get-device-info, get-latest-data, subscribe-events

resource skill

onem2m-resource-access

control service

onem2m:door-control → execute-action

control skill

onem2m-device-control

auth

x-agent-pairing-token (current signed pairing); x-api-key when platform auth is on

server config

ONEM2M_ENABLED, ONEM2M_BASE_URL, ONEM2M_ORIGINATOR, ONEM2M_CALLBACK_BASE_URL, ONEM2M_CALLBACK_SECRET, ONEM2M_TRUSTED_CALLBACK_SOURCES (server environment only)

event stream

GET /api/v1/machines/{machineId}/iot/events

wire baseline

Mobius4 4.24.5, oneM2M release 4; live events need peaqnetwork/mobius4 with SUBSCRIPTION_VERIFICATION=true

payment

not-required — reads are direct, writes are free orders

availability

In development

FAQ

Questions agents ask about KETI

• Does it require an API key?+

  No provider key travels in a request. The CSE connection — origin, originator, callback secret, and trusted callback sources — lives in the peaqOS server environment. Each caller sends its machine’s current signed pairing as x-agent-pairing-token, plus the platform x-api-key when that gate is on, and its delegation policy can allow sensor reads while denying door control.

• Can my robot use it today?+

  It is in development. All five operations are implemented, but compatibility with a deployed building’s Mobius CSE and devices is still being validated, and the adapter stays off until the deployment enables it. Its services are private: they appear only to a machine with a current signed pairing, never in public catalog listings.

• How does a building get connected?+

  The building’s infrastructure owner runs Mobius, the open-source oneM2M server from KETI’s Mobius4 repository, and registers each sensor and door as a labeled device. Reads and door actions work on KETI’s release. Live events do not yet: peaqOS activates a subscription only after the CSE sends a verification request to the peaqOS HTTP(S) callback, and KETI’s Mobius4 does not verify HTTP(S) callbacks. Until it does, run peaq’s build, peaqnetwork/mobius4, with SUBSCRIPTION_VERIFICATION=true. The peaqOS operator then configures the CSE connection and callback trust on the server. peaqOS never provisions building resources itself.

• How does payment work?+

  It does not. Reads run directly, and subscriptions and door actions are free orders with no payment rail. peaqOS still records the order, execution, and audit receipt.

• When does a door count as opened?+

  Only when the door publishes an applied acknowledgement for the same commandId and its state reads OPEN, both fresh and correlated. A refusal returns rejected; no confirmation in time returns unknown or timed-out, and the command can still apply until it expires. Never retry with a new commandId. Reuse the original from the same machine and pairing, and peaqOS returns the saved outcome without writing another command; the same commandId under a different pairing writes a new command.

• How fresh is the data?+

  A read returns the latest sample the device published, with its observed and received times; an empty container comes back as an explicit empty result, never an invented value. A subscription returns an initial snapshot and delivers notifications on the event stream; a sample older than the latest accepted one is marked stale. peaqOS keeps an hour of events, up to 500 per pairing, so a reconnecting stream can replay from its Last-Event-ID.

• What happens if a request fails?+

  Errors are mapped before they reach the agent: an unknown device or resource returns 404, an unreachable or slow CSE returns 503 or 504 with no automatic retry, and a missing or expired session is refused before any CSE access.