Two-way MQTT communication with Thinger.io MQTT devices (without using Products)

Hello Thinger team,

I am building a professional solar farm SCADA system using ESP32-S3 devices and Thinger.io MQTT integration, and I need guidance on enabling two-way communication (dashboard → device commands) without using the Product feature.

System Architecture

I have around 50 ESP32-S3 devices deployed in a solar monitoring system.

Each device connects as a generic MQTT device to Thinger broker:

  • Broker: ***.aws.thinger.io

  • MQTT Device type: MQTT (generic)

  • Each device has unique ID:

    solar_spvm_01_carnac
    solar_spvm_02_carnac
    ...
    solar_spvm_50_carnac
    

All devices publish telemetry via MQTT topics and data buckets are working perfectly.

Example telemetry topics:

spvm_01_sensor
spvm_01_sweep

These are correctly stored in buckets and visualized in dashboards.


Requirement: Two-way communication

Now I want to send control commands from dashboard → device via MQTT.

Each ESP32 already subscribes to:

Per-module command topic:

solar/spvm/01/cmd
solar/spvm/02/cmd
...

Broadcast topic:

solar/spvm/all/cmd

When payload "Start" is received, device starts IV sweep.

So device side is ready.


What I tried

1. Device property method

Created device property:

cmd (string)

Expected:
Dashboard/property change → MQTT publish → device receive

Subscribed ESP to:

v2/users/{user}/devices/{device}/properties/cmd

But property updates are not published to MQTT for MQTT devices.

So ESP receives nothing.


2. Products feature

I understand this can be solved using:

  • Product
  • API resource
  • Device topic routing

But for this project I want to avoid Products layer and keep system simple with:

MQTT devices + buckets + dashboard

Question

Is there any official way to achieve:

Dashboard button → publish MQTT message → specific MQTT device

WITHOUT using Products feature?

For example:

From dashboard button send:

Topic: solar/spvm/02/cmd
Payload: Start

So device receives command directly.


Ideal workflow needed

Dashboard control widget
   ↓
ThingER MQTT publish
   ↓
Device receives command

All devices are already connected via MQTT and publishing successfully.

Only missing piece is:
Dashboard → MQTT publish


Example ESP32 subscribe (working)

mqtt.subscribe("solar/spvm/02/cmd");
mqtt.subscribe("solar/spvm/all/cmd");

If Thinger dashboard can publish to these topics,
two-way SCADA control will be complete.


Summary

Looking for recommended method for:
Two-way MQTT communication with MQTT devices
without using Products.

What is the correct approach?

Thank you.

Thinger’s MQTT is not safe, since it does not support encryption over the internet.
You may want to take a look at my GitHub Tasmota-Thinger bridge, that concentrates MQTT messages from many ESP devices inside a WLAN into one single Thinger communication device.

It must not be Tasmota. Any MQTT will work if you adapt the code.
Of course the two-way communication is ensured.

Hi,

The property approach is a way to do it, it can be detected the property update as server event in mode red and unchain a flow to publish the required message at the desired topic.

Hope this helps

Hi @rin67630, not sure this statement is correct. Of course you can connect MQTT devices over TLS on thinger, using the standard port 8883.

OK, let me correct it:
Thinger community’s MQTT is not safe. It does not accept MQTT devices over TLS.

Why do you say the community version does not support MQTT over TLS?

image

did it change recently? A year ago, I could not get an encrypted connection between Tasmota and Thinger.

It always supported TLS. Maybe it is a problem with Tasmota?

2 Likes

A device connected since 2024… Impressive O.O

I’m curious, is it a uC?

The OP mentionned ESP32 devices. Nothing impressive having them connected durably over several years.

If you get no solution, you always can use a single local ESP32 working as a relay, accepting Thinger.io commands classically and translating them into MQTT commands on-site.

I agree that is not impressive that a device may last several years working online, however for me is impressive that there has not been any changes (at the network and the online server) that may represent a reconnection for the end device.