The article explains the usage and configuration of the core MobiusFlow specific Node-RED nodes. 

Nodes covered within this article:

• Discover
• Set Resource
• Set Multi-Resource
• Get Resource
• Get Object
• Clear Resource
• Resource COV
• Object COV
• Mobius Flow Inject

This article makes reference to Uniform Resource Identifiers (URI) and the function priority arrays. For more information regarding URI see MobiusFlow Uniform Resource Identifiers and for more information on how priority arrays work, see the Present value and the priority array section of MobiusFlow Architecture. Knowledge of setting up Node-RED flows is also important, see Node-RED Flows.

Discover Node

Usage

The Discover node is used to discover the children of any Mobius object. For example, the Discover node could be used to return information about all device types running within a given service or it could be used to return a list of all resources within any given instance of a device.

Configuration

The discover node does not have any configurable parameters within its properties window. Instead, the node relies on the topic of the incoming message to control the result. The topic of the incoming message should be a partial URI referring to the desired object whose children are to be returned.

For example, suppose information regarding the children of a given service was required, the topic of the incoming message should be a string in the form "HID/SID". A Hub ID (HID) of 000001 and a Service ID (SID) of 020 would require the topic to be set to "000001/020" in this situation. Information on how to set the topic of an incoming message is covered in the following example.

Example

In this example, an EnOcean microservice has been set up and three different EnOcean devices have been added to this service. As with all applications of node-RED, a node-RED connector service has also been set up. The information shown in the diagnostics tab regarding this configuration is shown below.

Within the Flows tab, a string of 3 nodes have been set up to demonstrate the usage of the Discover node. In the order the message will pass through, these nodes are the inject, discover and debug nodes.

The inject node, labelled Inject message, is used to inject a message into the flow and to set the topic of this message. The properties configuration for this node shown below.

The payload property has been left to its default value of timestamp because the payload of the message will not affect the Discover node. The topic property has been set to 000001/020. This means the topic of the injected message will be 000001/020 and this will force the Discover node to output information about all children of service 020 on hub 000001.

The Discover node has no configurable properties excluding its connection to the node-RED connector service, set by default to localhost:1890. The properties window for the Discover node is shown below.

Finally, the debug node, labelled output, is used to view the message after it has passed through the Discover node. The Discover node outputs the information regarding the children to msg.payload.response so a result, the debug node has been set up to show this object. The properties window for the debug node is shown below.

When the Flow has been deployed and the inject button on the inject node is clicked, the Discover node processes the message and sends the output to the debug node. The results are shown below.

The object bounded by the red box marks the returned list of device types running within the EnOcean micro-service. Entry 0 in the returned list is a reference to service itself while the remaining entries mark device types. Below shows the diagnostics window matching the result returned by the Discover node.

This shows the node has operated as expected. After processing the Discover node leaves the topic of the message unchanged. If an error has occurred during processing, the msg.error property will be set to true, otherwise, it will remain false. More information regarding the Discover node can be found with its node-RED help text.

 

Set Resource & Set Multi Resource Nodes

Set Resource

Usage

The Set Resource node is used to set a value of a given resource of any instance of a device. This can be used in several situations, for example, to set a lighting component to any given luminosity. It can also be used to simulate the behaviour of devices. Simulating the behaviour of devices can be useful when testing flows because it allows the user to see how the system would respond in hypothetical situations, without the need for a physical device or any real-world conditions.

Configuration

There are two properties to configure within the Set Resource node. These is the URI of the resource that is going to be set, and the priority in which the new value is set within the priority array. Below shows an example configuration of the Set Resource node.

Like all Mobius Node-RED nodes, the node requires a connection to a Node-RED connector micro-service. In the example above, this has been left as the default value of localhost:1890. The URI has been set to the specific resource that will be changed, in this case, 000001/020/0033/0001/40. The priority has been set to the lowest priority of 15.

The Set Resource node will take the value of the payload of any incoming message and set the selected resource to that value. If a message arrives with a null payload value, the selected priority within the resource is cleared.

