In this article, we will cover the core features that make up our Connect application programming interface (API). For Noda customers, Connect serves as the endpoint for all their building or portfolio data. It is functionally an independent data layer, which means the applications that use the data, including but not limited to Noda Energy, are built separately from the acquisition and normalization of data originated from disparate sources.

There are many aspects of Connect. As this article is an overview of the Connect functionality, links are embedded throughout for deeper dives into specific areas of operation and interaction. A key distinction for Connect is that it is not just a "read-only" API that allows other systems to retrieve data. It can accept new data being "pushed" into it and also allows other systems, like Noda, to "pull" data out of it.

For many users of the API, the first and most familiar feature is the GraphQL endpoint that they will utilize to run queries or mutations. This initiates the "pull" sequence, enabling users to grab data that has already been loaded from connected systems and send commands to connected equipment through Connect. The API has one endpoint (or URL) for all connected buildings and their downstream systems. The best part about this feature is all your data is available fully normalized, following our ontology. So a zone temperature setpoint in one building is a zone temperature setpoint in a thousand buildings.

Many APIs are capable of exposing specific system data, but become hard to manage when you are connecting to multiple APIs that expose data in differing ways. The power of Connect is reducing that complexity and surfacing your data in a consumable way, showing a point like "Zone Temperature" in the same format, regardless of the source system. This is incredibly important for advanced applications that have machine learning or other AI features that require clean data for other computers to easily understand.

Connect can also integrate with HVAC and Lighting controllers so it can provide the current values of connected equipment points and allow for overrides, alarms, scheduling, and optimization features like adaptive setpoint control (Automated Demand Management).

This all happens using the GraphQL API mentioned above. The queries and the mutations are what Noda leverages for its user interface, but the independent nature of Noda means it doesn't have to be Noda, any UI can hook into the API and read values or command points.

In addition to the ability to pull data out of Connect using the GraphQL endpoint, the Connect API has the ability to accept data "pushed" into it from MQTT sensors or equipment controllers. This allows cloud to edge connectivity in a fully secured, modern framework that scales easily and reduces the need for use-case specific integration methods.
​

Connect can record near-real-time values into the historian database and in turn, makes it available for Noda equipment views, like charts.

Connect currently has a webhooks integration to the Disruptive Technologies platform for sensor data direct from their devices, using their own REST API. Instead of commissioning a custom integration to the Disruptive API, Connect users can have their Disruptive Tech sensors "push" data into Connect, where it can be made available next to their other BMS, HVAC, and Lighting data.

Being able to push these near-real-time values directly from sensors like this is critical to organizations looking to have an adaptive building that responds to its occupants. Utilizing this connectivity method, Connect can make the sensor data like CO2, Occupancy or Temperature available in a few hours, faster than any integration method currently available.

While the GraphQL API endpoint is the most talked about, Connect has a REST API endpoint to allow for File Uploads. This small but mighty feature is important since we use images for company logos in the Noda UI, along with including a building image for every building in Noda.
​
​
​

​
​