JENEsys integrations are based on drivers developed by Lynxspring and other NiagaraAX developers. Drivers are programs that allow other programs to interact with specified hardware devices. Our integration drivers are designed to discover devices and bring data into the JENE-PC series platforms where those points and devices are "normalized".
Lynxspring Business Partners have a plethora of drivers available for open systems, legacy systems and data transfer. In addition, there is a driver development kit allowing integrators to create their own drivers for one-off applications.
The Allen Bradley CIP Driver supports the devices as below:
1. AbLogix5 series.
2. PLC/SLC 5 series.
3. PLC/SLC 2 Series.
All the connection to the devices must go through via the CIP device such a 1756‐ENBT/A Ethernet
module or 1769‐L32E Ethernet port.
This driver is compliant with PHP version 8.10 protocol specifications, as published in the document “PHP version 8.10 Public Host Protocol Guidelines”, dated August 2000. The PHP driver will function on all AX platforms that support serial communications.
To use the NiagaraAX PHP driver, you must have a target Niagara AX host (JENE) that is licensed for “aaphp”. In addition, other device limits or proxy point limits may exist in your license.
The PUP driver is compliant with PUP version 8.35 protocol specifications, as published in the document PUP version 8.35 Public Unitary Protocol Guidelines1dated July 2005.
To use the NiagaraAX PUP driver, you must have a target NiagaraAX host (JENE) that is licensed with the “aapup” feature, as well as the “serial” feature. In addition, the “aapup” feature may have other device limits or proxy point limits.
The Andover AC256 driver was developed against the following AC256 systems; AC256, Firmware version 8.3; 1 Package Control Unit, Firmware version 3.3
The Andover AC256 driver has been field tested against the following AC256 systems; AC256, Firmware version 7.0; 3 IOU panels and 3 LCU panels
The ANDOVER AC256 driver will function on all NiagaraAX platforms that support serial RS-232 communications. NiagaraAX-3.1 or higher is required.
The Andover Infinity driver was developed against the following two Infinity systems:
The Andover Infinity driver has been field tested against the following Infinity systems:
The ANDOVER INFINITY driver will function on all NiagaraAX platforms that support serial RS-232 communications. NiagaraAX-3.2 or higher is required.
In all NiagaraAX releases of the BACnet driver, support is provided for more than one link layer type,using multiple “network ports” under the Bacnet network’s BacnetComm, Network child container. BACnet/IP is the typical and default network port (IpPort) included in a new Bacnet network, with other port types available (EthernetPort, MstpPort) in the bacnet palette. The MstpPort, for support of a BACnet MS/TP device trunk, requires a station hosted by a QNX-based JENE.
The Barber Coleman ASD Driver is used to communicate to ASD devices through a serial communication RS-485 port with NiagaraAX 3.4.xx or higher JENE-PC series platforms. The Barber Coleman ASD driver will integrate the Microzone II (Zone2), VAV (Flow 2), Lighting Interface Module (LIM), Micronet Integrator, Micronet VAV (MnFlow), Micronet Heat Pump/Fan Coil (Mnhpfc) and PEM controllers.
The Barber Coleman GCM driver is used to communicate specifically to GCM controllers over a serial communication RS-232 connection at 9600 baud.
The Carrier Communication/Comfort Network (CCN driver) provides the components necessary to integrate CCN devices and data into the Niagara environment. The CCN Driver is made up of three primary components: 1) The CCN Network; 2) The CCN Device and, 3) a collection of Niagara objects to “shadow” I/O and variables in the CCN network. This is a serial driver.
The CSI I/Net driver supports the CSI/TAC I/Net 7801X on a NiagaraAX 3.4.xx or higher QNX platform. Serial communication RS-232 port required.
The EIBnet/IP driver was written to be compliant with KNX specifications Volume 3: System Specifications, Part 8:EIBnet/IP version 1.0 (Draft Proposal). This driver implements an EIBnet/IP client that can access services and data in a KNX system via an EIBnet/IP server.
The purpose of the FlexSerial driver is to provide a generic serial driver that can be configured to communicate to a wide range of “simple” serial communicating devices. The driver allows the user to model the native device message structures. This includes message framing detail and message payload content. The message framing detail is pushed down to the low-level, send and receive processing threads, so that properly framed messages can be sent and received. Once messages have been defined, they can be assigned to request-response pairs that then, can be used in components that require communications to a device.
The Honeywell Cbus TCP driver is compatible with the controllers from the Excell 5000 family (XL50, XL80, XL100, XL500, XL600 and Zone Manager). Flexible sizing up to a maximum of 30 C-Bus devices per driver network. A LNX-30P controller loaded with the Honeywell C-Bus firmware must be used in conjunction with a JENE-PC series controller to allow for TCP connection to Honeywell C-Bus network.
Through ANSI C12.20-2010 testing and compliance, a JENEsys® JENE-PC6000 series controller with the JENEsys® Metron C1220.jar file conforms to the requirements in C12.20-2010 and C12.1-2008 standards. A JENEsys® controller or equivalent with the ANSI C12.20 NiagaraAX Module installed can now be used to accurately and reliably record and transmit critical electrical data from demand side applications to owners, energy managers, generators (utilities), curtailment service providers, and others that need accurate and timely revenue-grade data. With the installation of the ANSI C12.20 NiagaraAX Module in any NiagaraAX product, you can now achieve:
The Metasys N2OPEN Protocol was developed to support a wide variety of devices. Due to this wide variety of components, the many devices deviate slightly from the true N2OPEN standard. These variations can exist on the same network, but can occasionally cause communication issues. Listed below is a list of fully compliant, partially compliant, and untested devices with the N2 module.
Fully Compliant VMA 1400 Series, DX9100, XT9100, VMA 1410, VMA 1420, VAV, AHU, VND, TEC devices.
Partially Compliant VAV-11-1, AS-UNT 111-1 (rev F), VND (Danfoss VSD & FX controller), AS-MIG-201-0 (rev X) Integrator 4073 v6.00 and DX-9100 devices.
The Metasys N2OPEN Protocol was developed to support a wide variety of devices. Due to this wide variety of components, the many devices deviate slightly from the true N2OPEN standard. These variations can exist on the same network, but can occasionally cause communication issues.
Lonworks network management requires a “single owner” to perform and maintain an accurate database of things such as node address assignments, nv bindings, message services used, and a raft of other definitions. The Niagara lonworks driver supplies this network management capability, by default. Typically,
you engineer a LonNetwork with the station acting as the “network manager” for all Lonworks devices on that network.
The Modbus protocol defines a message structure and format used in communication transactions. Modbus devices communicate using a master-slave method, in which only the master device can initiate a communications transaction. There can be only one master device on a Modbus network—in most integrations (modbusAsync, modbusTcp), this is the JENE. All other devices must be Modbus slaves.
However, note that two “slave” Modbus drivers are also available, in which the station can act as a dumb slave (server), using modbusSlave or modbusTcpSlave components. Usage of these drivers is expected to be infrequent. However, basic Modbus principles remain the same.
McQuay’s MicroTech network architecture permits a “multi-level” approach, where the single “level 1” master controller (the OPM) can have multiple “level 2” controllers on a comm trunk, each of which may have one or more “level 3” controllers on a different comm trunk. Level 2 controllers can thus be both a “slave” (always, to the level 1 OPM) as well as a “master” to level 3 controllers. Each MicroTech controller has an “L2” and “L3” (level 2 and 3) address that reflects its network configuration.
In a NiagaraAX integration, this network topology is essentially “flattened” under a station’s McQuayNetwork, where the same type of McQuayDevice component represents each MicroTech device, regardless of its position in the McQuay network architecture. Additionally, a McQuayDevice component represents the OPM device itself. Distinction is simply the specified L2 and L3 address for each McQuayDevice component.
oBIX uses the standard NiagaraAX network architecture. oBIX client components are the station interface to oBIX objects in one or more oBIX servers. For example, real-time data is modeled using oBIX proxy points, which reside under an oBIXClient “device”, which in turn resides under an oBIXNetwork container in the station’s DriverContainer (Drivers).
NiagaraAX RobertShaw DMS driver to integrate Robertshaw DMS products. It features polling-type communications between the JENE-PC series controller running this Network and the attached DMS serial port.
Niagara Ax DMS Integration module provides a port for read/write access to a DMS system. Two physical connections are supported. It supports either a single DMS panel or a multi-DMS panel system (DMS panels networked together on a NIM or CC network). Typically, only one DMS network is used. In this case, the other JENE-PC series controller serial port can be used for DMS Operator Interface (OPRIF) access to the same DMS system.
The NiagaraAX Robertshaw Microsmart Driver provides the components necessary to integrate Microsmart controllers. The MsNetwork provides all the configuration parameters necessary to allow the driver to communicate with a network of Microsmart devices.
The OpenADR 2.0a Virtual End Node Client is an Automated Demand Response client that is certified for the OASIS OpenADR 2.0a Standard. The client allows for communication with an ADR Virtual Top Node (VTN) Server. The OpenADR 2.0a client consists of three parts; NiagaraAX Service that hosts the authentication information and event handler, OpenADR2AssetBoolean object which is an asset output block that is used to provide a way to determine output values for the event program, assets and event levels, and OpenADR2Meter object which provides feedback to the ADR server.
The OpenADR 2.0a client enables the NiagaraAX platform to become an OpenADR 2.0a compliant Virtual End Node (VEN) for a Virtual Top Node (VTN). Together with Niagara’s extensive connectivity to both open and proprietary Building Automation Systems, the OpenADR 2.0a driver enables a facility to enroll in an OpenADR 2.0 program and realize significant revenue potential.