Introduction

The purpose of the MobiusFlow demo is to allow prospecting users to experience the MobiusFlow software prior to purchasing a full MobiusFlow license.

This article aims to cover the following:

• Install of the MobiusFlow demo software on Windows or Mac
• Configuration of the software to use simulated devices
• Visualisation of the data

Installation

MobiusFlow uses Docker containerisation software to run. As such, MobiusFlow can run on a wide variety of operating systems. These include:

• Mac OS X (Intel and Apple Architectures)
• Linux (CentOS, Debian, Fedora, Oracle Linux, RHEL, SUSE, and Ubuntu)
• Windows 10
• Windows Server

This article does not cover the full install procedure on windows or linux however the commands used in the Mac install can also be used in Linux terminals.

Mac OS X Install

Installing Docker

The docker install download can be found at the following link:

https://docs.docker.com/desktop/mac/install/

The screenshot below shows the download buttons on the page. Ensure the correct version is downloaded to match the chip architecture in use. 

Once downloaded, the installer should be run and the Docker software should be installed.

Installing MobiusFlow Demo

The MoboiusFlow demo is most easily installed and run using the Mac terminal. To open a terminal window, activate spotlight search by pressing CMD + SPACE, then search for terminal. The terminal option should appear as shown in the screenshots below. Run this to open a new terminal window.

Once the terminal window is open, the following command can be run to download the MobiusFlow demo container.

docker pull mobiusflow/mobiusflow-cloud-demo

The screenshots below shows this command having been entered into the terminal.

The screenshot below shows the result of running the above command.

Before the software can be run, a configuration file must be created. This file must be name 'docker-compose.yml'. The file provides the docker runtime with the relevant information to run the MobiusFlow software correctly. This file can be downloaded from the attachments section in this article or the file can be created by completing the following steps.

Note: Wherever the file is created / downloaded, this is the location the software will be ultimately run from.

To create a new file, run the following command in the terminal.

touch docker-compose.yml

The following screenshot shows the above command written in the terminal.

The new file must be edited in order to populate it with the relevant contents. The following command can be run to edit the file.

nano docker-compose.yml

This command is written into the terminal is shown in the screenshot below.

Once the command has been run, the editing window will be presented as shown below.

Copy the contents of the following box and paste it into the editing window within the terminal.

version: '3.8'
volumes:
    mobius-data:

services:
    mobius:
        image: mobiusflow/mobiusflow-cloud-demo:latest
        container_name: mobiusflow-public
        privileged: false
        restart: always
        environment:
            - MOBIUS_HUB_RESET_PSKS=true
            - MOBIUS_ENABLE_CONFIG_UI=true
            - MOBIUS_HUB_ID=000001
        ports:
            - 8080:8080
            - 1883:1883
            - 30815:30815
            - 30817:30817
        volumes:
            - mobius-data:/data

The following screenshot shows the above contents in the edit window.

To save the new changes to the file, first press CTRL + X. The editor will ask for confirmation which can be given by pressing Y followed by ENTER.

Running MobiusFlow Demo

If the docker-compose.yml file was created using a terminal, the same terminal can used to run the following command. This will cause the MobiusFlow demo to run.

Alternatively, if the file was downloaded from this article, the following command must be run in the same location as file.

docker compose up

To navigate the terminal window the to the file location, the following command can be run.

cd <REPLACE THIS WITH THE FILE PATH>

Finally, when the MobiusFlow demo software is running, the software can be accessed by using the following link within a browser.

http://localhost:8080/

Configuring MobiusFlow

Overview

Fundamentally, MobiusFlow is an IoT edge gateway software. It allows for connection of IoT devices and infrastructure in a protocol agnostic manner. MobiusFlow can be configured by the user with micro-services based on requirements. Each service plays a role within the general IoT architecture. The user can then add MobiusFlow objects to these services. A MobiusFlow object can represent a real-world IoT device such as a temperature sensor, light fitting or under-desk sensor. Furthermore, an object can also represent a logical construction e.g. an occupancy zone, simple numeric value or simple boolean value. All MobiusFlow objects can provide a useful and unique role when configuring the user's IoT setup. Contained within each object is a set of resources associated to that object. For example, a combined temperature and humidity sensor would have temperature and humidity resources associated with it.

