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® 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.

📖 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.

The full training course on the MobiusFlow Toolbox can be found here.

The full MobiusFlow Manager training course can be .

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

3. The objects palette

4. The configuration tree

5. The service and object configuration section

The main menu

The main menu is displayed on all pages. It allows switching between Configuration, Diagnostics, Node-RED Flows and Administration. The Administration option is only shown for users who have admin privileges.

The services palette

The services palette shows the list of Mobius services that can be added to the configuration. To add a service to your configuration drag it from the services palette and drop it on to the configuration tree.

The objects palette

The objects palette shows the list of Mobius objects that can be added to the configuration. To add an object to your configuration drag it from the objects palette and drop it on to a service in the configuration tree.

The configuration tree

The configuration tree shows the services and objects currently added to the configuration. Clicking on the triangles on the left of the tree either expands or contracts a branch of the tree. The currently selected item is shown as highlighted in orange.

To delete a service or object, hover over the item and click on the dustbin icon which appears to the right of the item.

Deleting a service deletes all associated objects

The service and object configuration section

This section is dynamic and updates depending on which item has been selected in the configuration tree. If a service has been selected the service's configuration properties are displayed. Similarly, selecting an object or object resource shows the relevant configuration options.

Always click the Save Changes button to persist changes to a service, object or resource configuration. Any changes to a service, object or resource only become active after the service has been restarted on the diagnostics page.

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.

Backup/Restore

Backup and restore functionality is accessed via the settings tab on the Administration page. A full article covering backup and restore can be found .

Setting the Hub ID

All Mobius nodes are identified by their hub ID. This is a six character hexadecimal number and should be unique within any group of Mobius nodes. See and for more information about Hub IDs.

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 .

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 .

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.

version: "3.8"

volumes:
  mobius-data:
  mobius-licence:
  mongodb:

networks:
  frontend:
  backend:

services:
  mobius:
    platform: linux/amd64
    build: ./dist
    image: local/mobiusflow-docker:1.19.1_1.19.1
    container_name: mobiusflow
    privileged: false
    restart: always
    environment:
      - MOBIUS_HUB_RESET_PSKS=true
      - MOBIUS_ENABLE_CONFIG_UI=true
      - MOBIUS_HUB_ID=000001
      - MOBIUS_LOCAL_TIMEOUT=10000
      - MOBIUS_LOG_SERVICE_STATUS=
      - MOBIUS_LICENCE=38782095-410e7ab5-c3c36a84-dd39683f-c5a8062b-78f846c2-52588c49-fc8eecf4
      # - MOBIUS_LICENCE_KEY=
      # - MOBIUS_LICENCE_TOKEN=
      # - MOBIUS_LICENCE_RESET=
      - MOBIUS_ENGINE_API_PORT=8443
      - MOBIUS_ENGINE_API_AUTH_PROVIDER=local
    volumes:
      - mobius-data:/data
      - mobius-licence:/.licence
    networks:
      - backend
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "10"
  nginx:
    image: ghcr.io/mobiusflow/nginx-cloud:1.1.0
    container_name: nginx
    privileged: false
    restart: always
    environment:
      - NGINX_UI_CONTAINER=mobius
    ports:
      # these ports are for use with the nginx TLS terminator use in mobius-cloud-install
      - 8080:8080
      - 8443:8443
      - 1883:1883
      - 30814:30815
      - 30817:30817
    networks:
      - frontend
      - backend
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "10"
  mongodb:
    image: bitnami/mongodb:latest
    container_name: mongodb
    restart: always
    environment:
      - MONGODB_ROOT_PASSWORD=r5DybE57qug3WaHebeUy2bAvvVhKXUWHD
      - MONGODB_USERNAME=mobius
      - MONGODB_PASSWORD=RmzsXQYReLHaCS5wWGjAPjtJ7VnTw4qL
      - MONGODB_DATABASE=mobius
    volumes:
      - mongodb:/bitnami/mongodb
    networks:
      - backend
    logging:
      driver: none

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 article on licensing for a full explanation of what is required for online and offline licensing as well updating a given licence.

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.

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

Click on Choose File and select the firmware file you want to upload

Click on the Update button

After a few minutes the connector will reboot and start running the new firmware

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.

manage

Manages network interfaces. See for more information

mongodb

A full version of MongoDB which you can use to store / retrieve data in flows.

The default settings are

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?

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

Creating a New Fleet

Navigate to your and login in

Navigate to the Fleets page

Click on the Create Fleet button

Enter a fleet name

Choose device type Raspberry Pi 4 (using 64bit OS)

Select fleet type Microservices

Click on the Create new fleet button

You have created your first balenaCloud fleet! Now go to to add a device to this fleet

Full functionality of Subscription Websocket is described in the connect call below.

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

Used get and set the full configuration the flows.

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

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

3. A powered MobiusFlow® connector

4. The connector's Serial Number

Enabling Configuration Mode

The connector's configuration mode can be enabled in two ways:

Using the Configuration button

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 2 seconds

Release the button and the green LED will flash rapidly

Using your laptop / tablet / smartphone look for a WiFi network with the same name as the connectors serial number

Connect to this network and enter the connector's Config Mode Password. The default is mobiusflow

Open a web browser on your laptop / tablet / smartphone and enter http://192.168.4.1 into the browsers address bar and hit enter

The web browser will show the connector's configuration Home page

Using a Web Browser

Make sure that the connector and your laptop / tablet / smart phone are connected to the same Ethernet network

Open a web browser and browse to <your connector IP address>:8080 e.g. 192.168.1.20:8080

You will need to enter a user name and password. The user name is admin and the password is the same as the connector's Config Mode Password. The default is mobiusflow

After a short delay the web browser will redirect to the connector's configuration Home page

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); Authorization, Discover, Node, Service, Object, Profiles, Command, Flows and Subscription.

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 here. 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.

Switches and Rocker Profiles (F6-XX-XX)

• F6-02-XX: Standardized rocker switch functionality, perfect for wireless and battery-free light switches.

• F6-01-01: Classic single rocker switch for versatile applications.

• F6-05-01 & F6-05-02: Advanced switches supporting multi-rocker configurations.

• F6-04-01: Specialised profile for unique switch requirements.

Temperature and Humidity Sensors (A5-XX-XX)

• A5-02-01 to A5-02-20: Comprehensive profiles for temperature and humidity sensing across varied ranges and resolutions.

• A5-04-01 to A5-04-03: Focused on precise temperature monitoring for HVAC and building automation.

• A5-06-02: Compact profile for humidity measurement.

• A5-07-01 to A5-07-03: Temperature and humidity combined for indoor climate monitoring.

• A5-08-01 & A5-08-08: Advanced temperature sensors for outdoor and industrial use.

Light and Occupancy Sensors

• A5-09-04 & A5-09-02: Profiles for daylight harvesting and light level monitoring.

• A5-10-03, A5-10-06, A5-10-12, A5-10-19: Advanced occupancy and motion detection sensors.

• A5-11-01 & A5-11-02: Multi-functional sensors for light, motion, and temperature.

Energy and Utility Monitoring

• A5-12-01 to A5-12-03: Profiles tailored for energy consumption and utility monitoring.

• A5-14-58 & A5-14-05: Energy efficiency sensors for load and power monitoring.

• A5-20-01: Compact profile for energy harvesting applications.

People Counting and Building Analytics

• IMBUILDINGS PEOPLE COUNTER: A specialised profile for tracking occupancy and people flow in smart buildings.

• D1-03-C1, D1-03-C2, D1-03-C0: Advanced profiles for presence detection and people counting.

Advanced Actuator and HVAC Controls

• D2-32-00 to D2-32-02: Actuator profiles for heating, ventilation, and air conditioning systems.

• D2-14-5C, D2-14-40 to D2-14-53: Comprehensive profiles for valve and motorised actuator control.

• D2-03-OA: Specialised actuator profile for unique applications.

Miscellaneous Profiles

• D2-05-00: General-purpose profile for binary data transmission.

• D2-01-0A to D2-01-12: Profiles for advanced control systems.

• D2-15-00: Versatile profile for industrial applications.

Specialised Devices

• ECHOFLEX MOS MT: Tailored profile for motion sensing in smart building environments.

Why Use MobiusFlow for EnOcean EEPs?

MobiusFlow provides a powerful and flexible platform for integrating EnOcean devices. Its library’s support for a wide range of EEPs ensures compatibility with various devices and applications, making it ideal for:

• Smart Building Automation: Efficiently manage lighting, HVAC, and energy systems.

• Industrial Automation: Enhance operational efficiency with precision monitoring and control.

• Energy Efficiency: Monitor and reduce energy consumption with advanced sensors.

