peaq Lets Robots and Machines Talk to Buildings with KETI's Mobius

Mobius, the open-source oneM2M platform built by the Korea Electronics Technology Institute (KETI), is now available to robots and machines running peaqOS. A machine can discover the sensors and devices in a building, read their state, and subscribe to changes as they happen. And it can open a smart door, and know for certain that the door actually opened. Autonomously, on demand, without human intervention. Available now on robotic.sh.

A delivery robot pulls up at the entrance of a building with Package #142 for Loading Area B. It can see the door in front of it. It can't see whether the loading area behind it is free, and it has no way to open the door.

It has two options. Wait at the entrance until a human notices and lets it in. Or ship with a custom integration for this building's door, this building's sensors, this building's access system, and build it all again for the next building on the route.

With Mobius via peaqOS, there's a third option: the robot talks to the building. It asks what's there, waits for the right moment, and lets itself in.

What Mobius Unlocks on robotic.sh

oneM2M is the global standard for how connected devices describe themselves and talk to each other. It's backed by eight standards bodies, Korea's TTA and Europe's ETSI among them, and more than 200 member organizations. Mobius is KETI's open-source implementation of that standard, the server a building's sensors, doors and gateways report to. KETI's Mobius was the first product certified as compliant with oneM2M Release 2.

A normal integration speaks one vendor's language. oneM2M gives every compliant device the same one. One standard, instead of one integration per sensor, per door, per building.

Starting now, oneM2M infrastructure is available through robotic.sh as two services. With Resource Access, a robot or machine running peaqOS can find the devices in a building, read their latest state, and subscribe to changes instead of polling. With Device Control, it can open a smart door. And sending the command isn't the end of it: the action only counts once the door acknowledges it and reports itself open. Every call goes out under the machine's own peaqOS identity, and the building's credentials stay with peaqOS, never on the robot.

It's the first integration of its kind on robotic.sh: a service that lets a machine act on the physical space around it, not just read about it. And it's live on robotic.sh today.

Why This Matters: Buildings Already Know What Robots Need to Know

Buildings are full of answers. Occupancy sensors know which room is empty. Doors know whether they're shut. Environmental sensors know when a cold room starts warming up. Until now, a robot couldn't ask.

Korea shows the gap clearly. It runs more robots per worker than any country on earth, 1,220 per 10,000 employees. It has also been wiring its cities with oneM2M since its first smart city pilots in 2015. The robots and the infrastructure grew up in the same country, and never spoke.

Getting them to work together used to mean an integration project per device, per building, per fleet. With Mobius via peaqOS, the machine learns one language and uses it wherever it's spoken. And it stacks: a machine in Korea can already take its route from NAVER Maps and its conditions from the country's public data, and now open the door when it arrives. Every new service added compounds peaqOS Scale's overall value.

peaq Handles the Coordination

peaq is the layer that lets machines reach oneM2M infrastructure and use it. For each request, peaq handles:

• Machine identity, via peaq DIDs. Only an activated machine with a current, signed pairing gets through
• Permissions per machine: a robot can be allowed to read the sensors and still be denied the door
• Building credentials held by peaqOS, never handed to the robot
• Coordination of the call, from request to result, including the events that come back
• Confirmation that a door really opened, not just that a command was sent
• A verifiable, auditable record of what ran

So a machine can work with a building's infrastructure, without a custom integration and without a key of its own.

Showcase: A Delivery Robot Lets Itself In

We're showcasing the integration with a demo where a delivery robot enters a smart building it has never seen before. It's a real oneM2M flow, simulated with peaqOS, with peaqOS handling identity, discovery and the record, and Mobius speaking for the building's devices.

Here's the scenario: Package #142, Loading Area B, and three connected devices the robot has never been integrated with, an occupancy sensor, an environmental sensor and a smart door. Here's how the process unravels:

→ The robot checks in under its own peaqOS identity and asks the building what's there. Mobius returns the occupancy sensor, the environmental sensor and Door 4

→ It reads the occupancy sensor: Loading Area B is occupied. So it waits instead of driving in

→ It subscribes to the sensor rather than asking again and again. Seconds later, the notification arrives: Loading Area B is clear

→ It sends one instruction to Door 4: open. The door acknowledges the command and reports itself open, and only then does the robot drive in and complete the delivery

→ Every call leaves a verifiable, auditable record. No payment runs on this path, and the robot never holds the building's credentials

Four calls, zero custom integrations. The robot had never met this building, and still knew when to wait and how to get in.

More Real-World Scenarios

Scenario 1 — A Cleaning Robot Works Around the People

It's 7 p.m. in an office tower and a cleaning robot starts on the twelfth floor. Half the meeting rooms are still in use, and nobody tells a robot when a meeting runs late.

The old way is a fixed schedule. Either the robot vacuums around a meeting in progress, or the room waits until morning.

Instead, the robot reads the floor's occupancy sensors through robotic.sh and subscribes to the rooms still in use. When a room empties, the event reaches the robot, and it goes in.

The building already knows who's still there. Now the robot does too.

Scenario 2 — A Forklift Checks the Cold Room Before It Opens It

An autonomous forklift is moving pallets into cold storage. Every time the dock door opens, warm air rushes in, and the cargo pays for it.

The old way is a fixed slot and a human holding the door, or a forklift that opens it the moment it arrives, whatever the temperature inside.

Instead, the forklift reads the cold room's environmental sensor before it commits. If the temperature is holding, it opens the dock door through Device Control and drives in. If it isn't, it waits for the room to recover.

One reading, one door, and the cargo stays cold.

And occupancy, climate and doors are where this starts. Buildings run on far more connected devices than that, and oneM2M already gives them a common language.

Available Now on robotic.sh

oneM2M infrastructure is now live on robotic.sh for robots and machines running peaqOS.

Machines can find the devices around them, read them, follow them and act on them, under their own identity. Every call leaves a verifiable, auditable record.

Because autonomous machines shouldn't have to choose between waiting at the door and a custom integration for every building.

They should be able to talk to the buildings they work in.

→ Visit robotic.sh to get started.