MobiusFlow® connects, controls and communicates with 1000s of sensors and control devices to provide actionable insights and automated responses. Developed and successfully deployed with many projects over the past 17 years by engineers with first-hand experience in project management and installation such as CBRE, Ingram Micro, TD Synnex and IBM.

Whether you are looking for a full walkthrough or just dipping in to get more information about a single topic, our documentation site is the perfect companion to the training courses on our main site.

3️⃣ MobiusFlow Version 3

We have rebuilt MobiusFlow from the ground up. MobiusFlow V3 has a bunch of new features and enhancements improving both performance and adding improvements to data handling, searching and customisation.

This section is dedicated to guides and technical knowhow related to version 3.

📖 User Guides

The user guides are instructional walkthroughs. Follow these guides from start to finish or jump to a section to learn how to perform specific tasks.

⚙️ Technical Docs

Looking for more detailed technical information? These articles dive deeper into the more technical aspects of MobiusFlow®, from Architecture to API details, ports, protocols, configuring services creating flows, and more.

MobiusFlow® is a middleware software application

MobiusFlow® connects, controls and communicates with 1000s of sensors and control devices to provide actionable insights and automated responses. Developed and successfully deployed with many projects over the past 17 years by engineers with first-hand experience in project management and installation such as CBRE, Ingram Micro, TD Synnex and IBM.

MobiusFlow Toolbox is a browser-based engineering tool enabling users to easily configure and monitor an instance of MobiusFlow

Navigation

Navigating around the Toolbox UI is very simple. The key areas are as follows:

• The current user is shown in the top right of the window. You can click on this button to change your password or log out

• The collapsable menu on the left side of the window is a quick way to access your configured Services, Flows, Historian settings, Object Profiles and instance Settings. Clicking on the menu icon in the the top left corner will either collapse or expand the menu. As you add new to your configuration they will shown in the menu under the Services heading

• With the exception of Flows, clicking on an item in the left menu will show the view for that selection in the main view. Clicking on Flows will open the Flows window in a separate browser tab, or navigate to that tab if it is already open

• Configuration of specific items such as services, objects and profiles will be shown in a pane to the right of the main view. This pane is only visible when a configurable item is selected

MobiusFlow V3 has been built from the ground up. We have listened to your feedback and added a host of new features to make MobiusFlow even more powerful and easier to use.

Tagging, we added it, custom object profiles, there too, and to make you even more productive we have added the ability for you to write your own data pre-processors and codecs. We are excite about these new features and are sure you will be too!

Engine and Toolbox

Both the MobiusFlow Engine (the heart of MobiusFlow) and MobiusFlow Toolbox have been completely rewritten to be more efficient and easier to use.

Object profiles define the shape and properties of MobiusFlow objects. Before version 3 object profiles were built into each release and could not be easily created or modified by users.

Version 3 has redefined how object profiles work. Object profiles can now be freely created by users in a simple editor. In fact each new instance of MobiusFlow has no object profiles defined. Instead we have taken all of the object profiles from version 2 (and a bunch of new ones) and created object profile templates.

Object profiles can be created from scratch, from templates, or from any profile that you have already created and then customised to your application. This gives users full flexibility without adding complexity as new objects can also be added directly from templates and MobiusFlow will automatically create the profile for you.

Exporting and Importing Profiles

Object profiles (along with their preprocessors, codecs and UI layouts) can be exported and imported allowing you to create your own library of profiles to be used on other projects.

Preprocessors, Codecs and UI Layouts

Have you ever needed to modify data before it is written to a resource? Have you wanted to change from °C to °F on the fly as new data arrives? Was totalising energy readings from meters difficult?

Not any more as preprocessor functions will do that for you!

Each object profile can have a preprocessor function written in Typescript or Javascript which allow you to do just that, you can even write it directly in a built in IDE in MobiusFlow Toolbox.

Codecs make adding new decoders for raw sensor data a breeze. Instead of waiting for us to add new decoders for sensors like EnOcean, LoRaWAN, or Ingy, you can create an object profile and define the codec to decode the raw sensor telegram. As with preprocessors, these codecs can be written in Typescript or Javascript using the built in IDE.

Capturing default values such as sensor IDs when configuring objects is simplified by adding your own configuration UI in a simple JSON format.

The data stored in MobiusFlow objects can now be persisted between restarts of a service. No longer will temperate values drop to zero, people counts be lost, and energy readings disappear when services are restarted! Persistence can be configured on a service by service basis and values are included in backups

Powerful tagging features have been added to both objects and resources. Tags can be defined on object profiles so that they are automatically added to each instance of an object, and added to individual object instances.

You can use simple tags or add values to tags. Tags are included as metadata when reading values or receiving change-of-value events via the new API.

Supported Browsers

MobiusFlow Toolbox supports the latest versions of most modern web browsers. We recommend the following:

• Google Chrome

The MobiusFlow software has been developed as an MQTT object bus which normalises all device data into standardised MobiusFlow objects which allow interoperability between all devices either real or virtual in the field or Cloud.

MobiusFlow enables actuators, sensors & controllers to connect, control and communicate with each other and to the Cloud so that IoT solutions using scalable monitoring, visualisation and predictive analytics can provide valuable insights into your business and act upon them automatically.