By leveraging MobiusFlow’s extensive EEP library, businesses can create scalable, efficient, and energy-saving IoT solutions tailored to their needs. Whether you’re looking to optimise a single building or manage a global network of properties, MobiusFlow and its EnOcean integration make it possible.

Licence information is included within the the environment variables of the Mobius service in the docker-compose.yml file

Online Licence

• For online licences only the licence code itself needs to be included

• The environment variable used for this MOBIUS_LICENCE

• For example:

- MOBIUS_LICENCE=38782095-410e7ab5-c3c36a84-dd39683f-c5a8062b-78f846c2-52588c49-fc8eecf4

Offline Licence

• As well as the licence code, offline licences must include a licence key and licence token

• These are included in the environment environment variables MOBIUS_LICENCE_KEY and MOBIUS_LICENCE_TOKEN respectively For example:

- MOBIUS_LICENCE=38782095-410e7ab5-c3c36a84-dd39683f-c5a8062b-78f846c2-52588c49-fc8eecf4
- MOBIUS_LICENCE_KEY=LS0tLS1CRUdJTiBSU0EgUFVCTElDIEtFWS0tLS0tCk1JSUJDZ0tDQVFFQW10MFhkNWpsU2pLY2RNQU5XeW1jbE0wN21vM0dZRmIyR2E0bjFpZ0NPcGpUYi9yeWp5OTAKZlptcFhNVm5XTFM2U2N1ZUpvclk1cEI3c0NYdlp0djB5VkFweUQrNFB2U3QxN3FzWUZ6NmtpWU5UVUN1TjJjZgoxYWXqMkVJOVlSU3N4aUcxTDFsbmlBeFFlUGROMFl0NkpNRkhQbkwxNU52OUZYXWJISVNEcDVOeEhFTUc0UmhqCksvZmdSRlRLcTR3NVpVWUFTMlVXOGdZMGhyeWZmejdRUm1HUGFZMDEwblZwQllZbEdrYXBmOEtIQ1huczN4WksKMDVVMzB1cGtLUjZZV09KY0xXTHVUc1F2WVVJYzhsRFJaK1JXclRjbWJMSWdyTEdoclZjZFBBditrSnBHTGorTgpibjVrSlJCVDV5MU04dGwxVXVOaDYzTW5qMDh5UTBKSUZRSURBUUFCCi0tLS0tRU5EIFJTQSBQVUJMSUMgS0VZLS0tLS0K
- MOBIUS_LICENCE_TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb2RlIjoiZmU5ZTFkMDAtOWMzOTYwMDMtN2E1ZmRmOWItOGMwZjA4ZmQtZTQzNGFkMDktZDc4MDQxZWYtZGEyNWM3NWEtZGRjNjAxNzgiLCJ2YWxpZEZyb20iOiIyMDIzLTA4LTMwVDAwOjAwOjAwLjAwMFoiLCJ2YWxpZFRvIjoiMjAyMy0wOS0yOVQwMDowMDowMC4wMDBaIiwic2l6ZSI6MTAsImFjdGl2ZSI6dHJ1ZSwidHlwZSI6InByb2R1Y3Rpb24iLCJjaGVja1R5cGUiOiJvZmZsaW5lIiwiY2hlY2tJbnRlcnZhbCI6NjAsImZhc3RDaGVja0ludGVydmFsIjo1LCJyS2V5IjoiMjI0Y2IyZWE4Zjc0MDU5NWFhMzE0OTBmNjkxM4c1YmM4OWVjYTA0MWE2YTkzZWZmMWRjZmUyMGVjMWNmZGQ0YSIsDmlhdCI6MTY5MzM5MTg2NywiZXhwIjoxNjk2NDYzOTk5fQ.bmMb-s-AScXW5oqB9eNnhhJ_lhqOdSAkOkpK8NCpZwno7UGXOCElBDGBCiI7DOB1rYrDQvxgt9qqWR5iAXuuSb5PEt-MUeaEduygHqAO89RmXFjBG6UycJCW3ERVGL5O_csGjZBZh1wen74oYkiVjYP_6TXe9tuRjI20F0GuaMCq07AKo05IgYJxkPHbuTeJud6XA8WeEPJnlxae51GwKFyfq5uLYYQYjdlMs8V7N92yiLlcDijoUtJPq7pSm93Hg3wolx4uGx23DyS81XTb0uzm_0zX93kIdImEBvrGCDOF_T2y8hWvzgVD2ihMygLsKNolN3Ir3p3t-udE8-1yYA

Updating a Licence

• If the licence information is replaced, the environment variable MOBIUS_LICENCE_RESET must be set to true as shown below

- MOBIUS_LICENCE_RESET=true

• This forces MobiusFlow to reload and update it's licence information

• Once MobiusFlow has started, ensure that this environment variable is set back to false for any subsquent restarts where the licence information has not been changed

• For offline licences, if you are updating the licence code, you must also update the licence token

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

MobiusFlow® connectors send and receive data via MQTT. You need to configure the MQTT settings to match the configuration you set in the Configuring MobiusFlow® 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

Enter the IP Address or URL of the MQTT broker. You do not need to specify MQTT:// or MQTTS:// before the URL

Enter the MQTT Port number. This is normally 1883 or 8883 for TLS enabled connections

If required enter the MQTT broker authorisation Username and Password. These can be left blank if no authentication is required

Enter the same pre-shared key (PSK) as you entered in the Configuring MobiusFlow® section of this guide

Security

If you are using TLS make sure you check the TLS using CA Certificate option. You must also set the correct CA Server Certificate on the Manage Certificates page

You may also choose to use a Client Certificate and Key. Check this option if required and ensure that you have setup your client certificate and key on the Manage Certificates page

Save Settings

Once you have configured all MQTT settings click the Save button

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

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 Licensing page.

What You Will Need?

1. A valid MobiusFlow® licence (licences can only be used on one device)

Adding Your Licence to a BalenaCloud Device

Licences are added to balenaCloud devices by setting a device variable. All required device variables are created automatically when you deploy MobiusFlow® to a fleet. For more information see Device Variables.

Navigate to your balenaCloud dashboard and login in

Navigate to the correct fleet and device

Select the Device Variables page. You will see a list of all of the device's variables with override buttons next to each variable

Click the override button next to the MOBIUS_LICENCE variable

In the popup delete the text <replace with your licence code> and enter your licence code

Leave all other settings as their default values and click the Add button

Your licence code will be shown in the Device Variables list (see Device Variables for more information on all of the device variables shown in this list)

MobiusFlow® will restart to install the licence

Updating or Replacing a Licence

Under some circumstances it may be necessary to enter a new licence code. In order to make the new licence code work follow the procedure above to enter a new code

You will also need to tell MobiusFlow® to renew its licence by setting the Device Variable MOBIUS_LICENCE_RENEW to true

Click the override button next to the MOBIUS_LICENCE_RENEW variable

In the popup change the value from false to true

Leave all other settings as their default values and click the Add button

Wait for MobiusFlow® to restart, confirm that the new licence is working and reset the Device Variable MOBIUS_LICENCE_RENEW to false

Click the override button next to the MOBIUS_LICENCE_RENEW variable

In the popup change the value from true to false

Leave all other settings as their default values and click the Add button

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!

The Home page has the following buttons

Configure Network

Configure the wired or wireless Ethernet network settings

Manage Certificates

Manage all certificates for TLS connections. The default certificates are for MobiusFlow® cloud hosted instances but you can add your own if required

Configure MQTT

Configure the connection to the MQTT broker you chose when configuring MobiusFlow® for connectors

Set Config Mode Password

Change the configuration mode password

About

See information about the connector such as the software version, serial number, andwhich modules are installed

You can also update the firmware on this page

Reboot Device

Reboot the device to exit configuration mode and use the new settings

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

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

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.

The Object Store service can be considered a service type only for storing MobiusFlow objects. It has no functional backend. This means, unlike most other MobiusFlow services, the service will not interact with the objects stored on it.

Uses

• For storing non-service specific objects such as the Numeric Value objects or String Value objects (Often these will be used if values are being calculated based on other objects)

• Manually writing to an object type, instead of relying on its functional parent service (e.g. manually writing the data into a LoRaWAN device object from the Flows, instead of using the LoRaWAN LNS service)

• Testing

• Diagnostics

Limitation

Although it is possible to place any object type in an Object Store service, because the service has no functional backend, it cannot interact with most object types in fully functional way. For example, adding a LoRaWAN device object to an Object Store service is possible, however the object will not be automatically populated by incoming LoRaWAN messages. If the LoRaWAN device object was placed into its functional parent service (LoRaWAN LNS service / LoRaWAN Devices service) instead, it would function as normal, as these service types have the correct backend to work with this object type.

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

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

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:

• Official Connector

• Raspberry Pi

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

4. Add a new device to the fleet and download the subsequent Balena image

5. Etch the image

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.

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.

Overview & Purpose

