Skip to main content
Technical Preview

Overview

One client-mode connector, SiemensIEM, for the Portal Public API of a self-hosted Siemens Industrial Edge Management (IEM-OS, or IEM Pro on Kubernetes). IEM is the central place where you onboard Industrial Edge Devices (IEDs) and deploy Industrial Edge apps to them. With this connector the broker can publish your edge fleet into the Unified Namespace (device status, statistics, installed apps) and drive app rollouts from MQTT: deploy an app, restart or stop it, push a new app configuration, then follow the batch until every device job is COMPLETED. The connector talks to the IEM management API only. Data on the devices themselves (Databus MQTT, connectors, IIH) is not part of this connector. Every reply is published on <topic>/response.

Authentication

The Portal API uses a token in the Authorization header, sent as is (no Bearer prefix):
  1. Publish to mes/siemens-iem/token/create with {"body": {"username": "...", "password": "..."}}. Use an IEM user or a technical user with the rights you need. The reply has data.access_token, valid for 24 hours.
  2. Put that token in "authorization" on every other event.
Keep the user name and password in Hub secrets (for example SIEMENS_IEM_USERNAME and SIEMENS_IEM_PASSWORD) and read them with GET SECRET. Never paste them into the connector. A missing or expired token returns 401.
Many IEM installations use a self-signed certificate (the Siemens examples call curl --insecure). The broker host must trust the IEM certificate authority, or every call fails during the TLS handshake.

Connector

Replace YOUR_IEM_HOST with your IEM address (no path). Every endpoint starts with /portal/api/v1.

Deploying an app

POST /portal/api/v1/batches takes multipart/form-data with one field, infoMap (JSON). The connector sends the fixed boundary CorefluxIemBoundary, so form carries the complete multipart body with CRLF line breaks:
Publish that to mes/siemens-iem/application/deploy. The reply is {"data": "<batch id>"}. Then:
  1. mes/siemens-iem/batch/get with batch_id: READY (batch accepted) or PROCESSED (device jobs created).
  2. mes/siemens-iem/batch-job/list with batch_id: one job per device.
  3. mes/siemens-iem/job/get with job_id: QUEUED, EXECUTING, COMPLETED, FAILED, …
infoMap can also carry delayTime (1 to 60 minutes between devices) and configs (for example [{"configId": "...", "templateId": "..."}], ids from ListAppConfigs). For other operations use mes/siemens-iem/application/command with operation set to updateApplication, uninstallApplication, startApplication, restartApplication, stopApplication, updateAppConfig or deleteAppConfig, and query set to "" or versionId=<id> (developer apps) and schedule=<ticks>.
Deploy and command events change what runs on production edge devices. Restrict who may publish to mes/siemens-iem/application/# with a broker rule.

Example actions

Log in twice a day, keep the token in broker state, and poll the device list every five minutes:

Notes

  • ListDevices takes query such as page=0&size=50. ListInstalledApps takes deviceid=<id>, or "" for all devices.
  • Device status is data.deviceStatus from GetDevice. There is no separate device status endpoint. GetDeviceStatistics returns the last statistics the device sent, keyed by timestamp.
  • Logout works on IEM-OS only (not on IEM on Kubernetes).
  • Not included: application import from file and file-based app configs (multipart file uploads), device creation and deletion, device reboot or shutdown jobs, log downloads, projects and companies, and the separate IEM Admin API.

References

Last modified on October 21, 2026