• A complete control and communications platform

• Microservice based architecture

• Secure, open protocol based on MQTT

• Scalable to 1000s of devices

• Platform and language independent

• Does not depend on a network connection for local control

• Provides full discovery of nodes, objects and resources in all directions

• Pub / Sub change of value notifications

• All sensor and actuator data is normalised from any source such as / / / / LoRaWAN / Analog / Digital etc.

MobiusFlow has been designed from the ground up as a micro service based design with a simple but common set of API commands. All communication between micro services is performed using the MQTT protocol, ensuring that micro services can be written in any programming language and will run on any device capable of TCP/IP network communications. The only requirement for any MobiusFlow system is that it contains at least one Node. This Node consists of a MobiusFlow Hub which initiates and facilitates communication between micro services in a secure way. Micro services can run on the same device as the Hub, or on another device such as a temperature sensor, connected to the Hub via a connection capable of transmitting via TCP/IP (provision has been made for future expansion, by adding translation services, to allow micro services to communicate with the Hub over any transmission medium capable to transmitting binary data).

Each Node is typically a stand-alone island which does not require any connection to any other device in order to perform local control. Nodes can be connected together via secure MobiusFlow Routers allowing the creation of a network of interconnected Nodes. When used in this configuration, Nodes can share data with each other and influence the control algorithms running on any connected Node.

Vanilla MQTT has some limitations in its usefulness as a peer to peer messaging and control protocol. It is based around the Publish / Subscribe pattern which is ideal where multiple devices are sending data to a single end point for logging etc. MQTT can be used where devices or services need to have a two way peer to peer flow of communication but the different services need to be aware of each other at design time. MobiusFlow defines a protocol layer above MQTT which enables discovery of devices and services at runtime and then allows two way peer to peer communication to take place, ensuring that new devices and services can be added at any time without having any design time knowledge of the other devices and services in a system.

Overview

As each application differs you will need to chose which services are required for your application.

To add a service, first click on Services in the main menu and then click on the Show Library button to show the list of available services, find the service you want to add, and click on the Add button for that service.

The service will get added to the configuration with the next available Service ID (SID)

Overview

Overview

To create a copy of a service along with all of its settings and objects you can click on the Clone button on the service card of the service you want to copy. The new service will be given the next available . You can change the SID in the service's settings if required.

System Services are required my MobiusFlow to function correctly. Examples include the Engine API and Historian services.

MobiusFlow Engine API

The MobiusFlow Engine API service is a RESTful API used by MobiusFlow Toolbox, Flows, and user applications to both configure an instance of MobiusFlow and read and write data to MobiusFlow objects.

It is not possible to configure or stop this service from MobiusFlow Toolbox as this would prevent Toolbox from communicating with the MobiusFlow Engine.

Overview

All MobiusFlow must belong to a service. To add, delete, modify, and view a service's objects you can either click on the main body of a service card on the 's page or click on the service in the main menu.

The full MobiusFlow Manager training course can be .

Preprocessors are run every time a new value is written to a resource. They are used to modify the value before it is written e.g. change from °C to °F, or update another resource e.g. update a message counter

Page coming soon. Please contact [email protected] to arrange a support call on this topic.

If you forget your connector's Config Mode Password or want to fully reset all settings to the factory default follow the procedure below

What You Will Need?

1. A SIM card removal tool, large paper clip or pin to push the configuration mode button

Factory Reset

Using a pin hold in the configuration mode button (inside the small hole to the right of the USB connector) on the front panel for 10 seconds

While you are holding the button in the green LED will start to flash rapidly and after 10 seconds the connector will reboot. Once you see the power on LED sequence release the configuration mode button

Configuring MobiusFlow for use with Connectors uses the MobiusFlow Connectors service. A full guide on how to use this service can be found here.

MobiusFlow Services are the starting point for any configuration. They are typically device drivers for a specific protocol or provide protocol interfaces such as an MQTT broker.

The main services page shows an overview and status of each service that has been added to the configuration. You can interact with services in a number of ways, including configuring a service, starting and stopping a service, or adding and configuring objects belonging to a service.

The main services page shows an overview of all services that have been added to an instance. Each service is represented by a card which provides status information and allows you to interact with the service.

As new services are added cards will appear on this this page. The service list is also visible in the main menu below the Services menu item.

Service Library

The service library is a list of all possible services that can be added to MobiusFlow. You can show and hide the library by clicking on the button in the top left of the page.

For more information on adding services please read the article.

Service Cards

Service cards show a lot of information about a service and allow you to interact with a service.

Service ID (SID)

The service ID is a three digit hexadecimal number and is shown in the middle of the coloured service status circle in the top left corner of the card.

Service Name

The service name is shown at the top of the main body of the card. The name can be set in the service settings and defaults to the service type.

Service Status

The service status is shown in two places on the card.

Quick Status Indicator

The coloured circle in the top left corner gives a quick indication of the health of a service. The indicator colours are as follows:

Detailed Status Information

In addition to the quick status indicator, detailed status information is shown in the main body of the card beneath the service name. If a service is in error, the error is shown here.

Last Seen