The node has two outputs. The first output will output a message containing the value of the newly set resource in its payload. The second output will output a message containing the value and name of the newly set resources to payload.pv and payload.name respectively. The usage of neither output is compulsory for the Set Resource node to function correctly.

Read the info tab while the Set Resource node is selected to learn more about the extra configurability of this node regarding input and output messages.

Example

This example will show how to use the Set Resource node to set a resource value within an EnOcean single Contact Input device. The device is virtual so this example will highlight the uses of the set resource node by showing how it can be used to simulate the behaviour of devices.

An EnOcean micro-service has been set up and a Single Contact input device has been added. The diagnostics tab is shown below. A node-RED connector service has also been set up.

The Single Contact input device has a single resource representing the open or closed state of the switch. This means the value of this resource can either be true or false (Boolean) representing the closed and open states respectively. This resource is labelled as the Contact resource.

When in the objects list within the diagnostics tab, the resources of any device can be viewed by clicking the + label next to the object name, shown in the orange box in the window below.

The red box in the window above shows the resource identifier (RID) of the Contact resource.

Within the flows tab, a string of 4 nodes has been set up. This consists of 2 inject nodes, a set resource node and a debug node. The debug node is connected to output 2 of the set resource node. This is shown below.

The two inject nodes are set to inject a message with the payload set to either true or false. This is to force the Set Resource node to set the desired resource to either true or false. The properties window for the true inject node is shown below.

The Set Resource node is set to change the Contact resource outlined earlier in this example. The URI is set accordingly. The priority is arbitrarily set to 15 as no higher priority values have been set. The properties window of the Set Resource node is shown below.

Finally, the debug node, labelled as output 2 in this case, is set up to display the payload of any message it receives. The properties window of the debug node is shown below.

The debug node is connected to output 2 of the Set Resource node. This means it will receive a message with a payload containing the newly set resources new value and the resource name. This will then be displayed by the debug node.

When the flow has been deployed and the true inject button is clicked, a message is sent to the Set Resource node to change the Contact resource to true. The false inject button is then clicked in order to change the Contact resource value back to false. The results are shown below.

The results show that the value of the contact resource has been set to true and then sent back to false. The flow performed as expected.

set multi resource

Usage

The Set Multi Resource node works in a similar way to the Set Resource node so is used in similar situations. The key difference between the Set Multi Resource node and the Set Resource node, is that the Set Multi Resource node can set more than one resource of any given object using a single message.

The Set Multi Resource node can be used to set resources of a device real or virtual, e.g. the light level and occupancy state of an illumination and occupancy sensor. Like the Set Resource node, this can be useful to simulate the behaviour of devices to aid the testing of flows.

Configuration

The Set Multi Resource node is configured by setting the URI of the set of resources to be changed. As the Set Multi Resource node sets more than one resource value at a time, the URI does not include the RID of a specific resource and instead includes up to the instance number of the device. An example configuration of the Set Multi Resource node is shown below.

Like all Mobius node-RED nodes, the node requires a connection to the node-RED connector micro-service. The property has been left as the default value of localhost:1890 in the example above. A given instance of a device has been selected by setting the URI to 000001/020/0030/0001.

The Set Multi Resource node takes an input message with a payload in the form of an array of JSON objects. Each entry in the array represents each resource that will be newly set. Each JSON object is in the following form.

{r: 'RR', p: PP, v: V}

where RR is the RID of the resource to be set, PP is the priority the newly set value will be set at within the priority array and V is the new value to be set. An array setting two different resources would be in the following form.

[
 {
 r : 'RR1', 
 p : PP, 
 v : V1
 },
 {
 r : 'RR2', 
 p : PP, 
 v : V2
 }
]

After setting the new resources the Set Multi Resource node will send an output message. Contained in the payload of this output message is the full object of the instance of the device with the newly set resources.

Read the info tab while the Set Multi Resource node is selected to learn more about the extra configurability of this node regarding input and output messages.

