Matrix Booking Sense 2.0 overview
This page covers the architecture and details of the hardware and service being utilised in the Matrix Booking Sense 2.0 component.
Contents
Overview
Matrix Booking Sense 2.0 is the second iteration of the Sense component offering, giving access to real-time occupancy and utilisation data for resources that are monitored by a growing variety of sensors.
In this update, we’re now able to leverage industry-standard gateway connectors and software to support additional sensors giving us the ability to collate more data points and a wider array of information. New attributes include integer values from sensors that are able to count the number of people in a room through to environmental sensors which can report on air quality, temperature, noise levels, and more. We’ll be able to augment the Sense analytics dashboards with these attributes if collated by the sensors installed.
In addition, the business rules applied for Sense 1.0 can now be associated with an organisation and location to provide you with the ability to configure Sense across your organisation in different ways specific to locations in your estate. There are also enhancements to the Sense 2.0 dashboards to allow a more granular utilisation calculation to be implemented that gives a higher degree of accuracy for different types of workspace settings.
Features | Sense 1.0 | Sense 2.0 |
|---|---|---|
Pressac PIR sensor compatibility | Yes | Yes |
Other sensor types | No | Yes |
Alternative data attributes | No | Yes |
Other sensor vendors | No | Yes |
Requirement for a GPD | Yes | No |
Dedicated support from IAconnects | No | Yes |
Multiple power options | No | Yes |
Connectivity options | No | Yes |
Self-provisioning connectors | No | Yes |
Connector failover | Yes | Yes |
Multi-location business rules | No | Yes |
Architecture
In the Sense 2.0 architecture, the goal is to deploy the necessary connectors to ensure sensor radio coverage in the designated area. These connectors will link up to a Matrix Booking Software-as-a-Service (SaaS) instance hosted on Amazon Web Services (AWS). This is where Mobiusflow will run. The connection will be established using MQTTS.
MobiusFlow connectors
The connector collects data from the sensors and sends the data to actuators via standard wireless sensor protocols, such as EnOcean and Workplace Occupancy. This data is sent securely to a MobiusFlow Gateway or MobiusFlow Virtual Cloud Gateway using the MQTT-based MobiusFlow Sensor Protocol.
Once the data has been received by a MobiusFlow Gateway, it’s decoded and the associated MobiusFlow object is updated with the latest sensor readings, which can be processed by the gateway. This all occurs in the Matrix Booking AWS instance.
The connectors are produced by Interface Devices Limited under a license from Mobiusflow – both of which are UK-based companies. These connectors are equipped with an ESP32 chip. The connectors have a variety of power options that have been described below.
Item | Description | Comments |
|---|---|---|
1 | Ethernet port and PoE Supply | |
2 | 5-24V DC screw terminals | |
3 | USB power | |
4 | Configuration button | Push and hold to enter config mode or factory reset. |
5 | Power OK indicator | Connector is powered. |
6 | 5-24V DC power OK | |
7 | USB power OK | |
8 | PoE power OK | |
9 | MobiusFlow® connected | Connected to MobiusFlow® gateway. |
10 | Network connected (upstream) | Network connection established. |
11 | Module present in slot 1 | |
12 | Module 1 activity | Flashes when module 1 sends or receives data. |
13 | Module present in slot 2 | |
14 | Module 2 activity | Flashes when module 2 sends or receives data. |
MobiusFlow gateways
The MobiusFlow software has been developed as an MQTT object bus that normalises all device data into standardised MobiusFlow objects. This allows interoperability between all devices either real or virtual in the field or the Cloud.
MobiusFlow enables actuators, sensors, and controllers to connect, control and communicate with each other and to the Cloud. This is so that IoT solutions using scalable monitoring, visualisation, and predictive analytics can provide valuable insights into your business and act upon them automatically.
MobiusFlow has been designed from the ground up as a microservice-based design with a simple but common set of API commands. All communication between microservices is performed using the MQTT protocol, ensuring that microservices 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 that initiates and facilitates communication between the microservices in a secure way. Microservices 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 microservices to communicate with the Hub over any transmission medium capable of transmitting binary data.
Each node is typically a standalone island that doesn’t require any connection to any other device 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’s based around the publish-subscribe pattern that’s ideal when multiple devices are sending data to a single end-point for logging. MQTT can be used when 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 the design time. MobiusFlow defines a protocol layer above MQTT that enables discovery of devices and services at runtime and then allows the 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.
To summarise:
A complete control and communications platform.
Microservice-based architecture.
Secure, open protocol based on MQTT.
Scalable to thousands of devices.
Platform and language independent.
Doesn’t depend on a network connection for local control.
Provides full discovery of nodes, objects and resources in all directions.
Publish-subscribe change of value notifications.
All sensor and actuator data is normalised from any source, such as OPC UA, BACnet, DALI, EnOcean, LoRaWAN, Analog, Digital, and more.
For more information, visit the MobiusFlow® website.
Migration
Sense 2.0 will be available from Q4 2023 and will be installed by default for any new installations. We’ll continue to support Sense 1.0 until the end of 2024. Migration from Sense 1.0 to Sense 2.0 can be done easily by replacing the Sense gateways with MobiousFlow connectors. Once replaced, you can add more sensor types to your infrastructure.
Security
Gateway
The Mobius Flow gateway doesn’t include an operating system. When in its operating mode, it can’t be accessed remotely or via wired access. The gateway offers a configuration mode that can be accessed by username and password authentication. This configuration mode is only available via a wired network connection. We recommend a VLAN with MAC address authentication to access the gateway to ensure its security.
Traffic
Sensor to Mobius Flow gateway isn’t encrypted and uses EnOcean Radio Protocol.
The gateways need access to the MQTT endpoint, which is project-specific, and will be supplied by our Matrix Sense team. The required port is 8883 and uses TLS. No other internet access is required.
Mobius Flow gateway to Mobius Flow Endpoint is encrypted with TLS1.2. The data at rest in the Matrix Booking infrastructure is encrypted.