Just confirming, MQTT can't do device to device

Configuration
1

:slight_smile: :stuck_out_tongue: :slight_smile: STUPID QUESTION WARNING :slight_smile: :upside_down_face: :slight_smile:

I realise that MQTT is a publish/subscribe system and so essentially for any work to be done between devices, the initiating device must publish a message which is received by a broker and sent out to any subscribers.

Subscribers (such as home assistant) can process those messages and publish itā€™s own message which is then received by those devices subscribed to the returning channel.

My thinking was that a device publishes something, MQTT sends it to HA (because itā€™s subscribed), HA doesnā€™t itā€™s magic and publishes back to the devices own subscribe channel. (basically I just repeated the last paragraph again slightly differently in order to emphasise how I understand it).

But can you orchestrate it such that one device can subscribe to another devices published material?

Iā€™m trying to ratify this in my mind and Iā€™m thinking it just doesnā€™t work like that, but I canā€™t satisfy myself either way. I certainly feel like it canā€™t be done.

P = Publish / S = Subscribe

Device 1 (sw) >> P >>      broker
                           broker  >> S >>  subscriber (HA)
                                          HA does magic
                           broker  << P << subscriber (HA)
Device 2 (light) << S <<   broker

I suppose my question is:

do devices ONLY subscribe and publish to a broker?
or
is it possible for one device to publish to another device that is subscribed to the first device?

ie device two subscribe to device one and device one publish to device two?

Iā€™m not asking if MQTT can do MESH at all, I realise thatā€™s a totaly different concept, Iā€™m more questioning a setup where the broker is optional (in the case of a light switch and relay may be concerned)

LIke I say, I donā€™t think itā€™s possible, Iā€™d just like to confirm

and pretty much as soon as I drew this, I kind of got the feeling it really is a stupid question, but I suppose this is what Iā€™m asking (which would be akin to throwing your letter out on the street and hoping the receiver picks it up. Well, not really, because device 1 and 2 know each otherā€™s IP address, but what would be the mechanism between the two? Oh, I knowā€¦ MQTT! LOL

Device 1 (sw) >> P >> 
                       >> S >> Device 2 (light)

I hope I made someoneā€™s day (that there really are stupid people out thereā€¦ ME!) :slight_smile:

2

Itā€™s not optional and that answers all your questions:

do devices ONLY subscribe and publish to a broker?

Yes.

is it possible for one device to publish to another device that is subscribed to the first device?

No.

device two subscribe to device one and device one publish to device two?

No.

Examples:
A temperature sensor is basically a publisher. It publishes its temperature readings to a topic via a broker. Any client interested in this data can subscribe to the sensorā€™s topic via the broker.

A light switch can be both publisher and subscriber. It subscribes to a topic (via the broker) that serves to control the switch. It publishes its status to a topic (via the broker) for use by any interested clients.

3

just-confirming-mqtt-cant-do-device-to-device

Well not directly as such but it can via an MQTT brokerā€¦

An MQTT device can interact with another MQTT device directly (via an MQTT broker) but to do that there must be an agreement on the topics used and the payloads. For example a control switch as one device could control a light as another.

There is however no agreed schema for this and so in most practical usage situations this requires a middleman ā€˜mappingā€™ intervention of some sort either at topic or payload levelā€¦ or both.

4

If you look at the Tasmota rules cookbook, you will find a lot of device-to-device examples, but as said, always a broker in between.

5

In the world of MQTT, there are clients and a broker. Home Assistant is a client and so is a Tasmotized switch and various sensors. All clients are on the same footing; they are free to subscribe/publish to topics.

So if you want the switch to receive data from the sensor, it must subscribe to the topic that the sensor publishes to. However, to achieve that, both must be connected to a broker. Typically it must be the same broker but, in more complex systems, brokers can be bridged.

6

Well, I donā€™t feel it was such a stupid question now. It kind of felt like that direct communications could happen, and with a broker, it is possible.

I have been using sonoff devices with tasmota for years. I have extensively been reading the document pages on his GitHub. I had no idea there was a cookbook!

Thanks

7

Itā€™s not really ā€œdirect communicationsā€ because thereā€™s a broker serving as middleman. All MQTT clients require a broker in order to communicate. Adding the adjective ā€œdirectā€ is meaningless in this context because any MQTT client (device) can communicate with another MQTT client (device) provided thereā€™s a broker to handle their topics and payloads.

Your question was never a ā€œstupid questionā€ but it was borne of a misunderstanding of how MQTT communications work. I encourage you to review the excellent MQTT tutorial provided by HiveMQ. Itā€™s important to understand MQTTā€™s Publish & Subscribe pattern:

8

you are correct, direct is definitely the wrong choice of word in this scenario/context. It is merely the fact that one device is subscribed to another devices published messages.

At any rate, I have kind of worked out what I was after, Iā€™m just putting the finishing touches on the concept.