One Platform 101


The One Platform is a hosted server-based system that allow for developers to connect and manage products and applications using web service APIs. Devices become a virtual 'Client' in the One Platform, in a hierarchy of other clients representing devices, users, and account owners.  This hierarchy can then be used to mimic the real-world use case of device and data ownership.

The platform’s simple interface and Portals web dashboards makes it easy to build a connected solution application. The Platform’s architecture and scripting interface make it powerful enough to manage fleets of product deployments.

What is the One Platform?

At a basic level, the One Platform is an application running on a server. It handles many concurrent requests from clients including devices talking to it's API, Web Portals, and other applications. It uses identifiers to authenticate connections and accept requests like read, write, edit, create, etc. The One Platform uses a couple of data bases, one to store the hierarchy of elements (clients, resources) and one to store actual data.

Clients Overview

Client Models - Deploying Many

Whitelabel / Vendor Accounts




One Platform’s structure is made up of fundamental elements, the first of which is Clients. Clients are entities in the OneP that have ownership and have resources. A client can be a parent or a child to another client, thus providing a strict control hierarchy of access. The most common scenario to envision is the main application adds users which add devices they own. When a user logs into the application, it would have stored the key (credential) for that user’s client in the hierarchy. The user only sees child clients (devices in this case) they own. Thus the application provides the linkage when the user logs in to the key for that user’s client in the hierarchy.


Data In/Out


One Platform’s APIs are shell services that perform specific tasks. Some of these APIs are just for sending data to be stored into a data port for the device client. Other APIs actually are function calls, possibly creating resources for a device client, creating a child client, reading out a set of data, etc.

API and Libraries 

Resources of a Client

Data, Rules, Scripts, Dispatches

Every client entity in One Platform can have resources, which include data ports, data rules, and dispatches. Each of these can be accessed thru APIs, to create, modify, write, and read. There is no theoretical limit of the number of resources a device has, it is really up to each application on how they are used.


Data Ports (Data Sources)

Data Ports are used to store data with time-stamps, as time-series based information. Data could be simple integer or float values for sensors or it could be string information as large formatted packets of data, firmware files, etc. The time-series history retention can be controlled by number of points, time period, or memory storage. This data is available on-demand for data rules and scripts to process or API function calls such as read. Data can also be combined to populate other data ports.


Data Rules: Scripts


Data Rules have two flavors. The first data rule flavor is script applications that have access to all of the clients resources to use for creating more advanced conditional rules or create algorithms to process data. These scripts are written in Lua language, have access to the client’s other resources as variables and functions, and have the ability to call dispatches.

One Platform Scripting



Data Rules: Events


The second data rule type is simple logical statements that can be applied to data ports over a number of points and/or time. If data port value is greater than x, y times, over time period n, then it is true, otherwise false. Logical data rules can be attached to multiple dispatches.



Dispatches are requests out from One Platform (an output). Most communication is done with the APIs as client requests and responses from OneP. Dispatches allow for the OneP to send information out, whether it is email, sms, xmpp, http, or even twitter. Dispatches are essentially ready to go messages that simply need to be triggered to send with a packet load. Triggers are data rule logic statements or script function calls.





Have more questions? Submit a request