At the bottom left of the main body of the card is a timestamp showing the last time a service interacted with the MobiusFlow instance.

Service Type

The service type is shown in the top right corner of the main body of the card.

In addition the internal Service Profile ID (SPID) which also indicates the service type is shown in the bottom right of the main body of the card

Service Toolbar

With the exception of system services, each service card has a toolbar in the top right. Hovering over the card will highlight the toolbar. The six buttons from left to right are:

Accessing Service Objects

Accessing the belonging to a service can be done in two ways. You can click on the main body of a service card or click on the service in the main menu.

To update a service's settings, first click on Services in the main menu and then find the correct service card.

On the service card toolbar click on the Settings button to open the service settings dialog.

The service settings dialog is shown above. All services have these default settings, but some services may have additional service specific settings. It is beyond the scope of this article to describe any service specific settings, please see the article for that specific service type for more information.

General Settings

SID

The SID or Service ID is a three digit hexadecimal number. It forms part of a .

When a service is it is given the next available SID, but this can be changed if required. SIDs must be unique within a MobiusFlow instance so you cannot assign a service an existing SID.

Name

The service name can be freely assigned. It has no relevance within a MobiusFlow instance and is just used in MobiusFlow Toolbox to make it easier for you to distinguish between your services.

Enable Service

Services can be Enabled or Disabled. Disabled services do not run at startup and cannot be manually started.

Run at Start

If a service is enabled and it is set to Run at Start the service will be automatically started when the MobiusFlow instance starts. If Run at Start is switched off for a service it will not start automatically but can be started manually by clicking on the service's start button.

Value Persistence

Value persistence ensures that objects keep their values between restarts. Please see the article for more information.

Logging Levels

A service and its underlying connection to the rest of the instance (the spoke) each have their own logging levels. Currently these logs are only visible in the terminal on the computer running the MobiusFlow instance and are not visible in Toolbox. We aim to make this available in a future version for developers.

The default logging levels are set to Info. Please do NOT change these unless instructed by a MobiusFlow engineer during a support incident as excessive logging could cause significant additional CPU load.

Service Specific Settings

Some services have their own service specific settings. The exact settings will depend on the service type. These are shown at the bottom of the service settings dialog. An example for the MQTT Broker service is shown below.

💥 Interactive Demo

Value persistence ensures that objects keep their values between restarts.

In MobiusFlow versions before v3 any restart would cause all resources to be reset to their default values. This would often cause anomalies or loss of data such as all temperature values dropping to zero, meter readings being lost or people counts resetting.

MobiusFlow 3 has solved this problem by adding optional value persistence. This can be configured on a service by service basis in the service settings. To access a service's settings follow the instructions here.

When a service starts it first creates all objects with their default values and then applies any persisted values before running.

Enabling / Disabling Persistence

You can enable or disable persistence on each service. Changing the persistence enabled state will affect all objects belonging to that service.

You can enable or disable persistence by clicking on the Enable Persistence switch in the service's settings.

Disabling persistence will also delete any persisted values. If you need to reset the persisted values you can disable and then re-enable persistence.

Setting the Persistence Interval

In order to lower CPU load values are only persisted at regular intervals and not on every value change. You can set this interval (in minutes) in the service's settings. Try to find a reasonable balance between saving the current values and load on the system. The more objects a service has, the greater the CPU load required to persist the values.

Default Settings

Services have persistence enabled with an interval of 5 minutes by default.

💥 Interactive Demo

MobiusFlow Objects represent real or virtual devices such as sensors, rooms, pieces of equipment, and machinery. All objects are based on an Object Profile which describes the shape of the object i.e. what properties (resources) an objects has, the data type of each property (resource), and metadata describing the object and it properties.

For more information on objects and resources read the article.

Objects must belong to a . To add new objects or configure existing objects on a service open the Service's Objects page by clicking on the service in the main menu or clicking on the main body of a service's card on the Services page.

For most use cases, Deploying MobiusFlow in the MobiusFlow Cloud is simplest and most cost effective hosting option.

Customers can create new MobiusFlow instances themselves using the MobiusFlow manager platform. A full guide on how to use this platform can be found here.

When creating a new MobiusFlow instance using manager ensure the Host instance on MobiusFlow Cloud option is checked:

On creation, there are several options that must be populated:

Hostname

This is the URL the new MobiusFlow cloud instance will be hosted on. In the above example, Manager has automatically suggested average-pug-2488. As such, new Cloud instance will be accessible at the URL average-pug-2488.mobiusflow.io.

Build Type

This selects the version of MobiusFlow to use. If use for the MobiusFlow LoRaWAN LNS is required, ensure the MobiusFlow V2 with LoRaWAN Stack option is selected.

Region

This specifies the region of the world the new Cloud instance is to be hosted on. It is recommended to host the instance as near to where it will be used as possible.\

Once a MobiusFlow Cloud hosted instance as online, an Environment is created, in-turn controlling how the instance can communicate with the outside world. A full article on this environment can be found .

The Connector collects data from sensors and sends data to actuators via standard wireless sensor protocols such as EnOcean and Workplace Occupancy, and sends this data securely to a MobiusFlow using an MQTT based Protocol.