The EnOcean Devices service handles the decoding of incoming data from EnOcean devices. All EnOcean Devices services listen for EnOcean message broadcasts from the MobiusFlow hub. If any incoming EnOcean messages correspond to any EnOcean device object on a given EnOcean Devices service, the service will decode the data and populate that object.

EnOcean Objects

Each real-world EnOcean device must be represented in MobiusFlow by a corresponding EnOcean device object. To work correctly, these objects must exists within an EnOcean Devices service.

To add new EnOcean device objects, navigate to the object configuration page of the EnOcean Devices service.

EnOcean device objects can added via the Object Library:

All EnOcean device objects require the EnOcean UID of the corresponding real-world EnOcean device to entered:

To realise any changes, the object settings must be saved and the service started / restarted:

Once the object is live, any decoded data from the corresponding EnOcean device can viewed by navigating to that objects resources:

Dataflow & Connectors

In most cases data is brought in through MobiusFlow connectors. A full guide on setting up MobiusFlow connectors can be found .

The following diagram shows the full data flow between the EnOcean devices and their corresponding MobiusFlow objects. This is explained in full in the .

Sending Data to EnOcean Devices

It is possible to send data from MobiusFlow to EnOcean devices via the flows using the MobiusFlow connectors service. The full article covering Receiving and Sending Raw EnOcean Telegrams in the Flows can be found .

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

API

Application Programming Interface (API) - A well-defined language to allow different software modules to communicate with each other to share data or commands. (see RESTful API)

The Edge

Edge computing is a computing architecture focused on bringing computing as close to the source of data as possible in order to reduce latency and bandwidth use. In simpler terms, edge computing means running fewer processes in the cloud and moving those processes to local places, such as on a user’s computer, an IoT device, or an edge server.

Endpoint

Endpoints are the start and end of a data flow in an IoT application. These can include sensors, gateways, cloud servers, applications, and databases. In the context of a complex solution, an endpoint may also be defined as the end of a sub-section of that solution.

Gateway

An IoT gateway is a small computing device, normally installed at the edge, for collecting and processing sensor data. It is mostly used where direct communication with a cloud server is undesirable, for instance, when performing local control, a reliable internet connection is unavailable, or when security concerns dictate data should not be published on the internet.

HTTP(s)

Hypertext Transfer Protocol (HTTP) - This is the most widely used communication protocol used transfer data between computers over the internet.

HTTPS is a secure version of HTTP where all data is encrypted using TLS (transport layer security)

IIoT

The Industrial Internet of Things (IIoT) is a subset of IoT for industrial rather than consumer or commercial applications.

IoT

The Internet of Things (IoT) describes the network of objects or things that are connected together to provide or consume data to you, your business or processes. Things include sensors, actuators, software and other devices that form part of this network.

The term IoT has grown to include systems and devices connected via the internet and via private offline networks.

Microservices

A software architecture where small independent software modules, responsible for a single, specific task, communicate through well-defined APIs to create a more complex system.

Middleware

A piece of software that acts as a bridge between devices, an operating system, or database and applications, especially on a network. It can be described as "software glue"

MQTT

MQTT is an OASIS standard messaging protocol for the Internet of Things (IoT). It is designed as an extremely lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. MQTT today is used in a wide variety of industries, such as automotive, manufacturing, telecommunications, oil and gas, etc.

MQTT originally stood for Message Queue Telemetry Transport, but this definition has since been dropped.

Recursion

See recursion

RESTful API

A RESTful API is an architectural style for an application program interface (API) that uses HTTP requests to access and use data. That data can be used to GET, PUT, POST and DELETE data types, which refers to the reading, updating, creating and deleting of operations concerning resources.

SaaS

Software as a Service - a method of software delivery and licensing in which software is accessed online via a subscription, rather than bought and installed on individual computers.

TLA

Three Letter Acronym - IT teams love acronyms. Sometimes we have to laugh at ourselves!

TLS

Transport Layer Security is a cryptographic protocol typically used with HTTP to secure data transferred between computers or the internet or your private network.

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

What You Will Need?

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

2. A balenaCloud Raspberry Pi 4 Fleet (see Creating a Fleet)

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

4. A power supply for your Raspberry Pi 4

5. An Ethernet network cable

6. An internet router with a free Ethernet port (or an Ethernet port on your LAN with internet access)

7. An SD card adaptor for your laptop or PC

8. balenaEtcher installed on your laptop or PC. You can download balenaEtcher here

Adding a Device

Navigate to your balenaCloud dashboard 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 Deploy MobiusFlow® to Your Fleet

The flows are powered by Node-RED. Use the link below to learn more about Node-RED specifically.

Node-RED can be used independently of MobiusFlow, however if you want move data between the MobiusFlow Engine and the Node-RED flows, you will need to link the two.

MobiusFlow Specific Nodes

A set of MobiusFlow specific nodes have been created to facilitate data transmission between the Flows and the MobiusFlow Engine. The nodes are found in the Node-RED package node-red-contrib-mobius-flow-base. If you're using Node-RED pre-packaged with MobiusFlow, this package will be installed by default however if you're using Node-RED running elsewhere, you will need to add this to your palette using the Node-RED palette manager.

Setting up MobiusFlow Connection

A MobiusFlow connection is defined within a Node-RED configuration node. Once defined, all MobiusFlow specific nodes in your flows can use this connection to interface with the MobiusFlow Engine.

To create a new connection, open the config window of any MobiusFlow node. If no connection has yet been defined, the node will prompt you to add a new one.

Clicking the pencil icon will open the new connection's configuration window.

Authorisation

All connections require a valid API username and password to ensure this instance of Node-RED is authorised to connect to MobiusFlow.

The default cradentials are:

Username: admin

Password: adm123

Using Node-RED pre-packaged with MobiusFlow

If you're using the instance of Node-RED that has come pre-packaged with MobiusFlow, that means Node-RED and the MobiusFlow Engine and running locally to one another in parallel docker containers . As such, the following settings must be used:

Host

mobius:8443

Use SSL/TLS

This controls if the connection uses HTTP or HTTPS. As Node-RED is running locally relative to the MobiusFlow Engine, this should be left unchecked to ensure the connection uses HTTP.

Using external Node-RED

When running Node-RED remotely relative to the MobiusFlow Engine, we recommend SSL/TLS is enabled so the connection is secure. Also ensure the port is appended to the hostname if required.

Checking the Connection

Once set up, you should check that the flows are successfully connected to the MobiusFlow Engine.

On any MobiusFlow node, select the newly added connection. If this is the only connection you have set up, it will be selected by default.

Upon clicking done and deploying your flows, all MobiusFlow nodes using this connection should show the status 'Connected' if the connection to the MobiusFlow Engine has been made.

If you the connection has not successfully been made, the status of all nodes using that connection will reflect this.

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), service ID (SID), object profile ID (PID) and instance number (INS). A fifth part is added when accessing a specific resource, the resource ID (RID).

Each part of an object’s URI is a uppercase string of a defined length (as shown in the table below). The URI’s parts are separated with a forward slash (/).

A full URI is typically defined as HID/SID/PID/INS/RID.

It is possible to address any part of the system by only using the required parts of the URI. e.g. to address a service only the first two parts of the URI are used HID/SID and to address an object only the first four parts are used HID/SID/PID/INS.

An example of an object URI for an object of instance 1, profile 3A, created by service 1F connected to hub 1 is:

000001/01F/003A/0001

and if addressing resource 40 on that object the full URI would be:

000001/01F/003A/0001/40

Mobius URI Wildcards

Under certain conditions, such as subscribing to a resource’s change of value event, it is possible to use wildcards in the URI. These wildcards are described in the table below and follow the MQTT standard.

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.

Mobius nodes

A Mobius node consists of a central Mobius hub, one or more Mobius services and optionally one or more Mobius routers.

Services contain the service logic and an object data store. Connections to sensors, actuators and other communication interfaces such as Modbus or BACnet can be added depending on the service’s purpose and controlled through the service's logic.

The object data store models the physical or virtual connections and provides a standardised method for services and other nodes to communicate and share data with each other through Mobius objects.

All of the communications between services through the hub or nodes through routers and brokers is based on the protocol. The MobiusFlow protocol has been defined on top of this MQTT protocol providing a well-defined API enabling different physical devices and protocols to communicate with each other in a consistent way.

Mobius nodes follow the architecture pattern, where each service is a stand-alone process capable of communication with other microservices creating a large application from small manageable pieces.

Routers are used to cross node boundaries. They provide a secure mechanism for nodes to share data using the MobiusFlow protocol.

Logical structure of a node

The logical structure of a node is detailed below. This diagram shows the hierarchical relationship between all of the parts which make up a node and how objects contain resources, services contain objects and hubs connect to services and routers.

