This article explains the usage and configuration of the Mobius Cloud Format Node and the Store and Forward Node. It also provides an example of how to use the nodes together with other nodes they will be commonly used within real-world applications.

To summarise, the Mobius Cloud Format node and the Store and Forward node work together to prepare data to be uploaded to one of the supported IoT cloud services.

Mobius Cloud Format Node

Usage

The Mobius Cloud Format node is used to change the format of a message object within MobiusFlow. Messages received from devices are in a standard format. This format is different from any of the standard Mobius cloud formats. The Mobius Cloud Format node is used to convert standard messages received from devices into Mobius cloud formats prior to upload.

Configuration

The Mobius Cloud Format node simply has one input and one output. Messages are received through the input and processed into the new format before being outputted. Below shows an example message object before and after the Mobius Cloud Format node. The message prior to conversion is shown on the left, the message after conversion is shown on the right.

The example above shows the differences between the formats. It is noted that the changed and families objects have been completely removed from the message. The 'pid' and 'ins' parameters have been removed in favour of 'deviceId' containing the URI of the device.

The resources object has also been reformatted to list resources by resource Name. Prior to processing with this node, some message objects contain resources listed by RID. The comparison between these two listing types is shown below. The pre-formatted state (by RID) is shown on the left. The post-formatted state (by Name) is shown on the right. It can be noted that the resource order does not change.

The properties window of the Mobius Cloud Format node is shown below.

The node has two configurable parameters, Publish and Verbosity. These are both explained in the following sections.

Publish

The published property controls which resources will be included in the post-formatted messaged. The different options are shown below.

All three options are self-explanatory however are briefly explained in the following paragraph.

The 'All Resources' option will include all the resources of the incoming message in the formatted output message. The 'Changed Resources' option will only include those resources which have changed since the device last sent a message. The final option is the 'All on First Message then Changed Only' option. When selected, this will cause the node to include all resources in the formatted message only on the first time it receives a message from a device. If any further messages are received by the device, the node will only include resources which have changed in the formatted message.

Verbosity

The verbosity parameter controls the amount of information the post formatted message will contain within each resource. The options are shown below.

The three options 'Minimal', 'Concise' and 'Verbose' control the amount of detail included in each resource, with 'Minimal' containing the least detail and 'Verbose' containing the most. Comparison of the three different levels of details are shown below in the exemplary formatted resource objects.

Minimal:

Concise:

Verbose:

It is seen above that the 'Minimal' option will only include the resource's present value in the formatted message. The 'Concise' option additionally includes the rid and data type parameters. The 'Verbose' option includes all parameters found in the input message.

The verbosity property should be configured to match the amount of resource detail which is required for upload to the cloud.

Example

In this example, an En-Ocean micro-service has been set up and a Temperature/Humidity sensor has been added. As always, a node-RED connector service has been added to connect Mobius Node-RED nodes to Mobius. Below shows the configuration tab of this setup.

A flow with 6 nodes is set up to demonstrate the function of the Mobius Cloud Format node. The flow is shown below.

Within the flow, 2 inject nodes, labelled 15 and 23, are coupled with a set resource node to simulate a changing temperature reading from the Temperature/Humidity sensor. The set resource node is configured to change the value of the temperature resource (resource 40). To find more information about the set resource node, see Mobius Core node-RED Nodes. The 15 and 23 inject nodes inject messages and the set resource node will change the temperature resource to 15 and 23 degrees respectively. The properties windows for these three nodes are shown below.

Inject Nodes:

       

Set resource Node:

The remaining 3 nodes include a Mobius inject node, the Mobius Cloud Format node itself and a debug node. The Mobius inject node has been configured to subscribe to any updates to the Temperature/Humidity sensor. For more information about the Mobius inject node, see Mobius Core node-RED Nodes. Once the state of this sensor changes, a message will be sent from the Mobius inject node to the Mobius Cloud Format node.  The configuration of properties for the Mobius inject node is shown below.

The Mobius Cloud Format node receives the messages and formats them based on the configured properties. In this example, the 'All on First Message then Changed only' option of the publish property is used as well as a verbosity of minimal. The configuration of properties is shown below.

