Technical Features. The ingest path, the integration matrix and every public endpoint.
A reading leaves a device, reaches an IoT Agent, becomes an NGSI-LD entity in Orion-LD, fans out through RabbitMQ to the consumers that store and evaluate it, and lands in PostgreSQL, TimescaleDB and MongoDB. The web back end is the read side. It is not in the ingest path.
Observe what is out there, collect it into one model, understand it, and give people somewhere to work. Each layer depends only on the one below it, which is why a new vertical is a licence and not a migration.
Air quality, pollutants and sound levels.
Free bays, flows and occupancy.
Consumption, generation and grid assets.
Supply, quality and surroundings.
Footfall, gatherings and safety.
Local conditions and forecasts.
LoRaWAN, MQTT, HTTP and third-party feeds.
Devices self-configure, with no firmware change.
NGSI-LD entities typed by Smart Data Models.
Time series in TimescaleDB, retention per plan.
Multi-variable rules on thresholds.
Models for air quality, parking and weather.
Cleaning, cross-referencing, counting.
3D twins and what-if scenarios, scoped per deployment.
Push to city platforms, ERPs and data spaces.
Dashboards &reports, alarms &rules engine, MCP server for AI assistants.
Licensed: AI engine, conversational assistant, 3D twins, AI marketplace.
Data sources, devices &connectors, entity explorer, workspaces.
All four in every plan.
Sector packs on the same core.
Per module: envair360, grid360, parking360, crowd360. On request: nebula360, berry360.
Administration &organisations, roles, single sign-on &audit trail, subscriptions, help.
Licensed: reseller portal.
Every badge below carries what it actually is. Certified means a certifying body and an expiry date behind it, evidence we send on request, and a line in a tender annex. Aligned means design and process work against a framework where no certificate exists yet, or where ours has not been issued. A badge you cannot evidence is a liability, so the two are never printed the same.
Three sides of the same delivery, and one route the readings always take.
Physical
Sensors, cameras and radar on the street, filtering at the edge so the network carries decisions and not noise. Libelium manufactures this layer, which is why we can tell you what a Smart Spot does at -10 C.
Data
Sensor feeds joined with telecom, traffic and utility datasets, then locked down: who sees what, who changed what, and where it is allowed to live.
Platform
Entities in Orion-LD, forecasts on a WRF domain, twins for the what-if question, and everything downstream reading one normalised model.
Device
Sensor or gateway emits a reading.
IoT Agent JSON
Normalises the payload. This is the entry point, and the web back end is not.
Orion-LD
Creates or updates the NGSI-LD entity in the context broker.
RabbitMQ fan-out
The subscription sink queues it for the consumers.
Storage and live feed
PostgreSQL, TimescaleDB and MongoDB. The real-time table goes out over change data capture to WebSocket.
The complete list of sources and destinations, and what each one takes to switch on: a setting, a field mapping, or a scoped project. Everything below is implemented today.
Not a roadmap and not a matrix of intentions: this is the connector list in a running deployment, with HTTP, MQTT, Azure IoT, Sentilo and FIWARE all reporting active. It is where a deployment starts. A destination that speaks HTTP or MQTT is a configuration; one that speaks a protocol we have not met is integration work with a date on it, not a platform change. Adding a destination is a form, and the same list is readable and writable through /connectors/out in the public API.
Not on the list? The FIWARE Manager and the generic HTTP connector cover most of what is missing. Send us the spec of your source and we will tell you straight whether it is a config or a project.
Get a token, discover what is deployed, read the current value or the whole history, send a command back, and bind devices to an out-connector. Eleven endpoints under /api/public/v1, all of them documented.
Two limits worth knowing before you design against it. This API does not ingest : readings enter through an IoT Agent or the context broker; and of the eleven endpoints only two write, so there is no device provisioning and no entity creation here.
An MCP-capable assistant gets a session of its own against a running instance. It is a session, not an export: there is no index of your data anywhere for it to search.
The commands and connector routes an assistant cannot reach are the two write endpoints of the public API.
The OAuth device flow, against the same Keycloak the web interface uses. The assistant prints a short code, a person completes the login in a browser, and the session is bound to that person.
Being a valid user is not enough. The account has to carry the role that permits MCP access, and without it the server refuses the session outright: it does not fall back to a smaller scope.
The tools are read-first: inventory, entities, the last values, time series, alarms and the reasons they fired, dashboards and out-connector definitions. It can also author a dashboard or a report, and that authoring is a two-step draft-then-confirm.
The same platform in every plan: the same dashboards, the same rules engine, the same eleven endpoints. What changes is whose infrastructure it sits on, and what that lets us commit to in writing.
A tenancy on our cloud, live in days. Three sizes, from a first pilot to a city running several teams, and the ceilings are the only thing that changes between them.
One dedicated instance inside your perimeter, on hardware your team controls. Chosen where the security review ends with "not in a shared cloud".
A cluster we run for one organisation and nobody else, sized S, M or L to a throughput you can name. The only one where we own the whole stack, which is why it is the only one with the commitment in writing.
Pulled from tenders, from pre-sales calls at minute twenty rather than minute two, and from the support queue.
It sits next to it. There is a Sentilo out-connector in production, so entities normalised in iris360 are published into your existing Sentilo instance and every consumer you already have keeps working. Replacing Sentilo becomes a separate decision you can take later, or never.
Us, for the whole chain. Libelium designs and manufactures the Smart Spot and Plug & Sense hardware in Zaragoza and writes the platform it reports into, so a suspect value gets traced from the probe to the dashboard by one supplier. On third-party sensors we can only go as far as the ingest path, and we will say so on the call.
Both, in that order. A reading arrives, an IoT Agent hands it to the Orion-LD context broker, and it becomes an NGSI-LD entity typed by a Smart Data Model; the time series lands beside it. That is why a parking sensor from one manufacturer and one from another are the same kind of thing for every dashboard, rule and connector downstream.
Forty-two, each one a separate permission in the platform: 27 chart types and 15 panel types: time series, bars, gauges, pie, heat maps, scatter, wind rose, radar, calendar heat maps, Leaflet maps, 3D views, tables and tiles.
Yes. Every dashboard has a public view route that needs no authentication, so a live panel can be embedded in a city website or a press page.
Yes, and it answers the lock-in question at the same time. POST /timeseries accepts an array of requests, each with its own entity, measures and aggregation options, and returns the history in one call, so a nightly script can mirror everything you own into your own warehouse. If you ever leave the platform, you leave with the data.
Yes. POST /devices/sendCommandsBulk sends commands to many devices at once, with the same bearer token you used to read.
Worth saying plainly: of the 11 endpoints, that one and the connector binding are the only two that write. There is no device provisioning and no entity creation over the public API, so if your integration needs to register hardware programmatically, tell us in the first call.
Yes. iris360 ships an MCP server. An MCP-capable assistant authenticates as one of your users and reads entities, time series and alarms through that user's permissions, against the live platform.
It is given access, not a copy. Nothing is exported into a third-party index for the assistant to search.
A project. There is no native Modbus or OPC-UA client in the platform. Those buses are reached through an edge gateway that speaks Modbus or OPC-UA on one side and MQTT or HTTP on the other, and that gateway is scoped and priced per site. Everything above it is standard configuration.
No. Devices reach the platform through an IoT Agent (JSON), MQTT, HTTP or the integrated LoRaWAN network server, so the gateway keeps sending exactly what it already sends.
No. There is an openapi.json you can generate a client from, and the reference portal. That is the whole developer surface today.
On the shared-cloud plans, in the EU. On Enterprise, on your own infrastructure, in a single node your team runs. On Special, on a dedicated cluster whose location is written into the contract.
Yes: that is the Enterprise plan. The trade-off is worth saying out loud. On-premise means your team owns patching windows, backups and capacity, and platform upgrades happen when your change process allows, not when we ship them.
Two: ENS and ISO/IEC 27001, each with a certifying body and a valid-until date we send on request.
Gaia-X, NIS2 and the AI Act appear on this site as alignment work. The architecture page keeps the two lists apart, and in a tender you get both.
The most useful first conversation is 40 minutes on a real integration. Bring one source you need ingested and one system that needs the data afterwards, and you will leave knowing whether it is configuration or project work.
English English 
Español
