Airoverse API's Overview

5 Minute Read

| The Need for Interoperability

With various OEMs and Integrators present in a Building space, having all BIS/BMS systems to be integrated under common dashboards or grouped for monitoring is not an easy task, adding to this complexity each OEM/Integrator uses its format of data and own interpretation that is maintained, having a standard simple way to extract only the data needed from one system and integrate this data into another OEM/Integrator's system will allow for various functioning and operation. It also allows various BMS/BIS systems to co-exist in a single building paving the way to interoperability.

| Airoverse API

The External APIs are quite similar to the project haystack reference API implementation.

The Haystack API allows software applications and devices to communicate using an open protocol, designed around exchanging data by querying based on Haystack tags. (For the developers).

For more information on Haystack refer to Project Haystack

Airoverse CCU APIs allow external partners and developers to integrate with the Airoverse system data. 

A simple REST mechanism to exchange Haystack-tagged data over HTTP or HTTPS. 

| API External Exposure

Airoverse APIs exposed to external use are extremely Simple and Haystack driven 

Airoverse REST-like JSON API is as simple as possible, ensuring that the API endpoints are in the same format as the haystack server used by the Haystack Community. 

OEMs/Manufacturers use the Haystack topology and taxonomy to generate and store data in an easy format for all BMS community of users to read and understand easily.  

For other haystack users to connect their applications with Airoverse-generated data for further integration with device data, Airoverse-exposed API service endpoints need to be programmatically used with haystack operations like reading, point write, filter, and many more.  

This enables a wide variety of functionality, features, and a vibrant community for data exchange for interconnecting things. 

When two systems speak Haystack, integrators can connect over APIs easily for them to “just work” seamlessly for providing a single pane of dashboards, control from their application, and trending from their application using Airoverse data.  

Note: It is the responsibility of the API consumer to refer to Haystack entities and points by referring to the Site explorer tool using the credentials created for a developer in the Airoverse for Facilities Portal. 

| Advantages

• Very Secure.
• An open API is based on modern web standards and uses OAuth 2.0.
• Extremely Simple and Haystack driven.
• REST-like JSON API, as simple as possible 
• Can be used to build any internal Airoverse app
• Can do everything we(Airoverse) can do. 
• Very well Documented and up to date
• APIs are live and Active
• Over 16 million API processed in a month. 

The Airoverse solution easily integrates into any 3rd party Web service via our haystack-compliant application programming interface.  

• This is useful where partners like utilities, REITs, and ESCOs would like  
  • real-time data feeds  
  • machine learning data for their learning models or compliance tools.  
• This would also apply to customers who might integrate Airoverse into their employee engagement apps or reporting dashboards. 
• This also helps us to further deepen our analytics based on Customer needs. 

Note: It is the responsibility of the API consumer to ensure that the Haystack entities and objects are properly handled by the caller's implementation. 

| Airoverse External API Access 

Below is an illustration of the Airoverse external API access.

Airoverse APIs will act as the entry point to all server architectures, which forms the basis of inter-component communication across systems. 

A very well-designed, implemented, and versioned API will ensure maintenance of current, large-scale software platforms becomes easy, without a very large technical support team. This detailed documentation for the Airoverse platform's APIs is to ensure that.  

• The platform integrations are less prone to defects.
• Integrations are not difficult but made easy so that both internal and external developers are not frustrated. 
• To ensure that external stakeholders do not misunderstand  
• To ensure that external stakeholders do not underestimate the value of this integration platform. 

| Airoverse External API Capabilities 

Airoverse API (Application Programming Interface) endpoints are interfaces that provide an external or internal program with a connection point to interact with the Airoverse system, to retrieve and/or change the haystack data or any other equipment data within it. Airoverse “web APIs”; that is, APIs provided over the HTTPS protocol for haystack-based data made available for integrators. 

The APIs will enable integration developers to 

• Retrieve site-level Information.
• Retrieve all zone data for a site.
• Retrieve all points generated by any equipment on a Site. 
• Retrieve all entities that have a set of tags in a Site 
• Retrieve all entities filtered by tags in a Site 
• Retrieve all vacations and schedules in a Site 
• Retrieve data of a particular point if the ID of the point is known 
• Retrieve the current value of a historized or writable point if the ID of the point is known 
• Poll a range of data for a date range for any historized point in the Site 
• Write a value to a point that is writable into the system if the ID of the point is known

The Airoverse API provides an HTTP-based interface for control and access to the Airoverse Platform data. Integrators will be allowed to read, update and poll information about their Site data. Airoverse aims to be backward compatible with previous versions of the API and to protect implementations from breaking when new features or changes are implemented. The API also strives to be self-documenting, easy to understand, and use. 

| JSON Notation 

JSON notation is used for the serialization of request/response objects sent to and from the Airoverse API. JSON is a lightweight data-interchange format. It is easy for humans to read and write and machines to parse and generate. JSON has become a common, open format, used widely in all manner of web-based applications. There are JSON parsers available for almost all development languages. 

More information in JSON may be found at http://json.org 

| ZiNC Notation 

ZiNC notation in APIs refers to the syntax and structure used by the ZINC database, which is a free resource for researchers to find commercially available compounds for virtual screening. The ZINC database provides a consistent set of rules for querying and retrieving data through its API.

Here are some key points about ZiNC notation in APIs: 

• ZiNC uses a uniform URL syntax for both web pages and machine-readable API requests. This allows for consistent querying across different resources1.
• The basic structure of a ZiNC query includes components like the resource type, identifiers, relations, subsets, and formatting options. For example, a query might look like /substances/ZINC000000000053/activities to retrieve activities related to a specific substance1.
• Results can be formatted in various ways, such as JSON, CSV, or HTML, depending on the specified format in the query1.
• The API supports multiple resource types, including substances, catalogs, and targets, each with its own set of query parameters and relations1.