",
}
}
```
From there, you would setup a Berry Script. Berry allows you to subscribe to arbitrary MQTT topics, parse JSON payloads, execute local commands, and publish the results back dynamically.
* * *
v3 support could be a future iteration if there is enough interest - but not likely to land in first iteration
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [6 July 2026 07:42 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/10 "2026-07-06T07:42:18Z")
> [@krambriw](#):
>
> What is the use case for such feature?
In a distributed system where data or operations live on separate edge devices, matching asynchronous responses back to the original triggering flow is incredibly clunky in MQTT v3.1.1.
A classic use case is **on-demand commanding**. Imagine a dashboard button or an API call that needs to query a specific device for a value, read a single database row from a remote server, or trigger a camera snapshot _right now_. Instead of subscribing to a continuous stream of data you don't need, you fire a single request and get the immediate answer back in line within the exact same flow. Couple that with multiple users performing operations at the some time and it gets complex very quickly
Here are some articles that do a better job of explaining than me:
- [MQTT Request-Response Pattern β MQTT 5 Essentials Part 9](https://www.hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern/)
- [MQTT 5 Request Response Pattern Explained: RPC Over MQTT](https://scadaprotocols.com/mqtt-5-request-response/)
- [MQTT Request / Response Explained and Example | MQTT 5 Features | EMQ](https://www.emqx.com/en/blog/mqtt5-request-response)
> [@krambriw](#):
>
> Just wondering why polling should be needed
What polling? This is 100% asynchronous and event-driven.
I see why you might think that if you imagine someone poorly implementing a loop to constantly poll a resource, but that isn't the purpose of an MQTT Request node. It standardises the request response pattern. Before v5, every engineering team invented their own workaround (like cramming IDs into JSON payloads). There was no protocol-level enforcement, leading to broken interoperability between different vendor systems.
Let me just finish with this: _once you know you need this - you need it bad_ π
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [6 July 2026 08:04 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/11 "2026-07-06T08:04:36Z")
> [@gregorius](#):
>
> Is the idea to add another core node or to do this with a separate `mqttv5-request-response` node package?
Core node. It shares deep functionality with the existing MQTT core codebase, and I want it to be a first-class citizen.
> [@gregorius](#):
>
> Can't you create such a node package and leave it at that?
Not cleanly. Doing this as an external package would require duplicating a large amount of the core code. It would lead to code divergence, maintenance fragmentation, and inevitably falling behind core updates.
To me, it doesnβt make sense to have native v5 MQTT support in Node-RED core while omitting one of the defining features of the v5 specification. Adding support for this pattern has been on my radar since I first introduced MQTT v5 to Node-RED core a few years ago. Recently, Iβve been integrating external systems where I had to handle this manually - it was cumbersome and clunky, which is exactly why a native solution is being proposed.
> [@gregorius](#):
>
> The fewer core nodes, the less the chance that something breaks in core and the less needs to be maintained in core.
I totally appreciate that concern, and as a rule of thumb, itβs a valid point. However, in this case, an MQTT Request node conceptually belongs in core right alongside `http request` and `tcp request`, alongside its brother and sister `mqtt in` and `mqtt out` nodes.
FWIW there are no new code files being added/required in core (only modification to the network/mqtt\* files). There are no new external dependencies or entirely new code subsystems being introduced. They use no additional runtime resources if you dont use them and minimal when you do. It is deliberately a separate node from the MQTT IN and MQTT OUT (so no breakage to existing nodes) and a clean dedicated design (for purpose) in both naming and feature (atomic).
Providing 1st class support for a foundational protocol pattern like this belongs in Node-RED core (IMHO)
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [6 July 2026 08:11 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/12 "2026-07-06T08:11:56Z")
> [@Steve-Mcl](#):
>
> _once you know you need this - you need it bad_ π
... in over 20 years of using MQTT I have never knowingly needed it π ... if I ever wanted something like that (before Node-RED) I would ensure the topic was a retained one, then just subscribe to the topic - data would be delivered - then unsubscribe - but again, that was incredibly rare.
If I really need to do single command response then things like http are "really useful" and well documented π
But hey I can see it does complete a set of tools so by all means make it so.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [6 July 2026 08:22 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/13 "2026-07-06T08:22:38Z")
> [@dceejay](#):
>
> > [@Steve-Mcl](#):
> >
> > _once you know you need this - you need it bad_ π
>
> ... in over 20 years of using MQTT I have never knowingly needed it π ... if I ever wanted something like that (before Node-RED) I would ensure the topic was a retained one, then just subscribe to the topic - data would be delivered - then unsubscribe - but again, that was incredibly rare.
Don't get me wrong, there are workarounds Dave (and I've used them!) - but having to build that custom logic on three different systems recently is what finally drove me to this.
The MQTT v3 approach of "retaining a topic, subscribing on the fly, and then unsubscribing" works fine for isolated or low-throughput tasks, but it does hit a wall - it gets incredibly tricky incredibly quickly when you layer on unknown/dynamic response topics, multitenant requirements, external system enforcements (to the v5 spec).
> [@dceejay](#):
>
> But hey I can see it does complete a set of tools so by all means make it so.
Muchas Grassy Bottom
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [6 July 2026 08:26 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/14 "2026-07-06T08:26:40Z")
Probably you have considered this already, but while implementing this, bear in mind the operation if the broker and/or the response client are across a network. They may go offline temporarily and so messages can be queued at various points and may eventually get dropped or may be delivered some time later when the network recovers. This can lead, for example, to repeated responses from the same request, or a response to arrive long after the initial request has timed out.
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [6 July 2026 08:27 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/15 "2026-07-06T08:27:57Z")
> [@Steve-Mcl](#):
>
> In a distributed system where data or operations live on separate edge devices, matching asynchronous responses back to the original triggering flow is incredibly clunky in MQTT v3.1.1.
A good example of feature-creep in MQTT. A message bus is, by design, asynchronous. Adding state (i.e. session) by coordinating request and response pairs is going beyond what a message bus should be doing - by design.
If I use a message bus, I don't expect it to be handling stateful request-response patterns. Strangely MQTT does do this. If I want request-response, then something like TCP/IP or HTTP would be more appropriate.
This is just a perspective of the MQTT specification, that it should be implemented if its available is clear. It's just unfortunate that such a feature made it into the specification.
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [6 July 2026 08:33 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/16 "2026-07-06T08:33:38Z")
Another use case is where you need to absolutely guarantee that every message from a client gets delivered to the other client, even if the network connection can fail temporarily. Currently this is complex to achieve, an MQTT response node would make it significantly simpler.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [6 July 2026 08:34 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/17 "2026-07-06T08:34:28Z")
**``**
> [@Steve-Mcl](#):
>
> > [@dceejay](#):
> >
> > Can you do that ? I thought the env syntax only allowed a single variable name - not compositions
>
> It definitely works for a a single composite replacement but you now have me doubting multiples.
@dceejay The brain fog cleared:
The ENV typed input does indeed permit multiple substitutions (I knew I wasnt dreaming π )
**``**
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [6 July 2026 08:36 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/18 "2026-07-06T08:36:21Z")
> [@gregorius](#):
>
> If I want request-response, then something like TCP/IP or HTTP would be more appropriate.
If the connection is over a WAN then that would likely involve opening ports into the response client, which using MQTT avoids.
---
### Author:  [@gregorius](https://discourse.nodered.org/u/gregorius)
#### Post date: [6 July 2026 09:13 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/19 "2026-07-06T09:13:17Z")
> [@Colin](#):
>
> which using MQTT avoids.
Ah ok, so MQTT handles the buffering of responses when networks drop away. Does the MQTT server than also handle the matching of requests/responses and send the client the appropriate pairing when it happens to have arrived?
I.e. so that the request-response pattern becomes transparent for the client.
From [here](https://www.hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern):
> Itβs important to note that this data is not relevant to the MQTT broker but serves to identify the relationship between sender and receiver.
So the client is still responsible for matching the original request with the response using the extra `correlationData` field in MQTTv5. So the client has to maintain the state while the broker remains stateless.
So then the new mqtt node here needs to know how to match request/response pairs using `correlationData` - I assume this would be a "simple" look up in a lookup table somewhere.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [6 July 2026 09:15 UTC](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413/20 "2026-07-06T09:15:56Z")
> [@dceejay](#):
>
> Do you need to worry about possible queue depths at all while waiting for (non)responses ?
> [@dceejay](#):
>
> came up recently (which is why I remembered) over here - [Help with `delay` node set to `rate limit` - #16 by dceejay](https://discourse.nodered.org/t/help-with-delay-node-set-to-rate-limit/101400/16)
Thanks Dave. That lead me straight to it - I updated code late last night but didnt get around to posting back that I added support for `nodeMessageBufferMaxLength` until now:
Much appreciated.
[Next page](https://discourse.nodered.org/t/we-have-http-request-tcp-request-serial-request-any-objections-to-an-mqtt-request/101413.md?page=2)