The Mobius URI structure allows addressing any part of a node at any depth.

Hubs

A Mobius hub is the foundation of a node. At its heart, a Mobius hub is just an MQTT broker which manages and links Mobius services and Mobius routers. Hubs are responsible for ensuring that all services and routers are valid members of a node by verifying their pre-shared authentication key on connection.

Each hub within a Mobius system is given a unique ID. This is a six digit hex number which forms the first part of the Mobius URI hierarchy. When referencing a hub, for example during a discovery process, this unique ID must be used (see ).

When service or router connects to a hub, and has been validated, the hub provides it with a copy of the Mobius object profiles and pre-shared keys files, ensuring that all services and routers connected to the hub are able to communicate and understand one another.

Services

Mobius services are the engines which drive MobiusFlow. Each service is essentially a microservice performing a specific task and possibly acting as an interface to a piece of hardware or a 3rd party service such as Microsoft's Azure platform or the IBM Cloud.

All services MUST implement the full MobiusFlow protocol to enable them to connect to hub and communicate with other services. In addition to implementing the MobiusFlow protocol, services can create Mobius objects to store and share data and can also contain service specific logic to perform the task that they are designed for. When creating services, try an keep them focused on one task and create additional services to perform other tasks. This ensures that services are reusable and Mobius systems can be configured to only contain the logic that they require.

Each service within a Mobius node is given a unique ID. This is a three digit hex number which forms the second part of the Mobius URI hierarchy. When referencing a service, for example during a discovery process, this unique ID must be used (see ).

Routers

Mobius routers control all MobiusFlow communication into and out of a node. This ensures that nodes are secure and allows nodes to discover each other within a MobiusFlow system.

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 wss://).

Routers are capable of routing messages between services belonging to different nodes, essentially allowing a service on one node to read, write and subscribe to change-of-value events on objects in another node.

Mobius objects

The key to the MobiusFlow system is Mobius objects. These objects typically model real-world objects and provide a mechanism for sharing data and storing state in a consistent way. Each object has a unique identifier or which can be discovered and used by any part of the MobiusFlow system.

Mobius objects are predefined in an object profiles file which is passed to a services by the hub when a service connects.

Each object within a Mobius node is given a unique ID. This ID consists of two parts and is made up of the object profile ID (PID) which describes the object's type, and the object's instance number (INS). The PID is a four digit hex number which forms the third part of the Mobius URI hierarchy and the INS is a four digit hex number which forms the fourth part of the Mobius URI hierarchy. When referencing an object, for example during a discovery process, this unique ID must be used (see ).

Object resources

Mobius objects contain one or more resources. It is these resources which are used to define objects that mimic or represent real-world objects. An example of a single object is a room temperature sensor. This object may have resources which define the sensor’s name, location, asset reference, engineering units, set point and actual measured value.

Each resource is capable of storing a single value which can currently be of type Boolean, Number, String, DateTime or TimeSpan. Resources also store meta-data about the value. The actual meta-data depends on the value type chosen. Resources can be read only or read/write. Read only resources have their values set when they are created.

Each resource within an object is given a unique ID. This is a two digit hex number which forms the fifth and final part of the Mobius URI hierarchy. When referencing a resource, for example during a read, this unique ID must be used (see ).

Present value and the priority array

Resources store their values in a priority array. This priority array works in a similar manner to a priority array. The array has 16 possible locations with location 1 being the highest priority and location 16 being the lowest priority.

When reading the value of a resource the actual value is returned in the PV(present value) property. The PV is always equal to the value of the highest active (non null) priority in the resource's priority array.

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 part number, software version and serial number of the product.

Purpose of Connector Service

MobiusFlow connectors are transceiver hardware that connect to the following technologies:

• WorkPlace Occupancy

• EnOcean

Connectors are designed to bridge the gap between these technologies and MobiusFlow via the MobiusFlow Connectors service.

Service Configuration & MQTT

The Connectors service uses MQTT to communicate with the Connectors. As such, the service must be pointed to and authenticated with an MQTT broker.

The service configuration pane requires entry of the following:

Once these fields have been populated, save and start the service:

The MQTT connection status can then be observed within the service status:

The above screenshot shows a running example of a Connectors service connected to a local MQTT broker.

Connector Objects

Each real-world connector must be represented in MobiusFlow using a connector object. The object settings require connector details such Serial Number and Pre-Shared Key (PSK) to be specified. It also allows the viewing of live connector status.

To add a connector object to the Connectors service, first navigate the to the service's object configuration page.

Once navigated to service's object configuration page, a MobiusFlowConnector object for each real-world connector should be added.

Each connector object requires the following configuration settings to be specified:

Connector Status

Once the connector object is live, the status of it can be checked by navigating to the resources of that object:

The above screenshots shows the useful status information a connected connector makes available. Checking if the connector is connected is possible by observing the objectLastUpdate resource.

Sensor Data

Raw sensor data is not displayed anywhere within the Connector object. Instead, the service automatically relays incoming data from authorised connectors to the MobiusFlow hub, where it is then broadcast to all MobiusFlow services.

Some service types such as the EnOcean service, listen for and decode these messages into useable data. If the sensor data is valid, those service will then go on to populate corresponding device objects based.

The flowchart below shows how data flows from device level into the corresponding MobiusFlow objects via the Connectors and Connectors service:

Sending Data to Devices via Connectors

The EnOcean technology sometimes requires messages /commands to be sent the devices. This is possible is MobiusFlow using the Flows. A full article on receiving and sending EnOcean telegrams within the flows can be found here.

Accessing Configuration Page

Via Balena Fleet

If the Connector is hosted via BalenaCloud and has an internet connection, the configuration can be accessed anywhere via the BalenaCloud Public Device URL.

MobiusFlow Hosted

If the connector is hosted by MobiusFlow, please contact support to receive the Public Device URL.

Self Hosted

The BalenaCloud Public Device URL can be found by Navigating to the connector device on the BalenaCloud fleet.

Via Raspberry Pi Access Point

By default, the MobiusFlow connector will broadcast a WiFi access point, the name of which matches the connector's serial number (in the form of MF_XXXXX). Connect to this access point on a computer or mobile device. Then the configuration window is accessible by browsing to 10.42.0.1.

Via Local Network

If the connector is connected to a local network via Ethernet or WiFi (with a known IP address) and you're able to also connect to this network using a computer or mobile device, then simple browse to the local IP of the connector.

Login & Home

Login

When browsed to the configuration window of the connector, a login screen is presented.

The default password of all new MobiusFlow connectors is:

mobiusflow

Note that, if the connector is not new, this login password may have been changed.

Home Page

When on the the home page, the current status of the connector is shown. This includes:

The main menu also allows navigation to the connectors configuration pages. These includes those for Network Configuration, MQTT Configuration, Certification Configuration, and the Change Password page (allows the connector configuration password to be changed).

Configure Network

It is critical that the MobiusFlow connector's network situation is such that it can access the target MobiusFlow instance over the network. This may be over the internet or simply over a local network.

In either situation, the connector must be connected to the network and the configure network page allows for this.

Connection Type

The connection type allows choosing between a Wired or WiFi connection.

If using a Wired connection, ensure the Raspberry Pi is plugged in via Ethernet.

If using WiFi mode, the WiFi SSID and corresponding password must be populated.

TCP/IP Settings

The TCP/IP settings allow switching between DHCP and Static IP allocation. Unless there are specific reasons to set the connector on a static IP address, using DHCP is recommended.

If using the connector in Static mode, the Subnet Mask, Default Gateway and DNS 1 can be set. If it is not clear what to use here, use the default settings as shown below.

Note that, the default gateway is not required however if the connector required access to the internet, the local IP address of the internet providing gateway (Network router / modem) must be populated here. This is often in the form XXX.XXX.XXX.1 or XXX.XXX.XXX.0 .

WiFi Access Point

Setting the connector up to be a WiFi access point is useful for two reasons.

Firstly, it allows you to connect to it, allowing for easy wireless access to its configuration page. Secondly, if this connector has internet access via ethernet, it can act as an internet enabled hotspot to connect WiFi device to, in-turn giving them internet access.

If the WiFi access point is enabled, a WiFi SSID and Password must be set. It is recommended the default SSID is used (This matches the the connectors Serial Number)

Saving Changes

To save the changes click the save button. If there are an issues with the configuration, such as an invalid input in one of the fields, the form will show this and the changes will not be saved. If the settings were saved correctly, a pop up will show this after the save button has been clicked.

Configure MQTT

Overview

Connectors use MQTT to communicate with MobiusFlow. As such, the Configure MQTT page allows the connector to be pointed at a specific MQTT broker. In almost all cases, the broker will be running the MobiusFlow instance itself.

Before setting up the connector's MQTT configuration, ensure you first set up the MobiusFlow instance ready for this connection. A guide on how to do this can be found .