Once the data has been received by a MobiusFlow instance, it is decoded and the associated MobiusFlow object is updated with the latest sensor readings which can then be processed by the gateway.

A full guide on configuring MobiusFlow for use with Connectors can be found here.

Connector Options

There are several hardware options for the MobiusFlow Connector software:

The Config Mode Password is used to login to the configuration pages of the connector. The default password is mobiusflow

You can change the password on this page

Save Settings

Click the Save button

Click the Home button on the settings saved confirmation page to return to the Home page

Setting CA / Server Certificates

When using TLS you will need to set the correct CA / Server certificates. You can have up to three certificates set. If the connector fails to connect using one of the certificates it will cycle through all three, trying each one until it connects

The default certificates are ISRG Root X1 certificates which are used when connecting to MobiusFlow® hosted instances of MobiusFlow®

You can set the certificate by pasting the certificate text into the selected certificate slot

Setting Client Certificate and Keys

If your setup requires the use of Client certificates you can set up to four different certificates and keys. Paset these into the selected certificate and key slots

The node calls are for reading a MobiusFlow hub as well as resetting the pre-shared keys on a given hub

Backup

The discover calls are used to learn about the present state of a given MobiusFlow instance

Used get and set the full configuration the flows.

Within a MobiusFlow system all hubs, services, objects and resources are identified by a unique address known as a Uniform Resource Identifier or URI. These URIs are hierarchical so given the URI for a Mobius resource it is possible to identify which object the resource belongs to, what the object type is, which service the object belongs to and which Mobius node the service is running on.

Mobius URI Definition

An object’s URI (or name) is defined in 4 parts, namely the hub ID (HID)

Mobius system

A typical MobiusFlow system consists of a single or multiple MobiusFlow nodes connected together via a TCP/IP network. Each node is capable of operating independently of the rest of the system, but nodes can interact with each other to form a complex system. All node interaction takes place through one or more brokers via a node’s router.In a multi-node system, the location of the broker is not important. It can reside on the same device as one of the nodes or on an independent device.

Each node is classed as, and exhibits the behavior of, an edge computing device. In this context edge devices are not only field devices but could also be on the edge of a server or cloud server providing the server with connectivity to all of the true edge or field devices.

To create a new profile open the Object Profiles page, make sure that the sidebar is closed, and click on the Create button. This will open the Create Object Profile wizard.

The wizard will have three starting point options. Selecting one of the options will change the steps required to complete the wizard.

All access to MobiusFlow Toolbox and the MobiusFlow Engine API requires a valid username and password. Adding, deleting, and modifying users is done on the User Management tab on the Settings page.

The User Management page shows a list of all users with their roles, whether they are active or not, and an Actions button for additional user management.

All MobiusFlow® instances require a valid licence to run. Licences define the maximum number of MobiusFlow® objects that you can add to an instance. For more information about MobiusFlow® licences refer to the page.

What You Will Need?

Tags are a powerful way to organise your objects and resources making it easier to find and group similar pieces of data.

Tags can be a simple key word or phrase (much like a hashtag in social media apps) or a keyword or phrase with an associated value.

Tags can be added to and individual instances. Any tags added to an object profile will be automatically added to all objects created from that profile.

The process of managing tags on object profiles, objects, and their resources is the same. To view the tag editor select an object profile, object, or resource and the relevant sidebar will open showing the tag editor. Once the sidebar is open follow the steps below.

Open the Object Profiles page and click on the profile you want to modify. The Object Profiles sidebar will open on the left of the window.

At the top of the sidebar is the object profiles settings toolbar. You can use this toolbar to switch between the four sidebar modes and to delete the profile if it is not being used. Use the X to the right of the toolbar to close the sidebar.

Below the toolbar are the Undo and Save buttons. Clicking on the Undo button will revert any changes and clicking on Save will save the changes.

The configuration page is used to create and configure the MobiusFlow configuration for a Mobius node (see ). The page is split into five main sections:

1. The main menu

2. The services palette

MobiusFlow® connectors send and receive data via MQTT. You need to configure the MQTT settings to match the configuration you set in the section of this guide.

MQTT Broker Settings

You can choose any MQTT client ID but this must be unique for your MQTT broker. The default is the connector's serial number

The Administration page covers user management, backup and restore, licence settings, security as well as setting the node's Hub ID. The page is divided into corresponding tabs accordingly.

User administration

Users can be added, modified and deleted from within the User Management Tab on the Administration page.

What You Will Need?

1. A device with a web browser such as a laptop, tablet or smart phone, capable of connecting to a 2.4GHz WiFi access point

Select Network Type

You can choose to use a wired or wireless (2.4GHz WiFi) connection to connect a connector to your MobiusFlow® instance

Select your network type using the Connect Via dropdown. The page layout will change depending on the option selected

After signing up to follow their instructions to create a fleet and add your first device. We have simplified the process so you will only need to perform some of the actions they list. The steps below outline the process but for more information see the balena.io .

What You Will Need?

The service calls are used to read, add, remove and manipulate MobiusFlow services.

balenaCloud devices can run multiple microservices in separate Docker containers. Deploying MobiusFlow® to your device will create three microservices. You can start, stop and view logs for each service on the balenaCloud device summary page.

