This document contains information on the wording that we use throughout our product suite. We mostly use the same terms in other languages as well to avoid confusion.

Software Components

BlueRange Admin App

Our iOS application that was previously named "BlueRange App" or "BlueRange Enrollment App". The reasoning behind the name change is, that it also allows calibration and some building setup and might also be used to diagnose problems. Also, we might introduce more Apps in the future which is why calling it "BlueRange App" would be too generic. In its short form, e.g. one the home screen of a smartphone, it can be called BlueRange Admin

BlueRange Server

Often also called Backend, this is the Software that we can install on premise or in the cloud.

BlueRange Portal 1.0

Our legacy management portal that can be accessed through a web browser.

BlueRange Portal 2.0

This is the current version of our portal with a focus on usability and productivity.

BlueRange Gateway WebUI

Our web interfaces provides, besides some parameters for monitoring, the possibilities to customize configurations. In addition to this, it can also be used to enroll the gateway in a network.

BlueRange MQTT Broker

As we have extended our MQTT broker with a special authentication plugin, so we prefix "BlueRange" to avoid confusion.

BlueRange OEM Kit

This is a package of software that we are going to deliver to our partners or to customers that pay us. We will also give them access to all of the open source parts that can be used in addition. Here are the parts:

  • FruityDeploy

  • Partner Source Distribution

  • FruityMesh Buildbox / CherrySim Buildbox / BlueRange Buildbox

BlueRange Open Source / Publicly Available Software

A number of our components are (or will be) open source or are at least publicly available, here is a list with their names:

  • FruityMap

  • FruityMesh

  • CherrySim

  • BlueRange iOS SDK / Android SDK / Smartphone SDKs

  • BlueRange Middleware

  • BlueRange Platform Docker Image


A number of other parts that did not fit the above categories:

  • BlueRange Website

Hardware Components (including software that runs on them)

BlueRange Device

The term BlueRange device or in marketing material BlueRange Ready device or a device that is BlueRange Ready covers all devices that we can manage with our platform. This means that we can enroll them, update their firmware, configure them, etc,…​ This covers all of our hardware such as the BlueRange Gateway, BlueRange Mesh Nodes or our BlueRange Tags. If these terms are used to describe a category, they should be written in lowercase letters. If they are used as a product name, they must be capitalized. The term BlueRange should always be written in camel case.

This is different from a 3rd Party Device. All of our BlueRange Ready devices come with a unique serial number that matches the format of all other BlueRange devices.

3rd Party Device

A 3rd Party Device is e.g. a Beacon running firmware from a different vendor. We might support tracking this Beacon through our Asset Tracking but it will most likely only have basic support: it cannot be updated, cannot be connected, automatically enrolled, etc,…​.

The device might have a product name such as Gira KNX Brightness Controller, Warema Blind XYZ, etc. after it is enrolled and the user can later rename it to Greenhouse brightness control or Office Light Shades.

BlueRange Gateway

Previously often called MeshGateway or Edgerouter, we now simply call it BlueRange Gateway or in short Gateway as it is not only a gateway for the mesh but also e.g. a gateway for KNX or BACnet.

When talking about its functionality, we can still say that it serves as a "mesh gateway" or as a "KNX gateway". Our product offering will be called e.g. BlueRange Gateway V4 for our next generation hardware. The exact name is not yet specified.

The software that runs on this hardware is simply called:

  • BlueRange Gateway OS

  • BlueRange Gateway Software

The BlueRange Gateway has a web server that can be accessed using any browser which is called Gateway WebUI while a second user interface is available under /system/portal/ which we call Gateway Console.

Our Gateway uses an integrated Bluetooth Low Energy device that we call Mesh Bridge which has most of the functionality that other Mesh Nodes have. Additionally, it can communicate with our Gateway. On some Gateways, the Mesh Bridge might be an external device such as a USB Dongle.

Mesh Node

Every device that runs on BlueRange Firmware or FruityMesh will now be called Mesh Node as all of these are interoperable and can be used to create a mesh network. These devices have previously been called e.g. SmartBeacon. A Mesh Node can be used to advertise iBeacon messages, collect sensor data, control a light fixture, etc,…​.

