Using a FieldServer to read data off an API and then serve it as BACnet/IP
Click here to view the Case
Study.
Please CONTACT
US if you have any questions
OVERVIEW
A customer came to Chipkin through our website's contact us page with an integration project for six schools in California. In those schools, the client had a total of 120+ thermometers (in various buildings on campus) installed. Each of these thermometers reported data points such as temperature, setpoint (present value), schedule, etc.
The thermostats were installed by Pelican Wireless. The data from those devices is continuously sent to a base station, wirelessly. From there, the base station sends the data, again, wirelessly, to a Pelican online API. This API allows the thermostat's data to be read anywhere that has an internet connection.
The customer's main goal was to be able to poll the data from the thermostats and to have the ability to read, write, and monitor all thermostats from a centralized Building Management System (BMS).
Unfortunately, the BMS could only communicate with BACnet IP and the Pelican API could not communicate with that protocol.
The Solution That Chipkin Proposed
To solve this problem, Chipkin suggested using a FieldServer (QuickServer) which could read the values from the Pelican API (over HTTP) and serve them over BACnet/IP locally. Since the local BACnet Network is connected to the BMS, it would allow the BMS to Connect to the Pelican API.
To achieve this, Chipkin would develop a new custom driver for the FieldServer QuickServer to facilitate communication between the two systems: web HTTP & BACnet/IP.
Challenges Chipkin Faced
One of the main challenges we faced was that certain points read from the API contained words (strings) instead of values. The QuickServer is unable to read/serve string values. The points that contained the string values were system run status, fan, and schedule. The strings coming from the API for these points were either "On," "Off," or "Auto."
Chipkin overcame this by assigning numerical values to these strings for the QuickServer to read properly. For example, when the API sent the word "On" we translated that string to be the value of '1', "Off" was given the value of '2' and "Auto" became '3'.
Also, if one of these values was written to the QuickServer, Chipkin would translate the value back to a string and then sent the string back to the API.
The second challenge Chipkin faced was the large number of data points that needed to be read/served within the QuickServer. The integration required a unique configuration file written by Chipkin on a scale that could handle many points across six different schools with 120+ thermostats. Knowing the FieldServer Platform to the source code level, Chipkin was able to generate a configuration file of this magnitude, while others may have struggled or simply would not have been able to make such a file.
Customer Advantages from using Chipkin Automation Systems
Chipkin Automation Systems is an expert in the field of protocol-to-protocol communications. We were equipped to understand the customer's needs from day one. Since our inception in the year 2000, we have been instrumental in helping clients with their building integration projects.
We are experts in BACnet, REST API, FieldServer, and data communication – which meant we were able to assure our customer that we could do the project and solve any challenges that could arise.
Keywords
HTTP, Rest API, SOAP, BMS, BACnet, Modbus, Gateway Conversion, Translation, School Districts, Temperature, Thermostats, Setpoints.
About Us
Chipkin™ is a building and industrial automation protocol expert. We develop, configure, install, and support gateways (protocol converters), data loggers and remote monitoring and control applications.