This document discusses using the BACnet protocol to remotely monitor and control devices over IP networks from handheld devices. BACnet allows communication with devices like HVAC systems, lighting systems, and industrial equipment. It describes two scenarios for accessing this functionality: through SMS/USSD commands, and through a smartphone app that uses XML requests. Both have advantages and disadvantages, such as the need to register services with multiple carriers for SMS access, while apps require development for different platforms and may use more data. The goal is to enable remote device access with minimal hardware investment using existing Internet and mobile infrastructure.

1. Remote monitor/control of devices over BACnet through handheld devices.
Overview of the protocol:
This section will cover the basic concept of BACnet over IP network, uses of the protocol, range of
devices that the protocol can be used to monitor/control.
BACnet is basically a communications protocol, used primarily for building automation and control
networks. This protocol can be used in systems designed to remotely control/monitor systems for
applications such as heating, ventilating, and air-conditioning control, lighting control, access control,
and fire detection systems and their associated equipment. These appliances may be any of industrial
(large boilers, engines, air and water flow valves, furnaces etc.), public infrastructural (hospitals, railways
stations, airports, stadiums etc.), or even user appliances (ACs, heaters, fridges etc.). The BACnet
protocol specifies 50 different objects.
BACnet works with IPv4 (and also IPv6, protocol evolving). This makes it deployable with common
operating systems like Windows and Linux. With Linux, portable embedded devices can be deployed
integrated on board or as enhancement.
In the above diagram, the appliances 2 to 6 are being monitored/controlled by appliance 1 which may
be a small application running over a PC.

2. Aim:
The aim of this presentation is to bring BACnet together with other internet and telecom technologies.
This is the technical side. For users’ perspective, the aim is to make BACnet protocol more near to
human and make remote monitoring/control of devices possible with existing infrastructure and devices
like cellphones and internet. This will mean no/minimal investment to hardware.
Technical overview and architecture:
This is a scenario where a user can remotely control/monitor a wide range of appliances through
sms/ussd or smart phone applications.

3. Scenario 1 – Through SMS/USSD:
The user will have to register through service provider using USSD, the way we register or query for
several services like - *123#, type BACnet and send it to 5566.
If user wants to know the status of device ID 4ad3 at a network with network ID 0eBAC98, the SMS to be
sent may look like:
STAT 4ad3 0eBAC98
And the response may look like:
Device 4ad3 at 0eBAC98 is active since 02/02/2012. 340 C, 2000 rpm.
The number 5546 should correspond to our BACnet service, which already should be registered with our
service provider. This means, we may need to register our service with every service provider so that
end user can access the service from any network.
Disadvantages:
The server will have to register with many service providers to enable users of all service providers this
service. Also, when the user travels to a different geographical region or country, there is no guarantee
of availability of service.
Scenario 2 – Through smart application:
The user will require a valid user ID/password. Once logged in, the application can query for devices
using XML/SOAP/REST messages. The appliance may have a local database of devices mapped with
device ID. An application may look like:

4. When data is required for user appliances, it may look like this:
A query by this appliance to the server may look like:
POST /InStock HTTP/1.1
Host: www.tuhincloud.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 157
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<soap:NetworkID>0eBAC98 </soap:networkID>
<soap:DeviceID>4ad3</soap:DeviceID>
</soap:Body>
</soap:Envelope>
This scenario is much robust when service availability with changing service provider or geography is
concerned.
Disadvantages/Issues with this scenario:
1) This will require different application for different handheld OS.
2) May require persistent connections.

5. Parallel Ideas:
http://www.automatedbuildings.com/news/nov03/articles/gipson/gipson.htm
http://www.modbusbacnet.com/ProductDetail.jsp?LISTID=80002C68-1297914298