I want to trigger with the telegram bot, a mqtt subscription to get a retained message.
How can I do that?
Will be the topic pre-defined or should be defined by the telegram message? Maybe if you explain a little bit more…
I want to send a command /roomtemp with telegram
the mqtt subscription with the retained message /events/roomtemp needs to be triggered
output goes back to telegram
Feed an MQTT In node configured for the topic into a function node and save the value in a node context variable. Also feed into that node a message when the telegram is received (but with a different topic). In the function node use the fact that the telegram topic has been received to send the saved mqtt value out to send the telegram back.
Yep, as Colin told you this very easy to achieve just take a look on this https://flows.nodered.org/node/node-red-contrib-telegrambot
The only tricky part maybe is to create a telegram bot that you will have to do it first, seems tricky but is not too difficult once you get it https://core.telegram.org/bots good luck
Thx for your replies, I got it working.
But it feels kind of a workaround.
Keeping it intuitive and simple a third mqtt node which could handle triggers would be awesome
Also a mqtt input node which could handle multiple topics (in an array or something) , and I mean not wildcards, would be a great addition too
1 Like
I'd been wanting such a node as well, to let me effectively disconnect and then reconnect in order to to get retained topics to re-trigger without having to redeploy the mqtt in node.
After much fiffiing and faffing and bodging, I've finally manged to get somewhere
If you search on flows.nodered.org you’ll find a few contrib nodes that already provide a dynamic mqtt subscriber node - so please don’t rush to create another.
If anyone was interested in contributing this functionality to the core mqtt nodes we could have that discussion.
#chagrin
I thought that since no-one had said anything that I’d see if I could have a go at making one 
I was just seeing if it could be done easily and then I was going to raise it up for discussion
But it was a very good learning experience for me in trying to bend the core 10.mqtt node into doing it.
I’ll go off and have a look at the contrib nodes and come back
Ah thank you, I'll give it a try
But what's the reason it is not implemented in the core mqtt nodes?
It would be a great addition....or?
Because it wasn't a requirement when the nodes were first written (they are literally the very first nodes ever written for Node-RED). And as I said in my previous reply, we can certainly have the discussion about how it could get added (there's a lot of detail to figure out before throwing the door open to code changes).
1 Like
So, the suggestions at the moment are :
-
Add an input to the MQTT In node (or create a 3rd MQTT node) so that subscriptions to retained topics can be retriggered without having to redeploy the node
-
Allow topic to be set via a msg with ability to handle multiple different topics using an array of topics
I’m keen on having the 1st enhancement and don’t mind if its an alteration to existing MQTT In node (but I understand that this could spoil the look of the current default input nodes as it would be the only one with an input visible). I also don’t mind if a 3rd MQTT node is added to the function section like the TCP request node
Simon
1 Like
In that case, I would prefer if a 3rd node is created, maybe most for cosmetic & readability reasons.
And what about the mqtt out node? Should there also be a new out node with an output??? Use case is debugging but could also be used in the flow logic using confirmations and error messages today only indicated in the status text (disconnected/connecting/connected, successful/failed data transfer and others) if available
The status node will reflect those status messages for you.
Yeah, right, is already available, thanks
I’m very new with node-red…
but cymplecy explains exactly what i needed
What kind of details do you need more?
I vote with my two hands for these features!
I wonder how this would be implemented. Is there a way within the MQTT protocol of asking for retained values to be re-sent? Possibly it would be necessary for the node to disconnect and reconnect for this to happen, which might not be desirable.
Afaik, subscribing to the topic will get the retained message.
So do you mean the node could re-subscribe to all topics configured? Would it have to un-subscribe first? If so then in the gap between the two it might miss a non-retained message.
