{"_id":"56c41ddb2e75e0170098605e","parentDoc":null,"__v":5,"category":{"_id":"56bc8e689afb8b0d00d62dd3","__v":6,"pages":["56bc8e699afb8b0d00d62dd5","56c2aadf46d27917009d0719","56c2bc123e1b8d2300fe4ca0","56c2bc1dde695a19009a4aa7","56c2bc2a46d27917009d0722","56c2bc398073830d00e42e6f"],"project":"56bc8e679afb8b0d00d62dcf","version":"56bc8e689afb8b0d00d62dd2","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-02-11T13:36:40.802Z","from_sync":false,"order":0,"slug":"documentation","title":"Getting Started"},"user":"56b98db7bb36440d0001f492","version":{"_id":"56bc8e689afb8b0d00d62dd2","project":"56bc8e679afb8b0d00d62dcf","__v":18,"createdAt":"2016-02-11T13:36:40.146Z","releaseDate":"2016-02-11T13:36:40.146Z","categories":["56bc8e689afb8b0d00d62dd3","56c3c837bc41330d009f25ed","56c3c83e521f350d00d348eb","56c3c8452d97560d00e23cd8","56c3c85234df460d00c2beb8","56c4180d70187b17005f43b4","56c418162d97560d00e23cf6","56c4181cc4796b0d007ef039","56c4182370187b17005f43b5","56c418292e75e01700986052","56c4183328bd680d005e7ac6","56c4183bbb64720d00552b88","56c418414040602b0064cea0","56c4184754b6030d00ec29a1","56c4184c28bd680d005e7ac7","56c4185370187b17005f43b6","56c4185b6063071700500cfc","582a98b6f8c0a0190053d7a5"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"project":"56bc8e679afb8b0d00d62dcf","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-02-17T07:14:35.039Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"The Buddy Platform is custom designed to handle large volumes of data from any IoT (Internet of Things) connected device.   Buddy APIs are based on HTTP/REST and can be easily called from devices with basic HTTP connectivity.  This walkthrough assumes your device has a library to make HTTP/HTTPS calls, and the code samples will be written using Javascript, but can easily be adapted to any platform.\n\n### Features and Scenarios\n\nWith just a few lines of code, the Buddy Platform provides a scalable, easy to use device backend that offers:\n\n* Secure, scalable storage for device data, in a geographical location of your choosing\n* Access to a broad set of platform functionality including device registration, binary upload/download, and metrics tracking\n*  Real-time visualizations of device usage statistics such as:\n   * How many unique devices are deployed and at what rate?\n   * Where are they?\n   * How often/long are the devices being used?\n   * What SKU/Model mix is beind deployed?\n   * What are failure/feature use rates?\n* An easy way to make data usable to your business, ranging from a live flatscreen dashboard, to direct import of device telemetry\n\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/co0dMJUS7W3MLeFf9o5f_image.jpg\",\n        \"image.jpg\",\n        \"800\",\n        \"459\",\n        \"#635fd5\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n** An example of a Buddy-powered Dashboard, available for any app ** \n\n### Types of Data in Buddy\n\nIn the Buddy Platform, there are a few different kinds of data that is handled by the API.  Knowing these types will help you best decide what is right for your application.  All forms of data are stored in the same geographical region as the application itself.\n\n* **Object Data**: Data that is associated with a Buddy object such as a User, a Checkin, or a Picture.  This data is structured and consistent.  For example, each of those object types have Location, Tag, Created Date, and Last Modified Data properties.  Pictures have a \"caption\" property, and Users have properties like \"email\", \"dateOfBirth\", and \"gender\". Objects can be created, searched, updated, or deleted.\n\n* **Object Metadata**:  Arbitrary data (key-value pairs) that can be attached to any object.  This allows you to extend the object schema or store application-specific data in a way that is easy to work with.\n\n* **Metrics Events**: Metrics are markers supplied by your application to indicate when something of interest has happened such as \"Button_Pressed\" or \"Firmware_Updated\".  These are arbitrary keys, and can optionally have values attached, and can also compute event duration, such as the amount of time a user is on a screen or using a feature.  This data is then aggregated and can be viewed via the Buddy Dashboard, but can not be accessed by the API.\n\n* **Telemetry Data**: Telemetry data is designed for large-scale data in longer-term data warehousing.  Telemetry data is not accessible via the API or the Buddy Dashboard, but is available for custom analysis when desired.  \n\n### Integration Steps\n\nImagine an Internet-connected thermostat.  This thermostat connects to the user's home wi-fi for the purpose of allowing the user to manage the thermostat via their mobile phone both in the home and remotely.  This device is capable of generating useful data, but needs an endpoint to securely send it.  Buddy provides that.\n\n#### Creating the Buddy App\n\nThe Buddy App is the secure, sandboxed backend for the device data.  Just visit the [Buddy Dashboard](https://buddyplatform.com), create an account, then create an app.  When you create this app, you'll be offered a list of geographical regions in which the app can be created.  When you create an app in a region _all of the data for that application is stored geographically in that region_.\n\nOnce you've created the app, get the application key and ID, which will look something like:\n\n    Application ID: bbbbbc.aaaabbbbcccc\n    Application Key: 0000000-0000-0000-0000-000000000\n\n#### Basic Functionality Overview\n\nAt it's simplest, you'll need to communicate with Buddy for the following:\n\n1. Authenticate the device, and it's unique identifier, with the Buddy backend.\n2. Configure a [telemetry configuration](/docs/2/IoT%20Telemetry#ConfigureTelemetry) to tell Buddy about the data you'll be sending.  This only needs to be done once, but can be modified at any time, even remotely.\n3. [Send telemetry](/docs/2/IoT%20Telemetry#AddTelemetryData) data to Buddy.\n\nWe'll walk through the steps below using a simple (and imaginary!) Javascript-based HTTP API.  Please consider the code below as for demonstration/understanding purposes only.  You would need to map these samples to the networking API supported by your specific device.\n\n#### Authenticating the Device\n\nThe first thing you'll need to do is use your AppID/AppKey to register the device with Buddy.  This registration will return a Device Access Token that will need to be saved for further calls to Buddy.\n\n    function registerDevice() {\n      httpApi.makeRequest(\n          {\n             method: 'POST',\n             url: 'https://api.buddyplatform.com/devices'\n             headers: {\n                 contentType: 'application/json',\n                 accept: 'application/json'\n            },\n            body: {\n                 appid: myAppId,\n                 appkey: myAppKey,\n                 platform: myDeviceType,\n                 model: myDeviceModelOrSKU,\n                 uniqueId: myDeviceSerialNumber,\n                 osVersion: myFirmwareVersion\n           },\n           success: function(response) {\n                 \n                  // TODO: error handling!\n                 accessToken = response.result.accessToken;\n                 accessTokenExpires = response.result.accessTokenExpires;\n\n                 // if we receive a service root, use that, otherwise use the default.\n                 apiUrlRoot = response.result.serviceRoot || 'https://api.buddyplatform.com';\n           }\n        });\n     }\n\nIf successful, this call returns us:\n\n* An **accessToken** which allows us to call other Buddy APIs.\n* A **serviceRoot** which is the URL root to be used for subsequent calls.\n\nYour device needs to save both of these values for subsequent calls, so these values should be cached.\n\n#### Configuring Telemetry\n\nOnce the device has been authenticated, ensure that your telemetry configuration has been registered.  Telemetry configuration tells the Buddy backend how to process the data you send it.\n\nIn this example, let's assume our thermostat sends back the following data points, as JSON:\n\n* The current temperature setting\n* What sort of schedule program it is running\n* The percentage of time it's spent heating versus cooling\n\nFor example, suppose the data looks something like this:\n\n    {\n      current_temp: 22,\n      customer_id: 131241241,\n      program_type: 'manual',\n      color_theme: 'coolblue',\n      statistics: {\n         heating: 72,\n         cooling: 12,\n         idle: 16\n     }\n    }\n\nDevices will generate data that has different impacts and value:\n\n* Data we want to store safely for later analysis\n* Data that we want to visualize in real time\n* Data that contains customer information we _do not_ want to store with the other data.\n\nIt's up to your app how often you send data to Buddy, but Buddy helps you handle all three of these types of data.\n\nThe **telemetry configuration** allows us to make choose how we want to store this.  You can see all of the options [in the documentation](/docs/IoT%20Telemetry#ConfigureTelemetry), but for this example, we'll set this basic configuration as follows:\n\n* `filterKeys` describes data that Buddy should remove from the telemetry before persisting\n* `metrics` describes a transform that allows us to convert telemetry data into [metrics events](/docs/2/Metrics), which can be displayed in near realtime.\n\n\n    function setupTelemetryConfig() {\n      httpApi.makeRequest(\n          {\n             method: 'PUT',\n             // note we use the root that we configured in device registration\n             url: apiUrlRoot + '/telemetry/' + encodeUriComponent(myConfigName)\n             headers: {\n                 contentType: 'application/json',\n                 accept: 'application/json',\n                 // here, we use the accessToken we received in device registration above\n                 authorization: 'Buddy ' + accessToken\n            },\n            body: {\n                // remove customer ID.\n                filterKeys:['customer_id'],\n\n                // promote current_temp and heating to metrics for\n                // realtime visualization\n                metrics:{\n                      current_temp: 'current_temp',\n                      heating_rate: 'statistics.heating'\n                }\n           }\n        });\n      }\n\nRemember, telemetry configuration only needs to be called once before the first data is sent.  You don't need to call it each time you send data.  And, if you decide you want to start handling data differently at any time, you can modify this, and subsequent data will be processed in accordance with the new configuration.\n\n#### Sending Data\n\nOK now it's time to send data!  Most devices send data on some regular schedule, but that's up to you.  In any case, sending data is easy, just package the data up and send it to the endpoint you configured above:\n\n    function setupTelemetryConfig() {\n      var deviceData = getMyDeviceData();\n      httpApi.makeRequest(\n          {\n             method: 'POST',\n             // note we use the root that we configured in device registration\n             url: apiUrlRoot + '/telemetry/' + encodeUriComponent(myConfigName)\n             headers: {\n                 contentType: 'application/json',\n                 accept: 'application/json',\n                 // here, we use the accessToken we received in device registration above\n                 authorization: 'Buddy ' + accessToken\n            },\n            body: {\n                data: deviceData\n           }\n        });\n      }\n\nYour data has now been stored securely with Buddy, and the appropriate metrics events have been created.\n\n#### Device Management\n\nMost devices also use the Buddy APIs for device management functions.  Typically, the device flow is as follows:\n\n1.  Device powers on\n2.  If connected, device checks Buddy metadata for any configuration updates\n3.  Device makes any changes requested configuration\n4.  Device caches configuration data\n\nThis configuration can be easily managed remotely via the Buddy API.  Typically, devices use [metadata](/docs/2/Metadata) to store and retrieve configuration.  Metadata is a key-value store for arbitrary data.  With our thermostat example, imagine some of the configuration points are:\n\n* How often to send telemetry data\n* How long to remain on after user interaction before going to sleep\n\nAn example configuration might look like this:\n\n    {\n       telemetry: {\n             sendIntervalSeconds:120,\n             includeSettings: true\n       },\n       sleepAfterSeconds: 30,\n       firmware: {\n          version: '1.1',\n          // see Buddy Blob APIs for information on how to use them\n          // to manage/distribute firmware updates\n          firmwareBlobId: 'bbbbbc.rcdbvlNmjKbj'\n     }\n    }\n\nNow, we can store this configuration in Buddy by setting it as a metadata value on the `app` object itself.\n\nIn the following example, we're doing something slightly more advanced, which is to save a configuration specific to a device model name.  This allows multiple configurations to exist side-by-side in the same app.  Note that this code would typically be called from outside of the device, but is written in the same format as the other code samples where for clarity and simplicity:\n\n     function saveDeviceConfigByModel(modelName, config) {\n      httpApi.makeRequest(\n          {\n             method: 'PUT',\n             // note we use the model name as part of the key\n             url: apiUrlRoot + '/metadata/app/' + encodeUriComponent(\"config_\" + modelName)\n             headers: {\n                 contentType: 'application/json',\n                 accept: 'application/json',\n                 // here, we use the accessToken we received in device registration above\n                 authorization: 'Buddy ' + accessToken\n            },\n            body: {\n                value: config\n           }\n        });\n      }\n\nFrom within the device, reading the configuration would look like this:\n\n    function readDeviceConfig() {\n      var configName = \"config_\" + myDeviceModelOrSKU;\n      if (NoNetworkConnection()) {\n           // use cached or default config;\n          return;\n      }\n      httpApi.makeRequest(\n          {\n             method: 'GET',\n             url: apiUrlRoot + '/metadata/app/' + encodeUriComponent(configName)\n             headers: {\n                 accept: 'application/json',\n                 // here, we use the accessToken we received in device registration above\n                 authorization: 'Buddy ' + accessToken\n            },\n           success: function(data) {\n                 if (data.result) {\n                        updateAndCacheLocalConfig(data.result.value);\n                 }\n           }\n        });\n      }\n\nBy defining settings in this way, you have an easy way to make modification to device  behaviors without having to update firmware or rebuild devices.\n\n#### Tracking Activity with Metrics\n\nThere may be other information that you are interested in capturing real time, such as when a button is pressed or how often a feature is used.    The following code sample shows how to record metrics events that correspond to usage of different buttons on our hypothetical Internet-connected thermostat:\n\n    function recordButtonPress(buttonName) {\n      httpApi.makeRequest(\n          {\n             method: 'POST',\n             url: apiUrlRoot + '/metrics/events/button_press',\n             headers: {\n                 accept: 'application/json',\n                 contentType: 'application/json',\n                 // here, we use the accessToken we received in device registration above\n                 authorization: 'Buddy ' + accessToken\n            },\n            body: {\n               value: {button_name:buttonName}\n            }\n        });\n      }\n\nThese metrics would then be available for analysis in the Buddy Dashboard, including breakdowns by device type, time, or geography.\n\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/42VbNAJ0RzSxCd9jSccJ_image.png\",\n        \"image.png\",\n        \"720\",\n        \"239\",\n        \"#d76654\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n** Example of metrics data ** \n\n###  Conclusion\n\nWith Buddy, a backend for your connected device is just a few lines of code away.  \n\nTo recap, with just a few lines of code, you now have a backend that:\n\n* Scales automatically with your traffic\n* Keeps your data securely, and privately, stored in a geographical location of your choosing\n* Allows real-time visualization of how many devices are deployed, where they are, and when they are being used\n* Provides a facility for long term storage of telemetry data and retrieval of the data for analytics\n* Allows for remote-management for device configuration as well as facilities for firmware updates\n\nFor any further questions, or to get started, just [contact us](mailto:support:::at:::buddy.com)!","excerpt":"","slug":"internet-connected-device-tutorial","type":"basic","title":"Getting Started With Your IoT Device"}

Getting Started With Your IoT Device


The Buddy Platform is custom designed to handle large volumes of data from any IoT (Internet of Things) connected device. Buddy APIs are based on HTTP/REST and can be easily called from devices with basic HTTP connectivity. This walkthrough assumes your device has a library to make HTTP/HTTPS calls, and the code samples will be written using Javascript, but can easily be adapted to any platform. ### Features and Scenarios With just a few lines of code, the Buddy Platform provides a scalable, easy to use device backend that offers: * Secure, scalable storage for device data, in a geographical location of your choosing * Access to a broad set of platform functionality including device registration, binary upload/download, and metrics tracking * Real-time visualizations of device usage statistics such as: * How many unique devices are deployed and at what rate? * Where are they? * How often/long are the devices being used? * What SKU/Model mix is beind deployed? * What are failure/feature use rates? * An easy way to make data usable to your business, ranging from a live flatscreen dashboard, to direct import of device telemetry [block:image] { "images": [ { "image": [ "https://files.readme.io/co0dMJUS7W3MLeFf9o5f_image.jpg", "image.jpg", "800", "459", "#635fd5", "" ] } ] } [/block] ** An example of a Buddy-powered Dashboard, available for any app ** ### Types of Data in Buddy In the Buddy Platform, there are a few different kinds of data that is handled by the API. Knowing these types will help you best decide what is right for your application. All forms of data are stored in the same geographical region as the application itself. * **Object Data**: Data that is associated with a Buddy object such as a User, a Checkin, or a Picture. This data is structured and consistent. For example, each of those object types have Location, Tag, Created Date, and Last Modified Data properties. Pictures have a "caption" property, and Users have properties like "email", "dateOfBirth", and "gender". Objects can be created, searched, updated, or deleted. * **Object Metadata**: Arbitrary data (key-value pairs) that can be attached to any object. This allows you to extend the object schema or store application-specific data in a way that is easy to work with. * **Metrics Events**: Metrics are markers supplied by your application to indicate when something of interest has happened such as "Button_Pressed" or "Firmware_Updated". These are arbitrary keys, and can optionally have values attached, and can also compute event duration, such as the amount of time a user is on a screen or using a feature. This data is then aggregated and can be viewed via the Buddy Dashboard, but can not be accessed by the API. * **Telemetry Data**: Telemetry data is designed for large-scale data in longer-term data warehousing. Telemetry data is not accessible via the API or the Buddy Dashboard, but is available for custom analysis when desired. ### Integration Steps Imagine an Internet-connected thermostat. This thermostat connects to the user's home wi-fi for the purpose of allowing the user to manage the thermostat via their mobile phone both in the home and remotely. This device is capable of generating useful data, but needs an endpoint to securely send it. Buddy provides that. #### Creating the Buddy App The Buddy App is the secure, sandboxed backend for the device data. Just visit the [Buddy Dashboard](https://buddyplatform.com), create an account, then create an app. When you create this app, you'll be offered a list of geographical regions in which the app can be created. When you create an app in a region _all of the data for that application is stored geographically in that region_. Once you've created the app, get the application key and ID, which will look something like: Application ID: bbbbbc.aaaabbbbcccc Application Key: 0000000-0000-0000-0000-000000000 #### Basic Functionality Overview At it's simplest, you'll need to communicate with Buddy for the following: 1. Authenticate the device, and it's unique identifier, with the Buddy backend. 2. Configure a [telemetry configuration](/docs/2/IoT%20Telemetry#ConfigureTelemetry) to tell Buddy about the data you'll be sending. This only needs to be done once, but can be modified at any time, even remotely. 3. [Send telemetry](/docs/2/IoT%20Telemetry#AddTelemetryData) data to Buddy. We'll walk through the steps below using a simple (and imaginary!) Javascript-based HTTP API. Please consider the code below as for demonstration/understanding purposes only. You would need to map these samples to the networking API supported by your specific device. #### Authenticating the Device The first thing you'll need to do is use your AppID/AppKey to register the device with Buddy. This registration will return a Device Access Token that will need to be saved for further calls to Buddy. function registerDevice() { httpApi.makeRequest( { method: 'POST', url: 'https://api.buddyplatform.com/devices' headers: { contentType: 'application/json', accept: 'application/json' }, body: { appid: myAppId, appkey: myAppKey, platform: myDeviceType, model: myDeviceModelOrSKU, uniqueId: myDeviceSerialNumber, osVersion: myFirmwareVersion }, success: function(response) { // TODO: error handling! accessToken = response.result.accessToken; accessTokenExpires = response.result.accessTokenExpires; // if we receive a service root, use that, otherwise use the default. apiUrlRoot = response.result.serviceRoot || 'https://api.buddyplatform.com'; } }); } If successful, this call returns us: * An **accessToken** which allows us to call other Buddy APIs. * A **serviceRoot** which is the URL root to be used for subsequent calls. Your device needs to save both of these values for subsequent calls, so these values should be cached. #### Configuring Telemetry Once the device has been authenticated, ensure that your telemetry configuration has been registered. Telemetry configuration tells the Buddy backend how to process the data you send it. In this example, let's assume our thermostat sends back the following data points, as JSON: * The current temperature setting * What sort of schedule program it is running * The percentage of time it's spent heating versus cooling For example, suppose the data looks something like this: { current_temp: 22, customer_id: 131241241, program_type: 'manual', color_theme: 'coolblue', statistics: { heating: 72, cooling: 12, idle: 16 } } Devices will generate data that has different impacts and value: * Data we want to store safely for later analysis * Data that we want to visualize in real time * Data that contains customer information we _do not_ want to store with the other data. It's up to your app how often you send data to Buddy, but Buddy helps you handle all three of these types of data. The **telemetry configuration** allows us to make choose how we want to store this. You can see all of the options [in the documentation](/docs/IoT%20Telemetry#ConfigureTelemetry), but for this example, we'll set this basic configuration as follows: * `filterKeys` describes data that Buddy should remove from the telemetry before persisting * `metrics` describes a transform that allows us to convert telemetry data into [metrics events](/docs/2/Metrics), which can be displayed in near realtime. function setupTelemetryConfig() { httpApi.makeRequest( { method: 'PUT', // note we use the root that we configured in device registration url: apiUrlRoot + '/telemetry/' + encodeUriComponent(myConfigName) headers: { contentType: 'application/json', accept: 'application/json', // here, we use the accessToken we received in device registration above authorization: 'Buddy ' + accessToken }, body: { // remove customer ID. filterKeys:['customer_id'], // promote current_temp and heating to metrics for // realtime visualization metrics:{ current_temp: 'current_temp', heating_rate: 'statistics.heating' } } }); } Remember, telemetry configuration only needs to be called once before the first data is sent. You don't need to call it each time you send data. And, if you decide you want to start handling data differently at any time, you can modify this, and subsequent data will be processed in accordance with the new configuration. #### Sending Data OK now it's time to send data! Most devices send data on some regular schedule, but that's up to you. In any case, sending data is easy, just package the data up and send it to the endpoint you configured above: function setupTelemetryConfig() { var deviceData = getMyDeviceData(); httpApi.makeRequest( { method: 'POST', // note we use the root that we configured in device registration url: apiUrlRoot + '/telemetry/' + encodeUriComponent(myConfigName) headers: { contentType: 'application/json', accept: 'application/json', // here, we use the accessToken we received in device registration above authorization: 'Buddy ' + accessToken }, body: { data: deviceData } }); } Your data has now been stored securely with Buddy, and the appropriate metrics events have been created. #### Device Management Most devices also use the Buddy APIs for device management functions. Typically, the device flow is as follows: 1. Device powers on 2. If connected, device checks Buddy metadata for any configuration updates 3. Device makes any changes requested configuration 4. Device caches configuration data This configuration can be easily managed remotely via the Buddy API. Typically, devices use [metadata](/docs/2/Metadata) to store and retrieve configuration. Metadata is a key-value store for arbitrary data. With our thermostat example, imagine some of the configuration points are: * How often to send telemetry data * How long to remain on after user interaction before going to sleep An example configuration might look like this: { telemetry: { sendIntervalSeconds:120, includeSettings: true }, sleepAfterSeconds: 30, firmware: { version: '1.1', // see Buddy Blob APIs for information on how to use them // to manage/distribute firmware updates firmwareBlobId: 'bbbbbc.rcdbvlNmjKbj' } } Now, we can store this configuration in Buddy by setting it as a metadata value on the `app` object itself. In the following example, we're doing something slightly more advanced, which is to save a configuration specific to a device model name. This allows multiple configurations to exist side-by-side in the same app. Note that this code would typically be called from outside of the device, but is written in the same format as the other code samples where for clarity and simplicity: function saveDeviceConfigByModel(modelName, config) { httpApi.makeRequest( { method: 'PUT', // note we use the model name as part of the key url: apiUrlRoot + '/metadata/app/' + encodeUriComponent("config_" + modelName) headers: { contentType: 'application/json', accept: 'application/json', // here, we use the accessToken we received in device registration above authorization: 'Buddy ' + accessToken }, body: { value: config } }); } From within the device, reading the configuration would look like this: function readDeviceConfig() { var configName = "config_" + myDeviceModelOrSKU; if (NoNetworkConnection()) { // use cached or default config; return; } httpApi.makeRequest( { method: 'GET', url: apiUrlRoot + '/metadata/app/' + encodeUriComponent(configName) headers: { accept: 'application/json', // here, we use the accessToken we received in device registration above authorization: 'Buddy ' + accessToken }, success: function(data) { if (data.result) { updateAndCacheLocalConfig(data.result.value); } } }); } By defining settings in this way, you have an easy way to make modification to device behaviors without having to update firmware or rebuild devices. #### Tracking Activity with Metrics There may be other information that you are interested in capturing real time, such as when a button is pressed or how often a feature is used. The following code sample shows how to record metrics events that correspond to usage of different buttons on our hypothetical Internet-connected thermostat: function recordButtonPress(buttonName) { httpApi.makeRequest( { method: 'POST', url: apiUrlRoot + '/metrics/events/button_press', headers: { accept: 'application/json', contentType: 'application/json', // here, we use the accessToken we received in device registration above authorization: 'Buddy ' + accessToken }, body: { value: {button_name:buttonName} } }); } These metrics would then be available for analysis in the Buddy Dashboard, including breakdowns by device type, time, or geography. [block:image] { "images": [ { "image": [ "https://files.readme.io/42VbNAJ0RzSxCd9jSccJ_image.png", "image.png", "720", "239", "#d76654", "" ] } ] } [/block] ** Example of metrics data ** ### Conclusion With Buddy, a backend for your connected device is just a few lines of code away. To recap, with just a few lines of code, you now have a backend that: * Scales automatically with your traffic * Keeps your data securely, and privately, stored in a geographical location of your choosing * Allows real-time visualization of how many devices are deployed, where they are, and when they are being used * Provides a facility for long term storage of telemetry data and retrieval of the data for analytics * Allows for remote-management for device configuration as well as facilities for firmware updates For any further questions, or to get started, just [contact us](mailto:[email protected])!