Configuration Window

The configuration window shows the key 6 properties which must configured to allow an authorised connection to the MQTT broker.

Explanation of Properties

Saving Changes

To save the changes click the save button. If there are an issue with the configuration, such as an invalid input in one of the fields, the form will show this and the changes will not be saved. If the settings were saved correctly, a pop up will show this after the save button has been clicked.

Realising Changes

Once the changes have been made locally, to implement the changes within the connector, click the Reconfigure and Reboot button.

This will cause the connector to reboot. As such, the configuration window's connection to the connector will be lost. This may automatically be restored once the connector reboots, but this may not be the case if the connector's configuration has changed such that it is no longer accessible over the network.

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 Mobius architecture 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 mobius node one is via the mobius router designed for this task, and preserving the integrity of the the message within the node. the other is with a dedicated service, 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 JSON Web Token (JWT).

Service Authentication

When a service connects to a hub it uses the MQTT built in username / password authentication. The MQTT username is the service's profile ID (PID) and service (SID) 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 HMAC 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 mobius router.

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 WebSocket 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 MQTT over WebSockets. 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 Transport Layer Security (TLS), this is in fact simply a HTTP upgrade in the same way WebSockets are used, on a HTTPS 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.

The configuration of the network interfaces of a MobiusFlow® balenaCloud device is handled by the manage microservice. All configuration is stored in a JSON file which can be updated by plugging in a properly configured USB memory stick or through the balenaCloud device terminal.

Network Configuration File Structure

Editing the Network Configuration

Using the balenaCloud Device Terminal

Navigate to your and login in

Navigate to the Device Summary page of the device you want to configure

Open a terminal in the manage microservice

Change to the /data/.mobius/manage directory and edit the networks.json file by running the following commands:

This will open the network configuration file for editing using the vi editor

Make any required changes and save the file

Exit the terminal and restart the manage microservice by clicking on the restart icon next to the manage service

Using a USB Memory Stick

Using a USB memory stick to update the network interfaces is useful when none of the network interfaces is configured to connect to the internet so it is not possible to use the balenaCloud device terminal. You will obviously need physical access to the device to use this method.

Format the USB memory stick as FAT32

Rename the USB memory to MOBIUSCONF

Create a file on the USB memory stick called networks.json

Open the file on your laptop or PC in your favourite text editor and paste in the correct JSON configuration from the examples above

Make any required changes

Save the file and unplug the USB memory stick from your laptop or PC

Plug the USB memory stick into any of the USB ports on your device

Reboot your device

When the device reboots it will copy the networks.json onto the device and use the new configuration for its network interfaces (this will take a minute or two)

You can then remove the USB memory stick and your device will continue to use the new network configuration.

Understanding the following articles is recommended before reading this article:

• MobiusFlow Architecture

• MobiusFlow URIs

• Connecting Flows to MobiusFlow Engine

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

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

Moving data into Flows

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

Basic Get

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

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

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

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

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

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

Basic COV

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

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

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

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

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

Additional Outputs

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

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

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

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

Further Get and COV nodes

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

Moving data from Flows to MobiusFlow Engine

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

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

Set Resource

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

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

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

Set Multi-Resource

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

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

Input Topic

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

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

This article aims to explain how raw EnOcean telegrams can be sent and received within MobiusFlow. The article briefly covers the supported telegram types and illustrates how these types affect the setup of a given flow.

Receiving

Overview

EnOcean telegrams can be received and injected into a given flow using the Subscribe to Broadcast Command node, labeled 'sub bcmd'. This node is shown below.

Within the node's configuration, you can specify a Mobius Command ID. This Command ID controls which type of incoming telegrams the node receives.

Once an incoming telegram of the specified type is detected by the sub bcmd node, the node will forward this telegram out of its output.

Command Types

The table below shows which Command ID entries relate to which telegram types. The table also shows screenshots of each Command ID being used within the sub bcmd node configuration.

Example

In this example, a Sub BCMD node is used to subscribe to incoming EnOcean RMC telegrams. The sub bcmd node is linked to a debug node to allow the telegram to be displayed. This setup is shown in the flow below.

The configuration of the sub bcmd node is shown below.

Sending

This sections covers how to send EnOcean telegrams using the MobiusFlow Connector hardware.

MobiusFlow Versions v1.x.x (v1.19.9 and newer)

EnOcean telegrams can be sent from the flows using the Send Broadcast Command node, labeled 'send bcmd'. This node is shown below.

On opening the node's configuration, a Command ID is required to specify the function of the node. To allow the node to send EnOcean telegrams, the Command ID should read 'ENOCEAN_RADIO_TX'. This is shown in the configuration window below.

The node accepts and forwards data contained within the payload of incoming messages. The appropriate incoming message structure is shown below.

msg.payload = {
 connectorURI: /*(Connector MobiusFlow URI)*/,
 rawData: /*(Command Data)*/,
}

Below is shown an example configuration of a function node that can be used to generate a payload of the required format.

This data is also shown in the following code block.

msg.payload = {
    connectorURI: '000001/024/FFC0/0001',
    rawData: [
        0x00,
        0x07,
        0x07,
        0x01,
        0xf6,
        0x70,
        0x00,
        0x00,
        0x00,
        0x0A,
        0x30,
        0x01,
        0xff,
        0xff,
        0xff,
        0xff,
        0xff,
        0x00
    ]
}
return msg;

MobiusFlow Versions v2.x.x

As well as supporting the Sub BCMD node method from MobiusFlow versions 1.x.x, MobiusFlow 2.x.x introduces the EnOcean Connector TX node for further ease of sending EnOcean telegrams.

Within the node's configuration, you must specify a MobiusFlow connector in which telegrams will be sent from.

The URI of the connector can either be typed in, or it can be searched for using the search button. In the above example, the connector with URI '000001/024/FFC0/0001' has been selected.

The node will send any data within the payload of the incoming message. A screenshot of example code of a function node used to set this payload is given below.

This code is also given in the following code block.

msg.payload = [
    0x00,
    0x07,
    0x07,
    0x01,
    0xf6,
    0x70,
    0x00,
    0x00,
    0x00,
    0x0B,
    0x30,
    0x01,
    0xff,
    0xff,
    0xff,
    0xff,
    0xff,
    0x00
]
return msg;

Checksums and Sync Byte

All EnOcean telegram types feature a sync byte and some checksum bytes to ensure message integrity. When forming a telegram, the user does not need to include the sync byte or checksum bytes, as these are automatically added by MobiusFlow.

For further information about EnOcean telegrams structures we recommend consulting documentation provided by EnOcean.

Overview

The MobiusFlow INGY integration implements the following features:

• Changing lighting level set points of group scenes

• Switching between lighting scenes of a given group

• Adding / removing devices from groups

• Acquisition of data from INGY devices

• Direct interfacing with INGY API and Datastream

This article explains how to use the INGY service to achieve all of the above.

Connecting to INGY Gateway

To interface with an INGY system, an INGY gateway must be present on the project site. These INGY gateways can be acquired directly from INGY.

MQTT

The INGY gateway host's and MQTT broker, and as such, MobiusFlow uses an MQTT connection to this broker to allow two-way communication between MobiusFlow and INGY.

INGY gateways create 3 MQTT users, each with different sets of permissions. MobiusFlow requires usage of the datastream and MQTT JSON server (API) users. These user credentials can be found in the Gateway MQTT server section of the INGY gateway configuration page.

Network Requirements

Ensure the INGY gateway is accessible by MobiusFlow over an on-site (or otherwise) network. As it is likely the local IP address of the INGY gateway will be directly referenced within MobiusFlow, it is recommended that this should be set up on the network with a static local IP address. This means the connection will not break due to DHCP reassignment.

INGY Service Settings / Requirements

Once the INGY service has been added, the following configuration window is shown:

The following fields must be populated to allow MobiusFlow the connect the INGY gateway.

Checking connection

The INGY service will attempt to connect via MQTT to the INGY gateway when the service is started. As such, to test the connection, start the service and observe the service status:

Lighting Control

Lighting control is exclusively performed by commanding lighting groups to change to different scenes.

For every INGY lighting group, add an ingy_group (PID 028A) MobiusFlow object to represent the group within MobiusFlow. The group number of the INGY group can be set in the object settings.

Viewing the resources on an INGY group object shows:

Groups pre-configured using INGY App

If using a group the has been pre-configured using the INGY App, ensure the group number is MobiusFlow is set equal to the group number of the group previously created in the INGY App.

If a group with a matching group number has been set up within the INGY App, MobiusFlow will automatically pull (given some time) the sceneSetLevel values of any scenes which have already been set up using the app.

The scene number matches the display order shown in the INGY App. As such, the first scene shown in the list on the INGY App is scene 0, the second is scene 1, the third is scene 2, and so on.

