IoT WEB

BACnet/WS is the web-interface of the DINGO software stack

Choosing an open and widely accepted standard is an absolute requirement when you select your IoT WEB interface.

Today BACnet/WS is probably the most advanced and most extensive web-service definition for IoT.

INTRODUCTION

The limitations of IoT become obvious as soon as one needs to integrate devices from various manufacturers into a single application or system.

In the IoT world, hundreds of incompatible protocols co-exist today. This makes the integration of data and services from various devices extremely complex and costly. In the Web of Things (WoT at the application level), any device can be accessed using standard Web protocols. Connecting heterogeneous devices to the Web makes the integration across systems and applications much simpler.

Wouldn’t it be great if any device could be easily integrated and consumed by any application, regardless of the networking protocols used by those devices? This is exactly what the DINGO software stack enables you to do. Its implementation of BACnet/WS is the key to the WoT. Any application from whatever vendor can easily access any "Thing" via a standard protocol; BACnet/WS.

However the world is not perfect. Not everybody is using BACnet/WS. There exist other less extensive standards which are very popular. MQTT is probably the best known. In some cases MQTT can be more appropriate to use than BACnet/WS. This is true in particular when dealing with connections that are only occasionally available and/or have low bandwidth. In such cases a Broker Server is needed to avoid losing data and commands when connection is lost to "a Thing" or a client. MQTT implements just such a Broker Server. Everything goes through this Broker Server via subscriptions and publications.

The DINGO software stack therefore implements a thin software module called MQTT2BACnet/WS which enables MQTT to access BACnet/WS transparently.

As BACnet/WS is extensive in nature (everything needed can be done), enabling another WoT standard 'X', is just a matter of adding another X2BACnet/WS.

For more details about DINGO software stack, click here...

BACnet/WS

As discussed above, IoT is unworkable without a WoT. DINGO software stack core WoT interface is an implementation of the BACnet/WS (Web Services) standard.

It does not matter where the application is located. Whether it is running locally on a DINGO BACKBONE or somewhere at the Internet is totally irrelevant, BACnet/WS will enable the application level access to "the Thing", wherever "that Thing" is located in the world.
What is even more beautiful is that it does not matter what "the Thing" is, a 1-Wire temperature sensor, an M-Bus electricity meter or whatever. From the application perspective it is just "another Thing" where "all Things" use a common application-level language.
This is so important when it comes to the big picture of WoT, that it cannot be emphasized strongly enough.

In developing DINGO, we have taken it another step further: All DINGO configuration, including peripheral manager, BACnet, APPs, etc. takes place via Restful Web Services based on BACnet/WS standard rules. Therefore any application wherever it is or whatever it is, has a homogenous access not only to "the Things" but also to all configuration parameters of the DINGO software stack.

For more details about DINGO BACnet/WS implementation refer to these links:

BACnet/IoT, section 4 here...
Software Development, section 2 here...
Try BACnet/IoT online here...

MQTT

As described above DINGO software stack implements the MQTT2BACnet/WS module to enable two features:

That a DINGO BACKBONE can subscribe to MQTT properties in a MQTT Broker Server. This opens up a whole world of information available on all the MQTT Broker servers "out there". So that for example, financial data can be brought into a DINGO BACKBONE to affect control parameters managed by BACnet, etc.
That MQTT clients can subscribe to property values in any BACnet network which has BACnet/WS enabled. A typical example would be a subscription to a temperature in a freezer-container in transport. Connection may be lost from time to time, but the subscribed value is updated to the subscriber immediately connection to the container-truck is reestablished.

The MQTT implementation is vital for IBM Watson IoT Platform™ support discussed below.

Gateway to IBM Watson IoT Platform™

The IBM Watson Internet of Things Platform is a fully managed, cloud-hosted service that makes it simple to derive value from Internet of Things (IoT) devices. When combined with the IBM Bluemix platform, Watson IoT Platform provides simple, but powerful application access to IoT devices and data. You can rapidly compose analytics applications, visualization dashboards, and mobile IoT apps. Create IoT applications that feed insights to your backend enterprise applications.

The go-iot.io BACnet to Watson gateway is implemented as a DINGO App in the DINGO software stack.

This gateway software is used to link BACnet object-properties to Watson MQTT topics. The gateway publishes values to Watson IoT Platform as well as it can receive commands from the Watson IoT Platform, like switching a binar-output, etc.

With this gateway you can do:

Publish change in property values to Watson IoT Platform. It supports BACnet Change Of Value (COV) service as well as BACnet polling if COVs are not available.
Receive "Write Property" and "Write Property Multiple" commands from Watson IoT Platform that are used to change value of commandable objects in a BACnet server. BACnet write-priorities are supported.
Passthrough BACnet/WS commands (see details in step5 below)
Reinitialize device (if BACnet server supports that service).

Note that with this gateway you an communicate with any BACnet device from any vendor in the BACnet network, which the gateway is running in.

Read more about IBM Watson IoT Platform here...
Read more about Bluemix IoT here... and here...

Some technical videos here... and documentation here...