Loading...
Loading...
Loading...
Loading...
Article explaining how to use MobiusFlow INGY service. It is recommended you read this article in its entirety before using the MobiusFlow INGY integration.
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.
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.
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.
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.
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.
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 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.
Note that: If INGY groups have been pre-configured in the using the INGY App, ensure the group number matches that of group number displayed in the INGY App. See full section here.
Viewing the resources on an INGY group object shows:
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.
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.
Note that: If the INGY App has been used to pre-set up some scenes, MobiusFlow will still allow you to change these settings. As such, it as advised to adhere to a common source of truth, either configuring all scenes within the INGY App or within MobiusFlow.
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 my something that was not MobiusFlow, such the INGY app or 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.
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:
Set the sceneSetting resource to scene number of the desired scene (if the resource currently shows the desired scene, this step can be skipped)
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.
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.
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.
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 resent. This often can occur if the device is offline with 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.
MobiusFlow will automatically pull all possible data from the known INGY nodes into corresponding MobiusFlow objects.
Two flow nodes have been written to aid direct interfacing with the INGY API.
Note that all INGY flow nodes share the MobiusFlow connection configuration node. If this has not been created already, the node will prompt you to set up the connection between flows and MobiusFlow.
The INGY Spy node is used to view all the 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.
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 recomendded 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:
Technical Documentation of how to use LoRaWAN Local Network Server
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.
If muliple LoRaWAN LNS service are used on the same instance, both will use the same LNS backend.
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.
The list will be populated soon. Please contact support for enquires about specific devices.
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.
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.
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.
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.
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.
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.
It is critical the correct port i used. The gateway may still be able to connect if the incorrect port is used, however this will cause the LNS to confuse the region of this gateway causing further problems.
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.
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.
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.
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.
The number of currently enqueued messages can be found for each device by viewing resource 21 of that object representing that device.
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:
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.
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.
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 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.
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.
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.
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.
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.
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.
This sections covers how to send EnOcean telegrams using the MobiusFlow Connector hardware.
Note that, sending is only support for MobiusFlow Connectors running firmware version v3.2.0 or later. Downloads links to the firmware version can be found here.
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.
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.
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.
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.
This page covers how to use the ADFWeb HD67941-B2 DALI/MQTT converter with MobiusFlow. The article covers control, querying and configuration for both standard luminaires and emergency lights.
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.
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:
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:
Navigate to the the MQTT Set Topic menu:
Once on the MQTT Set Topic menu, navigate to the MQTT publish tab. Create a single entry the following settings:
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:
Navigate to the MQTT Subscribe tab.
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.
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.
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.
Note that, the group membership of all luminaires should be set via changing the default value of any group membership resource prior to starting the adfweb dali mqtt service. Do not make the mistake of changing the live value of these resources after the service has started. Although this will work, if the service is restarted, this group membership information will not be saved.
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.
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.
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.
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 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.
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.
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:
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).
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.
| Setting | Explanation |
|---|---|
| Region | Port |
|---|---|
| Property | Explanation |
|---|---|
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.
| Object | Profile ID (PID) | Name in MobiusFlow | Parent Service |
|---|
| Query Type | Example DCMD Data |
|---|
| Query Type | Example DCMD Data |
|---|
| Object | Profile ID (PID) | Name in MobiusFlow | Parent Service |
|---|
| Action | Example DCMD data |
|---|
MQTT Broker
The IP location of the MQTT broker (IP address, DNS name, or otherwise). For MQTT over TLS include mqtts:// prefix, otherwise, inclusion of protocol is not required.
MQTT Port
Run by INGY on 1883 by default.
MQTT Username (Datastream)
Found on INGY gateway configuration page.
MQTT Password (Datastream)
Found on INGY gateway configuration page.
MQTT Username (JSON API)
Found on INGY gateway configuration page.
MQTT Password (JSON API)
Found on INGY gateway configuration page.
INGY Firmware Version
85, 94, etc. To use mixed firmware versions, use multiple INGY services each with different firmware versions.
EU868
1700
US915_0
1701
US915_1
1702
connectorURI
The URI of the MobiusFlow Connector that will be used to transmit the EnOcean telegram.
rawData
An array of single-byte numbers containing the transmission data. The length of this array will depend on the telegram type.
DALI Luminaire | 027A | dali_Luminiaire_v2 | adfweb dali mqtt |
DALI Group | 027B | dali_group | adfweb dali mqtt |
DALI Emergency Light | 0259 | dali_emergency | adfweb dali mqtt |
Type
Command ID
Example Screenshot
ERP1
(EnOcean Radio Protocol 1- Fixed Length)
ENOCEAN_RADIO_ERP1
ERP1 VLD (EnOcean Radio Protocol 1 - Variable Length
ENOCEAN_RADIO_ERP1_VLD
MSC (Manufactuere Specific Commands)
ENOCEAN_RADIO_MSC
RMC (Remote Management Command)
ENOCEAN_RADIO_RMC
Query power up level |
Query system failure level |
Query fade time / rate |
Query power failure |
Query dtr content |
Set maximum allowed lighting level |
Set minimum allowed lighting level |
Set power up lighting level |
Set system failure level |
Set fade time |
Set fade rate |
Store current lighting level in dtr |
Rest |
Inhibit |
ReLight Inhibit |
Start function test |
Start duration test |
Stop test |
Reset function test done flag |
Reset duration test done flag |
Reset lamp time |
Store DTR as emergency level |
Store test delay time high byte |
Store test dalay time low byte |
Store function test interval |
Store duration test interval |
Store test execuation timeout |
Store prolong time |
Start indentification |
Query battery charge |
Query duration test result |
Query lamp operational time |
Query emergency mode |
Query failure mode |
Query emergency status |