mobius

This microservice runs the MobiusFlow® application.

The about page shows you information about the connector. You can also update the connector's firmware by clicking on the Update Firmware button

Updating Firmware

Click on the Update Firmware button on the About page

The authorization controller is used to login to the API, in addition user management.

When a login call is completed, the API will return a bearer token which should be used in the auth header of all future calls. This token is set to expire 10 minutes after its generation.

A refresh token is also included in the login response, and this is used in the body of the refresh call to get new tokens with refreshed expiry times. Ensure a refresh call is made prior to any given bearer token's expiry to avoid having to login again.

Object Profiles Page

To open the Object Profiles page click on Object Profiles in the main menu.

The object calls are used to read, add, remove and manipulate MobiusFlow objects and resources.

The Home page has the following buttons

Configure Network

Configure the wired or wireless Ethernet network settings

Services can be started and stopped individually and if enabled, and set to run at start, will start automatically whenever the MobiusFlow instance is started.

Some services have which affect how they operate e.g. the ports used by the MQTT broker service. These settings are typically only loaded on service start so changes to these settings may require a service to be stopped and started before they take effect. If a service is running and any critical settings are changed MobiusFlow Toolbox will notify you that a restart is required.

The MobiusFlow Engine API is used interface with MobiusFlow via http and https. The API allows clients to perform all functions within MobiusFlow, from managing user accounts, to getting and setting data, as well as manipulating the MobiusFlow configuration by adding, removing and editing MobiusFlow objects, services and flows.

Additionally, the API allows clients to subscribe to specific real-time events within happening within a given MobiusFlow instance (see subscription controller). In this use case, the API will upgrade the client to use the Websocket protocol (ws / wss).

Controllers

All API endpoints are described in the following subsections. The subsections are divided into the functional groups (controllers); , , , , , , , and .

Protocols, Endpoints and Ports

If connecting to a local instance of MobiusFlow, the http protocol can be used. If connecting to an instance of MobiusFlow via the internet, https should be used. The API is always exposed on port 8443.

All endpoints lead with:

{{protocol}}://{{hostname}}:8443/api/v1

Where the protocol and hostname parameters are replaced with the true protocol and hostname. For example, in the case of connecting to a local instance of MobiusFlow, the leading path would look like:

http://localhost:8443/api/v1

Further Documentation & Postman Collection

Swagger documentation describing the API in full, can be found . This documentation includes example bodies and responses for every endpoint. Finally, a postman collection containing parameterised examples of all client calls can be downloaded below.

Service diagnostics and control

The service diagnostics and control page shows all of the configured services, their current status and controls to start and stop services.

Run state column

The Run State column (2) shows the current run state of the services in a traffic light. The colours are defined as follows:

• Grey - Not running, never started

• Red - Not running, manually stopped

• Amber - Starting or attempting to start

Actions column

The Actions column (3) has start / stop buttons for each service. Services can be manually started or stopped by clicking on the action buttons.

These action buttons do not modify the value of the Run on Start checkbox on the page.

Service status column

The service status column (4) shows the current status of all running services. In addition to a text message, the statuses are colour coded as follows:

• Amber - starting or status unknown

• Red - service is running but in fault (see text message for details)

• Green - service is running and not in fault

The values shown in the Service Status column are tied to the service status object associated with the service. These status objects are automatically created and updated by the services as object profile ID 0001 with instance 0001. You can read the status of these objects but should not write to them.

View objects column

The View Objects column (5) are hot-links to the Objects Diagnostics page, but filtered to only show objects belonging the the relevant service.

Object and resource diagnostics

The Objects diagnostics page can be shown by clicking on the Objects button on the left of the screen (section 1 in image below) or by clicking on the View Objects hot-link described above. To view all objects belonging to all services use the Objects button (section 1 in image below).

Clicking on the plus sign (3) next to an object expands it to show all of its resources and their current values (2).

Modifying a resource value

It is possible to manually modify a resource's value by writing to, or clearing a value in its priority array (see ). Click on a resource to display its full priority array. Click on a priority to modify its value or clear it.

Resource value modifications are temporary and could be overwritten by a service or Node-RED flow, and do not persist between service restarts or node reboots.

What is balenaCloud?

BalenaCloud is a small device fleet management platform which simplifies the process of managing and maintaining 1000s of edge devices. It allows secure remote access and monitoring of each device and installing and updating product firmware of an entire fleet with a few simple clicks. See for more information.

What Device Types are Supported?

MobiusFlow

We currently have software images for thee different device types for balenaCloud. These are:

MobiusFlow RPI Connector

The MobiusFlow RPI Connector works with the following Raspberry Pi types:

• Raspberry Pi 4

• Raspberry Pi 5

If you are ready to get started, jump into the section to begin creating your first fully managed MobiusFlow® device on balenaCloud.

The MobiusFlow software has been developed as an MQTT object bus which normalises all device data into standardised MobiusFlow objects which allow interoperability between all devices either real or virtual in the field or Cloud.

MobiusFlow enables actuators, sensors & controllers to connect, control and communicate with each other and to the Cloud so that IoT solutions using scalable monitoring, visualisation and predictive analytics can provide valuable insights into your business and act upon them automatically.

