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;

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.

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.

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 info@mobiusflow.com.

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 info@mobiusflow.com.

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.

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.

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

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.

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

Sending Data to EnOcean Devices