Example

In this example, the Set Multi Resource node is used to set two resources within a virtual EnOcean Occupancy and LUX sensor. An EnOcean micro-service has been set up and the device has been added to the service. Like all example in this section, a node-RED connector service has also been set up. The objects window of the diagnostics tab is shown below.

Within the flows tab, 3 nodes are used to create the flow. These consists of an inject node, a function node and the set multi resource node itself. The flow is shown below.

The inject node is simply to inject a message into the flow. The payload will be updated by the subsequent function node, therefore, it's not important what the payload is when the message is injected. As a result, the inject node has been left to the default payload of timestamp. The properties window for this node is shown below.

The function node is used to set the payload of the message before it reaches the set multi resource node. The payload is set to an array of JSON objects with each entry representing one of the resources to be set. In this example, the array has been set up to set the occupancy state and the lux level (RIDs 40 and 41 respectively) to values of true and 250lx respectively. Both priorities have been set to the default value of 15. The code within this function node is shown below.

msg.payload=[
 {
 r : '40', 
 p : 15, 
 v : true
 },
 {
 r : '41', 
 p : 15, 
 v : 250
 }
];
return msg;

The set multi resource block is configured by setting URI property to reference the instance of the device originally added at the beginning of this example. The RID is not included in the URI for reasons explained prior to this example. The properties window of the Set Multi Resource node is shown below.

The flow is deployed and the inject timestamp button is clicked. This injects a message which has its payload formatted by the function node. This formatted message proceeds to the Set Multi Resource node which set the desired resources. The resources of the device are viewed in the objects window of diagnostics tab. The results are shown below.

The results show that with this single message, the Occupied resource (resource 40) has been set to true and the Lux Level resource (resource 41) has been set to 250lx. This shows the flow has been successful.

 

Get Resource & Get Object Nodes

Get Resource

Usage

The Get Resource node is used to get the value of a resource of any instance of any given device. This is mainly used to read the data on the sensors, allowing the flow to respond to this data after it has been collected by the get resource node.

Configuration

The Get Resource node is configured by setting the URI to the desired resource within the properties window. This is shown below.

Like all Mobius Node-RED nodes, the node requires a connection to the node-RED connector micro-service. The property has been left as the default value of localhost:1890 in the example above.

The Get Resource node does not change its operation depending on the payload of the incoming message. The node has two outputs. The first sends a message containing just the newly received value in its payload. The second sends a message where the payload is an object containing both the received resource value and the resource name. They are set in payload.pv and payload.name respectively.

Read the info tab while the Get Resource node is selected to learn more about the extra configurability of this node regarding input and output messages.

Example

In this example, an En-Ocean micro-service has been set up and a EnOcean Occupancy and Lux sensor has been added to the service. A node-RED connector service has also been set up to connect the Get Resource node. The objects window of the diagnostics tab is shown below.

Within the flows tab, a flow with 3 nodes has been set up. These consists of an inject node, the Get Resource node itself and a debug node connected to output 2 of Get Resource node. The flow is shown below.

The inject node, labelled timestamp, is set to inject a message into the flow. The Get Resource node is independent of the payload of the incoming message so the inject node has been left to inject its default payload value, the timestamp. The properties window of the inject node is shown below.

The Get Resource node is set to get resource 41 of Occupancy and Lux sensor. Resource 41 represents the measured lux level of the sensor. The URI for this resource is 000001/020/0030/0001/41. The properties window for the Get Resource node is show below.

The debug node, labelled Output 2, is connected to the second output of the Get Resource node. This means it will receive a message from the Get Resource node containing an object in the message's payload. This object will contain both the received value and the name of the resource received. The debug node is set to display the payload object. The properties window for the debug node is shown below.

The flow is deployed and the inject button on the inject node is clicked. This sends a message to the Get Resource node which gets the value of the specified resource. It then relays this message to its output. The debug node connected to output 2 of the Get Resource node then displays the result. The result is shown below.

