Mad idea - link call type MQTT mechanism

General
1

Just while working on something and repeating something from another instance a (probably) daft thought struck me

As well as the link call return thingy, why not do the same across instances (using MQTT??)

e.g You want the RGB value of a colour
So you send it out of your flow (MQTT??)

In another NR instance, you receive the message - convert it - send it back to originating flow

Is this mad?
Already been done?
Dead simple?
Go away?

I'm thinking of this as local cloud computation :slight_smile:
Write something once on one machine but make it accessible to all your other flows

2

It would be a useful but niche shortcut for sure. I don't think many people would be using multiple instances in this way?

And of course, is is "just" a shortcut since it doesn't take a lot more to do this with existing nodes - and not just using MQTT but also Websockets, HTTP, TCP, UDP and even Unix sockets.

3

The idea popped into my head while using MQTT to transfer global context variables from one instance to another

4

Well, it is a fairly standard API approach. MQTT not really fully suited because of its lightweight nature. Full fat Message Queue services have response capabilities built in. I would say that a direct TCP connection would possibly be better.

5

If you got rid of the globals and use Retained MQTT topics instead then they would automatically be available anywhere.

6

I'm needing them to be global as I want to access their values in the middle of flows

7

There is always the Join node.

8

How would that work?

9

You can feed the mqtt node and whatever else you need to use it with into a Join node, so both are available.
Can you give an example of where you can't easily see how to use MQTT?

10

image

11

It is solvable, of course, but what is the real world use of that, where the mqtt value is required in more that one device?

12

MQTT v5 has a concept of returnTopic for this exact requirement.

@cymplecy if I get time tomorrow, I'll post a demo for you.

1 Like
13

Well the one I'm working on now wants to access the last 6 cheerlight colours
image

These are available as a global variable on another instance, so instead re-generating it in this flow, I decided to send it to my local broker on a topic called nr/globals/lastSixColours and then my 1st flow in this instance just converts all messages to that topic to globals

image

14

To eliminate the global variable, using that MQTT topic instead, I would feed the MQTT value and the payload to be checked into a Join node and change the Switch to test the property msg.payload.["nr/globals/lastSixColours"] Contains msg.payload.colour_topic where colour_topic is the topic of the message containing the current colour.

Do you also need to pass colours back to the original system to be added to the list?

15

Well ,all things can be done in different ways :slight_smile:
I.m going to stick to my current method for now.

No - the other instance has the code/flows to maintain last 6 list.

My whole concept here is a write once - use everywhere approach

One downside is one instance relying on another instance but this isn't a nuclear reactor controller :slight_smile:

16

Certainly, there is rarely a 'best' way in these situations, there are always trade-offs and to a large extent it is down to personal preferences.

Isn't that almost a definition of MQTT? :slight_smile:

1 Like
17

I wrote a thing a long time ago (before Node-RED ) to do request-response using MQTT.
As someone pointed out, you publish your data points retained, so they can be retrieved immediately they are requested.
You connect to a broker, subscribe to the topic, receive the retained message, disconnect.
Rather like an HTTP request node, but for MQTT.
I wonder if you could do this with the fancy new "live" MQTT node that came into a recent NR build?

18

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