• A complete control and communications platform

• Microservice based architecture

• Secure, open protocol based on MQTT

• Scalable to 1000s of devices

• Platform and language independent

• Does not depend on a network connection for local control

• Provides full discovery of nodes, objects and resources in all directions

• Pub / Sub change of value notifications

• All sensor and actuator data is normalised from any source such as / / / / LoRaWAN / Analog / Digital etc.

MobiusFlow has been designed from the ground up as a micro service based design with a simple but common set of API commands. All communication between micro services is performed using the MQTT protocol, ensuring that micro services can be written in any programming language and will run on any device capable of TCP/IP network communications. The only requirement for any MobiusFlow system is that it contains at least one Node. This Node consists of a MobiusFlow Hub which initiates and facilitates communication between micro services in a secure way. Micro services can run on the same device as the Hub, or on another device such as a temperature sensor, connected to the Hub via a connection capable of transmitting via TCP/IP (provision has been made for future expansion, by adding translation services, to allow micro services to communicate with the Hub over any transmission medium capable to transmitting binary data).

Each Node is typically a stand-alone island which does not require any connection to any other device in order to perform local control. Nodes can be connected together via secure MobiusFlow Routers allowing the creation of a network of interconnected Nodes. When used in this configuration, Nodes can share data with each other and influence the control algorithms running on any connected Node.

Vanilla MQTT has some limitations in its usefulness as a peer to peer messaging and control protocol. It is based around the Publish / Subscribe pattern which is ideal where multiple devices are sending data to a single end point for logging etc. MQTT can be used where devices or services need to have a two way peer to peer flow of communication but the different services need to be aware of each other at design time. MobiusFlow defines a protocol layer above MQTT which enables discovery of devices and services at runtime and then allows two way peer to peer communication to take place, ensuring that new devices and services can be added at any time without having any design time knowledge of the other devices and services in a system.

You can use the backup and restore feature to backup the full configuration of a MobiusFlow instance, and to restore the configuration of a MobiusFlow instance to a previously saved backup.

Overview

In summary, all configuration data of a MobiusFlow instance can be stored within a single .zip file. This means the current configuration of any MobiusFlow instance can be backed up by simply downloading this backup file and saving it in a safe location of your choice. Similarly, the configuration of any MobiusFlow instance can restored by uploading one of your previously saved backup files.

All backup and restore functionality is accessed through the 'Backup/Restore' menu located on the 'Administration' Tab.

Backup

On the 'Backup/Restore' menu, you can create a backup by clicking 'Backup'.

Once the backup file has been created, click 'Download Zip' to download it.

Alternatively, the you can click 'Request new backup' to return to the previous menu and generate an updated backup file.

Be sure to save your backup file in a safe location! There is nothing worse than not being able to find a much needed backup file.

Restore

The restore feature is particularly useful if you want to copy a MobiusFlow configuration onto to other MobiusFlow instances, however it also useful if you've managed to break everything.

The 'Backup/Restore' menu is also used for restoring. You can restore by first clicking 'Upload Zip' and then browsing to the .zip backup file you previously saved in a safe place.

Once uploaded, the menu will show the backup information as well as allowing you to click 'Restore'.

Accept the a confirmation dialog to proceed.

You will be notified that the restoration process has started and then MobiusFlow will then reboot, completing the restore process.

Congratulations for completing your restore!

Hardware Requirements

Raspberry Pi

A Raspberry Pi is required. Currently supported Raspberry Pi models include:

• Raspberry Pi 4

• Raspberry Pi 5

An SD card for each Raspberry Pi is required to store the connector image. We recommend a minimum storage of 8GB.

Transceiver Hardware

Most protocol types require specific hardware to translate that protocol to the Raspberry Pi.

EnOcean

The following transceiver types are supported. Only 1 is required per Pi:

Etching SD Image

BalenaCloud

MobiusFlow Raspberry Pi connectors run Balena OS. Athlough not required, if your organisation registers with BalenaCloud, Balena OS grants a direct VPN link to the connector, allowing configuration changes to be made over the internet.

When using more than 5 devices, BalenaCloud becomes a piad service. As such, we offer versions of the Balena images which do not support remote access and therefore do not require a subscription to BalneaCloud.

Without Remote Access

The following, no remote access images can be downloaded:

With Remote Acccess

The following is an overview of the steps involved to use BalenaCloud with MobiusFlow RPI connectors:

1. Create BalenaCloud Account

2. Create BalenaCloud Fleet

3. Attach BalenaCloud Fleet to the corresponding MobiusFlow Connector Balena Application

We have a full guide on how to use the BalenaCloud with MobiusFlow itself . Please note

Etching

We recommend using the to etch the images onto an SD Card. The tool is self-explanatory, but full full documentation of how to use the tool can be found .

BalenaCloud charges hosting fees when more than 5 devices are associated to the account. If remote access to the Connector confiruation is not required, the device can be deleted from the BalenCloud fleet. The Connector software running on the device will remain, and the device will operate as normal.

Part Numbers

It is possible to have up to two radios for wireless sensors in a single connector. This is useful when you have combination of sensors using different protocols.

