SedonaNetwork properties

Figure 13. SedonaNetwork property sheet


SedonaNetwork property sheet

Among common properties, the SedonaNetwork has the usual collection of Niagara driver status, health, and (ping) monitor properties that work in the standard way. For more details, refer to the NiagaraAX Driver Guide section “Network status properties” and “About Monitor”.

Other common properties include the typical container slots for Tuning Policies and a Poll Scheduler. Also the network has two available actions; for details see SedonaNetwork actions.

SedonaNetwork tuning policy notes

Proxy points of a SedonaDevice (under a SedonaNetwork) can be assigned to a specific tuning policy, by name. By default, starting in Sedona TXS-1.2, there are three differently-named tuning policies is in the network’s Tuning Policies container:

  • Default Policy — (Sox Event commType, preselected)

  • Sox Event — (Sox Event commType, fixed)

  • Sox Polled — (Sox Polled commType, fixed)

If needed you can also add additional tuning policies (duplicate, rename, modify properties) and assign to proxy points as needed. For general information about tuning policies and associated properties, see “About Tuning Policies” in the NiagaraAX Driver Guide.

By default, these tuning policies of a SedonaNetwork have the following characteristics:

  • The “Write On Start” and “Write On Enabled” properties have been modified to have a default value of false. This can help decrease network traffic, which may be critical with some devices.

  • Point poll frequency is specified in the tuning policy (similar to how it is done for the BACnet driver).

  • A “Comm Type” property specifies how Niagara attempts to update point values, where choices are:

    • Sox Event (default) — uses Sox to subscribe to points, where updates are sent via Sox event messages (similar to COV subscriptions in BACnet). See Sox Event considerations.

    • Sox Poll — uses Sox read messages to request point values.

Sox Event considerations

Although Sox event subscriptions provide efficiencies over normal (Sox Poll) polling from Niagara, be aware that the default “Sox Event” may be inappropriate for some proxy points. Exercise caution if the property has a rapidly changing value, or is a property of a component that has another property with a rapidly changing value. Note the other property does not have to be proxied to generate events on the proxied property.

Why? A proxy point assigned to a Sox Event tuning policy results in subscription updates triggered by any value change of any other “same type” property of that component (type is “runtime” or “config”). This can be a problem if a rapidly-changing property value results in constant event subscription updates, adding unnecessary messaging and possible message fragmentation issues.

For example, consider a proxy point created for the “out” slot of a UI (universal input) component in the Sedona Framework app. Although its value may appear relatively stable, another “raw” property of that component is constantly churning a new A/D (analog to digital) value. Each change results in a new Sox event message update containing all “realtime” property values of that component (the “out” and “raw” values, plus any other realtime property values). This can lead to message bottlenecks on the network, as well as in the Sedona Framework device. In this case, it would be much better to assign a tuning policy using “Sox Poll” for the proxy point for the UI’s “out” slot.

Typically, this consideration applies more to “runtime” properties of a Sedona component, and not “config” properties. Ideal proxy point candidates for tuning policies using “Sox Event” comm type are slowly-changing boolean property types, where the parent Sedona component does not have another property with a rapidly changing value.

SedonaNetwork poll scheduler notes

The single Poll Scheduler of a SedonaNetwork has the usual collection of properties. For general information about the poll scheduler, see “About poll components” in the NiagaraAX Driver Guide.

SedonaNetwork Comm Config

Comm Config in the SedonaNetwork properties specifies communication parameters for Sedona. These parameters affect polls and writes sent to SedonaDevices.

  • Retry Count — Number of times a failed message is retried before the transaction is abandoned, where the default value is 3.

  • Retry Time — Elapsed time before giving up on a message send attempt (default is 2 sec).

  • Session Linger Time — How long unused DASP sessions should be retained before being cleaned up (default=60 sec).

SedonaNetwork debug properties

Among SedonaNetwork properties are two useful for debug purposes. If enabled, and you have station logSetup (in spy) set to “trace” for both entries SedonaNetworkName and SedonaNetworkName.sox, this directs extra messaging to the station’s output (visible in platform Application Director):

  • Link Debug — For additional trace-level data in station output, useful in tracing the Sox traffic on top of the DASP (Datagram Authenticated Session Protocol) traffic. For example:

    1:46:29.529 PM│send0:127.0.0.01:r 72 02 00 07 01

    1:46:31:485 PM│rcvd:127.0.0.1:R 52 02 00 07 01 06 42 10 00 00

  • Transaction Debug — For additional trace-level data about Sox transaction management.

SedonaNetwork TimeSyncTrigger

Among SedonaNetwork properties is a “Time Sync Trigger” slot (TimeTrigger component), configurable to send periodic time synchronization messages to networked SedonaDevices. Such devices must support such time synchronization from the station, and be configured as “Time Sync Enabled”.

By default, the network’s Time Sync Trigger is configured for “Manual” trigger mode. No periodic time sync messages are sent until this is changed to either Daily or Interval (and appropriate ranges are set).

Each SedonaDevice has two related properties and a Sync Time action. For related details, see Niagara-to-Sedona device time synchronization.

Note the network also has a related action; see SedonaNetwork actions.