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”.
The 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:
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.
Proxy 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 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).
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.
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.
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.
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).
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.
Chopan 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.
Status 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.
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.
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.
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.
Jennic-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.
The 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.
Option 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.
Do 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
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)
This 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”).
These 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
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.
PAN 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
PAN 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
.
Pan 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).
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.
Copyright © 2000-2014 Tridium Inc. All rights reserved.