QUICK INTRO
In our previous Shelly + FIWAREBox blog post / tutorial, we showed how a simple Shelly Plug can publish live energy data into FIWAREBox - through MQTT, Node-RED, and a Context Broker. After some readers asked the same question:
“Cool, I see the data in FIWAREBox… but how do I control Shelly back from there?”
So here’s a short recap of what Shelly devices actually are, and how easy it is to make them bidirectional - controlled directly from FIWAREBox. Because true smart devices don’t just report — they respond.
SHORT RECAP: WHAT IS SHELLY?
Shelly is a family of small Wi-Fi IoT devices designed primarily for home automation - plugs, relays, sensors, meters, and switches.
They’re great because they speak MQTT natively and can work offline, without depending on any cloud.
Out of the box, you control them through the Shelly mobile app, which is sleek and powerful:
- switch plugs on/off,
- monitor consumption,
- set timers, and
- integrate with Alexa or Google Home.
PROBLEM: ONE-WAY DATA FLOWS AND CLOSED ECOSYSTEMS
Out of the box, the Shelly mobile app does an excellent job. It can toggle your plug, schedule timers, monitor power, and even connect to Alexa or Google Home. But it all stays inside the vendor’s ecosystem (although possibility to connect to external MQTT broker helps a lot with interoperability) - closed, cloud-centric, and non-semantic. Your factory, city, or energy platform doesn’t understand those commands, and can’t integrate them into broader data flows.
You can see the wattage, but not connect it to your building management system. You can switch the plug, but not link it to weather data, tariff models, or sustainability dashboards.Without open context, you’re just automating an island. But it is more than good enough if you stay in your house and not thinking about integrations.
That’s not IoT — that’s remote control.
That’s where FIWAREBox steps in.
Now we’ll solve the control one. Because true smart devices don’t just report — they respond.
SOLUTION: BI-DIRECTIONAL CONTROL WITH FIWAREBOX
In FIWAREBox, we go hybrid — combining MQTT (for devices) and NGSI-LD (for semantics).
Data and commands travel both ways.
Commands: FIWAREBox (DCaaS or DSaaS) → Context Broker → Node-RED → MQTT → Shelly
Data:
Shelly → MQTT → Node-RED → Context Broker → FIWAREBox (DCaaS or DSaaS)
When you update the status attribute in the Context Broker (on or off), Node-RED detects the change and sends a matching MQTT command to Shelly.
The plug executes it, reports the new state back, and the Context Broker updates the entity.
Closed loop: from click → to action → to confirmed update and telemetry data.
HOW IT WORKS
THE COMMAND PATH
- User changes the NGSI-LD property status (via Node-RED UI, Grafana, or API).
- FIWARE Context Broker receives the update (PATCH request).
- Node-RED subscription node detects the change.
-
Node-RED publishes "on" or "off" to Shelly’s MQTT topic:
shellies/shellyplug-s/relay/0/command*
- Shelly toggles the relay and reports its new state via MQTT.
THE TELEMETRY PATH
- Shelly publishes power, energy, and relay state to MQTT.
- Node-RED transforms the data into Smart Data Models (JSON-LD).
- FIWARE Context Broker updates the entity.
- Dashboards (Grafana, DCaaC, DCaaS, or custom UI) visualize live status.
EXAMPLE: TURN ON VIA NGSI-LD
Send a simple HTTP request to control your plug:
PATCH /ngsi-ld/v1/entities/urn:ngsi-ld:ShellyPlug:001/attrs/deviceState
Content-Type: application/ld+json
{
"deviceState": {
"type": "Property",
"value": "on"
}
}
Replace "on" with "off" to turn it off.
That’s it — no cloud API keys, no mobile app, no vendor lock-in. Just open context control.
SEMANTICS AND SAFETY
We map the deviceState property to the Smart Data Models definition:
https://smartdatamodels.org/dataModel.Device/deviceState.
This keeps our Shelly entity aligned with the standard Device data model in Smart Data Models.
Example payload:
"deviceState": {
"type": "Property",
"value": "on",
"observedAt": "2025-11-06T10:00:00Z"
}
You can still keep ON/OFF semantics on top of that (e.g. "on", "off", "error", "booting") - Smart Data Models explicitly allows vendor-dependent values here.
CLOSING THOUGHT
Shelly devices were designed for smart homes. But connected to FIWAREBox, they become semantic building blocks for smart cities and industries.
The same principle works across all Shelly families:
- Relays and Plugs → control and monitor power circuits.
- Sensors → publish environmental and motion data.
- Meters → provide detailed consumption metrics.
- Lighting Controllers → enable adaptive, context-driven illumination.
- Switches and Inputs → serve as triggers for automation flows.
Each of them can be modeled, catalogued, and managed through FIWAREBox - not as isolated gadgets, but as interoperable Lego blocks in a larger semantic system.
In that sense, Shelly is no longer just a home IoT brand. It’s a bridge: a practical, affordable step between consumer devices and smart-city infrastructure.
And that’s exactly the kind of simplicity we like to build on.
FUTURE EXPERIMENTS
We’ll extend this logic to:
- multi-relay devices (Shelly Plus series),
- motion sensors and environmental meters,
- energy meters for grid and solar integration,
- smart thermostats and lighting controllers,
- and door/window sensors for occupancy analytics.
All following the same hybrid MQTT + NGSI-LD pattern inside FIWAREBox.
If you’re interested, comment which Shelly device you’d like to see next — or suggest a non-Shelly equivalent (LoRaWAN, Modbus, Zigbee…).
Wish to know more or book a short consultation? Visit fiwarebox.com or reach out directly. Let’s build your next connector together.
Like everything we build under FIWAREBox, IoT Connectors follow the same rule:
INVEST 20%, GAIN 80%.
Sometimes the simplest improvement - “show me what’s inside” - delivers the biggest value.
DISAGREE, COMMENT, OR WISH TO KNOW MORE?
to be continued...