Semantic Energy Management with Shelly Devices and FIWAREBox

Overview

This use case shows how standard Shelly devices can be extended from a smart-home setup into a semantic energy and automation platform using FIWAREBox. Instead of living only inside one mobile app, Shelly plugs, meters, and sensors can publish their data to the cloud or on-premises FIWAREBox and receive commands back from it. In this way, the same Shelly device can:

• keep working as usual in the Shelly mobile application, and

• at the same time become part of a wider context: buildings, campuses, or city infrastructure.

FIWARE is an open-source framework for building interoperable digital platforms. It provides standards such as NGSI-LD, which give shared meaning to data across systems, and a Context Broker, which keeps live information about devices, environments, and processes.

FIWAREBox is a practical, ready-to-use implementation of FIWARE developed by SenLab. It combines the Context Broker with data catalogues, data spaces, dashboards, and connectors, turning local IoT data and other open data into reusable semantic context for cities, industries, and research projects.

Why “semantic” and why “context”?

In large-scale systems like smart cities or industrial networks, data alone isn’t enough - every reading must carry meaning: what it represents, where it comes from, and how it relates to other things.

A semantic layer defines this meaning through shared vocabularies (such as Smart Data Models), enabling different systems to understand each other without custom translation.

The Context Broker acts as a live “hub” that manages these relationships - devices, locations, people, and processes - so applications can always query or update the current state of the world.

This combination makes FIWAREBox ideal for interoperability: connecting diverse devices, protocols, and software into one coherent environment that works across homes, buildings, and entire cities.

Why a context broker is different from (and complements) an MQTT broker?

An MQTT broker is a lightweight message distributor. Devices publish topics, and other systems subscribe to them. It is extremely efficient, reliable, and perfect for moving data - but it does not understand what that data means.

A Context Broker, on the other hand, manages meaning and relationships. It keeps track of entities (devices, rooms, assets) and their attributes (temperature, power, state) in real time. Each update adds or modifies a property within a living digital twin of the world.

In short, MQTT answers “who said what”, while the Context Broker answers “what does it mean and how does it fit in the bigger picture.” When combined - as in FIWAREBox - MQTT moves the raw data, and the Context Broker turns it into structured, query able, and interoperable context. This pairing bridges the world of connected devices with the world of smart-city platforms, energy management systems, and data spaces.

Challenges

Typical users of Shelly devices today face several challenges when they want to go beyond “classic” home automation:

• Data is visible, but hard to reuse elsewhere
  Power and sensor data are easy to see in the Shelly app, but not directly available to external energy dashboards, research projects, or city platforms without additional integration work.

• Different systems speak different languages
  A building-management system, a research platform, and a municipal energy dashboard may all need the same data, but each expects its own format and API.

• Control logic is spread across multiple places
  Scheduling and rules may live partly in the Shelly app, partly in a local controller, and partly in custom scripts, making it harder to maintain or extend.

• Scaling from one flat to many buildings
  The same plug and sensor types are useful in public buildings, schools, laboratories, and small industries. Without a shared semantic layer, it is difficult to combine and compare data across these locations.

The goal of the solution is to keep the simplicity of Shelly devices while making their data and control usable in semantic energy and automation scenarios across different organizations and tools.

Solutions / Implementations

Architecture Overview

The combined FIWAREBox + Shelly solution uses a hybrid approach:

• MQTT for device-level communication (what Shelly already supports natively).

• NGSI-LD and Smart Data Models for semantic context in FIWAREBox (what energy and smart-city platforms expect).

There are two main data flows:

1. Telemetry path (Shelly → FIWAREBox)

   • Shelly publishes measurements to an MQTT broker.

   • A Node-RED flow (or other script/process) in FIWAREBox subscribes to those topics.

     

     

   • The flow transforms the payload into NGSI-LD entities based on open Smart Data Models (e.g., Device / Energy).

   • The entities are sent to a FIWARE Context Broker and registered in the Data Catalog as a Service (DCaaS) inside FIWAREBox.

     

     

2. Command path (FIWAREBox → Shelly)

   • A user or application updates a semantic attribute such as deviceState in the Context Broker (e.g., from “off” to “on”).

   • FIWAREBox (via Node-RED) receives a subscription notification about the change.

   • Node-RED translates this update into an MQTT command for the specific Shelly device.

   • The Shelly executes the command and publishes its new state back to MQTT, closing the loop.

In practice, the Shelly device continues to behave as before from a user’s perspective, but FIWAREBox adds a semantic, bidirectional channel that other systems can understand. And this is also a solid foundation for AI and LLM.

Implementation steps

Step 1: Connecting Shelly to the MQTT broker

Shelly devices natively support MQTT. To integrate them with FIWAREBox, the MQTT server in the Shelly web interface or app is configured to point to the MQTT broker that is part of the FIWAREBox environment.

Typical configuration parameters:

