Data Transfer between Flows and MobiusFlow Engine

All Node-RED nodes that facilitate the data transfer between the MobiusFlow Engine and the Flows are contained in the node-red-contrib-mobius-flow-base package. Ensure you add this package to your palette to continue. Also ensure you have setup a connection between the MobiusFlow engine and the Flows by following this guide.

All specific information on how to use each node can also be found within that nodes help pane within Node-RED. As well as this guide, we recommend using the help panes as a close reference when first learning how these nodes are used.

Moving data into Flows

Pulling data into a given flow can be triggered in two ways. Firstly, a message within the flows can cause a 'Get', where data is pulled from the MobiusFlow Engine on demand. Alternatively, flows can be setup to respond to a change of value (COV) of a given MobiusFlow resource or object within the MobiusFlow Engine.

Basic Get

The simplest 'Get' nodes come in the form of getResource and getObject nodes, which get the current value of a specified MobiusFlow resource or object respectively. An example flow using the getResource node is shown below.

Both the getResource and getObject nodes require a MobiusFlow URI to be specified to control which data they fetch. This is set within the node configuration.

In the above example, the URI has been set to the resource 000001/027/0201/0001/40. Upon clicking done, the node label reflects this specification.

When the getResource or getObject nodes receive an input message, the 'Get' will be performed and the results will be sent out of the node's outputs. In the above case, clicking the inject button will trigger the flow causing the 'Get' to occur, and the output of this will be detected and displayed by the debug node.

The getObject node works in an identical way however an object URI is specified instead of a resource URI.

Note that the output from a getObject node is more complex due to the data from a whole MobiusFlow object (including all resources) being pulled rather than just a specified resource.

Basic COV

Basic COV nodes include the resourceCov and objectCov nodes. These directly reflect how the getResource and getObject nodes work respectively however respond to a change of value within the MobiusFlow Engine, rather than a trigger message.

The nodes are configured in the same way, by specifying either a resource URI or object URI.

In the above example, the resourceCov node has responded the resource of URI 000001/027/0201/0001/40 changing to value of 1. This is reflected in the debug window.

The equivalent flow can also be constructed for the objectCov node. This flow will a respond to a change of any of the resources contained within the specified object.

Notice, in the case of the objectCov node, in the debug window only changed resource are shown (in this case the objectLastUpated time and the value). It can be changed in the nodes configuration so all resources are contained in the output message if this is required.

Additional Outputs

You may have noticed that in the case of the some nodes, an extra output is present. This output provides a response with an increased level of information if this is required in your flow.

Notice in the above debug window, the resultant response contains both the name of the resource as well as its new value, instead of just the value itself.

Increasing the level of detail of the output response can be further expanded for almost all MobiusFlow nodes by enabling the 'Use detailed outputs' option in the node configuration.

Notice now in the flow below that the node now has four outputs. Each output has an ever increasing level of detail and this is shown in the four responses in the debug window.

Further Get and COV nodes

There is an array of other node types which allow data fetching from the MobiusFlow Engine in a variety of specific ways. These will not be explained in full but will be summarised here.

Moving data from Flows to MobiusFlow Engine

Often useful data will be in your flows from an external sources or maybe simply the result of a calculation based on several other pieces of data. Either way, it is often useful to put this data back into a MobiusFlow resource so it can be used in the same way as any other data within MobiusFlow.

A 'Set' can be performed as a single resource or a group of multiple resource at once using the setResource and setMultiResource nodes respectively.

Set Resource

The setResource node allows the user to specify a target resource URI, and if valid, will set that resource to whatever the payload of the input message is.

In the above case, the inject node has been set up to inject a message with a payload of 10, causing the setResource node to set the MobiusFlow resource of URI 000001/027/0201/0001/40 to a value of 10.

You may notice the setResource node also contains outputs of its own. These allow the message to continue to trigger further actions if required.

Set Multi-Resource

The setMultiResource requires specification of a target object URI. It expects the input payload to contain an array of JSON objects each containing a resource / priority / value (RPV) triplet. More information can be found in the nodes help pane. An example payload to set resource 40 to a value of 1 and a resource 41 to a value of True may look like the following.

[
    { "r": 40, p: 15, v: 1},
    { "r": 41, p: 15, v: true }
]

Input Topic

It is very important to note that most of the node's functionality depend on input topic. If any of the nodes detect that the input topic is the form of a MobiusFlow URI, this input topic will override the URI specified within the nodes own configuration. This can often cause problem if you're stringing multiple MobiusFlow nodes together which relate to different URIs. These issues can be circumvented by using a change node to delete or change message topics where necessary.

The behaviour can also be very useful. This is because you can leave a given MobiusFlow node's URI field unspecific an rely solely on input topic to control its function. This means that the function of a single node can be dynamically change based on the state of other parts of your flows, avoiding the need for long lists of of the same type of node and complex switching logic.