Unique Resource Identifier

Every MobiusFlow resource has an associated Unique Resource Identifier (URI). URIs allow for unambiguous referral to any part of the MobiusFlow configuration. A MobiusFlow URI takes the following format:

HubID/ServiceID/ProfileID/InstanceID/ResourceID

or in short...

HID/SID/PID/INS/RID

URI Segment	Format	Explanation	Example
Hub ID (HID)	6 Character Hexadecimal	The HID refers to which MobiusFlow hub (MobiusFlow software instance) the resource or objects is located on. As many connected instances of MobiusFlow can me run, specifying which Hub a given object or resource is located on is necessary .	000001
Service ID (SID)	3 Character Hexadecimal	The SID refers to which MobiusFlow service the object or resource is located on.	022
Profile ID (PID)	4 Character Hexadecimal	The PID refers to the type of MobiusFlow object the desired object is, or the type of parent object the desired resource is located on	025A
Instance ID (INS)	4 Character Hexadecimal	The INS refers to the object instance number. This is necessary because it is often that multiple devices of the same type will be running in parallel on the same service.	000A
Resource ID (RID)	2 Character Hexadecimal	The RID refers to the MobiusFlow resource ID.	40

The URI structure makes it possible to define up to any level of the MobiusFlow configuration hierarchy. The table below gives some examples of this.

Example URI	Explanation
000001/022	Referral to a service. Specifically service 022 on hub 000001.
000001/022/0258/0002	Referral to an object. Specifically instance 0002 on type 0258 on service 022 on hub 000001.
000001/022/0258/0002/40	Referral to a resource. Specifically resource 40 on instance 0002 on type 0258 on service 022 on hub 000001.

