Generating Custom IoT Widgets Using Natural Language
There’s a moment every engineering team hits when building their first AI-powered IoT application. It usually starts with a simple idea:
“Let’s let the AI build the dashboard.”
Inside the sandbox, it works. You prompt an LLM, it generates some HTML, and suddenly you’re using AI-assisted development to build a UI.
But then you try to make it real.
The AI mixes up device types. It guesses field names. It produces something that looks right; but isn’t. So you start compensating. You add translation layers, inject context into prompts, and build validation logic to stop hallucinations from reaching users.
What started as a shortcut becomes a token-drain. Teams fall into a trap of consuming massive amounts of compute to generate ‘hallucinated’ code that requires manual fixing. You aren’t just building plumbing; you’re paying for high-volume outputs that lack the basic meaning required to actually function.
And that’s the trap many teams are stuck in today: trying to bridge natural language and industrial data with fragile, custom-built glue code.
The problem isn’t that AI can’t generate UIs. It’s that it doesn’t understand your world - or at least not all parts of it.
The Problem Was Never the UI
At Cumulocity, we’ve spent years making dashboards easier to build for humans. But once you introduce AI, something becomes obvious….rendering charts isn’t hard. Understanding what those charts should represent is.
An AI doesn’t know what a “machine” is in your system. It doesn’t understand how temperature relates to a specific asset, or which signals matter in a given context. Without that, every output is just an educated guess.
That’s why so many AI-driven approaches stall after the demo. They can generate something plausible, but not something you can trust.
The Missing Piece: Context
To generate something useful, the model needs more than just a prompt; it needs a foundation. The Semantic Layer serves as this context, ensuring that every token spent is grounded in your actual IoT environment. By connecting via MCP, the AI moves from expensive trial-and-error to immediate, meaningful execution.
In Cumulocity, that layer already exists. It’s the structured representation of your IoT environment, devices, hierarchies, telemetry, and relationships.
When you connect AI to it through the Model Context Protocol (MCP), the behavior changes completely. The AI is no longer guessing.
It’s operating within a system that already understands your environment.
AI-Assisted Development… But for Real This Time
This is where things get interesting.
When we started working with the AI-enabled HTML widget internally, the goal was simple:
Can we go from a sentence to a working IoT dashboard?
So we tried it.
Instead of writing queries or building components, we just described what we wanted:
“Show me all machines in Factory A with their current temperature, highlight anything above threshold in red, and include a trend chart for the last 24 hours.”
At first, the result looked impressive. Within seconds, we had a clean, responsive dashboard with live values, highlighted anomalies, and historical trend charts. But on closer inspection, we realized parts of the dashboard were still based on assumptions rather than actual understanding. Some relationships had effectively been hardcoded, and certain telemetry mappings only worked because the demo dataset happened to match the prompt.
So we iterated.
We invested in properly describing schemas, exposing the Semantic Layer through MCP tools, and grounding the model in real asset relationships, telemetry definitions, and platform-native context. Then we tried again. And again.
That’s when the behavior changed.
The system processes the request through Cumulocity MCP Server, grounding it in the Semantic Layer. “Factory A” is resolved as a real entity. The relevant machines are identified. Temperature is mapped to actual telemetry streams. Thresholds are applied based on existing logic rather than generated assumptions.
From there, the widget is generated. And this is the critical part: it’s no longer just a convincing mockup.
It’s a working, responsive UI component that can be dropped straight into a dashboard. It displays live values, highlights anomalies correctly, and renders historical trends based on real data.
No frontend rewrite. No manual API mapping. No cleanup phase afterward.
Eventually…it just works. A brand new customized widget or whole dashboard in minutes instead of multiple days ramping up your development skills & tools to build it on your own.
What makes this different isn’t that AI can generate HTML. We’ve all seen that before. What’s different is that the output is anchored in reality. The AI isn’t inventing structure. It’s selecting real data, binding it to real assets, and using platform-native capabilities to produce something immediately usable.
That’s why the result doesn’t feel like a prototype. It feels like something you would have built yourself, just without the time and effort.
A Small Shift with Big Implications
At first glance, this looks like a productivity gain. In reality, it removes one of the biggest bottlenecks in IoT projects: the constant translation between data, intent, and UI.
Traditionally, that translation layer has to be built manually. It’s where a significant amount of engineering time goes, and where complexity accumulates.
Here, the platform handles it. Which means teams can move from asking:
“How do we build this dashboard?”
to simply asking:
“What do we want to see?”
This Is How We Build Now
This isn’t a concept or a future vision. It’s how we’re already building internally.
We use this approach to prototype dashboards in minutes, explore ideas without committing engineering resources, and enable non-frontend experts to create meaningful UI components.
More importantly, it ensures that what’s generated is correct; not just visually convincing, but grounded in the actual system.
Stop Building Dashboards. Start Describing Them.
There’s a question every team should ask:
Are we building interfaces—or are we building value?
Because if your engineers are still wiring frontend components and translating data for AI manually, you’re not accelerating. You’re just shifting complexity around.
Cumulocity takes a different approach.
You buy the foundation, the structure, the context, the lifecycle management, and you build where it matters.
Now, with MCP and AI-native capabilities, that build layer becomes dramatically simpler. Sometimes, it’s just a sentence.
Final Thought
For years, AI-assisted development has been seen as experimental; too fragile for real-world systems.
But when AI is grounded in the right context, that changes. For the first time, you can describe an IoT application…and get something real back.
Not a prototype. Not a promise.
A working result.