The current options are EnOcean and Workplace Occupancy using either 868MHz for the EMEA region of 915MHz for the USA and Canada.

Download Connector Firmware

v3.1.1

v3.2.0

Object Profiles describe the shape of i.e. what properties (resources) an objects has, the data type of each property (resource), and metadata describing the object and it properties.

For more information on objects and resources read the

What You Will Need?

1. A balenaCloud account with Microservices access (this requires a paid account)

MobiusFlow has been containerised and is run via docker.

Mobius v1.X.X

Below is an example docker-compose.yml file you could use when running MobiusFlow. In this example, an online version of MobiusFlow 1.19.1 is used. Note that, as well as the MobiusFlow service (labelled simply 'mobius'), the file also containers a reference to an nginx and mongodb containers.

The nginx container is used for port mapping, and mongodb container used as a database. Neither of these are required to run MobiusFlow.

This file can also be downloaded here:

Licensing

It is important to include the correct licensing information within the environment variables of your docker-compose.yml file.

See the main on licensing for a full explanation of what is required for online and offline licensing as well updating a given licence.

What You Will Need?

1. A balenaCloud account with Microservices access (this requires a paid account)

2. A balenaCloud Raspberry Pi 4 Fleet (see )

3. A Raspberry Pi 4 with minimum 1Gb RAM and 8Gb storage (eMMC or microSD card. The following instructions are for an SD card)

Adding a Device

Navigate to your and login in

Navigate to the Fleets page

Click on the fleet you want to add a device to

Click on the Add device button

Leave all of the default settings. You can add a WiFi network (client or AP) later.

Select the Download balenaOS option in the drop down button. The balenaOS will start to download

Burning the balenaOS onto the SD Card

Place your microSD card into your SD card adaptor and connect it to your laptop or PC

Open balenaEtcher

Select Flash from file and choose the balenaOS image you downloaded above

Select your SD card as the target

Click on the Flash button

balenaEtcher will burn the balenaOS to your SD card and make it a bootable image. Wait for this to complete and for the image to be verified

Remove the SD card from the SD card adaptor and insert it into your Raspberry Pi 4's SD card slot

Plug the Ethernet cable into your Raspberry Pi 4's Ethernet port and your network

Power up your Raspberry Pi 4

Confirming Your Device is Connected to balenaCloud

After a few minutes your new device will appear in the balenaCloud dashboard. Navigate to your balenaCloud dashboard, select your fleet and view the fleet's Summary page.

You device will be added to the list at the bottom of the page. It will be given a random name which you can change on the device's summary page

You have successfully added a new device to your balenaCloud fleet. To deploy MobiusFlow® to this device go to

balenaCloud devices are configured using Device Variables. When deploying MobiusFlow® to a balenaCloud fleet a number of Device Variables are created with default values. These are defined at the fleet level but can be overridden at the device level. More information about working with balenaCloud Device Variables can be found here.

MobiusFlow Device Variables

The image below shows the Device Variables created when MobiusFlow® is deployed to balenaCloud.

Expand the items below for detailed information on each Device Variable

The ports in used by Mobius Gateways. These are for services that can be hosted on the Gateway.

The physical gateways fleet management and remote connectivity service require outbound access to these services

Mobius system

A typical MobiusFlow system consists of a single or multiple MobiusFlow nodes connected together via a TCP/IP network. Each node is capable of operating independently of the rest of the system, but nodes can interact with each other to form a complex system. All node interaction takes place through one or more brokers via a node’s router.In a multi-node system, the location of the broker is not important. It can reside on the same device as one of the nodes or on an independent device.

Each node is classed as, and exhibits the behavior of, an device. In this context edge devices are not only field devices but could also be on the edge of a server or cloud server providing the server with connectivity to all of the true edge or field devices.

Within a MobiusFlow system all hubs, services, objects and resources are identified by a unique address known as a Uniform Resource Identifier or URI. These URIs are hierarchical so given the URI for a Mobius resource it is possible to identify which object the resource belongs to, what the object type is, which service the object belongs to and which Mobius node the service is running on.

Mobius URI Definition

An object’s URI (or name) is defined in 4 parts, namely the hub ID (HID)

Introduction

MobiusFlow is a software platform designed for control and monitoring of sensors and actuators in simple (single instance) or complex (multiple instances working together) systems (see Mobius Overview for more info). It has a microservice based architecture where each microservice can contain both application logic and object state. Object types are predefined and contain any number of resources which represent the values associated to an object’s attributes (e.g. a temperature sensor may contain resources for Name, Location, Temperature etc.). A MobiusFlow node (a single instance of the software) contains a central hub and one or more microservices. All microservices contain an MQTT client and communicate with each other via the hub which is an MQTT broker. The broker is responsible for authenticating the services when they connect. The TCP/IP port used for internal MQTT comms is normally firewalled off to prevent any external traffic and all messages passed between microservices are encoded using JSON Web Token (JWT) to ensure message integrity. If communication is required between Mobius nodes, a Mobius router is added to the configuration. This is a special microservice which handles external traffic between Mobius nodes. All traffic passed through a router is encoded with JWTs using pre-shared keys (PSKs) specifically for this purpose ensuring that no internal PSKs leave a Mobius node. External traffic is also MQTT based and can be secured with TLS if required. One of the most important part of MobiusFlow is the “ Mobius protocol” over MQTT. This is a predefined set of MQTT topics based around the Mobius object URIs which allows “two way point to point” messaging via MQTT. This means that Mobius nodes and microservices can discover other nodes, services, objects and resources and microservices can read and write resource values on objects belonging to any other microservice on any node within a Mobius system. In addition to reading a writing, a microservice can subscribe to object or resource level change of value (COV) messages. The MobiusFlow protocol is similar to the LWM2M protocol but over MQTT.