There are a number of devices that act as Mesh Nodes. Below is a list of some of them. These are also the names that these devices should have after they were enrolled:

  • Vossloh Multisensor XS

  • Waldmann YARA Luminaire

  • BlueRange Node E2 (sourced as a Minew E2)

  • Regent Lightpad Tuneable

  • Belparts Dynamx 6-Way Valve

The firmware parts running on a Mesh Node are called:

  • Fruityloader

  • BlueRange Firmware for our commercial firmware

  • FruityMesh for our open source firmware

Some Mesh Nodes can work in a special Leaf Node mode, but this is typically only a term that is important for developers.

BlueRange Tags / Tracking Tags / Sensor Tags

In contrast to a node we offer Tags. These cannot form the core structure of a mesh network but can send and receive data either through advertising messages or by temporarily connecting or being connected to the mesh. All of our Tracking Tags are trackable through our Asset Tracking but it is also possible to give them a fixed position through our platform. Some of them also have sensors and can report their measurements, these are called Sensor Tags. When just talking about a generic one, we call it BlueRange Tag or simply Tag.

Once a tag was given a fixed position it would be possible to call it a fixed Sensor Tag or if it is known to be moving and correctly configured for tracking, it would be a trackable Sensor Tag.

Most Tags are running on either our BlueRange Firmware or on FruityMesh. This allows us to automatically enroll, configure, track, update and monitor them. There are 3rd Party Tags that we also support for tracking in our platform, these do however have a very limited features as they are running on 3rd Party Firmware.

The different kind of Tags will show up in the platform with their product names such as:

  • BlueRange CO2 Tag

  • BlueRange Tag R1 (sourced as Ruuvi Tag)

  • BlueRange ePaper Tag

Platform Features

Our platform supports a number of features to serve different use-cases.

Asset Tracking

Our Asset Tracking offering can track Tags running on BlueRange Firmware or FruityMesh. Also, we are able to track Tags from 3rd party vendors. To do the tracking, it needs a number of Mesh Nodes installed at fixed positions in a building or outdoors. These can be Mesh Nodes that are only used for the purpose of tracking something or they could be built into smoke detectors, lamps, etc. to add additional functionality.

Once you glue a Tag to something that you want to keep track of and you have set up this Tag to be trackable, it is called Asset.

Asset Tracking also allows you to work with Geofences so you are able to evaluate whether a Tag or an Asset enters or exists a defined region.

Device Management

Our platform has a legacy of an MDM platform and is therefore the perfect fit to manage a multitude of different devices.

It provides functionality such as Enrollment, sometimes also called provisioning which is basically a term for adding new devices to the system while also letting the device know about the platform.

When working with Mesh Nodes, you will typically create a Network. A network consists of a number of Mesh Nodes and exactly one BlueRange Gateway to be functional.

The Network was previously known as a Site but has been renamed after we introduced our building structure.


Configuring advertising messages such as Eddystone or iBeacon formats for our Mesh Nodes is useful for integrating with other apps, running marketing campaigns, etc,…​.

Building Structure

It is possible, but not mandatory to manage Networks by using a building structure. A Building is composed of a number of Floors and it is possible to have multiple Networks on one Floor. A Floor allows you to position all the Devices on a floor plan that you can upload.

Also, it is possible to group devices in a hierarchy that contains Rooms and Zones.

Other Features

Our platform offers a lot of other features such as User Management, Device Groups, Multi Tenant Management, Monitoring e.g. through Notifications, Configurations, Actions, …​.

You will typically use a Rule to configure e.g. monitoring. You might for example get notified with an E-Mail once a Gateway or Mesh Node was not reachable for a certain time.

To schedule automatic updates on the other hand, you can use a Setting.

If you want something to happen immediately, such as turning on a lamp, you can do this by using an Action.

Internal Names

System Test

In order to deliver high quality software, we have to test a multitude of different hardware in one system to make sure that it is interoperable and that there are no bugs that occur on specific devices from one vendor.