• MQTT server address and port (FIWAREBox broker).

• Device-specific topic prefix (for example, shelly-plug-s/roomA/workstation1).

• Optional geolocation and time-zone settings.

Once this is done, the Shelly device starts publishing messages containing:

• Instantaneous power, voltage, current.

• Energy totals.

• Relay state and other status information.

This is still “raw” transport data, but it is now available inside FIWAREBox for further processing.

Step 2: Adding semantic context with Node-RED and Smart Data Models

Inside FIWAREBox, a Node-RED flow subscribes to the Shelly topics. For every incoming MQTT message it:

• Parses the payload (JSON).

• Maps fields to Smart Data Models attributes such as power, voltage, current, totalActiveEnergyImport, location, phaseType.

• Builds an NGSI-LD entity representing the Shelly Plug.

• Sends the entity to the FIWARE Context Broker and database.

This turns individual Shelly readings into self-describing digital twins that follow established semantics. The same property names and units can be reused across homes, public buildings, and industrial installations.

Step 3: Cataloguing and exploring the data in FIWAREBox

Once entities are present in the Context Broker, FIWAREBox automatically integrates them into its semantic tools:

• DCaaS (Data Catalog as a Service) registers each data source and dataset using open specifications such as DCAT-AP, so Shelly-based measurements can be discovered and reused by other applications.

• The Extended Metadata Browser (EMB) shows how Shelly devices are modelled: types, properties, relationships, and provenance.

• The Extended Data Browser (EDB) provides time-series views of the Shelly measurements, including filtering and export options.

From a normal user’s perspective, this means:

• You can look at your Shelly Plug exactly like at any other energy meter in the system.

• You can easily find it again later (“all power meters in building X”, “all devices in classroom Y”).

• You can combine Shelly data with other datasets (solar production, tariffs, weather, occupancy) without custom integration for each tool.

Step 4: Enabling control from FIWAREBox

To go from simple monitoring to “smart device” behaviour, FIWAREBox also exposes commands through semantic attributes.

A typical pattern is:

• The Shelly Plug is represented as a Device entity with a property such as deviceState (“on” or “off”).

• When a user, dashboard, or external application updates deviceState in FIWAREBox, Node-RED receives an event.

• Node-RED publishes the corresponding MQTT command on the Shelly control topic.

• The Shelly device switches its relay and reports back its new state, which updates the entity again.

In this way, the Shelly device can be controlled from:

• FIWAREBox dashboards,

• third-party applications using NGSI-LD,

• automation rules that combine Shelly data with other context (for example, “turn off all non-essential plugs when the building is empty and tariffs are high”).

The original Shelly app can continue to be used in parallel. FIWAREBox simply adds another way to control the same hardware when integration with broader systems is needed.

What this means for users leaving the “home automation bubble”

For a typical user, the main benefits of connecting Shelly devices to FIWAREBox are:

• One set of devices, many possible platforms
  The same Shelly Plug can feed a local dashboard, an energy analysis notebook, or a city portal - without rewriting the integration each time.

• Consistent meaning everywhere
  Power from a Shelly Plug at home, from a Shelly EM in a school, and from an industrial meter in a factory can all be treated in a unified way because they share the same semantic model.

• Simpler long-term evolution
  Future systems can connect directly to FIWAREBox’s semantic interface instead of starting from scratch.

• Gradual transition, not a big bang
  You keep the Shelly app and extend functionality step by step: first monitoring, then semantics, then control and automation.

Results

Users who connect Shelly devices to FIWAREBox can expect:

• Improved visibility into real energy use, from a single plug up to entire buildings.

• Faster prototyping of new ideas using real data rather than simulations.

• Reusability of integrations thanks to open Smart Data Models.

• Bidirectional control driven by rules, tariffs, or external conditions.

The overall effect is that inexpensive Shelly devices become an entry point into semantic energy management and broader smart-city or industrial scenarios, without changing the hardware.

Conclusion

Shelly devices are designed to make home automation simple and accessible. When combined with FIWAREBox, they can also act as semantic building blocks in larger energy and automation systems.

By using MQTT for device connectivity and FIWAREBox for semantic context, cataloguing, and control, a single Shelly Plug evolves from a standalone gadget into a small but meaningful part of a wider data space. Users keep the convenience of the Shelly ecosystem while gaining the option to integrate with professional dashboards, open data catalogues, and smart-infrastructure tools.

This approach shows how existing Shelly hardware can serve both everyday home users and organizations exploring smart-energy and smart-city concepts, with FIWAREBox providing the semantic layer - and the Context Broker - that make interoperability possible.

We Value Your Feedback

Thank you for taking the time to read this use case. If you have remarks, ideas for improvement, or examples of your own projects combining Shelly devices with semantic platforms such as FIWAREBox, we would be glad to hear from you: integration@shelly.com

Devices Used

Devices Used Optionally