The result shows the Get Resource node has read resource 41 of the Occupancy and lux sensor and returned a value of 300lx. It also shows the name of the resource is lux confirming the expected resource has been read.

Get Object

Usage

The Get Object node has similar operation the Get Resource node. The get object node differs from the Get Resource node because the Get Resource node will only get a single resource within an object however the Get Object node will get the whole object. This means all resources of a device can be fetched using a single message.

This is particularly useful when the system must respond to the state of multiple resources simultaneously. Instead a set of individual message at marginally different times, the Get Object node can be used to fetch all the resources at the same time.

Configuration

The Get Object node requires the URI of the desired object to be defined. This URI does not include a specific RID because the Get Object node does not return an individual resource and instead returns an object with all the resources. This means the URI used in the Get Object node defines up to and including the device instance. An example properties configuration is shown below.

Like all Mobius node-RED nodes, the node requires a connection to the node-RED connector micro-service. The property has been left as the default value of localhost:1890 in the example above.

The format drop down box controls the format of the outputted object the node sends. The example above uses the default value of By RID. This will assign the resource objects to their RID values in the resultant object. The alternative is By Name, and this assigns resource objects to their names in the resultant object. Below shows a comparison of these output formats, By RID is shown on the left and By Name is shown on the right. Please note the objects are not in the same order in both lists.

 

The Get Object node is independent of the payload of any incoming message. The node outputs a message with a payload containing an object of all the resources of the device as seen above.

Read the info tab while the Get Object node is selected to learn more about the extra configurability of this node regarding input and output messages.

Example

In this example, an En-Ocean micro-service has been set up and an EnOcean Occupancy and Lux sensor has been added to the service. A node-RED connector service has also been set up to connect the get Object node. The objects window of the diagnostics tab is shown below.

Within the flows tab, flow with 3 nodes has been set up. These consists of an inject node, the get object node itself and a debug node connected the output of get Object node. The flow is shown below.

The inject node, labelled timestamp, is set to inject a message into the flow. The get Object node is independent of the payload of the incoming message so the inject node has been left to inject its default payload value, the timestamp. The properties window of the inject node is shown below.

The Get Object node is set to fetch all the resources of the Occupancy and Lux sensor. The URI has been set to 000001/020/0030/0001 to match the object URI of that sensor. The output format has been left as its default value of By RID. The properties window of this configuration is shown below.

The debug node, labelled Output 1, is set up to display the payload of any incoming message. It is connected to the output of the Get Object node so it will display the full object containing all the resources of the Occupancy and Lux sensor device. The properties window for the debug node is shown below.

The flow is deployed and the inject button on the inject node is pressed. This sends a message to the Get Object node which fetches all the resources of the specified device. It then outputs the resultant message to the debug node. The result is shown below.

The result shows the payload containing all the resources within the object, assigned by their RID values. This shows the flow has worked as expected.

 

Clear Resource Node

Usage

The Clear Resource node is used specifically to clear and a defined priority within a resource in a given instance of any device.

This could be useful if a higher priority needs to be cleared to allow for a device to return to normal operation. The node is also useful to reset resource values for flow testing purposes.

Configuration

The Clear Resource node is configured by setting the URI to the desired resource within the properties window. It also requires the priority position to be defined. In the example below, the priority is set to its default value of 15 (the lowest priority).

Like all Mobius node-RED nodes, the node requires a connection to the node-RED connector micro-service. The property has been left as the default value of localhost:1890 in the example above.

The Clear Resource node is independent of the payload of any incoming message. The node has two outputs. The first output sends a message with a payload containing the current value. If the node has worked successfully, this should be cleared (0 in the case of number). The second output sends a message with a payload object containing both the newly cleared value of the resource and the name of the resource. These are set to payload.pv and payload.name respectively.

Read the info tab while the Clear Resource node is selected to learn more about the extra configurability of this node regarding input and output messages.

Example

