>> Managing devices at scale over the year when
they're connected to different types of
back end might not always be easy.
The Mender is a solution that allows you to do exactly that.
Deploy software over the year,
manage your devices and
today Eystein from Mender is here to tell us about
an integration with Azure IoT Hub
from Mender the last to seamlessly
create identities and establish
connectivity between devices and IoT Hub.
All of that in Mender,
so that's today on
the IoT Show
[MUSIC].
Hi everyone, you're watching the IoT Show, I'm your host,
and today we're going to talk about Mender and for that,
we have Eystein here. Eystein, how are you?
>> Good. Thanks for having me.
>> Well, before we jump into the topic of the day,
which is about managing devices and integrating connecting
these devices that manage through Mender to Azure IoT Hub,
I would like for you to give us
a short introduction about yourself.
You came to the IoT show some time ago,
a year ago, a year and a half ago to introduce Mender.
But I think it's been long enough
so that we have you again on the show.
Tell us a bit about yourself,
tell us about Mender real quick.
>> Sure. It's good to be back here.
Mender is over the air software update manager and
device management solution with advanced features,
and it's backed by open source community.
I am the CTO of
the company and I basically lead the product development.
>> Perfect, so we have the right person to
talk technical here, that's perfect.
You do have customers using Mender
and you just mentioned it's about over the air updates.
This is a very critical point of IoT managing your devices,
making sure they're up to date to that you patch them with
security patches and you
get the latest version of softwares and so on.
Tell us a bit about what kind of customers you have,
what kind of solutions they're building,
and how they are using and leveraging mender and their solutions?
>> Definitely. It's quite interesting to work in
the IoT space because it's such a big variety.
I would say there is no specific
vertical that is bigger than the others.
But some examples we have is Airbus, for example,
to update devices that are in the plane and this is
a very interesting environment because
you can only update them while the plane is taxiing.
You cannot do it while it's flying, obviously,
and then we have other vertical with
an energy [inaudible] for example,
heating systems for homes.
That's another example.
They live in very diverse environments.
Some are offline, pretty much all the time, and yeah,
I connected the whole point.
>> If I were to ask you what specific and special about Mender?
There are other solutions for managing devices remotely.
What makes Mender special?
>> Right. We have an end-to-end solution.
We develop both the client and the server.
We deliver both on translation and
we have to focus on the OTA and device management.
We have some advanced features in that respect,
and it's also open source,
the core with a community behind it.
>> Deploying devices manage
them remotely in terms of software update is one thing.
The other one and we are big there,
which is connecting these devices
to a Cloud solution and Cloud applications.
You guys are in the business of this management of devices.
But customers who don't like to have two solutions,
it's better to integrate and as a matter of fact,
you guys put together some level of integration with Azure IoT.
Well, I know for a fact you came with demos,
and so tell us a bit about that integration and how it works.
>> Absolutely. We're seeing a growth
in Azure usage among our customer base as well,
and we're seeing they're using Azure
to get telemetry and connect their application,
and they're using Mender to develop
or to manage updates their devices.
It gets a bit complicated for them to
manage all of this on their own so we wanted to see,
how can we simplify this.
What we're doing is that we allow a member
to manage the devices in Azure.
So you have one place
where you can provision and manage your devices.
>> That makes sense because device identity
is something that's very key.
But yes, as soon as you start having
different identities for the same device in different systems,
it can get really quite complicated, well,
depending on how many devices you have
connected, it can be a headache.
Let's look at that,
let's look at what the integration looks
like and how a customer using Mender or
someone using Mender today can
connect their devices easily to Azure IoT Hub.
>> Absolutely. The first thing I wanted
to show you is that I have an environment here,
I have an Usher IoT Hub,
and then I have the Mender server.
I would first head over to the Settings
when I'm starting out and I go to Integration.
As you can see, I've already connected
my Mender server to the Azure IoT Hub that I have.
Now that I've done this,
Mender will automatically create devices in Azure IoT Hub.
So I can show an example of this.
I have a new device in Mender,
I will simply accept it here.
Let me see if I can find if they are accepted,
and you can see the device ID here in Mender a729 something.
Now if I go to my IoT Hub you can see that the device is here.
>> Nice, and in it's choosing the same identity, actually,
you don't have to care about what identity it's using because
Mender took control of that and created
that new device identity Hub,
mimicking what he had in the Mender database, right?
>> Exactly. In Azure IoT that's Mender is using,
so it's easy to correlate those two.
>> Nice. That's the first step.
Really creating that identity,
I guess, and we'll see that certainly later on.
But there's notion of the device life-cycle of my devices.
Identities are created in the system.
But then one day, if the device is being retired or replaced,
you need to manage that identity life-cycle,
basically, and remove it from your systems.
>> Exactly. This is a challenge over time,
obviously, and Mender is also taking care of this.
We call it Reject the Mender.
If we reject the device in Mender,
you would see it, then they're rejected
there but I'll just show any.
If I now go and refresh my IoT Hub,
you can see that the status is disabled,
which is the same as rejected in Azure.
>> Got it. Which means the device will
not have access to the IoT Hub anymore.
It's going to be denied access
because the credentials are not working anymore?
>> Correct. Yeah, exactly.
>> Okay.
>> The same would be true if I
were to delete the device from Mender.
It will also be deleted from the IoT Hub.
>> Nice note.
Mender is used to configure devices as well,
and so what we just saw here is
Mender interacting with the IoT Hub service.
What we didn't see here,
but I guess it happens,
is that when Mender creates the identity and then retrieve
the credentials for that device of that and
then passes it down to the device itself,
for the device to be able to then connect to IoT Hub, right?
>> Exactly. If we take you one step further,
we can see that
the connection string for the device itself is actually retrieved,
just like you said, into Mender,
and we can use
the remote terminal in Mender to take a look at the device.
If you look inside this,
there's a specific configuration file in that Mender.
All the configuration settings that you set in Mender,
and here we can see the connection string for the device.
>> Sorry for the interruption here,
but that's something which is very nice in Mender.
You just seamlessly brought up the terminal here.
But here we are opening an SSD session from
a browser into a device without
knowing the IP address or whatnot of that device,
because Mender establishes that a communication tunnel.
Is that what's going on here?
>> Yeah, exactly. It's not using the association technology,
but it's using web sockets.
But it is a secure channel from the device to the Mender server,
and it's only doing outbound connectivity here,
so it does not require any open ports on the device.
>> Nice. I just wanted to bring
that up because that's something that lot of
our customers might find super useful being
able to interact with the OS
on that device from
a remote terminal that is all secured and taken care of.
>> Exactly. Yeah. You never know when you need it.
If you find things, well,
you hopefully won't need it but usually, you will need it.
>> That's why it's called troubleshooting here, right?
>> Exactly
>> Well, yeah. You did get this connection string
to their device where Mender did get it and
now you're showing us on the device what's going on?
>> Right. Now the connection string is available on the device.
So if I had them Azure IoT application,
I could simply read this connection string immediately I
start sending data to Azure IoT.
>> Nice.
>> I do actually have a demo application
where I could show as well.
>> Okay.
>> This is based on the examples created by Microsoft.
It's a very simple application.
It sends telemetry in an infinite loop here,
and you can see that it's some set of
a frequency that's set by this variable through some interval.
>> Okay.
>> It reads also the device twin from Azure IoT Hub,
and it sets this variable
based on some interval from the device string.
Then it reports back also some interval,
so that we can see from the back end that it
actually has configured application.
>> Here, interestingly, the use of telemetry in
twins is something very common in the Azure IoT world right?
You're going to run this application
what's going to be interesting though is that
your customers are managing
their devices configuration from Mender.
They're not just provisioning,
they're also setting up the configuration for things
like what pace of
telemetry should be sent to your Cloud service, right?
>> Exactly. We do have an integration for this here as
well to configure the Device Twin and I will get into that.
I just wanted to show first
that what you do next is probably to deploy this application.
I have packaged it as a artifact here. It's the single file.
It's just one Python application,
and it includes also a script to start at
them and pass the connection string from that file.
Once I've created the artifact,
as we call it, that contains the Python file,
I can deploy this application to the device,
there are some more advanced configuration,
I won't use any of this right now,
but you can schedule it and you can gradually roll out
the application to the fleet and you
can also synchronize it so you can make sure that
all devices are updated or none
of them are or we retry if there are any failures.
But I'll skip all that now.
So simply just create deployment with
this Python application that's Azure enabled.
As you can see, it's finished already.
Now, if I go back to my terminal,
you can see it's been deployed here in
the directory and there's a log file.
This is simply an application output log and we can take
a look at it as we expect it started sending telemetry to Azure.
>> Well done. That's super interesting,
because you started from a device that only was running well,
I'm always here, plus your client declined for Mender.
I would assume it was
reposition with credentials to access Mender.
Got authorized to connect to Mender and then
Mender did create the IoT hub identity,
retrieve the credentials, send them down to device.
Well, eventually when you did configure
a deployment of an application that was using these credentials,
and so you were able to deploy the package
and then have to basically
start from a device that is almost blank.
We have the mender client
and then you end up with something that is
sending telemetry to Azure IoT as pretty without touching it.
>> Exactly. As you touched upon earlier as well,
we also integrate it with the device swing in Azure.
We added this device twin.
As you might remember, from an application,
there was a device twin property called an Interval.
That application was reading so I will simply change that
to five for the sake of this demo.
If we look back at, let me see,
if we look back at the application output,
you can see now that it did
receive the new sender interval
and it reported it back also to Azure.
>> Brilliant, pretty straightforward. Love it.
That's definitely a great demo here,
but there's one more thing that a Mender does as well.
It allows you to monitor devices.
You're able to get some level of information about errors
going on that are proper to Mender.
>> Exactly. In this case,
what I wanted to monitor is the connectivity to Azure IoT hub.
I will paste in two commands here in the terminal,
and I can explain them very quickly.
What this does is tell the number to create an alert.
If the word transport_exception
is found in the application log file that we were just looking at.
This is a bit application dependent what kind of errors.
But you can customize this here.
What I wanted to do is to actually try to trigger an error.
If I find my device in here,
let me see if I remember the idea of it first a seven something.
Same here. What I'll do here,
I'll simply disable the device in Azure IoT hub and that should
definitely cause some trouble for
our application not depends on sending data to Azure IoT.
If we go back to the memory interface,
there is an option to filter
devices that require attention and
you can see here that there is one.
The one we have actually has
an issue and we can scroll
down and we can see that this alert has now been triggered.
We can look into it and you can see
the matching line here that we were looking for.
It contains transport exceptions,
and you can also see
the lines leading up to it in our application logs,
you can see the full length section here to
help you get some more context,
as well as the following lines as well.
>> Awesome. The full monitoring definitely integrated as well.
I was just thinking about an interesting scenario
here which is any devices,
there are different types and connected
to different backend systems.
You might not all send to a single IoT hub or a single Cloud,
actually and so you can still manage for Mender
all these devices in one place in terms both of configuration,
deployment of apps and logging.
While these devices eventually talk to different backends in
different applications and everything is monitored here at Mender.
That's one of the valid scenarios I would guess.
>> Exactly. A lot of things
can go wrong when you connect to different systems,
and you definitely want to have a way
to make sure that you catch these issues.
>> Awesome. Eystein that's great and I love this integration.
I love the way you guys have simplified that connectivity
for your customers and our joint customers, hopefully.
If you want to learn more about what's going on with Mender,
its integration with Azure IoT,
you can go and check out this link below here,
aka.ms/iotshow/mender.io.
Nice time. Thanks a lot for coming to the show.
Have a great one, everyone.
Thanks as well for joining.
[MUSIC]