The same extension (DeviceExt and PointExt) can be used to receive commands from a third party.

The goal is to modify the value of a point using Niagara actions (set, override...). These commands are not applied directly to the document containing the value or the topic representing the point by modifying the "value" field. Indeed a command in Niagara is applied through an action that Niagara will try to push on the associated network and then read value in return to update the out slot.


In the example below, Niagara is trying to push the value through the proxy extension to the Modbus network. The out slot value will be updated once the drivers read the value of the point from the device


Inbound commands with connectors work the same. A "demand" for change is sent by the third party, an action is called (set, override..) and once the out value is updated, the extension will push back the updated value to the third party, so the third party can be certain the value was pushed on the field. Each connector implements its own way of creating this change request message but the concept is common.

The acknowledgment mechanism indicates that the message has been received in Niagara but does not confirm whether the change has been correctly applied or not.


Several options:


Payload default format


The control format of a point must follow a default template in which it is necessary to indicate at least :

           


The format of the message can be customized under certain conditions


Batch commands


MQTT-based connectors allow multiple commands to be sent in a single message. This allows, for example, to turn on the light in several rooms at the same time. This requires a special command sending format in which the point id is specified.

"points": {

    "$(pointId)": {

      "present_value": $(pointValue)

    }