In this example, an En-Ocean micro-service has been set up and an EnOcean Occupancy and Lux sensor has been added to the service. The Lux level resource has been preset to 250lx so this value can be cleared and the Clear Resource node operation can be demonstrated. A node-RED connector service has also been set up to connect the Clear Resource node. The objects window of the diagnostics tab is shown below, note the Lux level resource has a value of 250.

Within the flows tab, a flow with 3 nodes has been set up. These consists of an inject node, the Clear Resource node itself and a debug node connected to output 2 of Clear Resource node. The flow is shown below.

The inject node, labelled timestamp, is set to inject a message into the flow. The Clear Resource node is independent of the payload of the incoming message so the inject node has been left to inject its default payload value, the timestamp. The properties window of the inject node is shown below.

The Clear Resource is set up to clear the Lux level resource value within the Occupancy and Lux sensor object. The URI is set accordingly. The current value of the Lux level is stored in priority 15 so the Clear Resource node has been set up to clear this priority. The properties configuration for this node is shown below.

The debug node, labelled Output 2, is connected to the second output of the Clear Resource node. This means it will receive a message with a payload object containing both the newly cleared resource value and the name of the resource. The debug node has been set up to display the payload of the message as seen below.

The flow is deployed and the inject button of the inject node is pressed. This sends a message to the Clear Resource node which clears the selected priority of the resource defined in URI. It then outputs an object containing the newly cleared resource value and the resource name in the payload object. This is then displayed by the debug node. The result is shown below.

The result shows the flow worked as expected. The resource value was cleared to 0 and the returned named matched the resource being cleared, the Lux level resource.

 

Resource COV & Object COV Nodes

resource cov

Usage

The Resource COV (resource change of value) node is used to detected and output a message every time a change of value of a given resource is detected. It can be used to listen for changes and only respond when a change of occurs, rather than using other node types to continually check for changes. The node allows flows to become immediately responsive to situations which occur.

Configuration

The Resource COV node is configured by setting the URI to the desired resource within the properties window. This is shown below.

Like all Mobius node-RED nodes, the node requires a connection to the node-RED connector micro-service. The property has been left as the default value of localhost:1890 in the example above.

The node has no inputs. The node has two outputs both of which respond when a change of the value of the selected resource is detected. Output 1 sends a message containing the resources new value within the payload. Output 2 send a message containing the resources new value and the name of that resource within a payload object. They are set to payload.pv and payload.name respectively.

Read the info tab while the Resource COV node is selected to learn more about the extra configurability of this node regarding input and output messages.

Example

Please note, this example uses the Set Resource node to simulate changes in sensor readings in order to demonstrate the usage of Resource COV node.

An En-Ocean micro-service has been set up and a Single Contact input has been added to the service. The sate of the Single Contact input has been preset to false so this value can be updated and the Resource COV node operation can be demonstrated. A node-RED connector service has also been set up to connect the Resource COV. The objects window of the diagnostics tab is shown below, note the Contact resource has a false value.

Within the flows tab, a flow with 5 nodes has been set up. These consists of two inject nodes, a Set Resource node (operation covered earlier in this article), the Resource COV node itself, and a debug node.

The two inject nodes are set up to send messages to the Set Resource node. The payload of these messages will either contain true or false depending on which inject button has been clicked. The properties window of the inject node labelled true is shown below.

The Set Resource node receives the input from the inject nodes and sets the desired resource to match the value of the incoming payload. The node is set to change the Contact resource with URI 000001/020/0033/0001/40. The priority is left at the default value of 15. The properties window for the Set Resource node is shown below.

The Resource COV node is configured to listen to any changes to the Contact resource with URI 000001/020/0033/0001/40. The properties window for this node is shown below.

The debug node, labelled Output 2, is connected to the second output of the Resource COV node. This means it will receive messages from the Resource COV node. The payload of these messages will be objects containing the newly changed resource value and the resource name. The debug node has been set to display the payload of the incoming message. This is shown below.

