For some years now, we are talking about IoT as mega trend. This is good, but not good enough. It is obvious that powerful marketing influence people to think in many different ways, which often leads to misunderstanding about what IoT really stands for.
So I decided for me to setup this year on all my conferences focus on real projects, to help understanding what in this contact is and can be done, which is far beyond some playing motivation.
To give you a deeper idea about this please take a look on following article.
This year on WinDays I will grab out few scenarios from some projects and explain how daenet team has implemented them. For example, imagine we have a machine, which talks to PI (and vice versa) by using modbus protocol. In that case we do not need to do any electronic circuit on the PI. We will use it it as a gateway only, between machine (via modbus) and azure via IoTHub. We also have abstracted both protocols with a library called IoTApi, which is not in focus of this article.
As you can see on picture above, we have as in real live different devices. Independent on IoT, often people assk me if cloud is really the way to go. It is difficult to anybody to give an approvable statement on this, but in my opinion I have to ask, how one can realize such IoT scenarios at all if we don’t have service, which somewhere centralized and highly elastic and scalable? That is when the cloud makes sense and plays a major role.
As I explained this on WinDays 2016 boards, which we use to Run UWP capable applications like Raspberry PI for example (but not only), plays a role of a “gateway” from and to device/service. Form software developer perspective I see two kinds of gateway:
- Gateways, which are connected to device via circuit
- Gateways which are connected to device via protocol
First group of gateways require electronic and automation skills, which are typically not something, what a common developer has. Following picture shows a model of the car with the circuit, which daenet team has built.
Following example show how easy is receive a command and take a control of a LED of the car. For receiving of the command, we are using IotApi open source .NET Core library, which abstracts a communication with devices and services. In this case, we are using IoTHub by specifying “IotHubConnector”. This API is still in development, but it should soon provide various connectors. For example, this could be a Service Bus, Machine which supports Modbus TCP. HomeMatic XML Rpc etc. daenet and University of Applied Sciences in Frankfurt am Main are working on set of connectors.
| . . . IIotApi m_IotHubConn new IotApi(“IotHubConnector”); . . . await m_IotHubConn.OnMessage((msg) =>
{
try
{
if (msg != null)
{
DeviceCommandMessage deviceCommand =
JsonConvert.DeserializeObject<DeviceCommandMessage>
(Encoding.UTF8.GetString((byte[])msg));
executeCommand(deviceCommand);
}
return true;
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
return true;
}
},
m_TokenSource.Token,
new Dictionary<string, object>() { { "TimeoutInMs", 5000 } });
}
|
After a command is received, we will executed. Next code-snipped shows how LED is controlled via GPIO.
| private void executeCommand(DeviceCommandMessage deviceCommand) { if (deviceCommand.CommandType == DeviceCommandMessage.SwitchLight)
{
dynamic lightCmd =
JsonConvert.DeserializeObject<dynamic>(deviceCommand.Data.ToString());
if (lightCmd.LightState == true)
{
Debug.WriteLine("ON");
m_Led_Break.Write(GpioPinValue.High);
}
else
{
Debug.WriteLine("OFF");
m_Led_Break.Write(GpioPinValue.Low);
}
}
} |
Controlling of LED is typically trivial example. When working with other types of sensors and actors, things can get more complex. For example, GPIO ports have more than simple triggering values. Most circuits require signal edge detection . Following example shows, how we have detected falling and rising edge in a case of a ultrasonic sensor.
| . . . // With this signal On/Off we send UT signal
// and start reading of echo.
m_GpioUTScannTrigger.Write(GpioPinValue.High);
Task.Delay(TimeSpan.FromMilliseconds(0.01)).Wait();
m_GpioUTScannTrigger.Write(GpioPinValue.Low);
Task.Delay(TimeSpan.FromMilliseconds(300)).Wait();
. . .
private async void m_GpioEchoValueChanged(GpioPin sender,
GpioPinValueChangedEventArgs args)
{
if (m_IsSensorRunnuing)
{
if (args.Edge == GpioPinEdge.FallingEdge)
{
m_Timer.Stop();
await calcParameters();
}
else if (args.Edge == GpioPinEdge.RisingEdge)
{
m_Timer.Start();
}
}
}
|
For second group of gateways, we can build a software without almost no any knowledge about automation, electronic etc. Assuming that the board communicate to device (machine) via protocol, you can all do within Visual Studio. Isn't’ that good?
Smart Automation, HoloLens and Virtual Reality
Now, let’s try something else. Imagine we have a scenario where you need on demand to establish a communication with a device via some protocol. Assuming that we have implementation of that protocol on .NET core, we can reference it inside of UWP project. In our concrete scenario, we have used modbus TCP protocol.
Then I took our UWP application and deployed it to remote UWP capable device called HoloLens. Picture below shows a moment when deploying process has been completed and following one shows running application.
To recap this, we are using in this Case HoloLens device to connect to the machine via modbus TCP. It is obvious that we will not use HoloLens to act as never stopping gateway, but we can use it as a gateway, which on demand within Virtual world connects to the Real machine. In this specific case I used direct Machine to Machine communication.
As next, I also deployed an application as WebApp, which communicates to the machine via Service Assisted Communication (by using Azure Cloud Services). On picture below-left, you can see one HoloLens, which hosts Machine Controlling Application to send commands to machine and to receive telemetry data via IoTHub.
HoloLens 1 HoloLens 2
On the picture above-right, you can see another HoloLens device, which hosts a gateway application, which we have described before. This gateway is communicating with the HoloLens device shown above-left via IoTHub (Service Assisted Communication). Additionally the same gateway is communicating with machine via modbus-TCP.
Following picture shows architecture view of this scenario.
Application used in this example is not a holographic application, but it could be. We are right now working on 3D extensions in this context. However, scenarios shown in this article should illustrate how human machine interaction between real and virtual world can be implemented with C#, .NET Core and UWP with Visual Studio.
To me and my team, it is important that know-how around of .NET is an investment, which gives us a chance to play a serious role in new business areas.
Posted
May 01 2016, 07:44 PM
by
Damir Dobric