Add ObixService

For each R2 station to be integrated, you open it in the JDE, open the Local Library and expand the tridiumx/obix jar, and copy and paste the ObixService into the station’s Services container. No further configuration of that service is needed; however, you must restart that station for it to become an “oBIX server.” R2 object data from the station is then immediately available from an AX station running the Obix driver.

Note you can quickly verify if an R2 station is operating as an oBIX server. Simply open a web browser connection to that station, using the syntax

http://<host>[:port]/obix

where <host> is IP address or hostname, and [:port] is optional (if omitted, assumed as 80).

For example: http://192.168.1.94/obix for a typically-configured station at that IP address,

or http://192.168.1.75:85/obix for a station running on httpPort 85 on a host at that IP address.

As shown in Figure 2, after you login with station credentials you see an HTML representation of the station’s oBIX lobby, including hyperlinks to traverse into the object tree structure.

Figure 2. Example browser connection to confirm R2 station oBIX server operation

Note R2 oBIX is server only. Client access of remote oBIX servers is unavailable—no R2 “shadow objects” exist to get remote oBIX data (e.g. from an AX station). This simplifies engineering on the R2 side.

For this reason, the Supervisor station’s “Exports” folder under its ObixNetwork is not used when integrating Niagara R2 stations as ObixClients. However, AX to R2 schedule exports are possible using a different method—see R2ObixClient R2 Schedule exports.

Additional R2 station engineering topics are explained in the following sections:

R2 ObixExport objects

Use of these objects is entirely optional. Many R2 to AX oBIX integrations have not used them, as standard AX Obix proxy points for these specific R2 object types provide “right click command access”, along with value and status. Use is necessary only to permit an “interstation control link”, from AX to the R2 station.

The three “export” objects in the tridiumx/obix jar are available if you want to allow “link control” writes from AX to R2 objects, for example to the “priorityArray” input of an AnalogOutput, BinaryOutput, or MultistateOutput object. In this case, you copy one of objects from the R2 tridiumx/obix jar and paste it into the station, linking its output into the priorityArray input of the R2 object being controlled.

If controlling an AnalogOutput, BinaryOutput, or MultistateOutput, another link is also required—from the statusOutput of the controlled object back to the “feedbackValue” input (fIn) of the export object.

Figure 3. Example ObixAnalogExport object copied into station for linking into AnalogOutput object

Figure 3 shows an example of both links, where an ObixAnalogExport object controls an AnalogOutput (“Damper1”).

Figure 4. ObixBinaryExport object copied into station for linking into BinaryOutput (BO) object

Figure 4 shows a similarly-linked ObixBinaryExport object used for linking into a BinaryOutput object, “BO_Load1”.

You can also use an export object to link to a “status” type input of an R2 object, for example an input on a Math object (“FloatStatusType”, using an ObixAnalogExport) or on a Logic object (“BooleanStatusType”, using an ObixBinaryExport object). In this case, you simply link the statusOutput (sOut) of the export object into the statusInput of the R2 object, and need not link the “feedbackValue” input of the export object.

Figure 5. ObixAnalogExport object copied into station for use as “statusInput” type value

Figure 5 shows an example where an ObixAnalogExport object is used for setpoint control of an R2 Loop object, linked into the Loop’s “sInSet” input.

For any R2 export object you use, you must set up several Config properties, described in the next section, R2 Obix Export object properties. Then in the AX station, you can “discover” this object within station’s ObixClient “lobby,” and add a writable Obix proxy point for it. This allows you to link other AX station logic into the proxy point, as well as invoke actions on that same point.

R2 Obix Export object properties

All three of the R2 Obix export object have these common properties, as found on tabs in their property sheet:

Status

On the Status tab of an Obix export object, find these read-only properties

lastWrite — The last value written by the oBIX Client.
lastWriteTimestamp — The time of the last client write.

Config

On the Config tab of an Obix export object, specify these values accordingly:

priority — The priority to be used for writing values at the prioritizedOutput (defaults to 16).
units (if ObixAnalogExport), or

activeInactiveText (if ObixBinaryExport), or

stateText (if ObixMultistateExport) — In any type of export object, set units, etc. to mirror the units for the linked input on the controlled R2 object.

An ObixAnalogExport object has these additional Config properties, described below (see Figure 6). Use of these “limit” type properties is optional.

highLimit — The maximum value that can be written by the oBIX client.
lowLimit — The minimum value that can be written by the oBIX client.
limitEnabled — If set to true, high and low limits are enforced on client writes (default is false).

Figure 6. Config properties for ObixAnalogExport, including “limit” type properties

Any “outside of limit” value that a client attempts write to the R2 object input is rejected, and the last “in-limit” value is retained. For related details on the AX side, see AnalogExport Limit Notes.

Engineering

On the Engineering tab of an ObixExport object, find these read-only properties

feedbackValue — If linked, the value returned for client read requests on this object.
prioritizedOutput — Value being written on this “pOut” output.
statusOutput — Value being written on this “sOut” output.