The flow is deployed and the inject button of the true inject node is pressed. This causes the Set Resource node to set the currently false Contact state resource to true. The Resource COV node detects this change and relays the information to its outputs. The debug node displays newly changed value and the name of the resource. The result is shown below.

This shows the Resource COV has detected the change of value to true and shows that it was contact resource which changed.

The true inject button is clicked again. No repose is detected from the Resource COV node because no change of value has occurred. The false inject button is clicked with the following result.

The results show the flow is operating as expected.

Object COV

Usage

The Object COV (object change of value) node is similar in operation to the Resource COV node. It differs from the Resource COV node because the Resource COV node responds when a change of value of a specific resource is detected, the Object COV instead responds when the value of any resource within an instance of a device changes.

The Object COV node could be used when the general detection of a change of a devices state is required. 

Configuration

The Object COV node requires the URI of the desired object to be defined. The Object COV node does not listen for changes in individual resources and instead responds when any resource changes. This means that defining the RID in the URI is not required. An example properties configuration is shown below.

Like all Mobius Node-RED nodes, the node requires a connection to the node-RED connector micro-service. The property has been left as the default value of localhost:1890 in the example above.

The Object COV node features two drop-down configurable properties as seen above. These are Include and Format. The Include drop down controls which resources will be outputted in the message object. The options are All Resources or just Changed Resources. The Format drop-down allows for the control of the format of the outputted message object. The options are By Name and By RID and these control if the returned resources will be stored in objects named by the resource name or objects name by the resource RID. Both formats are shown below, the one of the left being By RID and the one on the right being By Name. Please note the resources are in not in the same order.

 

This object will be outputted in the message object through the Object COV node's single output.

Read the info tab while the Object COV node is selected to learn more about the extra configurability of this node regarding input and output messages.

Example

Please note, this example uses the Set Resource node to simulate changes in sensor readings in order to demonstrate the usage of Object COV node.

An En-Ocean micro-service has been set up and an EnOcean Occupancy and Lux sensor has been added to the service. The Lux level of the sensor has been preset to 250lx  and the Occupancy state has been set to false. This is so these values can be changed and the Object COV node operation can be demonstrated. A node-RED connector service has also been set up to connect the Object COV node. The objects window of the diagnostics tab is shown below, note the Lux level resource has a value of 250 and the occupancy state is false.

Within the flows tab, a flow with 4 nodes has been set up. These consists of an inject node, a set resource node (operation covered earlier in this article), the Object COV node itself and a debug node.

The inject node, labelled true, is set to inject a message into the flow with a payload of true. The properties window for the inject node is shown below.

The Set Resource node will take the message received by the inject node and set the value of resource 40 (Occupancy state) to match the payload of the incoming message (true in this case). This is done using the URI of resource 40, 000001/020/0030/0001/40. The priority is left at the default value of 15. The properties window of the Set Resource node is shown below.

The Object COV is set up to listen for any changes to the device using it URI 000001/020/0030/0001. It is also set up to show all resources in the message output, formatted by RID. The properties configuration for this node is shown below.

Finally, the debug node, labelled Output, is connected to the output of the Object COV node. It is set up to display the payload of any incoming message. The properties window for the debug node is shown below.

The flow is deployed and the true inject button is pressed. This sends a message to the Set Resource node to change Occupancy state to true. This change is detected by the Object COV node which sends a resultant message to the debug node. The result is shown below.

The result has resource 40 expanded to illustrate the change of value to true. The results display all resources formatted by RID as selected in the object COV configuration. This shows the flow has operated as expected.

The inject node and Set Resource node are reworked for the following state.

The inject node has been changed to inject a decimal value of 300 into the set resource node. The Set Resource node has been set to change resource 41 (the Lux level) instead of 40. This means when the inject button is pressed the Lux level will change to 300. The properties windows of both of these nodes are shown below with the inject node on the left and the Set Resource node on the right.

        

The flow is re-deployed and the inject button is pressed. The Set Resource node changes the light level to 300 and this change is detected by the Object COV node. This relays the result to the debug node. The result is as follows.