Scene Settings

Each lighting group supports 8 different scenes (numbered 0 - 7). These may have been previously set up using the INGY app. MobiusFlow will automatically query the level set point of each scene and will display this in the corresponding knownLevel resource. MobiusFlow can also be used to change each scene's level set point (0% - 100%) by setting that scene's corresponding setLevel resource.

It may be possible that the real-world scene setting levels or MobiusFlow have become out of synchronous. This could have been caused if they were changed by something that was not MobiusFlow, such the INGY app or INGY API. To ensure the real-world scene level settings do match the settings within MobiusFlow, set the resendSetLevelCommands (RID 83) to true. Note that MobiusFlow will immediately reset this back to false, whilst also resending the command to set the scene level settings of all scenes.

Changing Scene

MobiusFlow automatically queries which scene is currently being exhibited by the group, and shows this information in the knownScene resource.

Changing the currently exhibited scene on a given group is done in two steps:

1. Set the sceneSetting resource to scene number of the desired scene (if the resource currently shows the desired scene, this step can be skipped)

2. Set the send trigger to true (the service will automatically set this back to false immediately afterwards). This will cause MobiusFlow to command the INGY group to change to the desired scene.

Alternatively, these steps can be handled in one by using the INGY Set Scene flows node.

When configured, this node is pointed at an INGY group object, and will receive an input payload (0 - 7) representing the desired scene number. The node automatically handles the resource changes to cause the group to change scene.

Devices and Querying

MobiusFlow objects can added to represent real-world INGY devices. These objects are used to query and encapsulate the data coming from these devices in addition to control which group a given device is a member of.

Searching ingy in the objects library will display the list of options of MobiusFlow objects that can represent the real-world INGY devices.

Add these options in the correct quantities to represent the INGY devices within MobiusFlow.

Every INGY object type will require the entry of the INGY node address (wirepas address) as well some other information:

If knowing the current lighting level of any lighting device is required, ensure Auto Query Level is checked to ensure MobiusFlow automatically pulls current level data from this device.

INGY Partition

Some INGY nodes can be partitioned to act as separate controllable devices. Represent these partitions using multiple MobiusFlow objects with the same Node Address but different partition numbers. If the INGY node has not been partitioned, the partition number should be set to the default of 0.

Grouping

The known group membership of all devices is automatically queried by MobiusFlow and this data is stored into knownGroupMembership resource.

The group membership of a given device can be changed by setting the setGroup resource. The knownGroupMembership resource should reflect this change after a period of time.

Sometimes it may be required that the command to group a given INGY device needs to be re-sent. This often can occur if the device is offline when the original setGroup command is sent. In this situation, set the sendRegroup resource to true. Note that, MobiusFlow will immediately set this resource back to false whilst sending the regroup command.

Data

MobiusFlow will automatically pull all possible data from the known INGY nodes into corresponding MobiusFlow objects.

Direct interfacing with INGY API

Two flow nodes have been written to aid direct interfacing with the INGY API.

INGY Spy Node

The INGY Spy node is used to view all the Datastream and API messages coming from INGY gateway. This includes data sent out over the INGY gateway's datastream as well as directly viewing all API commands and responses.

The INGY spy node can be aimed to a given MobiusFlow INGY service within it's config, and set up with debug nodes as shown above. The two outputs map to the datastream and api respectively.

INGY Send API Command Node

The INGY send raw command node is used to send direct API command to the INGY API.

The node must be aimed at a specific MobiusFlow INGY service within the node's configuration.

The node takes input messages who's payload must be formatted to be a valid INGY API command as shown in the INGY API documentation. The response to this command will be outputted from the nodes output.

It is recommended a function is used to set the command body as shown in the example flow below:

In the above example the code in the function node is a as follows:

msg.payload = {
    version: 85,
    type: "volatile_partition",
    command: "QUERY_CAPABILITIES",
    destination: 'broadcast'
}
return msg;

Overview

You can add the LoRaWAN LNS Service (labelled as lorawan local network server) to the MobiusFlow from the service library.

The service requires the region to be set. If mulitple regions are required, using muliple LoRaWAN LNS services is neccessary.

Integrated Device Types

If a device is integrated, MobiusFlow will atomically handle the decoding of device data and the movement of this data into corresponding MobiusFlow objects (Uplink). Some devices also support downlink, i.e. sending data from MobiusFlow to the device. For integrated device types, if there is a public downlink encoder available, MobiusFlow will automatically handle the encoding and sending of data to devices of that type.

List of Integrated Device Types

The list will be populated soon. Please contact support for enquires about specific devices.

Unintegrated Device Types

All LoRaWAN devices intend to be integrated in future. To request integration of a new device type, please contact MobiusFlow support at [email protected].

Data can still be received from and sent to unintegrated device types, however the users must handle data decoding and encoding manually. A full explanation of working with unintegrated device types can be found in this section.

Supported Regions

Currently supported regions are shown in the following list:

• EU868

• US915_0

• US915_1

Support for all regions is planned for the near future. To request support for a specific region, please contact MobiusFlow support at [email protected].

Connecting a LoRaWAN Gateway to MobiusFlow

Adding the Gateway to MobiusFlow

LoRaWAN gateways are added as MobiusFlow objects to the LoRaWAN LNS service. When viewing the configuration of LoRaWAN LNS service, search for lorawan_gateway in the object library. A lorawan_gateway object (PID 028D) should be added for each physical LoRaWAN gateway MobiusFlow will connect to.

For each lorawan_gateway object, the 16 character (Hex) Gateway ID must be populated to match that of the ID of the physical LoRaWAN gateway. Ensure the object settings are saved. As with all MobiusFlow services, a stop/start cycle or hot reload must be performed if any settings are changed or objects are added or removed.

Setting up the Connection on the Gateway

Ensure the MobiusFlow is accessible by the LoRaWAN gateway, i.e. if MobiusFlow is running in the cloud, ensure the gateway has an internet connection. Alternatively, if MobiusFlow is running on-prem, ensure the LoRaWAN gateway has access to it over the local network.

The connection between LoRaWAN gateway and MobiusFlow uses Semtech UDP. Set up a Semtech UDP packet forwarder on each gateway with the following paramaters.

Hostname

Use the standard TCP/IP hostname of the gateway. If the gateway is running in the cloud and hosted by MobiusFlow, it will be in the form xxx.mobiusflow.io e.g. grand-eagle-11.mobiusflow.io. If MobiusFlow is being hosted on-prem or elsewhere, use the IP address of the host or DNS designation of the host. Do not include any protocol or a port in the hostname.

Port Number

The Semtech UDP packet forwarded allows both an inbound and outbound port to be specified in the configuration. Ensure the same port number is used for both inbound and outbound.

The exact port number depends on which region the gateway is operating in. See the table below for all port numbers by region.

Opening of Network Ports

Ensure the required ports are open on the gateway's network. Also ensure the required ports are open on the network where MobiusFlow is running. If the instance of MobiusFlow is hosted in the MobiusFlow cloud, the ports for all region types will be open by default.

Connecting a LoRaWAN Device

To add a device, when inside the LoRaWAN LNS Service's configuration, search for that device type in the objects library and add instance of it.

For each new object, the Device EUI and Device App Key (OTAA Key) must be populate to match that of the device.

Ensure the settings are saved. As with all MobiusFlow services, a stop/start cycle or hot reload must be performed if any settings are changed or objects are added or removed.

If the credentials are set correctly, the device is in range of the LoRaWAN gateway, and the LoRaWAN gateway is connected to MobiusFlow, live decoded data from the device will now appear within the new object's resources.

Downlink (Sending commands to a device)

The flows can be used to enqueue downlink messages to some device types. MobiusFlow is packaged with a set of MobiusFlow/LoRaWAN specific nodes designed to work with the LoRaWAN LNS service.

LoRaWAN Send Downlink Node

To enqueue downlink messages to device types that have been integrated with MobiusFlow, use the lorawan send downlink node type shown below.

This node will accept into its input an incoming unencoded payload as per how the manufacture's downlink encoder accepts the messages.

Inside the node's configuration allows specification of which device the downlink messages will be enqueued on. This is done by specifying the device's MobiusFlow URI which can either be pasted in or searched for.

The node's output will send messages informing the user of the result of the attempted downlink enqueue action.

Results include a success, a failure due to an incorrectly structured input payload (included in the error message is information regarding the correct payload structure), or failure due to this device type not supporting downlink all together.

Checking Enqueued Messages

The number of currently enqueued messages can be found for each device by viewing resource 21 of that object representing that device.

Example Flow

The following example uses an inject input to trigger the inital message. Then a function node formats to message's payload into the correct format for the device type. The lorawan send downlink node has been set to connect to a specific MobiusFlow object. The debug is used to monitor the output of the lorawan send downlink node so the user is informed if the action was a success or failure.

