BACnet/IoT

BACnet/WS brings BACnet™ to the world of IoT

BACnet™ is a standard communication protocol for Building Automation and Control Networks developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE).

Take advantage of BACnet™ in your IoT projects

INTRODUCTION

It is a common misunderstanding that BACnet only relates to Building Automation, when in fact BACnet is a fully blown device-to-device communication standard that defines Physical, DataLink, Network and Application layers of the ISO model. Most importantly it defines the Application layer - how devices communicate with each other on a network and in the 'outer world'. This is very important as it gives devices from different suppliers the capability to communicate intelligently with each other right from installation.

There is a selection of excellent BACnet introduction videos on Youtube. Feel free to watch all 8 videos, starting from here... (2 3 4 5 6 7 8)

BACnet/IoT is our implementation of the BACnet standard. We decided to implement it almost from scratch using C++ and high level POCO C++ library. That way we get the fastest, smallest footprint code without losing development speed. Most of BACnet/IoT is open source for our customers, helping to build up a community contributing to the software.

BACnet/IoT particularly addresses IoT needs. For example we decided at the beginning that we would implement the BACnet/WS (Web Services) part of the standard, even before that part of the standard was fully defined. This was to address the need to connect IoT devices to the Internet, securely in a standard manner without losing functionality. BACnet/WS is extremely comprehensive making it possible to perform any operation needed over the Internet. This is not true for other more simple standards like MQTT, though it can now easily be implemented as a subset of BACnet/WS, by implementing a MQTT-to-BACnet/WS software module.

BACnet/IoT takes specially into account IoT needs. For example we decided from the beginning that we would implement the BACnet/WS (Web Services) part of the standard, even before that part of the standard was fully defined. This was to address the need to connect IoT devices to the Internet, securely in a standard manner without loosing functionality. BACnet/WS is very comprehensive making it possible to perform whatever operation needed over the Internet. This is not true for other more simple standards like MQTT. Standards like MQTT can therefor easily be implemented as a subset of BACnet/WS. Actually we are doing so when this is written, by implementing a MQTT-to-BACnet/WS software module.

BACNET/IOT SERVER

BACnet/IoT Server is a one of a kind server; As its configuration is dynamic (configuration of objects, properties, gateways, etc.). It can be fully configured from DINGO MANAGER or another utility that uses the Restful Web Services for configuration. The server is also completely independent of origination of properties like "Present_Value". Those can come from Modbus devices, the GPIOs of DINGO, 1-Wire, I2C connected chip, PINGO device, etc. or even from a web service or database. Only a single handle into DINGO Peripheral Manager specifies the source of BACnet property value.

BACnet/IoT supports many BACnet object types, including:

Analog Input
Analog Output
Binary Input
Binary Output
Device
Program (in beta)
Pulse Converter
Schedule (in beta)
Trend Log
Trend Log Multiple (in beta)
...more coming soon

And these are some of the services supported:

Alarm & Event Services:
- Change of Value (COV) reporting
- Subscribe COV
File Access Services:
- Atomic Write File (in alpha)
Object Access Services:
- Create Object (in beta)
- Delete Object (in beta)
- Read Property
- Read Property Multiple
- Read Range
- Write Property
- Write Property Multiple
Remote Device Management Services:
- Reinitialize Device (in beta)
- Time Synchronization
- UTC Time Synchronization
- I have
- I am

The BACnet server has access to BACnet/IoT client meaning that it can easily perform service requests to other BACnet devices. This is important for example doing trend-logging from another device.

BACNET/IOT CLIENT

Our customers can of course select BACnet client products from any vendor. There is a large range of options in the market, ranging from simple free test-clients to advanced SCADA systems and server products.
Many simple test clients are free of charge and fun to play with. Such clients exist even for mobiles, for example bacmove.

BACnet/IoT supplies a BACnet Client library to be used with C++. This library is first and foremost intended for those needing to access BACnet servers directly with small footprint APPs written in C++ or those wishing to contribute to our open source BACnet Server/Client.

BACnet/IoT comes with many demo APPs that explain how to use this library.

BACNET/IOT WEB SERVICES

BACnet/IoT implements the cutting edge BACnet/WS part of the standard. This is very important for extending BACnet to the world of IoT.

The BACnet/WS module is a free standing software module. It only needs to be installed on one device (or computer) in the network of devices to be accessed from the LAN or WAN (the Internet). This module not only enables BACnet/WS access to our DINGO and WINGO products, but also to any other BACnet device on the network, from whatever vendor it is.

Key features are:

CRUD operations via simple POST-, GET-, PUT- and DELETE-requests.
Supports Change Of Value (COV) subscriptions by web socket push notifications.
Supports XML and JSON for structured data.
Supports plain text for primitive data.
Runs under HTTP and HTTPS.
Contains authorization - OAuth 2.0.

BACnet/WS is very easy to use. You are welcome to test it on our live demo BACnet network here...

BACNET/IOT VIRTUAL GATEWAY

A DINGO BACKBONE can manage a large number of sensors and actuators on many peripherals and buses. If all are configured in one flat structure as BACnet objects, maintenance and browsing becomes difficult.
Therefore we have introduced the BACnet/IoT Virtual Gateway, where BACnet objects can be grouped behind Virtual Gateways (VGs). A VG shows up as a BACnet-router with a unique network address.

A simple example is if managing hundreds of 1-Wire temperature sensors in a big building, they can be grouped behind 10 VGs, one for each storey.
In the same installation there might be 10 energy meters on Modbus which could be grouped behind the same VGs.

A special variant of the VG is the BACnet APDU-to-APDU gateway (A2AG). A2AGs are used to virtualize BACnet servers behind slow master/slave media like PINGO. Accessing those directly via BACnet requests, would be slow and cause timeouts in the requesting BACnet client.
To solve this problem an A2AG, has its values ready by intelligent polling, when requested by BACnet client. A similar thing happens when writing to a BACnet server. The A2AG returns immediately when a BACnet client writes to any BACnet object behind slow media, but afterwards the A2AG starts writing the value over the slow media as a background task. If that fails the value is rolled back in the A2AG BACnet object and it's Reliability property set to a fault value.

More about DINGO BACKBONE here...

BACNET/IOT OVER 6LOWPAN

Our family of WINGO sensors and actuators runs a native BACnet Server. This is a very small footprint variant of the BACnet/IoT server that is enabled to communicate on a 6LoWPAN network.

Fortunately the BACnet committee has recently published Addendum for supporting IPv6.
Read about it here...

6LoWPAN has many limitation. It is low bandwidth network (250/40/20 kbps). The payload in each packet is limited only 103 bytes. BACnet was originally designed for low bandwidth communication over RS485 networks. Therefore today it is the device communication standard that sends the most compact packets back and forth, utilizing the small payload space for 6LoWPAN in the best way possible. Compared to competing alternatives that mostly use XML or JSON strings, BACnet only needs a fraction of the bandwidth.
BACnet is therefore the ideal choice for 6LoWPAN.

More about WINGO here...