Windows
Windows
To help application developers more easily interact with the “Things” (e.g. light bulbs) around them, I am delighted today to introduce an alpha version of our new open source project (OpenT2T) on . Our goal is to enable application developers to write once, in an open and interoperable way, the exact same code to access functionalities that are shared across similar Things.
With this blog post, we introduce this new project and invite developers to take a look, check the demo video, and hopefully join in making this open source project a success.
There are just too many different APIs that application developers need to use today to control very similar “Things” created by different manufacturers or by using different protocols. It was my honor to in Santa Clara in the Internet Architecture Board three weeks ago with 40+ participants (from OCF, AllSeen, W3C, Eclipse, OGC and others) to discuss this exact subject. At the workshop, I said that I would share some initial work we are doing on this to inform the conversation.
How many different APIs do you need to turn on a light, or read a temperature?
We believe end users prefer a very consistent user experience when they use similar devices (e.g. lightbulbs or thermostats), even when they come from different manufacturers or support different protocols. Similarly, we believe application developers need a consistent way to control similar devices as they create apps that can support, at scale, many manufacturers.
Suppose you want to build and sell a smart application for controlling the environment in peoples’ homes (or in factories), such as temperature, lighting, or ambience. Because you don’t control all of the environments in which your application runs, you need to support a number of different devices. But talking to these devices can be taxing.
Consider, for example, these small code snippets intended for reading the temperature from three different devices:
tempCC = (5.0 * reading(tempPin) * 100.0) / 1024.0
tempC = (5.0 * reading(tempPin) - 0.5) * 100
tempC = log(((10240000/ reading(tempPin)) - 10000))
tempC = 1 / (0.001129148 + (0.000234125 + (0.0000000876741 * tempC ^ 2)) * tempC )
tempC = temp - 273.15
Similarly, how a developer turns on a light can vary much more than in the real world:
PUT http://<bridge ip>/api/<username>/lights/1/state {"bri":254}
PUT https://api.wink.com/light_bulb/<device_id> {“desired_state": { “powered” : true} }
Do app developers truly need to embed in their code specific knowledge of the characteristics of each physical device or hub?
The current alpha version uses JavaScript/Node.js, is open source and cross-platforms (with examples for Windows, OS X, Android, Azure, AWS). The basic logic, as we envision it, is composed of three parts: the schema, a translator, and the app.
“Things” start with schemas
We believe instead that developers should access a common “schema” across similar Things (e.g. a “Thermostat” or a “Light” schema) with specific properties (e.g. “Temperature” or “OnOff”).
Industry organizations, companies, or individuals create category schemas to describe devices (e.g. a schema to describe a light bulb or a thermometer). There are numerous existing initiatives doing this today with Open Connectivity Foundation’s tool being one of many examples. Microsoft will be working with the industry to create common schemas to describe similar Things, across protocols, in both the consumer and industrial space.
Translating a “Thing” to a common schema
Complementary to “schema” efforts, we also need a “translation” effort: We believe that the task of accessing the specific protocol calls supported by individual Things and turning it, here for example, into the Temperature or OnOff properties, is the job of a “translator” — a small piece of code that takes the input/output of an actual Thing and translates it into a common schema for application developers to access.
When many similar hardware devices are translated to the same schema, Cortana or apps or cloud automated rules can start targeting those common schemas and provide consistent and delightful experiences.
Developers interested in specific hardware will pick an existing schema (whatever is most suitable for that hardware) and write some cross-platform JavaScript code to translate the hardware to the schema. We think developers will “vote with their feet” and will connect their hardware to the most valuable schema they find and share their open source translator on OpenT2T. The best schema will get the most translators.
The job of the translator is to hide the implementation details about particular data models and protocols, exposing functionalities directly as programmable APIs. Turn a lightbulb on? No need for an app developer to think about RPC vs. REST, HTTP vs. MQTT, CoAP vs. ZigBee. What is needed is myBulb.turnOn() and the translator will map the API common schema call to the appropriate libraries to perform the operation. Cortana or other voice assistants could turn your bulb on whether it comes from Philips, Samsung, Wink, or another manufacturer.
Translators can run on local devices (PCs/tablets/phones) for proximally connected Things. Translators could also run in the cloud for cloud-connected Things or on gateways for gateway-connected Things and marshalled from the cloud.
The application experience
Application developers (client or cloud apps) can write the same code to control similar devices from different manufacturers, in an open and interoperable way. Developers achieve this by referencing the single category schema associated to similar Things and use the same function call defined by that schema to control them.
For example, suppose you want to write an application to read the temperature from a . Here are the steps to do this, from the OpenT2T project:
As an alpha project, we’re actively developing per our . Help us develop, test, and file issues. Keep in mind that it’s not ready for real deployment yet. The project is in the following six parts:
Our hope is that developers will check out the project, view an and demo videos, read the , ask , and contribute a first translator for their favorite hardware and overall to the project (please check our initial ).
We are looking forward to continuing the discussions about Translation to Things in the and with other groups, such as the Internet Architecture Board participants. Grounding those discussions around real code will help us tremendously.
We also checked the interest of other IoT developers and manufacturers in many companies in this space and many of them agreed to continue the conversation in the GitHub project. Among them are Sol Salinas (), Sergey Grebnov (), , , David Plans (), , , John Cameron (), Daniel Quant (), Brad Ree (), Jonathan Pickett and Charles Prakash Dasari ().
Today, we have pushed some alpha code on GitHub to start the conversation around translating Things to common schemas. In time, we hope OpenT2T becomes a vast repository of crowd-sourced cross-platform translators supporting a broad set of hardware Things and constantly curated by a thriving community where similar translators can compete, collaborate, combine, or diverge. Everyone could write a new translator to support a new hardware, from industry organizations to startups, from manufacturers to students, from enterprise to hobbyists. Translators can and will be forked, cloned, patched and discussed publicly: the proven dynamics of open source development will make the best translators associated to the best schemas emerge and provide long-term sustainability.
Written by Jean Paoli, Windows Developer Platform
With this blog post, we introduce this new project and invite developers to take a look, check the demo video, and hopefully join in making this open source project a success.
There are just too many different APIs that application developers need to use today to control very similar “Things” created by different manufacturers or by using different protocols. It was my honor to in Santa Clara in the Internet Architecture Board three weeks ago with 40+ participants (from OCF, AllSeen, W3C, Eclipse, OGC and others) to discuss this exact subject. At the workshop, I said that I would share some initial work we are doing on this to inform the conversation.
How many different APIs do you need to turn on a light, or read a temperature?
We believe end users prefer a very consistent user experience when they use similar devices (e.g. lightbulbs or thermostats), even when they come from different manufacturers or support different protocols. Similarly, we believe application developers need a consistent way to control similar devices as they create apps that can support, at scale, many manufacturers.
Suppose you want to build and sell a smart application for controlling the environment in peoples’ homes (or in factories), such as temperature, lighting, or ambience. Because you don’t control all of the environments in which your application runs, you need to support a number of different devices. But talking to these devices can be taxing.
Consider, for example, these small code snippets intended for reading the temperature from three different devices:
- LM35 temperature sensor probe (adapted from ):
tempCC = (5.0 * reading(tempPin) * 100.0) / 1024.0
- TMP36 temperature probe (adapted from ):
tempC = (5.0 * reading(tempPin) - 0.5) * 100
- Directly from a 10K Ohm Thermistor on a custom breadboard (adapted from )
tempC = log(((10240000/ reading(tempPin)) - 10000))
tempC = 1 / (0.001129148 + (0.000234125 + (0.0000000876741 * tempC ^ 2)) * tempC )
tempC = temp - 273.15
Similarly, how a developer turns on a light can vary much more than in the real world:
- If you are using a Philips Hue (adapted from ):
PUT http://<bridge ip>/api/<username>/lights/1/state {"bri":254}
- If you are using a Wink Hub (adapted from ):
PUT https://api.wink.com/light_bulb/<device_id> {“desired_state": { “powered” : true} }
Do app developers truly need to embed in their code specific knowledge of the characteristics of each physical device or hub?
The current alpha version uses JavaScript/Node.js, is open source and cross-platforms (with examples for Windows, OS X, Android, Azure, AWS). The basic logic, as we envision it, is composed of three parts: the schema, a translator, and the app.
“Things” start with schemas
We believe instead that developers should access a common “schema” across similar Things (e.g. a “Thermostat” or a “Light” schema) with specific properties (e.g. “Temperature” or “OnOff”).
Industry organizations, companies, or individuals create category schemas to describe devices (e.g. a schema to describe a light bulb or a thermometer). There are numerous existing initiatives doing this today with Open Connectivity Foundation’s tool being one of many examples. Microsoft will be working with the industry to create common schemas to describe similar Things, across protocols, in both the consumer and industrial space.
Translating a “Thing” to a common schema
Complementary to “schema” efforts, we also need a “translation” effort: We believe that the task of accessing the specific protocol calls supported by individual Things and turning it, here for example, into the Temperature or OnOff properties, is the job of a “translator” — a small piece of code that takes the input/output of an actual Thing and translates it into a common schema for application developers to access.
When many similar hardware devices are translated to the same schema, Cortana or apps or cloud automated rules can start targeting those common schemas and provide consistent and delightful experiences.
Developers interested in specific hardware will pick an existing schema (whatever is most suitable for that hardware) and write some cross-platform JavaScript code to translate the hardware to the schema. We think developers will “vote with their feet” and will connect their hardware to the most valuable schema they find and share their open source translator on OpenT2T. The best schema will get the most translators.
The job of the translator is to hide the implementation details about particular data models and protocols, exposing functionalities directly as programmable APIs. Turn a lightbulb on? No need for an app developer to think about RPC vs. REST, HTTP vs. MQTT, CoAP vs. ZigBee. What is needed is myBulb.turnOn() and the translator will map the API common schema call to the appropriate libraries to perform the operation. Cortana or other voice assistants could turn your bulb on whether it comes from Philips, Samsung, Wink, or another manufacturer.
Translators can run on local devices (PCs/tablets/phones) for proximally connected Things. Translators could also run in the cloud for cloud-connected Things or on gateways for gateway-connected Things and marshalled from the cloud.
The application experience
Application developers (client or cloud apps) can write the same code to control similar devices from different manufacturers, in an open and interoperable way. Developers achieve this by referencing the single category schema associated to similar Things and use the same function call defined by that schema to control them.
For example, suppose you want to write an application to read the temperature from a . Here are the steps to do this, from the OpenT2T project:
- Identify a category schema. In our initial alpha, we support the AllSeen schema syntax. You can see a very simple sample testing schema we wrote for our alpha version . The goal is to bring consistency around schemas syntaxes and encourage the creation of schemas for different categories of Things. Together with you, we will do this through working with OCF and others in the industry. Our recommendation is to start with existing standard industry schemas though you may need to create sample schemas for testing purpose.
- Find and use a translator already written by the community. Or help the community and write a translator for the data that comes off the CC2650 to that schema. The data that comes off the CC2650 device is described by Texas Instruments in a spec sheet, available . You can see an example of that translator on the OpenT2T project . The translator is written in JavaScript using Node.js in our alpha version but the community could decide to build support for other languages such as C++, C#, or Java.
- Write an application that controls your Things, in this case the CC2650. You can see five sample applications on the OpenT2T project . The alpha version has examples for writing UWP apps for Windows (), Android apps (), JavaScript/Node common code (with and specific examples). For example, in this , there is a unique function call, m_Consumer.GetCurrentTemperatureAsync(), that needs to be called to get the temperature from all different hardware sensors that have been translated to the common .
As an alpha project, we’re actively developing per our . Help us develop, test, and file issues. Keep in mind that it’s not ready for real deployment yet. The project is in the following six parts:
- : Repository of translators. They are grouped by translators written for a specific schema. The translator name is a unique string provided by the manufacturer identifying a “Thing” specific model
Next steps: We would love to work with the community to add new translators to the initial existing sample schemas, in order to help testing additional new Things and additional protocols. - : On PCs/tablets/phones, developers use the console app as a runtime to communicate with and onboard (i.e. initially setting up) actual Things. The console app hosts the node.js process: when a Thing is onboarded, it is recognized by its unique identifier, its translator loaded. The Thing is then exposed on the bus as a device supporting the schema it has been translated to.
Next steps: We hope the community will help us fully support Windows, OS X, finalize Android support, build iOS support, explore additional ways to host the runtime and to identify/build robust cross-platform libraries for the different protocol buses used to communicate with “Things”. - : In the cloud, developers use the same schema to communicate to similar Things translated to that schema in a node.js process.
Next steps: our call to the community is to help us test new Things and support additional protocols (CoAP, MQTT). We can achieve this by adding new translators, running on the cloud, for cloud-connected Things or by testing how to run Translators on gateways (e.g. Arduino, home Hubs, others) to gateway-connected Things marshalled from the cloud. - : command line interface used by developers to onboard and communicate with actual Things and running the JavaScript translators.
Next steps: We would love to work with the community to round up the CLI to become the tool that developers use to run to test their JavaScript code. - : The alpha version provides samples of UWP apps for Windows (), Android apps (), JavaScript/Node common code (with and specific examples)
Next steps: We can work with the community to add sample apps for other UI frameworks such as Xamarin, Cordova or Swift and for other clouds such as Google Cloud. - : By adding a voice file that can understand a specific schema, developers enable their favorite assistant to control virtually all similar things that are translated to that schema. A few samples voice files are provided for Cortana to control lights and thermostats.
Next steps: we would love to see the community add more voice files for Cortana for different categories of things and provide samples for other assistants such as Alexa and others.
Our hope is that developers will check out the project, view an and demo videos, read the , ask , and contribute a first translator for their favorite hardware and overall to the project (please check our initial ).
We are looking forward to continuing the discussions about Translation to Things in the and with other groups, such as the Internet Architecture Board participants. Grounding those discussions around real code will help us tremendously.
We also checked the interest of other IoT developers and manufacturers in many companies in this space and many of them agreed to continue the conversation in the GitHub project. Among them are Sol Salinas (), Sergey Grebnov (), , , David Plans (), , , John Cameron (), Daniel Quant (), Brad Ree (), Jonathan Pickett and Charles Prakash Dasari ().
Today, we have pushed some alpha code on GitHub to start the conversation around translating Things to common schemas. In time, we hope OpenT2T becomes a vast repository of crowd-sourced cross-platform translators supporting a broad set of hardware Things and constantly curated by a thriving community where similar translators can compete, collaborate, combine, or diverge. Everyone could write a new translator to support a new hardware, from industry organizations to startups, from manufacturers to students, from enterprise to hobbyists. Translators can and will be forked, cloned, patched and discussed publicly: the proven dynamics of open source development will make the best translators associated to the best schemas emerge and provide long-term sustainability.
Written by Jean Paoli, Windows Developer Platform