Windows 10: Open Translators to Things: Open Approach for Accessing Similar Things

Brink · Apr 4, 2016

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 Open Translators to Things (OpenT2T) on GitHub. 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 code 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 participate in Santa Clara in the Internet Architecture Board Semantic Interoperability workshop 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 here):

1 tempCC = (5.0 * reading(tempPin) * 100.0) / 1024.0

TMP36 temperature probe (adapted from here):

1 tempC = (5.0 * reading(tempPin) - 0.5) * 100

Directly from a 10K Ohm Thermistor on a custom breadboard (adapted from here)

1
2
3 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 here):

1 PUT http://<bridge ip>/api/<username>/lights/1/state {"bri":254}

If you are using a Wink Hub (adapted from here):

1 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 oneIoTa 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 Texas Instruments CC2650 Sensor Tag. 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 here. 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 here. You can see an example of that translator on the OpenT2T project here. 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 here. The alpha version has examples for writing UWP apps for Windows (C# example), Android apps (Java example), JavaScript/Node common cloud code (with Azure IoT Hub and AWS Kinesis specific examples). For example, in this temperature sample, 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 sample schema.

Where we are right now and next steps

As an alpha project, we’re actively developing per our roadmap. 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:

Translators: 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.

Console: 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”.

Cloud: 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.

CLI: 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.

Sampleapps: The alpha version provides samples of UWP apps for Windows (C# example), Android apps (Java example), JavaScript/Node common cloud code (with Azure IoT Hub and AWS Kinesis 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.

Voice: 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.

How to get involved and join the discussion

Our hope is that developers will check out the project, view an end user and code demo videos, read the tutorial, ask questions, and contribute a first translator for their favorite hardware and overall to the project (please check our initial roadmap).

We are looking forward to continuing the discussions about Translation to Things in the Open Connectivity Foundation and with other groups, such as the Internet Architecture Board Semantic Interoperability workshop 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 (Accenture), Sergey Grebnov (Akvelon Inc), Acer, ASUS, David Plans (BioBeats), Dell, Lenovo, John Cameron (LIFX), Daniel Quant (Multitech), Brad Ree (Nortek), Jonathan Pickett and Charles Prakash Dasari (Schakra Inc.).

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

Click to expand...

Source: Open Translators to Things: An Open Approach for Accessing Similar Things | Building Apps for Windows

:)

Ramesh Srinivasan · Apr 4, 2016

Things open with notepad

Hi,

You seem to have somehow associated .lnk or .exe files with Notepad. If that's the case, here is a registry fix to resolve the problem. Double-clicking
EXE Files Open Notepad or Any Other Application? (Registry Fix)

normaneystad · Apr 4, 2016

Things open with notepad

II've had w-10 for 2 days now.

When I first logged on to w-10 I clicked on open with notepad.

Now when I click on an icon on the desktop it opens with just text.

I need to change that.I don't know how to go back there and click on to

something else.Maybe it would be browser,not sure.

Windows 10: Open Translators to Things: Open Approach for Accessing Similar Things

Open Translators to Things: Open Approach for Accessing Similar Things

Open Translators to Things: Open Approach for Accessing Similar Things

Open Translators to Things: Open Approach for Accessing Similar Things - Similar Threads - Open Translators Things

six key opening up snipping thing

Things not opening

Many important things not opening!

Open files with thing

Computer Opening Things When Typing

Things opening on its own

Edge is default but things open in IE

Preventing reset to factory settings and similar things

The Font Thing - similar?