The is designed to allow efficient communication for IoT Devices whilst providing structure and definable trust boundaries.

There are 2 ways to move messages to and from a one is via the designed for this task, and preserving the integrity of the the message within the node. the other is with a dedicated , this breaches that integrity to a degree but may be desirable and even necessary in some situations.

Node Internal Communication

With Each node consisting of the base of a hub and one or more services, and optionally routers. If for the purpose of this initial discussion assume that the services are only communicating with local hardware, or handling logic, therefore having no mechanism for communicating off of the local hardware. We will discuss how this can be achieved later on.

As the hub is created a pre-shared key (psk) file is generated, these can also be changed using the configuration service. each valid service must have a copy of its psk, to successfully authenticate with the hub. The hub will have the corresponding psk in its psk file. This key is used as a secret key as part of a .

Service Authentication

When a service connects to a hub it uses the . The MQTT username is the service's and 001F/01F and the MQTT password is a JSON object containing the services PID and SID with a timestamp which is then converted into a JWT (JSON Web Token). The time stamp ensures tight time synchronisation is a requirement and provides greater integrity.

If the service signs its JWT with the same psk as is stored in the hub's psk file it will successfully complete the authentication process to the hub. On doing this it will be sent a copy of the hubs psk file, giving the service the ability to the received directly signed messages from authorised services.

After successful authentication the service will have a copy of the psk of all services that are authorised to communicate through the hub. The service will then with no further action from the hub be able to validate the authenticity and integrity of messages that have come from a service on the same node.

Service Communication

Once passing traffic the MQTT message will consist of:

the JSON Web Token will also carry the topic, the message payload itself, and a timestamp this will all be hashed along with the service own key creating a to allow integrity checking:

The time stamp will allow for the message to have a validity life span that can be configured for all services connected to the hub. Internally all messages will be signed in this way and therefore provide a high degree of integrity to the internal communication.

Services may be intentionally created to connect to external interfaces such as a service the connects to remote I/O via TCP/IP or an Azure IoT hub Client, if it is desired to configure a node in this scenario, it is recommended to utilise two interconnected nodes one that handles the external communications and one that handles the more trusted internal communication, the nodes could exist on the same hardware. doing so would allow the creation of multiple trust boundaries

Node External Communication

Although as just discussed it is not impossible to create service that communicate to external interfaces, it is not recommended to use these on the same node as it compromises the integrity of the node. It is preferable to utilise a known route into and out from the node, it is recommended that this route is a .

Routers are split into two parts, one side of the router communicates internally with its associated hub and all of the services within a node, while the other side of the router communicates externally through a 'no-mans' broker to other routers on other nodes. All external communication is done using MQTT over the protocol. This could be done over a secure or non-secure connection (ws:// or ws s://).

The internal side of the router acts in exactly the same way as a service, but will automatically subscribe to all messages from every other service within that node.

The external side of the router will have the ability to sign its messages in the same fashion as the services do for internal communication, it will have two pre shared keys and internal or service psk and an external psk.

Node Peering

To allow router to validate the authenticity and integrity of messages form other routers, the external psks will be required to be manually shared between all the routers that want to take part in this communication. the result is that the external psk file will contain the keys of all authorised routers and therefore nodes.

This communication is done over the WebSocket protocol as it reduces the need to configure firewalls to allow MQTT communication. node peering is best used in an enclosed environment where there is a high degree of confidence in the integrity of the network with which the communication is taking place. This is like to require the input of network and cyber security professionals.

Node Peering will require the provision of a MQTT broker capable of using . this will be a function that will be optionally provided by the mobius router.

Larger Node Deployments

In larger deployments of nodes peering may not be viable because of the administrative overhead, or there may be low confidence in the network integrity. there may also be a require to not only ensure Authenticity and Integrity of messages, but also confidentiality.

to achieve this the nodes should utilise WebSockets over (TLS), this is in fact simply a upgrade in the same way WebSockets are used, on a connection

In this case it will almost always be easier to provide the node with access to the public internet where things like server name resolution and certificate control are well practised and understood.

Due to the large complexity in provisioning the system in this scenario, It is envisaged at this stage that IAconnects will provide the service that provides the functions of the architecture shown above.

Power Options

You have three options to power the connector

Network Options

You can connect to your network via wired Ethernet or 2.4GHz WiFi

Front Panel

The image and table below describe the connections and LED indicators on the front panel of the connector.

Product Label

The product label is on the bottom of the connector. It shows the , software version and serial number of the product.

Accessing Configuration Page