SedonaJen6lpNetwork properties

Among common properties, the SedonaJen6lpNetwork has the usual collection of Niagara driver status, health, and (ping) monitor properties. For general details, refer to the NiagaraAX Driver Guide section “Network status properties” and “About Monitor”.

Figure 33. SedonaJen6lpNetwork property sheet


SedonaJen6lpNetwork property sheet

NoteThe network’s Monitor mechanism, as well as the related “Ping” action on each child SedonaJen6lpDevice, is unique in that device communications are not used on a ping. Instead, the check is with the “Joined” status of the device in the JACE coordinator’s address map for the JenNet network. See these automatically-added entries by expanding the “Address Map” container slot in the property sheet of the SedonaJen6lpNetwork. For details, see SedonaJen6lpNetwork coordinator properties.

Other common properties include the typical container slots for Tuning Policies and a Poll Scheduler. A single “Ping” action is available on the network.

These sections provide more details on SedonaJen6lpNetwork properties:

SedonaJen6lpNetwork tuning policy notes

Proxy points of a SedonaJen6lpDevice (under a SedonaJen6lpNetwork) are 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 (Chopan commType, preselected)

  • Sox Event (Sox Event commType, fixed)

  • Sox Polled (Sox Polled, commType, fixed)

If needed, you can 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, tuning policies of SedonaJen6lpNetwork 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:

    • Chopan — (default) uses CHoPAN “GET” requests to retrieve point values. This provides efficiencies over other (Sox) comm types, by “batching” multiple reads into a single request.

      NoteProxy points using a tuning policy with the Chopan comm type will remain in fault unless the associated Jennic-based device has the chopan kit installed, and its Sedona Framework app is configured to be a Chopan server. For related details, see Chopan comm type considerations.

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

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

Chopan comm type considerations

Chopan is the most efficient “Comm Type” for a tuning policy, providing a device is configured as a Chopan server. Otherwise, you will need to assign a tuning policy using a comm type of either “Sox Poll” or “Sox Event” to a device’s proxy points. Of those two choices, “Sox Poll” is best for rapidly changing values—see Sox Event comm type considerations for details.

In the initial point discovery of a Jennic-based device, you can determine if the device supports CHoPAN message requests, by looking in the Sedona Point Manager’s “Discovered” pane (Figure 34).

Figure 34. Look for ChopanS(ervice) and child ChopanS(ervlet) under App’s services node


Look for ChopanS(ervice) and child ChopanS(ervlet) under App’s services node

Expand the app node then service node, and look for “ChopanS” with a child “ChopanS”, as shown in Figure 34 above. These represent the required ChopanService and ChopanServlet, respectively. If these components are not found, likely the device is not configured to support tuning policies using Chopan.

In this case, proxy points using a tuning policy with “Chopan” as comm type will remain in fault.

Sox Event comm type considerations

Although Chopan is typically the most efficient “Comm Type” for a tuning policy, it may be that a target Jennic-based device may not be configured to support it. If not, you must assign proxy points to a tuning policy using another comm types (Sox Event or Sox Poll).

Sox event subscriptions provide efficiencies over normal (Sox Poll) polling from Niagara. However, be aware that the “Sox Event” choice 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 that 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 uneccessary 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 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. Even more efficient would be “Chopan” (if supported by the device).

Typically, this Sox Event 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 boolean property types, where the parent Sedona component does not have another “like type” property with a rapidly changing value.

SedonaJen6lpNetwork poll scheduler notes

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

SedonaJen6lpNetwork Comm Config

Comm Config in the SedonaJen6lpNetwork properties specifies communication parameters for Sedona. These parameters affect polls and writes sent to Jennic-based devices.

  • 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 seconds).

  • Session Linger Time

    How long unused DASP sessions should be retained before being cleaned up (default is 60 seconds).

SedonaJen6lpNetwork Chopan Server

Chopan Server in the SedonaJen6lpNetwork properties contains properties to configure the CHoPAN server mechanism for this network in the JACE’s station. Networked Jennic-based devices can access station data via “Chopan points” in their apps, as client requests to this server. Chopan server operation is required if the network includes any hibernating[2] Jennic-based devices.

NoteChopan server operation requires the JACE’s jen6lp license feature to have attribute export=”true”.

  • Port

    UDP port that the JACE station monitors for CHoPAN client requests from networked devices. The default port is 1810.

  • Enabled

    Enables or disables (the default) the network’s Chopan server.

  • Debug On

    If enabled, and you have station logSetup (in spy) set to “trace” for SedonaJen6lpNetwork.chopanSvr, extra messaging is directed to the station’s output (visible in platform Application Director).

  • Status

    Status of station’s Chopan server, typically “ok” if enabled.

    NoteStatus is fault if the JACE’s license feature jen6lp does not have attribute export=”true”.

  • Fault Cause

    If the Chopan server has a fault status, this text string explains why.

SedonaJen6lpNetwork debug properties

