>> Did you know that you can send
device telemetry to Event Grid thanks to IoT Hub?
Well, that's a new capability that Ashita from
the Azure IoT PM team is
coming on The IoT Show to tell us everything about.
[MUSIC]
>> Hi everyone. Thanks watching The IoT Show.
I'm Oliver, your host,
and today we have Ashita back on The IoT Show to talk about
enhancements to the Event Grid Integration
of IoT Hub. That's a lot of words.
>> Yes.
>> Thanks Ashita for coming to the show.
>> Thanks for having me.
>> So real quick, once again can you introduce
yourself and your team for those who don't know you.
>> Sure. I'm Ashita and I'm a Senior PM in the IoT Hub team,
and I focus on data integration type features that help
our customers flow their data from IoT Hub to
different Azure services or their own business applications.
>> So Azure IoT Hub is becoming
a very powerful device gateway that
not only allows to ingest data from these devices,
but also last to be smart in the way you're going to actually
route these messages to various endpoints,
and services, and the rest of your application basically, right?
>> Yeah.
>> Until now we had an integration with Event Grid
which is the Azure pub-sub infrastructure that was
just about some of the creation and
deletion of the devices in IoT Hub device registry.
But now you can actually start
sending to Event Grid telemetry messages.
>> Yeah.
>> So tell us a bit more about
that unless I spoiled the whole thing.
>> No, that's perfect. So, yes.
So as you mentioned, we already have an out of the box capable
called message routing that allows
you to automatically configure routes,
and send data to different endpoints.
We support only four different services
as custom endpoints in IoT Hub.
One being Event Hubs,
Service Bus Queue, Service Bus Topic and storage.
>> Okay.
>> But Event Grid opens up that endpoint lists
to many many other server-less application type services,
and also third party applications.
So I can send data to Azure Functions, Azure Logic Apps,
Microsoft Flow, or even
my third party application through a Webhook.
So that's a big benefit of using Event Grid.
>> So Event Grid actually was mentioned as a pub-sub system.
So in principle, you will then have IoT as a publisher, right?
>> Yes.
>> So you're a publisher on
that infrastructure and any other service that actually can be
a consumer of these topics on
that pub-sub system can actually receive that notification.
>> That's right. Exactly right.
So Event Grid is actually
a universal back-plane that is connecting
Azure services with other Azure services,
and as more and more services
onboard as publishers and subscribers,
it's really easy to push events out
to other things and trigger workflows.
>> So I have a trivial question.
Why do I need to go through IoT Hub?
Couldn't a device directly post
a message on Event Grid to trigger something?
>> IoT Hub gives you the benefit of having
per device identity and security,
which is really important in IoT scenarios usually.
So that's a big benefit of going through IoT Hub.
>> Makes sense.
>> Yeah.
>> I think there's another aspect of it because now
that we have that Event Grid integration,
why will we need to eventually
still send and wrap message to Event Hub,
or topics, or what's
the difference and when would you use which one?
>> Yeah. So routing allows you to give ordered messages out.
So it guarantees ordered delivery where Event Grid doesn't,
but Event Grid gives you the option of expanding that
to many endpoints and many types of endpoints.
But routing you can also use because it's free,
Event Grid is going to charge you
to ingress the data to Event Grid,
and then egress, even though it's very
smallest at $0.60 for a million events.
>> One million. Okay. Yeah.
>> Yeah. But routing also has very rich queries.
So you can actually apply querying on
device twin as well as the body and then routes default.
>> Okay.
>> So for many customers,
100 routes are enough,
but sometimes they needed to go to more.
>> We're talking about the scale,
because like eventually you have
a big IoT application with like millions of devices.
What kind of scale are we talking about in
terms what Event Grid can ingest?
>> Even Grid can Ingest about 10 million events a second,
so it can handle up to scale.
>> So we're good?
>> Yeah.
>> Awesome. Let's look a bit more into how it works,
and show us a demo.
>> So as you mentioned, we actually have
four Device Life-cycle events today which are available.
Like device created, device deleted, device connected,
and disconnected that can trigger
workflows for customers in near-real-time.
So we've added a new events device telemetry
which is basically the device data that comes from the devices,
and it's going to Event Grid.
>> Okay.
>> Here's what the events schema looks like,
and I would just like to go through it real quickly.
That every event that comes from
IoT Hub to Event Grid will be
put in this envelope from Event Grid,
and what that entails is
an ID with is a unique identifier for that event,
a topic which is which resource gave this event,
and in this case it'll be our IoT hub,
subject is the device ID that produced this event,
and then the event type and time,
which is what time the event was generated.
Data is where IoT Hub populates what needs to be in this event,
and here we have basically the IoT Hub message format,
and the body that is coming from my device.
The properties are obligation properties,
and then system properties.
>> So I can put, basically if I have,
a bunch of data that I put into
body eventually it's binary whatever,
it will still flow through Event Grid [inaudible]?
>> Yes. It will still slow,
but it'll be in the Base64 format.
>> Yeah. Okay.
>> If this content type and encoding are set to JSON and UTF-8,
it's more powerful because you can then actually filter
on the content of this in your subscription. Yeah.
>> Got it. Okay. Makes sense.
>> So in order to demo this, I'll do couple of things.
I created a logic app to
post a message on a team's channel every time an event occurs,
and then I'll go and create an event subscription,
and then we'll test it with a device simulated.
So let's first look at the logic app.
So here I have a workflow
where anytime each of the request is received,
I am going to take an action of posing on my team's channel,
and in the request I actually was able to put
this event schema into there
so that logic app was able to parse it,
and I use that to create a message.
>> Okay.
>> All I have to do is basically copy this HTTP link,
and I'm going to use Webhook as my endpoints.
>> Okay.
>> So in IoT Hub,
we have this Event Grid blade.
This is a universal blade that
any service publisher for
Event Grid will have the same look and feel.
>> It's not specific to IoT Hub.
It's just, I'm the publisher on Event Grid so
here is the look and feel in the data I'm going to put in there.
>> Right.
>> Okay.
>> So I'm just going to add a name to this subscription,
and you can see here that we have
four events pre-selected which is all of our device events.
So let's say I want to add telemetry to this,
and my endpoint is of type Webhook,
and all I have to do to create this
is paste my HTTP link here, and that's all.
So it's that easy.
Now let's test this.
So here's my Teams channel,
and what I'm going to do is I'm hoping to see events here.
So let's go and look at a device simulation.
So here is my device I'm sending, weather, temperature,
location, and I've set my content type encoding to JSON UTF-8.
>> Nice.
>> I'm just going to play this,
and it's going to send me telemetry every five seconds.
>> Okay. Sent.
>> I am hoping to see data here right away. Here we go.
>> Yes. Pretty straight forward and fast.
>> Pretty fast. So it's near real-time.
>> Nice. Actually is there any,
you say near real time,
do we have SLAs in terms of to
Event Grid messages ingestion delivery?
>> It does guarantee delivery,
and we'd retry 24 hours.
>> Okay.
>> So IoT Hub has a retry policy of one hour,
so it'll try to send the message to
Event Grid with retries in an hour.
But then Event Grid will try to send it to
its subscriber in 20 products
>> Okay. When you are developing
an application into one in the Cloud anyways,
you can actually instrument the application to monitor
the errors that the services will send,
and so if a message was never sent,
and after retry it,
you should actually monitor that there's been
an error in the message sent
and then react in your own application?
>> Absolutely. We have rich monitoring metrics
for both these things.
>> Awesome.
>> So now just to explain what actually happens behind the scenes.
Whenever we create a new device telemetry subscription,
IoT Hub is actually going to create a route to Event Grid.
>> Okay.
>> Now, note that you may have multiple subscriptions,
but there will be only one route because for IoT Hub,
Event Grid is one single endpoint.
>> Okay.
>> In this route, what users can do
is actually filter data go into Event Grid.
As I mentioned a vendor
charges when you ingress data to Event Grid.
If customers do not need to send all the telemetry all the time,
you can easily go in here and just change the query.
Note that nothing else is editable,
so the data source can only be telemetry messages,
and that's when the route is created for telemetry.
So I can go in here and actually
I can say, $body.Weather.Temperature.
Sure is greater than let's say 25.
>> Okay.
>> So my device data is between the range 20-30.
>> Okay.
>> Now, I'm expecting that every time the data is above 25,
only then I will get the message.
>> Got it. Anything below will not be sent?
>> Right.
>> Nice.
>> So let's say I go to 26 and then 24,
let's give it some time to see the route.
>> We should only see the above 26.
>> Above 26, right. So you notice 24,
21 will not show up,
and then 29 will show up.
>> Awesome.
>> Right.
>> Love it.
>> Now, another thing in Event Grid is that we have
the capability to filter in the subscription,
because as I said, you may have many subscriptions,
but you can query on one route.
>> Okay. So we can actually go in the Event Grid subscription,
and this is a very advanced filter where you can filter
on the body of the message as well.
So all I have to do here is add a new filter.
My key value is going to be my data.
>> It will be we fair to say that once you've adopted
the Event Grid infrastructure,
basically you would recommend doing the filtering there, right?
>> Yes.
>> Okay.
>> The only advantage of routes is you can
filter on device twin as well.
>> Okay. Yeah. So let's say I want to do this now at
27 for this particular subscription.
>> You can actually also, as you're doing,
piling on the various,
there's the route and then there's a filter?
>> Yes. Yes.
>> Okay.
>> Yeah. The concept is very similar.
You basically have a data source
and an endpoint where it goes in a filter.
So it's pretty similar.
So this is saved,
and I'm expecting to see data only with when I have 27 degrees.
So I go to 21 and 23.
>> These ones will not show.
>> That's right.
>> Then if you have changed so you're going to get something in
between 25 and 27 that
will not show in here because of that second filter you just have.
>> That is correct. Yeah.
>> Okay.
>> Yeah. So I think that just showed up,
25 did not show up between the Intune.
Yeah. So this is very useful
when you are pools processing data from many, many devices.
>> Yeah.
>> You have micro services
that need to only get to particular set of data,
and if you're running different functions
every subscription can have a different filter.
>> I love it.
>> Yeah.
>> So if people want to learn more they can go to
that aka link that you have up there,
which is aka.ms/ iotshow/telemetryoneventgrid, one word.
Awesome. Ashita, thanks a lot for coming on the show again.
I really look forward to
your next appearance to talk about IoT Hub messaging,
and all the goodness in there.
>> Thank you.
>> Thanks all for watching The IoT Show.
Don't forget to subscribe, and I'll see you soon.
[MUSIC]