u-IoT¶
URG's own hardware for everything a building has that is not a robot: call
buttons, lights, sound, potential-free contacts, door and lift signals.
Built and operated by URG site integration (site/iot-integration).
Status as of 11.09.2026 — aligned with the u-IoT handover of 10.09.2026 (data sheet and user manual 1.0). Documents: u-IoT — Documents.
What the module is¶
One device, one firmware, four build forms. Two digital inputs for volt-free normally-open contacts, two digital outputs for a light, a buzzer or a relay, an action engine, a web interface on the device itself, Wi-Fi as its own access point and as a client on the site network, and a device-to-device radio link between u-IoT units that is independent of the site network.
Call button, light and sound are not three devices — they are the same assembly, fitted differently. The light and the sound are configurations of the two outputs, not separate hardware logic. That is worth knowing before ordering spare parts.
| Build form | What it does | Order codes |
|---|---|---|
| Call | A button calls a robot to a map point; a light and a buzzer give feedback | UIOT-B, UIOT-BL, UIOT-BS, UIOT-BLS |
| Call without button | Signal station at a handover point: light, sound or both, switched by the fleet | UIOT-L, UIOT-S, UIOT-LS |
| Door opener — uGate | A volt-free relay contact in parallel with the open input of the door operator; opens the door when a robot approaches | UIOT-D |
| Robot bridge | Sits on the robot, powered over USB from the tablet case; follows pose and planned path and switches the uGate units along the route; can also coordinate several call buttons | UIOT-X |
Order codes¶
| Code | Designation | What is fitted |
|---|---|---|
| UIOT-B | u-IoT Call Button | button on input 1 |
| UIOT-BL | u-IoT Call Button with Light | button, light on output 2 — flashes while the request is pending, stays on until the robot arrives |
| UIOT-BS | u-IoT Call Button with Sound | button, buzzer on output 1 |
| UIOT-BLS | u-IoT Call Button with Light and Sound | button, buzzer on output 1, light on output 2 |
| UIOT-L | u-IoT Light | light on output 2, no button |
| UIOT-S | u-IoT Sound | buzzer on output 1, no button |
| UIOT-LS | u-IoT Light and Sound | buzzer and light, no button |
| UIOT-D | u-IoT Door (uGate) | volt-free relay on output 1; input 1 optionally as "door open" feedback |
| UIOT-X | u-IoT Bridge | no input/output fitting; powered over USB on the robot |
Combination rule. Two outputs. Door opener, light and sound therefore cannot run together on one unit; where a door also needs signalling, a second unit (UIOT-LS) is placed next to it.
Naming. The door-opener form is called uGate in every customer document. Older sheets that describe door modules of other origin — different wire colours, a different network name, a different supply range — do not apply to the u-IoT; the earlier "call-me button" sheets are superseded by the u-IoT data sheet and user manual 1.0.
Lifts. Connecting lifts through the robot bridge is under trial and is released individually per lift type. Release status: to be confirmed.
The call button already exists¶
The call-button logic is in the firmware, including the roles: standalone (the unit keeps its own robot list and dispatches directly), coordinator (central point for several call buttons), client (forwards to a coordinator), door opener (dedicated to the door, does not dispatch). The coordinator's status carries the list of pending requests. This is not something to be rebuilt on the robot side; it is something to be read. Measured on the test bench: the health, I/O status and call status endpoints each answer.
How the robot is addressed¶
In the firmware currently delivered, a robot is entered in the unit's robot table by the address of its chassis; where the site network assigns addresses automatically, the robots need a fixed assignment, otherwise a call goes nowhere once an address changes. The target: the robot is addressed through a uGo service key and uGo maps identifier to address, so that units no longer hold robot addresses. Firmware version and date of the changeover: to be confirmed. See Access control (sessions, service key) and Building API for the platform side.
Two findings that belong in every commissioning¶
The module has no set clock. Reported as not synchronised on the test bench. The time problem is not confined to the chassis — it runs through the building hardware too. See Time and Time Source.
The module opens its own wireless network. The access point is always broadcast; its name is derived from the serial number on the device label. This has to be explained to the customer's IT department before they find it themselves during a scan. A device that opens an access point nobody announced is, from their side, indistinguishable from an intrusion. The access point is open as delivered — a password of at least eight characters is set during commissioning, before productive operation.
Security note¶
The device interface (REST) operates without its own login and is therefore run only inside a protected network segment; operation on a publicly reachable network is not permitted. The configuration export contains passwords and keys in readable form — that file is not an attachment, not a ticket entry and not a chat message. The relay contact issues the same command as a manual push button; it is never wired into the safety chain of a door.
Open points¶
Carried as to be confirmed in the data sheet and the user manual 1.0; nothing is estimated:
| Point | Blocks |
|---|---|
| Dimensions, weight, degree of protection and mounting per build form | data-sheet line, enclosure |
| Rating of the driver stage for light and buzzer (switching type, operating voltage) | delivery of the variants with light or sound |
| Ambient conditions | data sheet |
| CE marking and conformity of the box | delivery, CE note in the data sheet |
| Firmware version released for delivery | series release |
| Firmware version for the changeover to the uGo service key | commissioning section of the manual |
| Lift bridge: release per lift type | sale of the lift application |
Related pages¶
- Doors and Lifts — how the module plays together with door and lift control
- Building API (/api/gebaeude)
- uGo server — the u-IoT pass-through
- u-IoT — Documents