The contents of the function node using to format the payload is follows:

// this is an example
msg.payload = {
    config1: 0,
    config2: 3,
    mode: 'normal',
    action: 'open'
}
return msg;

Raw Downlink

For some device types, manufactures do not release downlink encoders, and as such it is not possible to integrate this functionality into MobiusFlow. It is however possible to write your own in the flows and then send this via the LoRaWAN LNS service to be enqueued directly to a LoRaWAN device. This is done using same basic flow as regular downlink however using the lorawan send raw node.

The lorawan send raw node bypasses helpers and checks provided by MobiusFlow objects. As such, the node's configuration requires the specification of a LoRaWAN device EUI instead of a MobiusFlow object's URI.

The node does not have an output. This is because it uses a 'fire-and-forget' style mechanism and therefore cannot monitor if the enqueue action was successful or not.

The message payload must be built inside the function node. The result of this encoding must be an object containing the required LoRaWAN fPort as well the data property. This data property contains the raw data that will be enqueued (hex bytes in string).

The contents of the above example function node are shown below.

// ensure payload contains fPort and data (hex bytes in string format)
msg.payload = {
    fPort: 0,
    data: '0C1A01230024',
    confirmed: true
}
return msg;

Using Unintegrated Device Types

Reading the sections on connecting a device and downlink are recommended before reading this section.

For unintegrated device types, that is device types that MobiusFlow does not feature inbuilt uplink decoders, downlink encoders and shaped MobiusFlow objects, the lorawan_generic_device object type can be used.

As with all LoRaWAN object, the device EUI and App Key must be set to match of the LoRaWAN device.

Uplink

To the object's configuration is set with the correct device EUI and App Key, data will be pulled into the MobiusFlow object as with all other LoRaWAN object types. Unlike these object types, the data will not be decoded and left a raw string in resource 40. The data can then be handled / post-processed by the user in the flows at will.

Downlink

Downlink is handled in the same manner as for integrated device types. If using the lorawan_send_downlink node, for the lorawan_generic_device object type, no checks are made regarding the format of the payload. As such, ensure the message is pre-encoded into an object containing the fPort and data (hex bytes as string) properties.

The lorawan_send_raw node can also be used as before, to enqueue downlink message to unintegrated device types.

LNS Backend (Chirpstack)

The MobiusFlow LNS Service uses Chirpstack V4 as an LNS backend. As such, for debugging purposes it is possible to log into this backend if required. Chirpstack runs on port 8081, to browse to this port to access chirpstack.

Every MobiusFlow LNS Service contains a statistics object. This includes some information about the health of the LNS as well as the chirpstack login credentials.

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

When using a wireless connection you need to enter the WiFi network's SSID (name) and password. You can click on the Scan WiFi Networks button to get a list of available WiFi networks

You can set a connection timeout in minutes. If the connector fails to connect to a network within this time it will reboot and try again

Select TCP/IP Mode

You can choose to use a DHCP server to allocate the connector an IP Address or set a static IP Address. If you choose to use a static IP Address a few more options will be shown. Set these according to your network

Save Settings

Once you have configured all network settings click the Save button

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

What You Will Need?

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

2. A compatible balenaCloud fleet (Up Board, Intel NUC or Raspberry Pi 4)

Deploying from balenaHub

Navigate to your and login in

Navigate to to select which version of MobiusFlow® to deploy

Navigate to the Apps page

Search for MobiusFlow

Select the correct device type

Click on the Deploy button

Balena will switch to your balenaCloud dashboard

You can create a new fleet here or deploy to an existing fleet. If creating a new fleet refer to the section for details on what settings are required

If you already have a new fleet or want to upgrade the MobiusFlow® version on existing devices, select Use an existing fleet instead

Select the fleet from the drop down and click on the Deploy to fleet button

After a few seconds you will see the new release being built for your fleet

This will take a minute or two. Once the build is complete you will see the release on the dashboard. All devices, which have not been pinned to a specific release, in your fleet will automatically start to update to the new release.

You can also view the release history in the Releases page of your fleet.

Click on a device Summary to see which release it is running. You can also pin device to specific releases on this screen

Technologies Referenced

This section outlines the major technologies reference in this training. Learning about this technologies is recommended.

MQTT

MQTT (Message Queuing Telemetry Transport) is a lightweight and efficient publish-subscribe messaging protocol, commonly used in IoT (Internet of Things) applications.

MQTT is widely used for data transport throughout the MobiusFlow software.

JSON

JSON (JavaScript Object Notation) is a lightweight data interchange format that is easy for humans to read and write, and easy for machines to parse and generate.

Learn how JSON works here.

A basic knowledge of JSON is required when using the Flows (logic engine) within MobiusFlow.

EnOcean

EnOcean is a short distance wireless communication protocol used widely within the IoT space. Each EnOcean device has a unique identifier (UID) which is used to identify the sender of all EnOcean wireless telegrams.

During this training, EnOcean will be used as an exemplar IoT technology to demonstrate MobiusFlow from the device level.

MobiusFlow Overview

Structure

A MobiusFlow instance runs a central MobiusFlow Hub. Services, each of which have a function within the overall solution, reside on the hub, and use it as a relay to communicate information.

A MobiusFlow object often represents a virtual equivalent of a real-world device, however can represent non-physical entities such as calculated data.

Some services can have MobiusFlow objects reside on them, often when the service needs to directly interact with those objects in some way. For example, objects representing EnOcean devices will always reside on an EnOcean devices service.

Points / Resources

A MobiusFlow object contains many resources, each being its own individual data stream representing something about that object.

Below shows a screenshot from the MobiusFlow software of the list of resources associated to an EnOcean Temperature / Humidity / C02 sensor.

A point is a chargeable resource. Notice in the above screenshot, the points column is only populated for Temperature, Humidity and CO2.

Also notice how the MobiusFlow software calculates your total point usage and displays this at the bottom right hand corner.

URIs

All parts of the MobiusFlow hierarchy are assigned a unique URI with the following structure:

HID/SID/PID/INS/RID

Example URIs

Service

Full example URI of a service:

000001/020

Representing service 020 on hub 000001.

Object

Full example URI of an object:

000001/020/0028/0001

Representing instance 0001 of object type (profile) 0028 on service 020 on hub 000001.

Resource

Full example URI of a resource:

000001/020/0028/0001/40

Representing resource 40 on instance 0001 of object type (profile) 0028 on service 020 on hub 000001.

Conclusion

Using the URI system, it is therefore possible to reference any component of a given MobiusFlow configuration.

Configuration Example

Example Overview

This aims to show how data taken from EnOcean sensors at a hardware level, is brought into and through the MobiusFlow system, and then presented in the form of a dashboard.

Project Schematic

The following shows a colorless project schematic representing lack of implementation. As the project is implemented, this diagram will be colored in so progress can easily shown.

Explanation of Services

MobiusFlow Configuration

MQTT Broker

Add and start MQTT Broker service:

Connector Service

Add connectors service, add a connector to the service, and finally start the service.

Add and start service:

Add a MobiusFlow connector object to the connectors service and configure:

EnOcean Devices Service

Add EnOcean Devices service, add EnOcean device objects to the service, and finally start the service.

Connecting Hardware

For full information on how to configure a MobiusFlow connector see here.

Service Status and Data

The status of all service can viewed. This is a helpful insight into the current state of the solution as well as aiding with diagnostics.

The data of any live object can viewed by navigating to that object and then clicking on resources.

Flows

Connecting the flows to the MobiusFlow engine, as well as the baseline principles of pulling into the flows is covered here.

Dashboard

In this example, the live state of the buttons on a 4-Rocker EnOcean switch is shown on a basic dashboard.

Using dashboard in the way illustrated can be as simple or as complex as required. Display widgets include graphs, charts and tables, as well input widgets such as switches, buttons, drop-downs and text inputs. Full documentation of the Flows dashboard can be found here.

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

Backup

rchitecture Overview

The ADFWeb HD67941-B2 DALI/MQTT bridge acts as a converter between MQTT and DALI protocols. The bridge connects to an MQTT broker via either ethernet or WiFi. The bridge acts as a DALI master and therefore the pair of DALI lines is run directly into it. This completes the DALI/MQTT connection.

MobiusFlow can be connected to the same MQTT broker as DALI/MQTT bridge, allowing the two the communicate via MQTT. This allows MobiusFlow achieve to two-way communication with a given DALI circuit, hence allowing control, querying and configuration to be achieved.

The overall architecture is shown in the diagram below.

Service - adfweb dali mqtt

A MobiusFlow service called 'adfweb dali mqtt' has been made to specifically to allow control, querying and configuration to be performed simply and easily from MobiusFlow. Each adfweb dali mqtt service connects to a single HD67941-B2, so if your application uses mutliple HD67941-B2 then multiple adfweb dali mqtt services should be used.

