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.
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.
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.
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.
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 ?
There is a design for a new dynamic mqtt node that provides much more control over the connection.
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.
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.