In some situations the MobiusFlow URI structure allows wildcarding (e.g. 000001/# to refer to all services on hub 000001), this is however out of the scope of this walkthrough.

User Interface

Initially when browsed to, and assuming no users have already logged into the MobiusFlow instance, the user will be prompted to create a username and password and then log in.

Following login, the primary MobiusFlow user interface is presented. The interface is divided into four tabs; Configuration, Diagnostics, Flows and Administration. The function of these tabs is explained in the table below.

Tab	Explanation
Configuration	The configuration tab is used to build the MobiusFlow configuration hierarchy. Firstly, the interface allows the user to add MobiusFlow services as well as allowing the each service's associated service settings to be set. Secondly, MobiusFlow objects can be added to any appropriate services. Similarly to MobiusFlow services, the settings of each MobiusFlow object can be set.
Diagnostics	The diagnostics tab allows for observation and control of any configured MobiusFlow services. The interface allows the user to perform the following: Start and Stop MobiusFlow services View the run (or error) status of any running services View the MobiusFlow objects currently configured on any service View the current value of any resource on any MobiusFlow object Obtain any MobiusFlow URI
Flows	The flows tab allows the user to build logic within MobiusFlow. Resources and objects running within MobiusFlow can be fetched or set - injected into the flow or results of the flows saved. Furthermore, value changes within objects can be subscribed to, allowing for event driven logic to be built. Additionally, the flows allow connections to made to external systems such as IoT cloud platforms, data visualisation platforms, databases and other IoT protocols. Finally, the flows allow the importation of a huge range of open-source node types, all of which providing useful and unique functions, and as such, the capabilities of the flows are expansive.
Administration	The administration tab allows administrative and management functions to be performed. These functions include, user management, backup and restore, setting network settings and Hub ID changes.

EnOcean Devices Service

What is EnOcean?

EnOcean is a popular brand of IoT device. They provide all manner of IoT devices from simple temperature sensors to full automatic meter reading or weather monitoring stations. EnOcean devices send simple propriety telegrams over the air. These telegrams can be detected and decoded into useful data.

Why is an EnOcean service required?

MobiusFlow contains the option to add an EnOcean devices service. This service is responsible for decoding incoming EnOcean telegrams. As such, all EnOcean devices in use must have an equivalent MobiusFlow object present on the EnOcean devices service.

Unique Identifier

Each physical EnOcean devices has a unique identifier (UID) associated with it. This is so any connected software can recognise which telegrams originated from which sensors. EnOcean UIDs are always in an 8-digit hexadecimal format e.g. 1298ABFE. As such, when adding EnOcean device MobiusFlow objects to the EnOcean devices service, the UID of each object must be populated. This links the new MobiusFlow object to the real-world EnOcean device.

How does the EnOcean service work?

All incoming EnOcean telegrams will contain a UID denoting which EnOcean device the telegram has come from. The EnOcean devices service will then search if the UID assigned to any of its child objects matches that of the incoming telegram. If a match is found, the service will decode the incoming telegram accordingly and populate the MobiusFlow object with data.

Configuring Service

Initially, add an EnOcean service by dragging one in from the palette on the left as shown in the screenshot below. The service will appear in the workspace.

Next, add some EnOcean devices to the service. This is performed by dragging the EnOcean device onto the EnOcean service. This makes the new EnOcean device a child of the EnOcean service. Add an EnOcean A5-02-05 Temperature Sensor to the EnOcean devices service as shown in the screenshot below. Populate the UID field to be 'A5020501'.

Repeat this process for an A5-07-03 and an A5-09-04. The screenshot below shows these devices having been added to service.

Populate the UID fields of the devices as follows:

Device	A5-02-05	A5-07-03	A5-09-04
UID	A5020501	A5070301	A5090401

Simulated EnOcean Devices

As this is the MobiusFlow demo, it is unlikely that users will have any physical EnOcean devices as well as the iaconnects  EnOcean transceiver hardware. As a result simulated devices will be used to demonstrate the capabilities of the software. It is worth noting, the UIDs assigned in the above table are simply the EnOcean device EEPs (e.g. A5-02-05) without dashes and with 01 appended to the end. In a real-world situation this would not be the case because the UID field would be populated with the real EnOcean device UIDs. As simulated devices are to be used instead, for connivence the UID is set like this. 

Sensor Gateway Service

The sensor gateway service is required to connect MobiusFlow to any external iaconnects hardware. This hardware includes transceivers for several different IoT protocols (including EnOcean) as well as iaconnects room displays. This hardware is connected to a local network or the internet and is directed at a sensor gateway service running on a MoibusFlow instance. As such, the sensor gateway service is required to securely manage the connections to this hardware.

Connector

An iaconnects transceiver is require to detect proprietary telegrams in the air and forward these to MobiusFlow. Wireless transceivers sold by iaconnects are referred to as connectors. An iaconnects EnOcean transceiver would therefore be referred to as an EnOcean connector. Each instance of MobiusFlow can be connected to a very large number of connectors (spanning many different protocols) and as such ,a large physical area can be covered with just a single MobiusFlow software instance.

Configuring Service

First add a Sensor Gateway service by dragging one in from the palette on the left. The new service will appear in the workspace as shown in the screenshot below.

The network port in which the gateway will run can be specified by the user. Due which network ports are exposed on the container in which MobiusFlow is running in, either 1883 or 30815 should be chosen. In the screenshot below, note 1883 has been chosen.

To add a new connection to an iaconnects hardware device, the blue plus button should be pressed. This adds an entry in the Authorised Sensors section as shown in the screenshot above. Notice how the new device has been populated as follows:

Field	Description	Value
Description	The description on the device. This can be anything or can be left blank. The field is simply used for user convenience.	Simulated Connector
Type	The type of iaconnects hardware being connected to. A 'Connector for Wireless Sensors' would refer to a connector.	Connector for Wireless Sensors
SID	The MobiusFlow service ID the new iaconnects device will use once connected to MobiusFlow. Typically connector service IDs are set to C01, C02, C03 etc. Displays are set to D01, D02, D03 etc.	C01
PSK	The pre-shared-key the connecting iaconnects hardware will use to connect. This field ensures security such that no unauthorised devices are able to connect to MobiusFlow. The key can be anything however it is recommended a long and random string of characters is used. In this example 'super-secret' is used for convenience. Such a PSK would not be recommended for use in real-world situations.	super-secret

Flows Connector

As explained earlier, MobiusFlow features the Flows tab which allows for flow-based logic to be built within the software. MobiusFlow uses an industry standard technology called Node-RED to achieve this. An instance of Node-RED always runs natively with every instance of MobiusFlow however it is possible for users to run Node-RED separately or even on a different machine entirely. This leads to the requirement for a flows connector.

The flows connector is used to connect MobiusFlow to an instance of Node-RED, most likely running locally on MobiusFlow, but potentially running elsewhere. This is why the connection between MobiusFlow and the flows is not set up by default. The service which manages the connection to the flows is called the node-red connector, because it is the connection to any given instance of Node-RED.

Add a node-RED connector service by dragging one in from the palette on the left. The service will appear in the workspace as seen in the screenshot below.

The service requires several fields to be configured. The configuration is explained below:

Field	Explanation	Value
Host	The host location of Node-RED. As the desired Node-RED instance will be running in parallel with the MobiusFlow software in most situations, this field will almost always be set to localhost. Alternatively, this field could be populated with an IP address if Node-RED was running elsewhere.	localhost
Port	The network port the desired Node-RED instance is running on. If Node-RED is running within MobiusFlow this will be 1890 by default however can be changed.	1890
PSK	The pre-shared-key the connecting Node-RED instance will use to connect to MobiusFlow securely. This field ensures no unauthorised Node-RED connections are able to connect. The key can be anything however it is recommended a long and random string of characters is used. In this example 'super-secret' is used for convenience. Such a PSK would not be recommended for use in real-world situations.	super-secret

The configuration is shown populated in the service below.

Starting Services

All services can be viewed by navigating to the diagnostics tab. The screenshot below shows the three new service that have been added.

To start the service, click the play buttons on each service. This will cause all the services to attempt to start. Once started, the services will report their status as shown in the screenshot below.

Note how the node-RED connector service is currently reporting an error, with the error message stating 'Waiting for Node-RED to connect...'. This is to be expected as this stage as node-RED has not yet been setup to connect back to MobiusFlow. All services report their status or error status in a similar manner, each providing useful error messages to aid the user in overcoming issues.

Simulated Data

To add an input stream of simulated data to MobiusFlow, a simulated EnOcean connector as well as some simulated EnOcean devices are required. These can be added in the flows tab.

Simulated Connector

A simulated connector connects to MobiusFlow in the same manner as real connector. This connection works in the same way as a real connector, and therefore MobiusFlow detects the simulated connector as being no different to a real connector. The simulated EnOcean connector is therefore used to forward simulated data to MobiusFlow in a manner no different to how it receives real data.

Note: A node-RED connector service is not required for the simulated connector to function. This is because the simulated connector connects to the sensor gateway service just like any normal connector.

First add a simulated connector node by dragging one in from the palette on the left, as seen in the screenshot below.

Double-click on the node to open it's configuration. The configuration should be set according to the table below.

Note: The configuration matches that of the connector previously set up within the sensor gateway service.

Field	Value
SID	C01
PSK	super-secret
Addr / URL	localhost
Port	1883

The screenshot below shows the above configuration inserted into the node's configuration form. The done button is used to confirm the changes

The deploy button should now be pressed. If configured correctly, the simulated connector whill show connected status as seen in the screenshot below.

Confirmation of the connected connector can be found by looking at the service list within the diagnostics tab. In screenshot below, notice how the new connector with service ID C01 has appeared at the bottom of the list.

Simulated Devices

Simulated device nodes are used to produce simulated data. Drag a simulated EnOcean A5-02-05 from the palette as seen in the screenshot below.

On opening the new node's configuration, the user is prompted for a UID. This UID should match the UID setup when the EnOcean A5-02-05 object was added to the MobiusFlow configuration, in this case A5020501. The done button is used to confirm the changes.

The screenshot below shows the UID as populated when the MobiusFlow object was added. It can be seen the UID matches both the screenshot above and below.

Repeat the process of adding a simulated node, this time adding an EnOcean A5-07-03 and A5-09-04 setting the UID fields to be A5070301 and A5090491. The result of adding these nodes is shown in the screenshot below.

Finally, an inject node must be added to control when the simulated devices produce a data point. Drag an inject node in from the palette on the left as seen in the screenshot below.

Open the configuration of the inject node. The node should be set to repeatedly inject on an interval of 5 seconds (or an appropriate interval of the users choice). This is shown in the screenshot below. The done button is used to confirm the changes.

The flow should be wried as shown in the following screenshot. Connections can be added by dragging between the connection points on nodes. The wiring is setup such that a trigger message will leave the inject node on interval, trigger the simulated nodes to produce simulated data and this data will then flow out through the simulated connector to populate the MobiusFlow objects.

Pressing the deploy button will begin the data streams and show the setup as below.

The incoming data can be viewed by navigating to the diagnostics tab and clicking the View Objects button on the EnOcean devices service. This is shown in the screenshot below.

Expanding any of the objects should reveal the incoming data. In the screenshot below, notice how resource 40 is populated with a value of 11.6.

Visualisation

Overview

There for many methods for viewing data, the simplest of which is natively built into MobiusFlow. The flows tab has the ability to create complex dashboards to show a wide range of data types in a variety of formats.

MobiusFlow can be linked to other external platforms for data visualisation and analysis however this is not covered in this walkthrough.

Flows Dashboard

Using dashboard nodes as well as the dashboard menu, a dashboard can be constructed based on user requirements. This section will cover the process of creating a simple dashboard structure and then adding a simple line graph of this structure to view a single data-stream.

Dashboard Structure

The dashboard menu can be found by selection the dashboard option after pressing the drop down menu at the top right of the flows tab. This option is shown in the screenshot below.

The dashboard menu is presented. Add a new dashboard tab as shown in the screenshot below.

The user is presented with some settings as shown in the screenshot below. These can be left as the default value or changed to the user choices. Once this is complete, press the 'Update' button.

Each tab is split in a series of groups. A new group can be added using the button shown in the screenshot below.

The group configuration settings are presented to the user as shown in the screenshot below. The settings can be changed to the user's choices however for the purposes of this demo, the width of the group should be set to at least 10. The settings are confirmed by pressing the 'Update' button.

Subscribe to Device Data

Changes of value of data with MobiusFlow objects can be subscribed to. Drag in a resource change of value (resource cov) node from the palette on the left. This node is used to subscribe to any changes to a specified MobiusFlow resource.

Upon opening the node's configuration, a connection to MobiusFlow is required. This connection is what connects the the previously set up node-RED connector service, and is shared by all MobiusFlow nodes to allow for access to MobiusFlow objects and resources. Add the new connection by pressing the pencil icon as shown in the screenshot below.

The fields should be populated the same as those within the node-RED connector service. These are listed in the table below and shown in the screenshot below. Press the add button to confirm the settings.

Field	Value
Host	localhost
Port	1890
PSK	super-secret

The MobiusFlow URI of the desired resource to be subscribed to should be populated in the URI field.

URIs can be easily found on the diagnostics window. The screenshot below shows the URI of the desired object (the simulated temperature sensor in this case) is 000001/020/0013/0001. The resource ID of the temperature resource is 40, therefore making the full URI of the desired resource 000001/020/0013/0001/40.

The screenshot below shows the above URI in the URI field of the resource cov node. Press done to confirm the changes and the node is now subscribed to changes of that resource.

Add a debug node to the flow as shown in the screenshot below.

Wire the resource cov node to the debug node and press deploy. If setup correctly, the changes to the subscribed resource are now being shown in the flows debug window.

It can be further noted, when viewing the diagnostics tab, the node-RED connector service is now reporting a 'Connected' status showing it is now connector to node-RED.

Sending Data to Dashboard

Instead of sending data a debug node, the data can be sent to a chart node to be plotted on the dashboard. As such, delete the debug node.

Drag the a chart node in from the palette on the left as seen in the screenshot below.

Open the configuration of the chart node and ensure the dashboard group is set to the one previously added. The other settings can be changed to match the user's requirements.

Wire the resource cov node to the chart node and press deploy as seen in the screenshot below.

Finally the dashboard can be viewed by pressing the arrow icon on the dashboard menu. This is highlighted in the screenshot below.

The dashboard windows is presented in a new browser tab. The data is shown on the chart as shown in the screenshot below.