The results show an updated lux level of 300 which is expected.

These two cases outline how the Object COV node responds independently of which resource is changed.

Mobius Flow Inject Node

Usage

The Mobius Flow Inject node is used to respond to messages sent by devices. The node can be controlled to respond to specific devices or a set of devices. When responding to a set of device, the include/exclude subscription system allows for filtering of exactly which devices the node will respond to.

The node is used in conjunction with other nodes to complete actions based on a message from a device. This node marks the initial injection of the message to start this process.

Configuration

The Mobius Flow Inject node is configured by setting a series of filters. These filters can either be set to include or exclude a defined URI. An example configuration is shown below.

Like all Mobius Node-RED nodes, the node requires a connection to the node-RED connector micro-service. The property has been left as the default value of localhost:1890 in the example above.

The example above uses two filters. The first filter is set to include changes to all devices within the service 000001/020. The # is a standard MQTT wild card and causes the node to include everything within this service. The second filter is set to exclude device 000001/020/0034/0001. This means despite this device being in the included service, because this exclusion filter is set the node will not respond to any changes to this device.

The device has a single output which sends the full device message from any device the node subscribes to. 

Example

Please note, this example uses the Set Resource node to simulate changes in sensor readings in order to demonstrate the usage of Mobius Flow Inject node.

An EnOcean micro-service has been set up and an EnOcean Single Contact Input sensor and Temperature/Humidity sensor have been added. The temperature sensor reads an initial temperature of 15 degrees and the initial state of the Single Contact Input is closed (true). A node-RED connector service has also been set up to connect the mobius node-RED nodes to Mobius. The configuration window for the setup is shown below.

A flow of 7 nodes is setup. The flow consists of 3 inject nodes, 2 Set Resource node (see earlier in article for more details on this node), the Mobius Flow Inject Node itself and a debug node. The flow is shown bellow.

The three inject nodes are used to send messages to the two Set Resource nodes. The inject node, labelled 15, will inject a message into the upper set resource node causing it to set the temperature resource of the Temperature/Humidity sensor (URI - 000001/020/0034/0001/40) to 15 degrees. The configurations of properties for the inject node labelled 15 and the upper Set Resource node are shown below.

Inject node:

Set Resource node:

The remaining two inject nodes, labelled true and false, send messages to the lower Set Resource node. This will change the state of the Single Contact Input device (URI - 000001/020/0033/0001/40) to either true or false corresponding to which inject button is clicked. The configurations of properties for the two inject nodes and lower Set Resource node are shown below.

Inject nodes:

     

Set Resource node:

The Mobius Flow Inject node is subscribed to include all messages on the EnOcean microservice. This is performed using the URI of the microservice (URI - 000001/020) followed by # wild card. This is shown in the configuration of properties window below.

The output of the Mobius Flow Inject node is connected to the debug node. The debug node has been configured to show the payload of the message. This is shown below.

Within the flow tab, the flow is deployed and the inject button labelled 15 is pressed. This changes the temperature value of the temperature sensor which is detected by the Mobius Flow Inject node. The message is relayed to the debug node by the Mobius Flow Inject node. Following this, the inject button labelled false is pressed. This changes the state of the Single Input Contact to false which is detected by the Mobius Flow Inject node and is relayed to the debug node. The results of these two actions are shown below.

The results above show how the Mobius Flow Inject node has injected messages in response to both of these devices. This is because both devices are included within the EnOcean service.

The Mobius Flow Inject node is re-configured by adding an additional filter to exclude the Single Input Contact sensor (URI - 000001/020/0033/0001). Now all devices in the EnOcean service will be included excluding the Single Input Contact sensor. The new configuration of properties for the Mobius Flow Inject node is shown below.

The flow is re-deployed and the inject button labelled true is pressed. The state of the Single Input Contact is changed to true by the lower Set Resource node. The Mobius Flow Inject node does not respond because the new configuration excludes the Single Input Contact device.