1. Home
  2. Docs
  3. AnalyticsOS – Cloud API Documentation v.1.0
  4. Sensor Ingestion v1

Sensor Ingestion v1

[bt_bb_section layout=”boxed_1200″ lazy_load=”yes” show_boxed_content=”no” allow_content_outside=”no”][bt_bb_row][bt_bb_column lazy_load=”yes” highlight=”no” align_to_edge_column=”no” width=”1/1″][bt_bb_text]

Sensor data can be sent to AnalyticsOS℠ Cloud using a HTTPS request with a JSON payload.

1.1.1        HTTPS Request
Field Value
URL https://cloud.analyticsos.com/sensor-ingestion/api/v1/sensor-data
Request Type POST
Autorization Bearer Token
1.1.2       HTTPS Request Parameters
Parameter Data Format Value Optional Default
user_id String ID of User requesting data from Yes Null


  • Some API clients will have access to data for multiple users and user_id must be provided. If an API client is

for a single user, then user_id may be omitted.

1.1.3        HTTPS Request Body Structure

“sensor_points”: [



























1.1.4        Sensor Ingestion Details

The sensor_points JSON Array contains all the data points AOS Cloud should process.  The fields and their descriptions are outlined in the subsections below.


The sensor topic declares an identifier for each source of data. Sensor topic names are case sensitive. It is suggested that all topics names be uppercase and underscores used in the place of spaces. It is also suggested, but not required, that topic names be in the following format:

Location of System/Major Component/Subcomponent

Other naming conventions may be employed for sensor topics, such as using ID strings generated by the data source application or intermediate data handling layer. The sensor topic must also be known by the AOS model developers before the deployment of AOS.

Description of the components and subcomponents can be eliminated or expanded as dictated by the complexity of the sensor-system integration. That is, if a system does not have any subcomponents, the sensor topic name may only specify the major system; conversely, if a system has several layers of complexity, additional subcomponent tags can be added to the sensor topic name.

In the case of multiple systems of the same type being published to the same AnalyticsOS℠ data subscriber, clarifiers should be added in the level of system which they are differentiated (e.g. SITE_1/MOTORA/WINDING/ TEMPERATURE and SITE_1/MOTORB/WINDING/TEMPERATURE for two motors operating in the same environment).

Where possible, consistency should be used in subcomponent and variable naming conventions.


The key offers a second level of hierarchy in data organization.  Two sensor data points could both use a SITE_1/MOTORA/WINDING topic, while one used a key of TEMPERATURE and one used a key of HUMIDITY.  It is the combination of sensor topic and sensor key which form a sensor’s unique identifier.


The sensor data value as a float. Note this is a JSON number, not a string representation of the number.


Timestamp messages contains the date and time of the occurrence being measured. In order to define a timestamp, use the clarifier timestamp followed by the data value as an integer i.e. 1473269535670 (which represents Wednesday, September 7, 2016 12:32:15.670 PM GMT-05:00 DST). Timestamp values should be specified in the Julian milliseconds since 1/1/1970 00:00:00 UTC standard.


Units of the sensor topic may be optionally specified by a separate JSON key units. Units are not required for designation within AnalyticsOS℠ but should be known when configuring an interface to AnalyticsOS℠ Cloud.

External Asset ID

Customer identifier for the asset in question.  This is how the AnalyticsOS℠ Cloud knows which sensor data to use when providing analytics for one asset vs another.


It is not necessary for topics to be published at a consistent time interval, even within one sensor topic. The AnalyticsOS℠ Cloud engine is capable of aggregating and analyzing asynchronous data.