# TypedInput for mqtt-in and out nodes

**URL:** <https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751>\
**Category:** Feature Requests\
**Created:** [11 November 2020 15:13 UTC](https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751 "2020-11-11T15:13:51Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![w4tsn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/w4tsn/32/11054_2.png) [@w4tsn](https://discourse.nodered.org/u/w4tsn)\
**Post date:** [11 November 2020 15:13 UTC](https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751/1 "2020-11-11T15:13:51Z")

</div>

Is it a huge problem to provide the built-in mqtt in and out nodes with the TypedInput field? This would allow the mqtt-nodes to be programmable through the usage of ENV variables or globals (it works if only the ENV variable is required, but it does not work if the ENV variable has to be embedded in other properties).

I know there is a custom mqtt node which claims to be programmable and compatible to the built-in nodes but it's configuration node does not feature certificate based authentication.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [11 November 2020 15:19 UTC](https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751/2 "2020-11-11T15:19:51Z")

</div>

I don't see why not - although it hasn't been done before because there are a number of workarounds.

For example, you can set the field to `${FOO}` and it will use the `FOO` environment variable. As you say, you can't compose with that - `"myTopic/${FOO}"` - like you could if it were an env TypedInput, but you could do that composition outside of Node-RED wherever you set that env var.

The other workaround is to wrap the MQTT In node in a Subflow. You can then configure the MQTT In node to use `${FOO}` as its topic, and you can define `FOO` as a Subflow property which _can_ be set using an env TypedInput that supports composing a value.

When you say "or globals" - what are you referring to exactly? They couldn't be global context properties as that would imply their value could be changed dynamically - and the node doesn't support that.

---

<div class="post-metadata">

**Author:** ![w4tsn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/w4tsn/32/11054_2.png) [@w4tsn](https://discourse.nodered.org/u/w4tsn)\
**Post date:** [11 November 2020 15:38 UTC](https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751/3 "2020-11-11T15:38:49Z")

</div>

The work-around with the subflow is pretty neat. I think this catches some of my use-cases.

I have topics that are composed at runtime. Or after some programmatic initialization so to speak. Those components of the topics are not present at the system level where I set the env, although I could work-around that by writing to /etc/default/whatever with nodered and restart the service. I'd rather avoid that because it's kinda ugly 😅 That's why I'd like to compose the topic with values from globals or in fact any variable and initialize / start the mqtt connection with that.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [11 November 2020 15:53 UTC](https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751/4 "2020-11-11T15:53:34Z")

</div>

Just to reiterate, for the standard mqtt input node the topic is setup once when the flow is deployed, you cannot delay that until later, or change it later.

---

<div class="post-metadata">

**Author:** ![w4tsn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/w4tsn/32/11054_2.png) [@w4tsn](https://discourse.nodered.org/u/w4tsn)\
**Post date:** [12 November 2020 10:37 UTC](https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751/5 "2020-11-12T10:37:23Z")

</div>

Is that something that could be changed? That the mqtt-node can create a connection to the broker not only on deploy but at runtime? This is crucial to get this node programmable and I think a programmable mqtt-in / out node is quite important for any automated setup.

Maybe toss that directly into the re-design of the node vor MQTTv5 discussed in [Node-RED Mqtt 5 support](https://discourse.nodered.org/t/node-red-mqtt-5-support/17847) ?

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [12 November 2020 11:07 UTC](https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751/6 "2020-11-12T11:07:54Z")

</div>

@w4tsn this has been discussed many times.

There is a design for a new dynamic mqtt node that provides much more control over the connection.

> <https://github.com/node-red/designs/blob/master/designs/dynamic-mqtt-node.md>

That design has existed for 18 months and as yet, no-one has stepped up to help implement it. So its in the default state of waiting to be prioritised into everything else I do.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [11 January 2021 11:07 UTC](https://discourse.nodered.org/t/typedinput-for-mqtt-in-and-out-nodes/35751/7 "2021-01-11T11:07:56Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
