This driver requires the UPM BACNETMSTP driver (PR #385) to be merged
first.
This module implements support for the Veris E50H2 and E50H5
BACnet Energy Meters.
From the datasheet: The E50H5 BACnet MS/TP DIN Rail Meter with
Data Logging combines exceptional performance and easy
installation to deliver a cost-effective solution for power
monitoring applications. Native serial communication via BACnet
MS/TP provides complete accessibility of all measurements to your
Building Automation System. The data logging capability protects
data in the event of a power failure. The E50H5 can be easily
installed on standard DIN rail, surface mounted or contained in
an optional NEMA 4 enclosure, as needed. The front-panel LCD
display makes device installation and setup easy and provides
local access to the full set of detailed measurements.
This module was developed using the upm::BACNETMSTP module, based
on libbacnet-stack 0.8.3. Both libbacnet 0.8.3 and the
upm::BACNETMSTP libraries must be present in order to build this
module. This driver was developed on the E50H5. The Trend Log
functionality is not currently supported.
The Binary Input Objects are also not supported as these are only
used for the Alarm bits which are already available from Analog
Input Object 52 as an alarm bitfield incorporating all of the
supported alarm indicators.
It was connected using an RS232->RS485 interface. You cannot use
the built in MCU TTL UART pins for accessing this device -- you
must use a full Serial RS232->RS485 or USB-RS485 interface
connected via USB.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
This driver is implemented as a singleton due to it's reliance on the
bacnet-stack implementation. This implementation does not currently
support multiple BACnet networks at the same time, though in the
future it might, depending on the future of bacnet-stack development.
The version of bacnet-stack used in developing this driver was 0.8.3.
This driver is not intended to be used directly by end users, rather
it is intended for UPM drivers supporting specific BACnet devices,
such as the Veris E50H5 Energy Meter.
Unfortunately, this means that a process can only support a single
RS-485 BACnet network, though you can support multiple devices on that
network.
No examples are provided. Please look at the E50HX driver for an
example of how to use this class in a BACnet MS/TP device driver if
you want to write one.
When initialized, the bacnet-stack library will attach to your RS-485
based BACnet network, and start a Master Finite State Machine (FSM) in
a separate thread. This thread will handle the details of token
passing and locating other Masters in the network (Poll For Master).
This driver will appear as a BACnet Master device on the BACnet
network, which supports only the required Device Object and any
required services (readProp) and Device Object properties.
When initializing the driver, it is important to select a Device
Object Instance ID that is unique on your BACnet network. This is the
unique identifier that will be used to identify your Master to the
rest of the BACnet network.
In addition, it may take some time after initialization before you
will be able to communicate on the network, as the first thing that
has to happen is that all Masters on the network need to be identified
(handled by the Master FSM) and a token needs to be received before
your Master can begin transmitting (making requests). This may take a
couple of minutes on a large network.
You can speed this process up by specifying a maxMaster (to
initMaster()) that is smaller than the default (127) -- but only if
you are CERTAIN that there are no masters with a MAC address higher
than the value you choose. If you fail to follow this rule, you may
introduce hard to identify token passing problems on the network for
yourself and other BACnet Masters.
Currently, this driver only supports the readProperty and
writeProperty requests to other BACnet devices. In addition, array
property reading and writing is not currently supported.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
Fixed a few small typos for handling node as well as a
small conditional for building PYTHON.
* Fixed some NODE_EXECUTABLE->NODEJS_EXECUTABLE instances
which must have been missed from a previous commit.
* Added a qualifier for python documentation so both
BUILDSWIGPYTHON AND BUILDSWIG must be set to add
dependencies for pydoc.
Signed-off-by: Noel Eck <noel.eck@intel.com>
Changed ${LIB_INSTALL_DIR} with lib, because the variable expands to
/usr/lib, making the install path /usr/usr/lib/node_modules, which
is incorrect. Now the install path is /usr/lib/node_modules.
Signed-off-by: Andrei Vasiliu <andrei.vasiliu@intel.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
Small change to get rid of a warning in newer cmake versions.
Versions of cmake (>= 3.0) throw a warning on the add_dependecy
method for non-existant dependencies (add_dependency call before
target_link_libraries call).
Removed the call to add_dependency since target_link_libraries should
provide the same functionality for ozw and modbus dependencies.
Signed-off-by: Noel Eck <noel.eck@intel.com>
This avoids using include files from a pre-existing UPM installation
as they can break the build if API changes are made.
Signed-off-by: Henry Bruce <henry.bruce@intel.com>
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
Use the same methodology as in mraa, by default build for python2, if requested
use python3 for everything
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Internal sensor onboard the Curie/Arduino101 can be accessed via Firmata using
this plugin. You will need mraa compiled with -DFIRMATA=ON for this to work and
be using Firmata with the CurieIMU firmata extension for ExtensibleFirmata
Signed-off-by: Ron Evans <ron@hybridgroup.com>
Signed-off-by: Justin Zemlyansky <jlstigman@live.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
This module implements support for the Veris H8035 and H8036 Energy
Meters.
The H8036 is similar to the H8035, but provides much more data.
The Enercept H8035/H8036 is an innovative three-phase networked
(Modbus RTU) power transducer that combines electronics and high
accuracy industrial grade CTs in a single package. The need for
external electrical enclosures is eliminated, greatly reducing
installation time and cost. Color-coordination between voltage leads
and CTs makes phase matching easy. Additionally, these transducers
automatically detect and compensate for phase reversal, eliminating
the concern of CT load orientation. Up to 63 Transducers can be
daisy-chained on a single RS-485 network.
This module was developed using libmodbus 3.1.2, and the H8035. The
H8036 has not been tested. libmodbus 3.1.2 must be present for this
module to build.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
The Bosch BMI160 is a 3-axis Accelerometer and Gyroscope.
Additionally it supports an external Magnetometer, accessed through
the BMI160's register interface. This driver was developed with a
BMI160 "Shuttle" board, which included a BMM150 Magnetometer.
The device is driven by either 1.8v or 3.3vdc. This driver
incorporates the Bosch BMI160 driver code at
https://github.com/BoschSensortec/BMI160_driver .
While not all of the functionality of this device is supported
initially, the inclusion of the Bosch driver in the source code
makes it possible to support whatever features are required that
the driver bosch driver itself can support.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
The Veris TEX00 temperature sensor family is made up of a series of
RTD thermistors in wall mount packaging.
This driver was developed using the TED00, which utilizes a 10K Ohm
Type 2 thermistor. However, this driver can support the other 12
variants of the TE series as well by providing the correct sensor type
to the class constructor. These other sensor types have not been
tested. Only the TED00 hardware was tested with this driver.
This sensor must be connected as part of a voltage divider, with the
balancing resistor ideally matched to the sensor's 25C detection
range. For the TED00 (10kt2), a 10K Ohm (1% tolerance) resistor was
used in a circuit like the following:
GND o----|TED00(10k2)|----o----|balanceResistor(10K)|----o VCC (+5vdc)
|
|
|----o A0 (analog input to MCU)
A 3.3vdc voltage can be used as well if desired.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
The driver adds support for the Veris TEAMS Temperature Transmitter.
It provides it's output via a 4-20ma current loop. The supported
temperature range is 10C to 35C.
This sensor was developed with a Cooking Hacks (Libelium)
4-channel 4-20ma Arduino interface shield. For this interface,
the receiver resistance (rResistor) was specified as 165.0
ohms.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>
The driver was developed using the Veris CWLSHTA CO2 Gas sensor. The
'T' variant supports a temperature sensor, and the 'H' variant
supports a humidity sensor.
All 3 signals are provided by the device as analog 0-5Vdc, 0-10Vdc, or
4-20ma loop current outputs. For devices supporting temperature, the
valid temperature range is 10C to 50C. The humidity ranges from 0% to
100% (non-condensing). The CO2 sensor ranges from 0 to 2000 ppm.
This driver was developed using the 5Vdc outputs and the 4-20ma
outputs. For voltage outputs, your MCU must be configured for 5V
operation. In addition, you must configure the sensor (via it's
configuration switches) to output 0-5VDC only. Using any other analog
reference voltage will require the appropriate external circuitry
(such as a voltage divider) in order to interface safely with your
MCU.
In addition, the sensor can be configured for 4-20ma usage, by
specifying the correct receiver resistance (in ohms) in the
constructor. This sensor was tested with a Cooking Hacks (Libelium)
4-channel 4-20ma Arduino interface shield. For this interface, the
receiver resistance was specified as 165.0 ohms.
Signed-off-by: Jon Trulson <jtrulson@ics.com>
Signed-off-by: Abhishek Malik <abhishek.malik@intel.com>