The debug node is used to collect and display the output from the  Mobius Cloud Format Node. As most changes are related to the resources of the message, the debug node has been set to display only the resources object within the message payload (msg.payload.resources). The configuration of properties for the debug node is shown below.

The flow is deployed and the 23 inject button is pressed. The result below shows how the Mobius Cloud Format node formats the message. The result is shown on the left and this is compared to the pre-formatted message shown on the right.

      

The result above reflects the selection of 'Minimal' verbosity because it shows only the present values associated to the resources. It is also seen the resources are now listed by Name instead of by RID

The 15 inject button is now pressed. The Mobius Cloud Format node formats the new message. Again, the result is shown below.

The result reflects the selection of the 'All on First Message then Changed only' publish option. As this is no longer the first message from this device, the Mobius Cloud Format node has only included the changed resources within the formatted message. These resources are temperature and objectLastUpdated.

Store and Forward Node

Usage

The Store and Forward node is used to store message objects and send them out immediately or at a different time. The node is primarily used before uploading into cloud services. The ability to store messages is necessary for two reasons. Firstly, there will not always be a definite connection to cloud services so it is important that a buffer exists to store these messages while connection to the cloud is waiting to be re-established. Secondly, the rate in which messages are sent to the cloud must be controlled to ensure the maximum data transmission rate is not exceeded. If many messages arrive into the Store and Forward node in a short space of time, it can store these messages and send them at regular and controlled intervals.

Configuration

The Store and Forward node has one input and one output. It simply outputs anything it receives at the input. The configuration of this node controls when these received messages will be outputted. The node has two modes of operation. These are explained in the following section.

Modes

The two modes of operation used by the Store and Forward node is the store mode and the forward mode.

Store Mode

The store mode causes the node to store any incoming messages within the node. This mode would be used when connection to cloud services had been lost and messages could no longer be forwarded. When cloud connection resumed, the node would be put into the forward mode.

Forward Mode

The forward mode causes the node to store any incoming messages and then forward the messages to the output. The rate in which these messages are forwarded from storage is controlled from the node's configuration of properties, discussed in full in the Queue Control section.

Mode Selection

The selection of the mode is controlled by the storeFwdControl parameter of the incoming message (msg.storeFwdControl). If this parameter equals 'forward' the node switches to the forward mode of operation. Likewise, if this parameter equals 'store' the node switches to the store mode of operation. The parameter can also equal 'clear' which clears the storage of the Store and Forward node but does not change its mode of operation.

In practice, the control of this parameter will commonly automatically be handled by a Mobius cloud node because this will switch the mode of the Store and Forward node depending on if it has a connection to cloud services.

Queue Control

The section discusses the control of when stored messages will be forwarded to the output. This is only relevant when the node is in the forward mode of operation. Below shows the properties window of the Store and Forward node.

The 'Send new messages immediately when forwarding' controls if incoming messages will be forwarded immediately or not. Please note, this property is only relevant if the node is in forwarding mode. If checked (and the node is in forward mode), the node will send incoming messages to the output as soon as it receives them, even if there are other messages waiting in the store to be sent. If unchecked, any new incoming messages will be sent to the bottom of the queue ready for forwarding.

The node will use the 'Send Every' property to determine the rate stored messages will be sent to the output. In the example above the send rate has been set to 5 minutes.

The 'Queue Max' property controls the maximum number of messages the node can store. In the example above a value of 250 has been used. When the queue is full, the node will begin discarding messages from either the oldest end of the queue or the newest end of the queue. This is controlled by the adjacent drop-down box and has been set to Oldest in this example.

Example

This example shows the function of the Store and Forward node. It outlines both forward and store modes of operation.

A flow of 7 nodes is set up. This consists of the 3 inject nodes, 2 change nodes, the Store and Forward node itself and a debug node. This is shown bellow.

The two inject nodes labelled timestamp are used to inject messages into the change nodes. The change nodes are used to set the storeFwdControl parameter of the message object (msg.storeFwdControl). This is to control the mode of the Store and Forward node. The change node labelled forwardMode sets the storeFwdControl parameter to 'forward'. The change node labelled storeMode sets the storeFwdControl parameter to 'store'. The configuration of properties for the two change nodes are shown below.

    