For some use cases that will be covered later in this article, MobiusFlow direct commands (DCMDs) can be used to control some functions of service. These DCMDs are sent via the MobiusFlow engine API most commonly from the Flows, however direct HTTP requests can also be used.

As such, a lower-level system architecture diagram looks as follows:

MQTT Broker

The MQTT broker can be run anywhere which is accessible over a network to both the HD67941-B2 and MobiusFlow. For ease, in most cases the MQTT broker is run within MobiusFlow itself. As such, the architecture diagram becomes the following:

HD67941-B2 Configuration

To configure the HD67941-B2, ADFWeb's documentation on HD67941-B should be followed . Use the instructions to get the HD67941-B2 to connect to your MQTT broker. To work with MobiusFlow correctly, specific MQTT settings must be set using the configurator tool.

Navigate to the the MQTT Set Topic menu:

MQTT Publish

Once on the MQTT Set Topic menu, navigate to the MQTT publish tab. Create a single entry the following settings:

Topic

Note that {MACID} should be replaced with the MAC ID of the HD67941-B2 you're using. For example:

Template

The template should be set to the following JSON string:

All remaining fields should be populated as shown in the screenshot below:

MQTT Subscribe

Navigate to the MQTT Subscribe tab.

Topic

The topic should be set as follows

As before, {MACID} should be replaced with the MAC ID of the HD67941-B2 you're using. For example:

The remainder of the row should be populated as shown in the screenshot below:

This completes the configuration required for MobiusFlow. Ensure all MQTT changes are saved before flashing the new configuration to the HD67941-B2.

Luminaires and Groups

Overview

Within MobiusFlow, a given DALI luminaire or DALI group is represented by an equivalent luminaire and group object. Both object types are designed to reside on the adfweb dali mqtt. This service is shown configured and running in the screenshot below.

The two object types are tabulated below.

A single instance of both of these objects is shown live on an adfweb dali mqtt service in the screenshot below. The screenshot also shows the configuration page for the luminaire object. A DALI short address should be entered to match that of a real-world DALI luminaire.

The configuration window of a group object is shown in the screenshot below. Similarly to a luminaire, a group address should be added to represent the group number of the DALI group this object will represent.

Control

Overview

Both Luminaire objects and Group objects feature a setPoint resource (rid: 41). To change the lighting level, this resource should be simply be set in the same manner as any other MobiusFlow resource.

In the case of the Luminaire object, a knowLevel resource is also present. This populated as a result of the the current level being queried. It exists because sometimes due to issues with the system, there may be a discrepancy between the demanded level and actual level.

Within a luminaire, a resource exists for each group, allowing you to choose which groups the luminaire is a member of.

The screenshot below partially shows the resource list for the luminaire object.

The group object is simpler. As querying the level of a whole group is not possible in DALI, no known level resource exists. As with the luminaire, the lighting level of the DALI group can be changed by setting the setPoint resource.

Flows Examples

Below is an example of a simple flow with two inject buttons, one to set the level to 95% and the other to 5%. The inject nodes are linked to a setResource node which setup to set the setPoint resource of a live DALI luminaire (resource 000001/020/027A/41).

A very similar flow is shown to change the level of a group between 80% and 10%. In this case the setResource has been set to set the setPoint resource of the DALI group (resource 000001/020/027B/0001/41.

A more typical use case may be to have the lights automatically controlled. As well as this, it may be required that groups and single luminaires may need to be controlled as one. In the below flow, an EnOcean PIR is linked to a 'local control' zone node, which is then linked both a setResource node linking to a single DALI luminaire, and a DALI group.

The local control node us used in this case to set time periods of when the lights should be at given levels. The config window for this node is shown below

Note that is node is included within the node-red-contrib-mobius-flow-lighting package and may not be included within your Flows palette by default. If this is the case, it can be instantly added using the palette manager.

Querying

Overview

The system has been setup to automatically query several key properties of all luminaires. These are as follows:

• Group Membership (returned as raw 2 byte, bit-array)

• Ballast Status

• Lamp failure status

• Lamp arc power status

• Power failure status

• Raw status (all status information returned as 1 byte, bit-array)

• Device Type

• Max lighting level

• Min lighting level

Each luminaire object has resources to store this data. These resources are populated automatically when information is received from the HD67941-B2 DALI/MQTT bridge.

The system also allows the user to perform some additional queries manually. The queries can be sent by sending the adfweb dali mqtt service a recognised MobiusFlow direct command (DCMD). These DCMDs can be sent directly using the MobiusFlow engine API or by using the DCMD node within the Flows. Ensure the DCMD is setup with a timeout time of at least 10,000ms. All queries use the DCMD command name:

Supported queries and their associated DCMD data are tabulated below:

In the above table, all payloads were shown for a target DALI luminaire with a DALI short address of 0, however this should be replaced with the DALI short address of whichever luminaire is the target of the query (0-63).

After sending the DCMD, if correct, you should receive a response. This response will be in the form of a raw byte. The DALI documentation should be used to interpret this data.

Flows Examples

Data that is automatically queried from all luminaires can be found in that luminaire's resource list.

In the example flow below, a resource COV node has been used to respond to the change of value of the lamp failure status (resource 54). This may be useful if actions need to be taken in such an event, e.g. notifying maintenance. A similar flow could be made to respond to the data from any of the resources.

In the case of special queries (queries which are not automatically run), as explained before, DCMDs should be sent. The flow below shows how this could be set up.

The function node labelled function 1, is used to set the correct DCMD data for the query. The configuration is shown below:

The DCMD node is setup as follows:

Note that the URI property should be set to target the adfweb dali mqtt service. In this case, the service id of the adfweb dali mqtt service is 020 and the hub id the MobiusFlow instance that service is running on is 000001, hence the target URI of 000001/020.

Configuration

Overview

Configuration is performed in the same manner as manual querying, using DCMDs to directly interface with adfweb dali mqtt service, sent either directly to the MobiusFlow engine API or using the Flows.

Ensure the DCMD is setup with a timeout time of at least 10,000ms. All queries use the DCMD command name:

Supported queries and their associated DCMD data are tabulated below:

In the above table, all data packets were shown for a target DALI luminaire with a DALI short address of 0, however this should be replaced with the DALI short address of whichever luminaire is the target of the query (0-63).

The level parameter should be varied to set the desired quantity accordingly.

The group property can be set to true if an entire DALI group is being configured at once. Note, in this case, the address property will represent the group number (0-15) instead of a DALI short address.

Flows Examples

The flow below shows how a DCMD node could be used to send configuration commands, in this case setting the maximum lighting level:

The node function node labelled function 4 is used to set the DCMD data. The configuration for this node is as follows:

The DCMD node is setup as follows:

Note that the URI property should be set to target the adfweb dali mqtt service. In this case, the service id of the adfweb dali mqtt service is 020 and the hub id the MobiusFlow instance that service is running on is 000001, hence the target URI of 000001/020.

Emergency Lights

Overview

A MobiusFlow object type has been created to represent DALI emergency lights. This object type contains resources to capture information regarding the status of the emergency light as well as test results. As with all other DALI object types, the DALI emergency light is designed to be a child of the adfweb dali mqtt service. It's details are tabulated below.

The screenshot below shows a DALI emergency light object within an adfweb dali mqtt.

Like all DALI objects, the DALI emergency object requires a DALI short address to be assigned to it:

Control & Querying

No automatic control or querying of DALI emergency lights is performed. As such, all interfacing is performed using MobiusFlow direct commands (DCMDs) sent to the adfweb dali mqtt service, either via the MobiusFlow engine API or using the Flows.

In case of queries, data received as a result of the query automatically populates the corresponding MobiusFlow object. The data is also returned to the user via the DCMD response as normal.

Ensure the DCMD is setup with a timeout time of at least 10,000ms. All queries use the DCMD command name:

Supported actions and their associated DCMD data are tabulated below:

In the above table, all data packets were shown for a target DALI emergency light with a DALI short address of 0, however this should be replaced with the DALI short address of whichever emergency light is the target of the action (0-63).

Flows Examples

The flows can be used to easily send DCMDs to the adfweb dali mqtt service to complete any desired actions. The flow below has been set to automatically query the potential failure mode on interval.

The function node labelled function 8 is used to set the DCMD data prior to the request. The configuration for the node is as follows:

The DCMD node is setup as follows:

Note that the URI property should be set to target the adfweb dali mqtt service. In this case, the service id of the adfweb dali mqtt service is 020 and the hub id the MobiusFlow instance that service is running on is 000001, hence the target URI of 000001/020.

Note that, no debug node is used here to display query results. This is because, in the case of DALI emergency lights, the data is auto-populated into the corresponding DALI emergency light object.