The term “Jennic-based” device is used in NiagaraAX and Sedona Framework documentation to mean a device based on a Jennic micro-controller, with built-in 802.15.4 wireless connectivity, 6LoWPAN stack support, and the Sedona Framework Virtual Machine (VM). Typical devices are low density I/O modules, thermostats, or other application-specific devices, often installed in places where running communications wiring (back to the JACE) is deemed cost prohibitive.
From a Niagara integration viewpoint, there are two important categories of Jennic-based devices:
Continuously powered devices — Devices that are always powered, typically from some AC source. Unless noted otherwise, Jennic-based devices are assumed to be in this category.
Hibernating devices — Devices typically powered by a self-contained battery or batteries. These devices introduce some integration complexity. See Hibernating devices.
Additionally, it can be helpful to understand details on the underlying Jennic RF network. See About the Jennic RF network.
At the time of this document, Sedona Framework support for hibernating devices is not widely available. Therefore this section
does not apply to most installations. Other sections of this document that mention hibernating devices also note this. However,
the SedonaJen6lpNetwork driver in the NiagaraAX station is “ready” for such devices, in case this changes.
Some Jennic-based devices may be battery-powered, where the only power source is a self-contained battery (or batteries). To conserve battery life, such a device “hibernates” (sleeps) most of the time. At some periodic, configurable interval, the device “wakes up” and executes its routines, which include sending and receiving updates (as needed) on the wireless network. The device then immediately returns to hibernation, consuming almost no power.
While hibernating, the device is unreachable on the Jennic network. Here, the term “wireless” applies to both station communications and power wiring—as there is no power wiring to an external power source. Low power operation is essential to minimize the eventual need to replace these batteries.
To support hibernating device integration in Niagara, a special “sessionless” CHoPAN protocol (Compressed HTTP over Personal Area Network) is used for communications between the device and the JACE acting as the coordinator node. Associated are “Chopan client” components, configured and used in the device’s Sedona Framework app. In the station, each SedonaJen6lpDevice component includes a special “Chopan Virtual” gateway for building the necessary “Chopan points”.
More Chopan details are in other sections of this document, with complete details contained in the document Sedona Framework Chopan Usage.
Chopan is used in a Jennic-based hibernating device in solving these challenges:
In normal operation, a hibernating device is in hibernation most of the time, and thus a poor candidate for standard Sedona proxy points. Sedona proxy points should not be used for a hibernating device. Even if the device is configured as a Chopan server (which is not recommended), and proxy points are assigned to a tuning policy using Chopan “comm type”, most poll requests will go unanswered because the device is hibernating. This results in unanswered poll requests, retries, and polling timeouts. Thus, it can adversely affect point polling of other continuously powered devices.
Instead of proxy points, you use the “Chopan Virtual” gateway of a SedonaJen6lpDevice to model “Chopan points” in the device’s Sedona Framework app. Chopan points can be either Boolean or Numeric types, and read-only or writable. Additional Sedona Framework app programming is then required to “link in” Chopan points to other components in the app. In the Niagara station, standard control point “targets” can be made to “receive” writable points from the Sedona Framework app. Conversely, writable Niagara points can write to read-only Chopan points in the hibernating device.
For related details, see About the Chopan Virtual gateway.
In normal operation, the periodic “awake time” of a hibernating device is often a fraction of a second—again, to conserve precious battery power. However, sometimes a device needs to remain awake, for example when some change is needed in its Sedona Framework app, or if Sedona Framework provisioning (kit changes, backups, etc.) is required.
A Sox connection from Workbench is needed to perform such Sedona Framework operations. When you use Workbench to Sox connect to a hibernating device, the device automatically remains awake for the duration of that session. When you Sox disconnect from the device, it returns back to hibernation.
However, the normal “awake time” of a hibernating device is too short to set up a Sox connection. The device needs a way to “know” that a Sox connection is needed, so it can suspend hibernation for some period, to allow a Sox connection. To provide this, the SedonaJen6lpDevice component in the JACE station (that represents any Jennic-based device) has an available action “Request Maintenance Mode”.
For related details, see About maintenance mode.
Copyright © 2000-2014 Tridium Inc. All rights reserved.