This setup allows for the mode of the Store and Forward node to be changed when either of the timestamp inject nodes are clicked.

The inject node labelled Test Message is used to inject messages directly into the Store and Forward node to generate a queue and demonstrate the operation of the Store and Forward node. The Store and Forward node is configured to forward messages every 10 seconds. The max queue length has been arbitrarily set to 250. The configuration of properties is shown below.

The debug node is connected to the output of the Store and Forward mode. It is configured to display the payload of any message received.

The flow is deployed and the storeMode is triggered by clicking the lower timestamp inject button. The Test Message inject button is the clicked 5 times to add 5 messages to the queue. The flow shows the following.

The information outlined in the red box is showing the Store and Forward node is in store mode and has a queue of 6. The queue of 6 is because 5 test messages were sent as well as the initial message to set the mode to store.

The upper timestamp inject button is then clicked to set the node's mode to forward. After a minute passes all messages have been relayed to the debug node at 10 second intervals. The test messages are shown in the result below.

The red boxes outline the 10 second intervals the Store and Forward node forwarded the messages at.

Combined Usage Example

This example illustrates how to use the Mobius Cloud Format node and the Store and Forward node together. These node are most commonly used to prepare data to be sent the cloud services so this example will demonstrate these nodes being used in that context.

An En-Ocean microservice has been set up and a Temperature/Humidity sensor has been added to it. A node-RED connector service has also been set up to allow Mobius Node-RED nodes to connect to Mobius. The configuration tab for the setup is shown below.

Within the flows tab, a flow consisting of 7 nodes is setup. This includes 2 inject and a set resources node, used together to simulate the behaviour of the Temperature/Humidity sensor. The flow also includes a Mobius Inject node, the Mobius Cloud Format & Store and Forward Nodes themselves and a Mobius IBM IoT node. The flow is shown below.

The two inject nodes send messages to the set resource node. The set resource node will set the temperature of the temperature sensor (URI - 000001/020/0034/0001/40) to either 15 or 23 degrees depending on if either the 15 or 23 inject button is pressed respectively. The configurations of properties for these three nodes are shown below.

Inject Nodes:

      

Set Resource Node:

The Mobius Flow Inject node has been configured to subscribe to any changes of the sate of the Temperature/Humidity sensor. When a change is detected, the node will send a message to the Mobius Cloud Format node. The configuration of properties for the Mobius Flow Inject node is shown below.

The Mobius Cloud Format node formats incoming messages from the Mobius Inject node into cloud format. For this example, the node has been configured to include all resource every time and use minimal verbosity. This configuration of properties for this node is shown below.

After the data has been formatted to cloud format, the flow leads the data to the Store and Forward node. The Store and Forward node has been set up to send messages every 10 seconds. The max queue length has been set arbitrarily to a value of 50. The configuration of properties is shown below. 

Messages forwarded by the Store and Forward node are fed into the Mobius IBM IoT node where they are uploaded to the IBM cloud. The output of the Mobius IBM IoT node is fed back into the input of the Store and Forward node because this automatically controls the mode based on if connection the cloud has been established or not. The below flow shows the disconnected state. It should be noted the Store and Forward node is operating in store mode because the Mobius IBM IoT node has lost connection to the IBM cloud.

The flow is deployed and the 23 inject button is pressed. This updates the Temperature/Humidity sensor temperature reading to 23 degrees Celsius. This change is detected by the Mobius Flow Inject node which relays the message to be formatted by the Mobius Cloud Format node. If the connection to the cloud is currently active, the Store and Forward node will be in the forwarding state and will format them message to the Mobius IBM IoT node for upload. For more information on how the Mobius IBM IoT node is used see IBM Cloud Node-RED Connection Node.

The screenshot below shows the state of the flow just after the inject button has been pressed. The red box outlines that there is one message in the queue ready to be forwarded.

After 10 seconds, the message is forwarded and uploaded to the IBM cloud by the Mobius IBM IoT node. The state of the flow just after this happens is shown below.

The red boxes acknowledge that the message has been forwarded and the queue is now empty and that the data has been sent. Checking the IBM cloud for the data shows the following.

This shows the flow has been successful and the data has arrived in the format expected.