Two SedonaJen6lpNetwork properties are useful if troubleshooting. If enabled, and you have station logSetup (in spy) set to “trace” for SedonaJen6lpNetworkName and SedonaJen6lpNetworkName.sox, this directs extra messaging to the station’s output (visible in platform Application Director):

  • Link Debug

    For additional trace-level data about 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.

SedonaJen6lpNetwork TimeSyncTrigger

Among SedonaJen6lpNetwork properties is a “Time Sync Trigger” slot (TimeTrigger component), configurable to send periodic time synchronization messages to networked SedonaJen6lpDevices. Such devices must support such time synchronization, 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 SedonaJen6lpDevice 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 SedonaJen6lpNetwork actions.

SedonaJen6lpNetwork coordinator properties

Among SedonaJen6lpNetwork properties are several that apply to the Jennic coordinator operation of the Sedona Jennic option card in the JACE controller:

  • Panid

    This PAN ID is a two-byte identifier from 0000 to ffff (in hexadecimal) that must be set to match the one in the Sedona Framework app of each Jennic-based device. The default Panid value is “defa”.

    For jobs that have multiple JACEs equipped with a Sedona Jennic option card, it is important to use a different PAN ID for each one (SedonaJen6lpNetwork).

  • Channel

    The Sedona Jennic option card for a JACE operates in the 2.4Ghz range, on one of 16 selectable channels. Channels are from 11 to 26. Many channels overlap channels used in 802.11 WiFi. To avoid interference from WiFi (in U.S. installations), recommended channels are 15, 20, 25, or 26.

    NoteJennic-based devices to be integrated typically have a “Channel Map” property in their Sedona Framework app (e.g. service.plat.rfChanMap) that specifies which of the 16 possible channels it searches (with “beacon” message) for the network coordinator. A best practice is to limit the value of this property to only the channel used by the JACE option card (to which the device will be networked).

    In jobs with multiple JACEs equipped with a Sedona Jennic option card, it is recommended to use unique channel assignments, if possible, so as not to share bandwidth.

  • Diag Level

    The level of Jennic/Sedona Framework-related debug messaging to include in the station’s standard output (in the platform Application Director view). The value of 0 (default) provides the smallest level. This is read as a bit field, where each bit in the field turns on a different set of debug.

    NoteThe station’s log level must have sedona.6lp and sedona.plat.jen6lp set to trace level in order for this property to have any effect. To minimize resource overhead, return log levels back to message level after debugging.

  • Radio Power Level

    This controls attenuation of the RF transmit power level of the coordinator, where the default (0) is highest power. Range is in db, from minimum (-31) to maximum (0).

    In most cases, radio power level is best left at default. If desired, you can set to lower power levels to “simulate” devices that are farther apart or have poor RF connectivity.

  • Firmware Version

    The firmware version level of the Sedona Jennic option card installed in the JACE.

    NoteOption card firmware is automatically installed the first time a station starts up with a new or upgraded platJen6lp module. Typically this adds about 30 seconds to the station startup process.

    CautionDo not remove power to the JACE during this initial station startup process, for example following an upgrade of software that includes the platJen6lp module. Otherwise, it could be possible for the option card to lose important data.

  • Enable Ipv4 Mapping

    Enables mapping of IPv6 addresses of devices to IPv4 decimal addresses (default is true).

  • Address Map

    Figure 35. Example Address Map entries after enabling network


    Example Address Map entries after enabling network

    Container to specify the IPv4 address network “base” as well as hold entries for discovered nodes:

    • Ipv4 Address Base

      Private IPv4 subnet for the JACE coordinator to map discovered wireless Jennic-based devices. This subnet must fall within the Class A, B, or C address range, as follows:

      • 10.0.0.0 to 10.255.255.0 (Class A)

      • 172.16.0.0 to 172.31.255.0 (Class B)

      • 192.168.0.0 to 192.168.255.0 (Class C)

      NoteThis must be a different IP subnet than the one used by the JACE. Otherwise, the JACE TCP/IP stack will be unable to route packets appropriately. Also, this must be an unused subnet on the domain. For example, if the domain uses the 192.168.1.0 subnet, the default Ipv4 Address Base should not be used. Use a subnet not utilized, say 10.10.8.0, or 172.16.1.0.

    • entry1-n

      Automatically added entries for Jennic-based devices discovered by the JACE coordinator. As new wireless devices are discovered, they are assigned the next available IP address. The first address (n.n.n.0) is reserved for the coordinator.

      Each of these dynamic entries has the following read-only properties:

      • Ipv4 — Mapped IPv4 address for the device, which is used as its Address when discovered and added as a SedonaJen6lpDevice in the network.

      • Mac154 — The unique 802.15.4 64-bit (8 byte) MAC address of the device, in hexadecimal notation, for example: 00158d00:000f86b1

      • Joined — Current “JenNet” status with the JACE coordinator, where “true” reflects “ok” device status, else “false” means no communications (device seen as “down”).

      NoteThese dynamic entries persist until cleared. Note a “Clear Table” action is available on the Address Map container, which clears all dynamic entries—potentially useful if “starting over” with a new address base.

  • Coord Address

    The unique 802.15.4 MAC address of the Sedona Jennic option card (JACE coordinator), in hexadecimal notation without leading zeroes, for example: 158d00:9b50b

