>> Are you a .NET Developer and think that
embedded development is complicated and hard?
Well, will prove you wrong today.
At least Laurent will prove you're wrong by showing you how to
connect.NET nanoFramework to Azure IoT
with just a few lines of codes.
Magic. That's today on The IoT Show.
[MUSIC]
>> Hi, everyone. This is the Internet of Things show.
I'm Olivier, your host. Thanks for joining.
Today, I have my friend Laurent was here to
discuss .NET nanoFramework and how to connect that to the Cloud.
Laurent, welcome back to the show. How are you?
>> Hey, Olivier. All good. Thank you.
>> For those who have not seen that first episode
of the IoT Show with you,
there was the introduction to .NET nanoFramework.
So we will not go through the introduction
again because they can go and watch that video again.
But tell us a bit about yourself real quick.
What are you doing? What is your team working on these days?
>> I'm working in Microsoft for commercial software engineering.
I'm leading a team of software engineer,
and we are focusing on doing
co-engineering with our largest customers.
A lot of scenarios does involve IoT,
so that's what we are doing.
>> Nice. Last time,
you give us an introduction of .NET nanoFramework at a high level,
so we got to see how .NET
developers can develop for microcontroller devices.
Before we jump into how you can do more by
connecting these microcontrollers run .NET code to the Cloud,
you actually have some interesting comment
in our preparation meaning
about why would someone want to do that?
Why would you want to run code on microcontrollers?
I think like, we get that at a high level,
but why would we want to bring up .NET on microcontrollers?
>> Well, if you're a .NET developer,
you like .NET and you understand it's a very productive language.
You can do things very quickly.
User element is that if you are a .NET developer,
you can develop from the Cloud to
a PC to a small device like your Raspberry Pi,
for example, with .NET IoT.
Then the next one, it's clearly MCUs.
Today, with the .NET nanoFramework,
you can do that, you can have discontinuity.
It won't be the same code that you will run in Azure Data Center,
and then you will run on your MCU.
But the C-Sharp competency that you will
be able to reuse are there.
That's we're about using.
The other element is about connecting MCU to the Cloud.
You said like, "Why can't connect those MCUs to the Cloud?"
One of the element is that they've become much more
powerful and get much more network coverage as well in all basis.
Like you take this little ESP32 which I will do a demo.
Later on, it can connect to Wi-Fi.
If you have a place cover with Wi-Fi,
you can get those things connected very quickly,
and putting them to the Cloud, so why not?
>> Why not? Exactly. I think as you were saying,
definitely these microcontrollers are
getting smarter and smarter because they're more capable.
We can now instead of forcing people to do
embedded development with C code and/or sometimes [inaudible],
which can become very complicated real quick.
Now, we're abstracting all of that with this kind of
frameworks. I love that.
As you were saying, connectivity is becoming more pervasive
as well on these tinier devices
with technology consuming less battery.
Because battery is definitely a big problem there.
We'll see. I think you and
your team has been developing an SDK that allows
connecting a .NET nanoFramework device to Azure IoT to the Cloud.
We'll see that. But before we jump into that,
can you give me a little rundown of the state of
nanoFramework and where are you guys at?
>> .NET nanoFramework works on
multiple platforms as you can see on the screen,
and we do support all ESP32 families,
all the STM32 family,
and some of the Texas Instruments as well, NXP.
So you really have a broad range of processors supported.
When I says support is that you have of course,
the support for the board,
but you have as well the support to .NET nanoFramework.
To connect to that, and we can see that in a demo later today.
There is a Visual Studio extension that you install,
and then you can see your device,
connect your device, debug your device.
You will see its magic. There is as well a unit test framework.
There is really all the tools that you are used to have.
>> Nice. The embedded development has
a reputation of being complicated and hard,
and it involves wiring soldiering staff at
the same time as many pleading registers
and low level memory and whatever.
Let's show .NET developer how it's done using
their favorite language and their favorite tools.
Show us how you connect
the .NET nanoFramework device to the Cloud now.
>> First, I'll start by maybe explain
few concepts about what I will do here.
I will use a service which is an Azure service called DPS.
No, that's the nickname.
It does allow you to provision devices to the Cloud.
Why? I mean, you asked me before that why
connecting devices to the Cloud? I say like, why not?
But that comes with a couple
of elements that you have to take care.
Managing your devices, provisioning your devices,
being able to revoke devices if you have an issue,
security issue, and doing most things like that.
This service allows you,
so this device provisioning service,
DPS, allows you to do,
and those kind of things in a very transparent and very easy way.
>> There's someone actually was presenting DPS,
saying the device provisioning service as
saying that it's the concierge for
devices that must come in to DPS,
they identify themselves with some unique piece of identity,
and then they are given the keys to an IoT Hub in to
a gateway in the Cloud instance
that they can then connect and communicate.
>> Exactly. Here, for example,
I will show how to provision
an individual device where I've
prepared that a little bit so that it can go faster.
That's the nano DPS device.
I've created it with just a asymmetric key.
It has not been yet on any IoT hub,
and it's supposed to go in my IoT hub,
like [inaudible] IoT service.
I go in this one,
I will try to search for this device.
This device is not here,
so this device does not exist.
I just trust in a field.
Now, what I will do is I will go in Visual Studio,
and I will launch this code.
I have done my device connected,
it will do a bit of magic,
and I will try just to come at first, but you can see.
>> The code you're showing here
is available on GitHub as a sample,
so you have the SDK itself,
and then you have the [inaudible].
>> Yes. In a very detailed sample.
As you can see, it's C# 9 style code.
I'm using Visual Studio 2009.
I have my folders,
that's C#. No doubts about that.
From the registration service,
I have and then my registering ID,
the global ID provisioning the scope,
it's basically my own.
Then these beautiful key which I just copy paste a bit before.
The deployment is happening on the device.
It will finish very soon and it will start connecting.
The first thing I need to do is connect to
my Wi-Fi to get some Cloud connectivity.
Once that's done, I have the Azure
certificates that I will be able to use in order to use SSL.
I mean, SSL is supported on those devices,
in this case, SSL TLS.
The debugger is now starting.
Then I will create a provisioning service.
I just pass my secrets.
I will ask to register the device.
If all goes right, my status should be green.
Now it's connecting to the Wi-Fi.
We can see that on the bottom here.
Very soon it should get connected.
>> Laurent, I'm always doing that.
There's a couple of things you mentioned that I
think are interesting to double-click on.
The SSL part,
that's a part that is interesting because we do
require devices to encrypt communication to connect to the Cloud,
so that's a reason why.
The time is important.
People sometimes forget that when you establish
an SSL connection you need a token that has an expiration dates.
For security reasons, you need to
create a token that has an expiration date.
If you don't want to have the expiration date to be in
the past and never work for the token,
you better have the right time.
You need to sync the time on the device.
This tinier devices don't have a battery,
don't have a knowledge
of the time unless they synchronize with the server.
>> Absolutely.
>> These are things that I think are important to mention.
>> Yes. Here you can see I can get the time, the dates,
and which you can see the principal threads run,
and I'm meeting a break point here in my code.
>> Something people might not realize,
you're running the code on the device.
You're debugging from Visual Studio on your Dev machine.
This is something that's in the embedded world is not trivial.
This is something that very often requires
advanced hardware like JTAG debuggers
and things like that to make this happen.
Here you're doing that from the comfort of Visual Studio
on your machine connected over USB,
and it's certainly serial over
USB or something like that, that help us.
You're just doing breakpoints and
step-by-step and things like
that in Visual Studio and you cross the bug.
>> Yeah, absolutely. Here I can hit "Continue", for example.
It seems like my connections went well.
I get all my details.
The statues, the default information.
What you haven't seen, but in the meantime
it gets connected to Azure,
so I created my Azure connection with the credential and with
the information I got from my GPS.
I opened that. All good.
Here what I will do is I will get my twins as well.
Before I get the twins I need to show you that
in the portal on the device.
We will quickly check that the device has been provisioned.
I click on "Device" here and I will show you some more magic.
My device has been connected,
the time in GMT.
That much with the time you've seen just before.
Here, there is this concept of twins.
The concept of twin, it's really properties that you
can give it to your device and your device can report as well.
For example, if there are
some specific settings about some pins
or about some naming or about whatever,
you can give that to the device.
That's provision as well.
Now that's what I want to get.
I just click "Play",
and here I should see my twin.
>> Okay. The GPS service
not just provided credentials
to the device for it to connect to IoT Hub,
it also set an initial configuration
for properties in the hub for that specific device.
That's what you're doing now.
>> Absolutely. If I go back to the portal
and if I try to search for my device,
this time I will have my device.
>> Yeah.
>> I have my device here,
I can click a candidate details of the device and I
can go and check the twins of the device if I want,
and that's going to be the same twin that we've just provisioned.
>> Fantastic.
>> I can make a change,
then it will get the new twins but in the meantime,
I have my twins in there like just
to see they ask to unblock NANO is just asking.
Fantastic. Magic.
>> Yeah.
>> I can continue. I can send message.
This is how simple it is to send a message.
The first one is text message.
The second one is JSON,
like manually than JSON.
But there are few things I haven't shown you.
First, is that we are a lot of
nuggets and these are just a nugget.
All the magic that happens when I click "Play"
before and when it connected to GPS and
all the exchange and all that happen is based on couple of things.
First, the JSON 1.
Second, the entity workout that we are using,
but this is totally transparent.
You don't need to know that.
You just connect and you just play and that's good to go.
If I continue with play and the message we'll go to the Cloud and
my device is available
to do whatever you want. Now, it's connected to this.
>> Very nice. Yes,
as you just emphasized and just mentioned,
you have that SDK,
that's layer that tracks
the complexity of things because at the end of the day,
someone could implement their code on top of a MQTT client,
which is that protocol we're using to communicate.
>> Absolutely.
>> Here was with
your recently released Azure IoT SDK for NANO Framework,
this is one line of code,
I noticed that you're actually also using
name spaces that are very similar to the one we are using in the,
I would say, big .Net SDK.
>> Exactly.
>> Developers can also consider
migrating there could pretty easily, right?
>> Exactly. That's what I wanted
to highlight and to show us where it is
that the definition of the functions are almost the same.
It's not the same code.
You can just copy, paste,
run and you can copy, paste,
I just few persons,
play and you're able to go. Something else as well.
I'd like to mention is that here I produce secrets in a good,
that's usually not good.
Of course, we do support as well certificates.
I have the exact same sample which I want to learn.
With certificate they could do certificated
here as well in the code, and that's no good.
But there are a couple of tricks.
It's that with NANO framework,
you can upload your certificates
without having to upload your code.
They visit configuration panel in the Visual Studio extension,
and that you can do as well problematically.
Well, you can approve device certificates,
all certificates, and then you don't have to put any senior code.
We have certificate device.
>> Usually when you take advantage of
an OS like Big Windows and Linux,
you have a certificate store that the apps can go feed from.
Here what you're saying that isn't the nanoFramework
that offers that cert store as well?
>> Absolutely, yes.
As a feature from nanoFramework
that's done on this book goes to devote to have
the capacity to revoke
fresh new certificate on the device we saw to be refreshed code
Fantastic. That means that you can have
a device that is flashed in factory,
actually sends to GPS and that certs store,
where you have the SSL connectivity
through the cert store in that certs store,
and then you can have an enrollment in GPS.
It leverages certificates.
Having a group enrollments,
have your search for that group enrollment in that store,
and then the code being generic on
the device that leverages that to do the authentication of GPS.
>> You will search devices around
the world you don't know where they will be.
With GPS, once the device connects, you can circulation,
which is the lowest latency and if you have
multiple IoT Hubs all over the world to reduce the latency,
then the device will be able to get connected to
the one which is the closest to IoT.
>> Awesome. Cool, all.
That's a great demo of how to connect
a device in .Net directly on the device to the Cloud.
I hope everyone enjoyed that.
I personally am impressed.
I love where the NANO framework
is going and where your team and yourself are doing there.
If you want to learn more about what you just saw in
the SDK for connecting a NANO Framework to Azure IoT
you can get to aka.ms/IoTShow/nanoFrameworkAzure IoT.
If you're a .NET developer,
it's this time of the year where .NET conf is soon.
Don't forget to sign up for .Net conference,
I think it's November ninth to 11 or something like that soon.
>> Save the date for .NET CONF 2021,
November ninth through the 11th for the .NET 6 launch. Netconf is
annual free three-day virtual developer
event co-organized by the .Net community and Microsoft,
sponsored by the .Net Foundation and our ecosystem partners.
For three days, you'll learn
from featured speakers from the community
and .Net Teams at Microsoft talking about .Net 6,
C# 10, Azure,
Visual Studio and more.
This is your chance to learn, ask questions live,
and get inspired for your next software project.
We've got wall to wall content for web,
mobile, Cloud, desktop, games,
services, libraries, and a variety of
platforms and devices all with .NET.
Everyone is going to learn something,
no matter if you're just beginning or you're
a seasoned engineer. Don't delay.
Head to www.dotnetconf.net,
that's dotnetconf.net to learn more and tune in.
>> Sign up. They'll get some more content.
They might be something that a form of content during
that dotnetconf but we also are thinking
about what can we offer as an event as
content for you .NET developers when it comes to IoT.
Feel free to come back to the IoT Show. Ping us.
Laurent, thanks a lot for your time today.
I hope to see you soon again on
the IoT show for more about nanoFramework.
>> All right with pleasure as always,
essentially adjacent driven. Bye.
>> Thank you all. Bye. [MUSIC]