Nuts & Bolts

A QUICK SUMMARY

The basics.

HIERARCHY OF CLIENTS AND OWNERSHIP

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 INPUT / OUTPUT = API

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.

RESOURCES. 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 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 RULE: LOGICAL STATEMENT

Data Rules have two flavors. One 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.

DATA RULE: SCRIPT APPLICATION

The second 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.

DISPATCH

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.