SedonaJen6lpNetwork Pan Info properties

Among SedonaJen6lpNetwork properties are several applicable to JenNet “PAN info” for networked wireless devices, including link quality and statistical data. This data, along with data from child devices operating as router nodes, is used in the network’s graphical Pan Sheet view.

NotePAN info requires each router-capable device to have the paninfo kit. If PAN info is to be read by CHoPAN, the device also requires the chopan and paninfoChopan kits. Some minor app configuration is required. Devices that are not router-capable do not require any configuration. Please refer to the “PAN Info Quick Steps” section in the Jennic Network Visualization (Pan Sheet) - Engineering Notes document.

SedonaJen6lpNetwork Pan Info properties include:

  • Pan Info Load Time

    Timestamp of last successful load of PAN info.

  • Child Pan Info

    Container component for dynamically-added SedonaJen6lpNeighborEntry (MAC802.15.4MacAddress) child components, described below.

    • MAC802.15.4MacAddress LQI n (for example, MAC00158d00_00117f0f LQI 174)

      Contains read-only data about each direct child node under the JACE coordinator, including:

      • Is Sleeping End Device — Whether device is a battery powered (hibernating) end device type (true) or a continuously powered device (false).

      • Link Quality — Value between 0-255, representing strength of last packet received from this node. Values over 60 represent a good link. Also known as “LQI” (Link Quality Index).

      • Packets Lost — Number of packets sent to device for which an ack(nowledgement) was not received. Note an ack is not expected on all packets.

      • Packets Sent — Number of packets sent to device from coordinator.

      • Packets Received — Number of packets coordinator has received from device.

      • Mac154 — The unique 802.15.4 MAC address of the device, in hexadecimal notation without leading zeroes, for example: 158d00:9b017

      • Stale — Typically false, else true if this node entry is stale, meaning the device represented is no longer a child. For example, if a device resets and rejoins the JenNet network, it may have a new parent (say a router node). In this case, this Stale values shows true.

  • Pan Info Poller

    NotePAN info polling may be useful for debugging or understanding the network topology, but increases network traffic.

    Contains configuration and read-only status properties for the “PAN info polling” mechanism that retrieves JenNet PAN info data from child Jennic-based devices on the SedonaJen6lpNetwork.

    • Enabled

      Enables PAN info polling if true, else if false (the default) disables polling.

    • Use Chopan

      Whether CHoPAN is used for PAN info polling (the default, true) or if false, Sox messaging is used for PAN info polling.

    • Desired Poll Period

      Desired PAN info poll period between each device, in hours, minutes, seconds. Default is minutely, that is 00000h 01m 00s. Note this varies from the “standard” poll scheduler in drivers, where the poll period is the time to complete the entire poll cycle (all devices). See the “Actual Poll Period” property for statistics on the entire poll time.

    • Statistics Start

      Read-only timestamp of the start of all accumulated PAN info statistics.

    • Node Count

      Read-only count of both the “current” nodes and “average” nodes with polled PAN info.

    • Average Node Poll Time

      Time in milliseconds for average polled node.

    • Inter Node Delay

      Time in seconds between PAN info polling one device to another device.

    • Busy Time

      Percentage of PAN info polling time to total uptime of network.

    • Actual Poll Period

      Average time for PAN info polling to complete once for all devices.

    • Debug

      If set to true enables debug of PAN info polling; the default is false.

NotePan Info Poller has three available actions, described as follows:

  • Enable — set the Enabled property to true.

  • Disable — set the Enabled property to false.

  • Reset Statistics — reset Pan Info Poller statistics (as above, including Statistics Start, Average Node Poll Time, Inter Node Delay, and so on).

SedonaJen6lpNetwork Network Steady State Time property

Among SedonaJen6lpNetwork properties is this one, found near the bottom of the property sheet:

  • Network Steady State Time

    Allows specifying the time after station startup (say from a reboot) before the Sedona Jennic network is considered in a “steady state”. Until this timer expires, various service threads do not run, including device ping monitor, proxy point polling, PAN info polling, and automatic writes to proxy points (such as from tuning policy rules like “Write On Start” and “Write On Up”). This allows all devices to join the 6LoWPAN network before initiating application-level communications.

    The default time is 1 minute (00000h 01m 00s). In cases of large and/or “deep” networks, adjusting upwards may prevent “write fault” or similar errors from occurring just after station startup.



[2] Currently, Sedona Framework support for hibernating devices is not widely available. Therefore, use of the JACE Chopan server is not typically required.