New initiative of Microsoft OpenT2T: "Interface of all"

Microsoft has long been showing noticeable activity in the field of the Internet of things: Specialized cloud services, IoT-edition Windows 10, .Net version for microcontrollers, many hackathons, etc. Not so long ago , a new project was presented , which, in theory, could significantly simplify the life of many IoT system developments. It is called Open Translators to Things (OpenT2T). In a nutshell, this project can be described as "Interface of everything". A more detailed description later in this article.

Anyone who has developed software for devices has come across a wide variety of protocols and approaches using the same class of components. It would seem that all temperature sensors work approximately equally. You just need to read their testimony from them, that's all. However, in practice we see the following:

Reading data from the LM35 temperature sensor is as follows (taken from here ):

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

For the TMP36 sensor , the code will be like this (taken from here ):

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

If you use a thermistor of 10K ohms, you might get this code (taken from here ):

 tempC = log(((10240000/ reading(tempPin)) - 10000)) tempC = 1 / (0.001129148 + (0.000234125 + 0.0000000876741 * tempC ^ 2)) * tempC ) tempC = temp - 273.15 

Here, for example, different options for working with a light bulb:

Philips Hue (taken from here ):

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

Wink Hub (taken from here ):

 PUT https://api.wink.com/light_bulb/<device_id> {“desired_state": { “powered” : true} } 

And so in everything.

Microsoft decided to try to fix this problem with the help of a new initiative: Open Translators to Things (OpenT2T) . The idea is to ask the developers themselves to help create "work patterns" for different classes of devices. It must be said that this idea is not new. For example, there is the Open Connectivity Foundation. Microsoft wants to unite the efforts of such groups, individual manufacturers and developers. A repository on GitHub was created specifically for this, thanks to which anyone can join this process.

Technically, “interfaces of all” are proposed to be created in JavaScript / Node.js. The result is cross-platform. There are examples for Windows, OS X, Android, Azure and AWS. Each "interface" consists of three parts:

1. Scheme
2. Translator
3. application

The circuit combines devices of the same class. This is a generic "interface" for identical devices. For an example on GitHub, you can find a circuit for temperature sensors. Now schemes are used in AllSeen format .

A translator is an implementation of a circuit for a specific device. He must hide the features of working with the device, which will help developers not to waste time studying the documentation, but immediately get to work. Translators can be run both on local devices (PCs, phones, tablets, specialized controllers, etc.) and in the cloud. It all depends on the principles of operation of the controlled device. Examples of translators are written in JavaScript using Node.js. But no one forbids the use of other languages ​​and platforms: C ++, C #, Java, etc.

The application is an example of the operation of the scheme and translator for different platforms.

How to use it all? Suppose we want to read the temperature from the CC2650 sensor.

1. First we need to find a suitable scheme. In our case, it is [here] ( https://github.com/openT2T/translators/blob/master/org.OpenT2T.Sample.SuperPopular.TemperatureSensor/org.OpenT2T.Sample.SuperPopular.TemperatureSensor.xml ). If the scheme does not suit you with something, then you can put it up for discussion and edit it.
2. Then find and use a suitable translator or write your own. In our case, the translator is here .
3. Next, write an application that uses your chosen device. For the CC2650 OpenT2T sensor already contains several test examples for different platforms: UWP C # , Java for Android , Azure IoT Hub and AWS Kinesis .

To understand what kind of help Microsoft expects from the community, you need to look at the Roadmap . The project is now in Alpha-stage and is divided into several parts:

• Schemes and translators. Everyone is invited to participate in the formation of device diagrams and the creation of new translators.
• Console. It is assumed that developers will use console applications on their devices for the initial setup of modules that contain a node.js process that recognizes new devices and loads the appropriate translators. It requires help to create full applications for all operating systems (Windows, OS X, Android and iOS).
• Cloud. Work with devices can be carried out through a variety of clouds. There is a lot of work in this area related to the support of different protocols and formats for sending data to cloud services.
• CLI. Command Line Interface, which will be used by developers to test JavaScript translators. The community is expected to help refine this tool.
• Sampleapps. The repository already contains examples for different platforms. But the more examples, the better. Therefore, it is proposed to add examples for everything that interests you. For example, Xamarin, Cordova or Swift, as well as other clouds (Google Cloud) will be relevant.
• Voice. Adding new voice files will allow Cortana and other voice assistants to control devices.

Taking part in this process is quite simple. You can start by watching this and this video. You can read the tutorial . And you can participate in the discussion on GitHub. Other platforms for communication are here and here . All are welcome.

Summing up, it can be noted that the idea is correct and timely. But in my opinion, somewhat naive. Causes questions and technology stack . But, given the resources that Microsoft can include in this project, something can come out of it. In any case, the initiative is useful as a platform for discussing the problem and finding its solution. And this is half the battle.