>> If you are interested in MQTT or are already an
expert in that domain, I'm sure today's IoT show
will be interesting for you. Shane is joining me to
share his experience in discovering Azure IoT services from the perspective of an MQTT guy. That's today on the
IoT Show with Shane. [MUSIC]. >> Hi, everyone. This
is the IoT show. I'm Olivier, your host. Today we'll make sure
that friends don't let friends do IoT without Azure. For that, we have Shane with
us today. Shane, how are you? >> Not too bad. I love the T-shirt. >> Yeah, right. >> It's very cool.
I need to get one. >> I'll send you one.
I have some of these. >> Please let's do it. >> I've been waiting for being
on an episode with someone like you to spot the T-shirt and go through that
sentence, to be honest. >> It's good. >> Yeah, so my friend, let's
talk about your background. Let's talk about MQTT. Let's talk about how
you came to learn about Azure IoT tools and services. Let's share your experience
with other developers out there so that
they know what to do, what not to do, where to go. Everyone's experience is
going to be different because everyone has
different objectives, different skills,
different preferences. But still, it's going to
be a very interesting conversation we're
going to have today. Before we jump into
that, who are you? >> I am Shane Baldacchino. I am a passionate technologist
out of Melbourne, Australia, currently, work for Microsoft in the role
of Chief Architect in Australia. My background is someone who's been incredibly passionate about
technology in general. The kid who took a dose manual to school for
show and tell at age eight. That probably gives you a
little bit of a taste here through starting and
founding a startup, through to working for a scale-up. I've worked for hyperscale
Cloud providers and for really large food manufacturers and now here I am at Microsoft. >> Having fun, playing
around with technology, recommending architectures,
and so on. Right? >> That's what we do exactly. Demystifying the magic, helping customers see around corners and get past
those rough edges. >> Love it. You have
a blog plus we'll send a link at the
end of the show here, that people can follow
you and can see your, what I call tribulations. Right now you went through
that experience of discovering the Azure IoT services
and for that you wanted to connect your
home automation system. Tell me a bit about this
automation system of yours. >> Look, I would like
to think I've got a somewhat more advanced automation
platform than most here. It's based off an Allen Bradley PLC, what you might find
on the factory floor. But the challenge of that is things cost a lot of money
when you're talking, PLCs. That Allen Bradley PLC, with its limited amount of I/O. Bulletproof by design, I squared C, digital inputs and outputs, analog, the whole kit, and caboodle. I came to a point where I run out of I/O and I needed to
expand and I thought, this is getting a
little bit expensive. Having alarm system that is
also wired over the top, it's got a serial IPI
like an event hub stream. It controls my doors, my locks. Doors and locks are the same thing. Motion sensors all
through the house. It's my eyes that feed this PLC. But I needed more I/O, and I went down the path of, I could probably run an Arduino
mega and I might use it as an I2C slave to the PLC. But look in the fullness of time, you go through things, you evolve, things change, and
I settled on MQTT. It's a bit of a standard these days. In my house today, MQTT does everything from doors, locks, through to roller
shutters for windows, my solar PV array, alarm, sensors, it's a transport
medium and a bit of a fun fact. I found this way at the end after
I wired everything into Azure. My house does 1.4
messages per second, averaged over the course of a day. Eleven thousand messages a day gets shunted into
Azure IoT help today. You can find some really
interesting results when you're starting to get
that amount of telemetry. >> Got it. That's interesting because you were saying
MQTT is a standard, I like the metrics you just shared. But back to the MQTT topics, a lot of customers are using
MQTT in the industry as well. It's not just like a
protocol that's been used by hobbyists for their
home interaction system. Is something that is used broadly, it happens to be the
protocol used by lots of the hyperscaler IoT platforms
as well, including Azure IoT. We're using MQTT though in a way which is a bit particular
and you're going to share a bit on some of your rantings
or observations on that one. But we're going in
direction that I think people will like in terms of
supporting an actual MQTT broker. You basically created your
own automation system, evolved from that PLC that
was not everyone's PLC, and then you landed
on an MQTT broker. Like Mosquitto that's is installed
on the machine at your place. It allows you to orchestrate the messages between all these
devices that you have in your home. It was purely local
though, in your home. >> Correct. We've gone from
a PLC to having an Arduino. Initially, I had a HTTP interface between syncing things up
and all that practical. The UI has also change so Home Assistant incredibly
popular platform. I'm sure lots of our listeners here today watching this show
are using Home Assistant. Home Assistant to me is like the presentation
layer for everything. But we've got
realistically implied as Home Assistant there is a PLC, there's an Arduino, and there's about 100
different things that also speak and subscribe to MQTT
topics out there as well. It's a bit of an evolution but yes, MQTT is the spine, Mosquitto is effectively
the backbone of my house, which is a popular MQTT
broke up by Eclipse. I wanted to initially when I
joined Microsoft, I'm like, can I just sync Mosquitto
into Azure IoT, just like I did in the past. The answer was kind of not
right like it is possible. It was great because it enabled me to really get an understanding, a taste of Azure IoT, the nuances, what works, what doesn't work, what are the strengths, what
are the weaknesses, and so on. >> Honestly when you
came to me the first time and you introduced
yourself and we got to discuss, got all excited about the
potential things to do. I was like, yes, we do support MQTT, but you're an MQTT broke, I don't know, let's try it. You went on with the
first experience, which is about connecting that
MQTT broker directly to IoT. You were saying not so positive, certainly not the scenario that IoT hub has been designed
for to start with, but tell me, what was your first
experience with that first trial? >> My first experience was, I can't find anything
on Google, Bing, whatever your favorite
search engine is, that would help me down this path. Azure IoT Hub, today is not fully MQTT compliant. >> Yeah. >> We lack that broker, so I tried initially to get
the Mosquitto client tool. For those who aren't familiar
from Mosquitto client tools, they are popular
tools for Mosquitto, the MQTT broker, to simulate subscribing and
publishing to an MQTT topic. It's a pub sub-system. >> At home, I am running
MQTT with not over TLS. Azure IoT of course, it's a public implant, it
requires TLS which is fine. But having a trusted route
certificate authority, so our route CIA is not trusted, it requires learning
key change and it just became a little less practical
than what I thought it would be. It would mean I would have
to modify all of my devices, the light switches
behind me here and so on to speak to Azure
IoT hub and then, more so when we talk
about the laws of IoT, needing to turn a light switch on as an example and having to send a call out to the Azure Cloud is not going
to bode well if I'm not here. If something goes wrong, I'm sure my family would not be
the happiest with that situation. It was more of a proof of concept. Could I get these to
talk to each other was the question I
was asking myself. >> First solution not working
well for you because of TLS, because of these things,
which makes sense. Actually, it seems to me that
you wanted to keep things local. You want to keep something
happening down there. The control wheel
should be down there. The autonomy should be down there. You don't want to
rely on a back end. It might not be accessible
for some reason. What was your second
option and trial? >> Well, the second
path here is IoT edge. It's a fabulous platform, incredibly extensible,
containerized in effect. I have a 42 IU rack in my house
because of course, one does. Alarm system is recommendable, storage is recommendable, but today the only
realistically compute that I have in my house is one IU
worth of four Raspberry Pi, is power every ethernet has, powered off a switch and I went down the path IoT edge just
started supporting, the humble but
formidable Raspberry Pi, MQTT was in preview form. I thought, hey, let's have IoT Edge, be my local MQTT server. Could I replace Mosquitto and
have my things in my house, my PLC, my devices, everything., those 1.4
messages a second, could I send them sent into
IoT Edge and then have them be transparently proxied into Azure
without reconfiguring my devices. It was somewhat successful, but I still needed to
reconfigure my devices. You need to add every device
as a child inside IoT Edge and it was going to be a little
bit too hard for my login. You've got your t shirt
friends don't let friends do IoT without Azure. I've got a Pied Piper
t-shirt on, I like to build. So we have a pivoted,
I thought, hey, is there a better way to do
this that meets my needs here, thinking about all the challenges
that I had with my house, I've had to build
my own thermostats. I've built interfaces with cooling
and heating systems and so on. I'm familiar with the oscilloscope
and the soldering iron, so I thought, hey, let's build. I pivoted. In the last probably 5-6 years, my skills have
definitely moved towards the open source world and
we've got a Python SDK. How awesome is that? I pivoted and I thought, hey, could I build my own version
of let's say version of IoT Edge but could I do the
same thing as IoT Edge was doing, without having to add
more devices into Azure IoT Hub and with the
any device configuration. >> When you say the
same thing, well, basically you were
looking for as well, first not change any code on the lead devices for them to
just talk MQTT to a broker, and then that broker would be doing the identity translation as well as whatever data
transformation you needed to fit in the data onto Azure. Is that a great capture
of what you did? >> Yeah, exactly. Pretty much. Look, perhaps we'll switch
to sharing my screen. >> Let's do that. Let's
look at what you have here. >> This on the screen here is a
scenario of what I've ended up at. On the left hand side
here we have the things, lots of things, over 100
things speaking MQTT. They continue to speak to
Mosquitto or my MQTT broker, and then we're using the
Paho Python library, so power MQTT, along with the Azure IoT Python SDK and I'll just make a
call into Azure IoT Hub. It is one way. Today, I only push
messages into Azure IoT. I do not receive messages back, but the SDK does support that. If that's something I want to go down that path in the
future, then absolutely. I'll switch now to a little
bit of code here and just walk our audience through
how this magic happens. As we can see here, we have
some Python code here. It shouldn't be too hard
to follow along at home. We're importing a library, so importing our Paho, so Paho is going to
speak to Mosquitto, and we're importing
Azure Python IoT SDK. Now a bit of I like to print
stuff out nice and verbose. We've got a few functions
here on Connect. We've got a callback and we've
got a sync call into Azure. I'm going to scroll down
to the bottom because basically how this works is we are connecting
to our Mosquitto, we're going to listen for messages. We're just listening for messages. >> Here you say when
we receive a message, you're basically listening to the MQTT messages that are
arriving on your book, right? >> Yes. Now, what I should
probably point out here is MQTT has a bit of
a topic structure. What I'm listening to is, I'm listening on the path stat, plus or to match anything and power. Now, I might just bring up MQTT explorer. Now I think my kids are
stationary at the moment, but this is a topic structure here. What I'm saying here is, I want to know for example, here we're looking at stat, anything that matches
stat and power, I want to understand if
the state has changed. I'm going back to our code.
It's my topic filter. You could do a topic of, say, hash, which is a wild card
to match everything, but you will also get some
broken stats as well. But look, we are
waiting for messages. Once we receive that payload, we then run an asynchronous call
on call that Azure function, which then goes on its way, do a bit of manipulation of the message and I send
a payload into Azure. It's great to talk about this, but I would like to show not tell. Let me just open up
my terminal here. Oops. Kick this off, I'm just trying to make
this a little bit bigger. >> Look, we are listening
for messages now. I have a few messages I've
just left on my broadcast. Inside MQTT you can define what's
called last will and testament. You can have messages that are
effectively that persist on there. For the purpose of this demo, we're getting a lot of
messages initially, but then it will catch up to that, 1.4 or so messages per second. >> We're better that
rhythm right now. Say one something every
second basically? >> Yeah. >> You have the system
working here, as in, receiving a message and
listening for topics that are about power and then sending all
these messages up to Azure IOT. All that in a few lines of codes. Actually, you don't have much there. >> It's like 80 lines of code and a lot of it is a lot
of print statements. Because I'd like to know
what's what's happening. >> Yeah. Another matter of fact now if you want
to receive something, you can attach a callback in your Python code to the
"Cloud" message and then basically send that to devices using the MQTT brokers, the clients. You can actually now
then send a message to the devices in the MQTT
format using the right topic. >> Correct. I think that's
a lot of being builders. It's really up to us. SDK supports being
able to call back. I could send a message
back and then what I do with it is completely up to me. I have this thing when the garage
door opens and it's my wife, my lights in my study here, the flash a different color to
let me know that she's come home. You can do so many things. The world is your oyster. Think about Azure is effectively
just another input into my house. >> That's interesting very
often we're talking about, Azure and the Cloud
being where things are happening and I like your
perspective of like, no, wait a second, I have my
MQTT infrastructure here. I have my broker. I created
my collection of topics. It makes sense to me. My system is here. The Cloud is going to be a way of monitoring and eventually
controlling remotely, but the system is here. The intelligence for now, I build it here. I want
to keep it like that. As a matter of fact, you were saying with that last solution of yours, you didn't have to change
anything on the devices. They're still talking
to your broker. The broker is there and you're
just interacting with that broker, using the Python client for Azure IOT to have
that interface up there. >> Correct. >> Nice. >> I hear you went on
an experiment with the embedded C SDK as well
because you are a maker, right? >> I'm a maker and what
I have learnt over time, we all are constantly on
a learning or planning, filing and learning path is. Hale sales and micro-controllers,
they're really reliable. Think about the Raspberry Pi that
this is running on in my rack. It's pretty reliable,
but it's got an SD card. Yes, you can flash them these
days to be able to boot off USB. You can get some devices, [inaudible] a boot off an SSD or an NVME and with their
compute module form, it's got PCI express. You can effectively boot off NVME. But it's still got
an operating system. It needs to be watered and fed. Now, I'm sure I don't need to tell you or our audience here today. There is nothing more
reliable than hardware. These micro-controllers are
just really super reliable. I was super excited
to say that, hey, we have started to
support the esp32 device. I'm a big fan of that because
it is Arduino compliant, something I'm familiar with. I thought, hey, could I pull
what I've just done into hardware and the answer is
absolutely. I went on that journey. >> Okay, so basically creating
the embedded C Client. The piece of code you're
describing is still interacting with your
broker running on that Pi. The brokers are running
somewhere and you just have the ESP to device it. There will be the Azurifying of
your solution device. Right? >> Yeah. I've got an esp32 on my desk and so how
that shows on camera. But look I'm, I've got some C++
code on the screen here now. It's effectively the same as Python. The logic is the same, and usually we're connecting
to we've got a set up here. We're connecting to our broker, we're connecting to our WI-FI. We're stuck in a loop until I
can connect to my local broker. If we go through a bit
of a set up function and once we're connected, we are just waiting for
messages to be received. Then we push into Azure IOT Hub. >> Yeah. >> I'll just go back up here. It's exactly the same thing. Wait until we're connected
and here's a callback. We're waiting for messages here.
It's a little bit different. Yes. To the path in here. The challenges, I guess in the
C++ is just different to Python. I'm sure we can all agree
it's just different, but the logic effectively
is the same here. We're subscribing to topics, messages are coming in, we're debugging them, not debug, we're decoding the
messages coming in in the payload and we make
a call into Azure. If I go down the very bottom here, I believe, we send the message. >> I found something very
interesting here, Shane. In your journey, you started with, I'm an energy developer. I'm doing MQTT stuff. Here you are trying to
trace this from the esp. Basically the same thing is what we're saying on a Python app, right? >> Correct. Yeah, exactly.
That's running now. It's actually doing the same
thing, but it's in part with. >> Yeah, we're saying that in your
journey you started off from, I'm in MQTT I want to talk topics. I remember we had a conversation
you were telling me, hey, all of you have the force, the format of the topics and so on. It's annoying. I can do
that, what I want and so on. Interestingly, your journey, you went on to decide that, Hey, you know what, at
the end of the day, I want to keep my MQTT
broker infrastructure here and what I'm going to talk to Azure IOT actually in your
code when you talk to IOT, you don't even care
whether it's using MQTT, HTTP or whatever protocol. It doesn't matter because
you have a function. It's called send event, right? >> Correct. >> That's all you need to to
communicate with the "Cloud" here, even though under the hood
it's also using MQTT. But from your perspective, it doesn't really matter because
you have an SDK which comes as a software library that makes
that easier for you, right? >> Yeah. My summary
from all of this is our SDK are incredibly powerful. For me as a builder, being able to use SDK was, it opened up so many possibilities. It was really quick. We're talking like less than 100
lines of code for both solutions. Yes, I can make them a
little bit more robust. I could have them to be full duplex, but we're not talking
much code here. >> Yeah. >> The SDK is do a little
way with, like you said, it doesn't matter if I'm
speaking MQTT or not. Ultimately, I'm still getting my messages into Azure and
achieving my outcomes. >> One thing that you
started off saying that, in your first experiment, you had issues with TLS, for example, here with SDK, you basically are just leveraging the infrastructure of the SDK to use TLS stack that is available
for the CE example on Python, it was pretty
straightforward as well, leveraging the search store on the OS that is, hosting
the application. Using the SDK definitely should
be the final thing here. You didn't have to do anything
else and just provide the credentials and
things were connecting, working and everything securely. I'm fairly sure our teams here will be very happy
to hear about that. Shane, thanks for sharing your experience here.
You have a blog post. We're going to bring
up the link down here and it's going to
be a description here, which is
automation.baldacchinno.net with two c and h in a middle there. Shane, you're welcome in the IOT in the future when you have some more
experiments you're working on. I'll be happy to put
you on the wrong track so that then you're
going to correct and tell me no Olivia it
doesn't work for me. That's going to be a
fun one, I'm sure. >> Thanks Olivia and look, thank you very much for having
me on the show tonight. >> Well, thanks for coming. Everyone thanks for tuning in and hope to see you soon on
the IOT show. Bye, guys. [MUSIC]
