Episode: 1035
Title: HPR1035: OGG Camp 11 Panel Discussion
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1035/hpr1035.mp3
Transcribed: 2025-10-17 17:45:06

---

The full circle podcast on Hacker Public Radio in this episode, Ogg Camp 11, Andy Piper
on MQTT.
Hello World and welcome to the full circle podcast on Hacker Public Radio.
This is the fourth of our highlights of last summer's Unconference, Ogg Camp 11 held
at Fawn & Malttings in the south of England.
The full circle podcast is the companion to full circle magazine, the independent magazine
for the Ubuntu community.
Find us at fullcirclemagazine.org forward slash podcast.
So this is Andy Piper's presentation on MQTT, that's MQ telemetry transport, which
is a messaging protocol.
Or more precisely, MQTT is a machine to machine, Internet of Things connectivity protocol designed
as a lightweight, published and subscribed messaging layer.
It's useful for connections with remote locations where a small code footprint is required,
or where network bandwidth is at a premium.
It's been used in sensors communicating to a broker via satellite link over occasional
dialogue connections with healthcare providers and in a range of home automation and small
device scenarios.
It is also ideal for mobile applications because of its small size, low power usage,
minimized data packets and efficient distribution of information to one or many receivers, at
least that's what it says on the project homepage.
Andy Piper called himself a social bridge builder, photographer, diehard, techie, speaker
and podcaster.
He works as the web sphere messaging community lead at IBM and sits on the committee for
at Digital Surrey.
I'll let Andy tell you more.
Thank you for coming back today to everyone, I think everybody enjoyed the party, I had
a splendid time, and I think yesterday, you were a different section to mention this
thing, we don't keep TIT.
I know a few of you in the room are completely met, some of you are grinning about that.
Excellent.
OK, so this is my first op-camp, it's become something of an op-camp theme, this particular
project.
So let's have a look at what's about, so fundamentally, it's kind of an exciting time,
because as a few people mentioned yesterday, we've got this whole piece of equipment.
What does that mean?
It means that increasingly we've got very powerful, very small devices, and we've got ridiculously
lacking in power, very small devices, but which have enough processing power to increase
the data, and probably some means of transmitting the data.
Now, we should mention my work right now, and I'd be able to talk about this in a small
market, a small plant, and so the idea is, is that we're helping with the world's
next-all of these devices, by pulling this information together and making some connections
between the information and matching it up if you like, we can start some interesting
things.
So hopefully, improve the way you live.
So in order to achieve this, wouldn't it be nice if we had some protocols, or we've
got some protocols, we've got a protocol for T-C-I-P, and we've got some others, and
I'll mention a particular one, as we go through this tool, but N-Q-T-T-S is another
protocol, which we think is really interesting in this place.
So as I mentioned, this is a bit of an op-camp theme, the first op-camp of 2009, my colleague
Dr. Andy Stamford Clark here, who actually invented the protocol over 10 years ago,
talks about its Twitter accounts, and some Twittering barriers, and if you don't know
Andy, he's got some great talks on my own.
I think this video is this first op-camp talk as well, but certainly, there's more
yet close, which is on the slideshow, which you can have a look at.
So Andy is much more prepared than I can ever, as far as I've been.
He has a farmhouse and a lot of white stuff, which he has heavily introduced, just a
little bit.
He can possibly imagine, including the instruments of the cheese, and the mouse traps in his
loft, because he's discovered that, no, there's no adjustment, the instrument of the mouse
traps, so he knows on his smartphone when the track has been sprung, and he's going to
clear out the dead mouse.
And he's also discovered that he might have quite a certain crutches, so if the cheese
isn't crushing off, the mouse might have been weird, so he's stuck a couple of electrodes
into the mountain, into the cheese, and there's a half on this resistance, goes up and
he knows that the cheese isn't crushing off.
So, yeah, and all of this is done using his own QTT protocol, that's what it's called.
He also has a long form, and they can track the lambs around the field, which is this protocol.
So Andy haven't had a load of stuff in his space.
I mean, there's a load of products that implement QTT, this protocol, but Roger, the day
of the same day, the same evening, the same day, the original talk, created a record called
mosquito, and has been developed on that for the last couple of years.
So, here we are, in 2011, the third iteration of all CAP, and the third iteration of the
first set of big news I had to share about QTT.
So, I'm going to talk a little bit, first of all, about the big exciting news, and then,
if you come across anything to see, I'll give you an introduction to the protocol, and
why we think he's exciting, and it's something you should look at.
So, lots and lots of things have happened in the last sort of 12 or 18 months.
First of all, we have a community site, and QTT.org, where we try to collect as much information
as possible to use for people that are developing this protocol.
And we know what it's like, can't make you eyes in around about 12 languages, including
things like Delphi and Leua, as well as the kind of classic, well known languages.
IBM, for a company called EuroTech, has shared the specification.
We published it last year for re-punched last year, under a royalty-free list, which means that
anybody can go ahead and build this protocol into their products.
Now, I'm going to give quite a similar talk to this one at Leua's conference in Australia in January.
And I was talking next to a lady from Intel, who is responsible for Leua's Intel's working
with a network and strategy process, and she said to me, well, I don't know.
A royalty-free is not good enough, is it really?
You know, how can we guarantee it?
It's very much sort of things that Karen and Simon were talking about yesterday.
How can we guarantee that you're not just going to sort of change the losses back into some stuff?
Last week, in fact, on Friday, IBM and Eurotech opened their standardization pool.
So, the plan is to put this forward to a proper status body and have their managed
press cost specification going forward.
There's open tools for any of you happy music, press development.
We'd be delighted to have you get involved on this, give us your feedback on the specification.
Now, that was the official news last Friday.
This is my day job, so this is a thing that I published.
And then I came up with a podcast and published a Friday event.
And all of a sudden, my email and Twitter started going nuts because the other thing happened.
It was, first of all, a company that you've heard of, announced that they are not using this specific purpose
this protocol for any first of a messenger.
I don't go looking for it to many European app stores on Android or my phone,
because it's not made available yet.
It's available in the US at any moment.
But they have a new group messaging app.
They call it a company called Beluga in about February this year.
And they've been an inspiration Beluga and they now have a group messaging capability.
EnergyT is a very small protocol, which Lucy Zangir suggests is useful,
so I'm going to take it to a question about the other things.
The point is that this particular protocol is designed explicitly,
I'll go into this in more detail, to optimise the bandwidth of your music and optimise the power of your music.
So as she noted, we have a very good ability to achieve both,
with delivery in hundreds of milliseconds, and also the very power of your music.
So it's extremely cool, and to have a company like Facebook actually validates technology at this point,
is really exciting.
Now let's have a chat application.
And I started off by talking about these kinds of things.
So let's see if we can join some of this stuff up.
So in QTT stands for in key telemetry transport.
IBM has been in the application application,
and we're now beginning to collect two M machines and machine messaging space for about 15-20 years,
with something called NQ Series, message-curing.
So this is not about sending emails, it's about saving small information between applications of your system.
And my data for the last 15 years can help them pick companies to integrate their data-price systems,
their account systems with their new high management system with their new cloud thing
that they might be doing on Salesforce.
And that's an important role.
Because if you're in a counting organisation,
you really don't want to lose production, but lose the ability to build somebody,
because your message wasn't reliable enough.
So we can rely on messaging.
But typically, back to the moment, we need to do things like persisting the data,
we need to do things like, you know, hands shaping all these kind of things.
And there's actually a spectrum of capabilities that we need to be able to address.
And increasingly, we've got this, you know, very small development set of devices.
We've got these lightweight networks that we want to use.
So we know that at the other end of that scale,
we want to deal with much smaller devices in your big main range of new systems.
And that's where the slavery aspect gets in.
Let's talk a little bit more about what this looks like.
It's a publishing-subscribed mechanism.
So if you're not familiar with that, the idea is that when I send a message,
I send a letter, rather than send it directly to somebody,
I can just say, here's some information about the weather in the farm in the UK.
And somebody gets subscribed.
So I'm interested in all information about the weather.
Or they could say, I'm only interested in information about whether in the farm in the UK.
And they would receive all of the information to be published on most topics,
based on that filtering.
So it's not a point-to-point approach to tell this explicitly about publishing information
to a large number of listeners potentially or to no listeners,
because they might subscribe to the information they're publishing on you.
Another design point is that 10 years ago,
we had many years ago, when this was designed in the first place,
Andy and his colleagues were dealing with very kind of reliable networks
with potentially very small bandwidth.
Potentially very able, kind of satellite connections to, you know,
in the middle of an oil field in Siberia.
So we need to be very, very efficient with our new system to support that network bandwidth.
Not only that, we're dealing with potentially low bandwidth, very high latency,
because the network might just not be a very efficient network,
unreliable and high cost, by which I mean, high cost to run.
And it's not only a customer in the U.S. at the moment,
who are dealing with integrated energy electricity meters in their customers' houses,
but they said to us, well, we're using the Verizon 4G network,
and that costs us a lot.
And they charged per data packet.
So we really want to reduce the amount of data we're sending over that virtual wire.
So we want to deal with all of these kind of issues.
We also need to expect, again, it comes back to the history,
maybe 10 years ago, we had much less powerful computing systems than we did today.
So we want to expect that the environment where our application is running
has got limited resources available.
Could be a small load power processor,
or a lack of memory available, or whatever limitation we have.
If we have a more powerful than the thing it's said,
that managed to do an iPhone or Android mode,
then that's fine, we use as much resources as we throw at it,
but we're convicted to a very small amount of space.
And from an idea perspective, this is the last point three interesting,
because typically, the idea doesn't go around hanging out.
It's press rolls and things, because it's worth a lot of money to them.
But in this particular case,
because we're dealing with important kind of funny devices,
you know, processes that we don't deal with in all day-to-day lives
in an idea that can really cover a range of standards and enterprise computing platforms.
So we might have to compile a drone on a smaller device,
which you simply can't compile for ourselves,
or we can publish this protocol for anybody to go ahead and implement.
And as I say, at a moment,
we're just going to say,
it's free, it's free for anybody to implement.
And we're going forward looking to standardize it,
and actually hack it quite quickly.
So it's also very easy API to get running work.
If you ever use them, I don't know how many of you are into this space,
something like the Java messaging service program API,
there's a lot of complexity overhead, and you've got to get connection factories
with the self-transaction, you have to do,
put some guest commits and things.
Well, the NQTT API is really simple.
There are five verbs, effectively.
Connect, disconnect, publish, subscribe, and unsubscribe.
That's it. That's all you really need to know.
Really straightforward.
As I mentioned, a very small footprint on the wire,
we don't have, again, with J-messi-havies,
additional properties you've been assigned,
message data you've been assigned to a message.
We don't have any vats, very simple, small payload.
We're really tiny, small as possible packet size.
We weren't sending any message, any message quality and tool.
We were just sending out commands and NQTT server or broker.
It would just be a two-byte packet.
And we also have this really kind of interesting thing that we built in
to cope with the fact that it might be dealing with one of these underline networks,
or even an underline system that runs down on that tree or something.
Which is this idea of what's called the last word of a testament message.
It's what we can do there.
It's our hello, hello Mr. Broker.
I'm a new device on your network.
I'm going to be publishing this topic.
If you ever do something to me,
if I go away randomly without telling you the long way,
then please publish on this topic on my part.
I tell people that I've gone away.
So it's kind of interesting.
And often people say to me,
well, this is actually a really interesting thing.
You know, we can call any old rest web service into the web via HTTP.
And that's absolutely true.
Of course, it's a very well-known postcode.
But let's look at a couple of differences.
Which I think you're quite cool.
And I'm not saying one is better than no other.
I'm simply saying that there are different protocols here for different spaces and different use cases.
So HTTP is basically invented to get documents.
I want you to get that web page on that server.
It's a document-centric protocol.
And over time, we've bent it a little bit.
So actually, all my documents are messages now.
So it's our rest of JSON.
That's what we're getting.
We're posting.
And HTTP doesn't get.
And HTTP is not about documents.
It's about just other packets of information.
It's really simple.
As I mentioned, we've really just got a few methods.
HTTP is also pretty simple if you're just doing, basically, get, actually, post.
But if you start doing application type calls, API calls, use HTTP.
You then start getting into, to put and get into the leads and other things.
So it comes a bit more complicated.
And you also think what a hand will list my return post.
404 or 401 or 301 or 301.
You know, it gets a bit more interesting.
What we've also mentioned, we've got a really tiny packet site.
We've built from the ground up to be small.
We are not having lots of extraneous stuff as we want messages.
And if you look at it, you do it on wire.
The wire show up on an HTTP call.
And you're going to find there's a whole bunch of stuff in the headers.
And there's probably, if you're doing a post with a whole bunch of chats at the server,
yes, OK, thanks.
I've got that.
Here's your turn look.
Because we're publishing, so anybody who's subscribing,
and this is a nice thing when we look at a post with use case.
We don't have to do lots and lots of calls.
If you were to say, if you were to say that post with a messenger, use case,
and say, OK, 304, if you're in my group,
and I'm not supposed to post a message over HTTP through your four of you,
and you're probably going to post a set for server,
and then that's going to have to post with a bunch of other people.
So it's going to generate a lot of additional traffic.
Whereas with HTTP, you publish a message.
And that's it.
Because everyone who's subscribed is going to get that data.
So again, coming back to this, it's not quite an ancient approach at all.
It's not just a light on the network or the virtual network client.
It's also quite small in memory studies.
So again, as a reference implementation of a small broker,
the deal in this, and this is what we call the server, we have clients,
which do the publishes and subscribes.
We have a broker at the middle where a number of brokers at the middle
can actually manage those, and the distribution of those subscriptions and publications.
So we have a simple broker.
And that's that he's K anyway in the binary.
With HTTP, you simply have to draw in a bunch of other libraries,
depending on the kind of work you're doing.
So you've got XML and JSON libraries to sort of arrest all these other pieces.
And again, I'm not saying that's bad.
And so what you're using it for.
It's not being necessary for a sensitive work, for example,
to have that kind of stacked in place.
And there's another thing, which is to do with the qualities of service.
We've got effectively, we've got PTT, three qualities of service.
We've got a quality of service for delivery of messages, which is zero.
And that basically says, send the message, I've got a publishing, just hope it gets there.
It doesn't matter whether that's fine or not care.
It doesn't matter if maybe it's listening or this particular packet was missing.
So we're going to have one in the scene, which is a bit more kind of handshake.
They kind of say to the broker, please let me know that you've got this thing to publish for me.
I'm not going to go into detail on the quality of service today.
But HTTP itself has no attempts, even attempts at once, only delivery.
You have to handle your retry.
If you get an HTTP 500 or whatever that you'll post failed,
you have to handle that.
You deal with it yourself and you can go through trial.
So let's look at some geeky case cases.
I took out a load of IDME kind of industrial use case, because it is in use in a number of different industries.
Let's look at a few examples.
I can't just get a talk about the nano.
It's imported to Arduino.
It's imported a couple of years ago to the Arduino platform.
So if you've got Arduino applications, you just want to do simple publications and sensors from.
You can do that very easily.
It was also imported over Christmas last year.
It's another embedded platform called the NMET, which is a kind of chewing gum stick size.
It's a prototype in the world.
Over here at the top, it's a little Android application.
We've got Himes, Java, the library.
So it's very very easy to go to Android.
We've got a nice blog post on the MQTT in the hall.
Website, which talks about various ways you can use it with Android.
And there's some really nice tutorials about that.
This down here is my power mixture of home.
Look at what his current cost mix is.
It has a serial port at the bottom.
Which is just focusing out over the serial port.
Here's my, uh, into my bigger than you see.
A string of XML to say this is in current usage.
And then I can publish that to a broker that we have.
Running an IBM cloud.
And then a number of us can then grow off and care off energy usage.
So we have a little competition that goes around the lab.
To see if you can keep that energy usage baseline as low as possible.
And you see that you can run about during the day.
You have this at the splice because, you know,
the bridge turns as compressor on, you know,
various other bits and pieces around payroll,
which might be cycling themselves.
But then of course you come home and be in the term of catalytic
but washing machine on and so on.
And you splice them on.
So what we see, you know, this is just MQTT is just providing the ability
to publish the data to a visualization system there.
And over here I've got the idea.
I haven't proven this yet, but I think it's pretty straightforward.
The Kindle would be quite a nice way of having a,
the ability to publish data to just, you know,
an ear display.
Because the Kindle is a lot thinner than its box.
He needs a room to gel-breaking.
It's pretty straightforward.
And it effectively is gel-based,
ladies and gentlemen.
Yeah.
The previous thing that Harrison had done in my opinion
is to keep the Kindle development kit very close to the control
and have really well-distributed it.
So the people who are doing home-group hacky-cooking do it.
So I've mentioned that people like to use this
and we find in lots of different cases.
I think I'm really pleased that people are using this.
This is one of my friend, Levering, in Australia.
And he's using this sector of his home automation system
similar to our standard path system actually.
He's got, for example, as I have a current cost of meter
attachment, which is publishing the power and the temperature in home.
He's also got some no-bout that sits on his desk
so people can see the current settings.
He's got now the mobile interface to switch on
off his lights around in the house,
and so on.
I forgot the link to this.
That's what we talked about this.
Dan Fisher's got this using a Mosquito-breakable MQTC
to do a bunch of stuff to go out and actually water his dog.
So that's my core.
And you can monitor more on the ground so I can fix it.
That's the honest thing.
It's just staying doors where the nice computers are
and what do you value from indoors?
This is some of the even more awesome examples.
And if everything's here,
but I've made yesterday and kept the ground working
there to be more on there,
the BBC's Vegas Bridge, thank you, yes it was.
Exactly right.
But there you have this test to see
whether these mind control headsets
that begin to come out for gaming applications
could be used to drive a lot of taxes.
So thinking back through,
you didn't get to teach the same commands
to a proper taxi.
I mean, the device is an attached to the taxi.
Chris Phillips from Sir Habsett decided
to correct ambient Arduino control,
bashing nuts, kind of fun.
He's written a nice blog post about how we do that anyway.
Don't ask me about some of the new people
who pull up the rubber ducts together as a problem.
We're going to take a conference,
we're going to take a conference,
and we're going to get up and ready to log in.
I think I might be able to answer this one
when I'm obliged to tell you.
I think I'm going to be able to look at the system
all around all three reference broker
implementation you can download
for a long holiday and how for work site.
And literally, you download zip-file and zip-run it
and you have a broker running,
there's some zip-fives, the job clients
that are available for our website as well,
you can start to play with.
And you'll find that it's actually
powerful for bringing different things,
including, for example, the Slug and a few other things
as well as all the Mac as well if you're interested in that.
And also our next scale, which is what I said to be unusual.
But we're exciting one, I think,
with a lot of kind of perspective,
it's a gorgeous, fantastic project.
It's really come with a lease and bound over the last few years.
Really nice.
Very, very easy to get using on the Ubuntu users,
so we Ubuntu example off here.
It's got some clients,
so they've just come online clients
to enable you to test, publish, and subscribe.
And he's also the Python library there,
and he's got Ubuntu for a different package Linux distributions.
Of course, you can compile it directly
from a bit budget as well.
Again, it wouldn't really be a good conference
to talk for a podcast about code in my presentation.
Here's an example of a little bit of Java code.
Pretty straightforward, really.
Really just to make that connection initially,
you set up a little bit of property information
to contain where your broker is.
Here we are.
We want to keep ourselves the main test client
or broker who's running on Portation 83.
And then connect and publish a little bit of,
and we're done. That's it.
And really trivial to do.
In fact, if the Python code touch here
at the minute is even simpler than that.
And then we just have a callback to say
there's something puns in.
Let's just bring it out to scan it out.
This is a mobile device,
who's over there,
and we've just done some lovely little posts
about using Python and MQTT.
This is a really nice example on that.
This is an e-tug through that where I've shown you.
It's not the client, but it's kind of cool.
You can publish some information from a sensor
or a device like a phone
and have little notifications pop up in a bunch of it,
which you've got the PY-nose code to post.
Again, really trivial.
If you look at the actual amount of the code,
which is related to MQTT,
this top part here really is just the notification spot.
So just out here, we've got the
ability to connect and then publish what's going on.
And I mentioned community,
and the fact that we've got community sites,
and we've got lots of exciting developers.
MQTT.org is our kind of main community site.
It's kind of on-site for IBM.
It's trying to really cool out and point out
cool stuff that people are using at this school,
rather than saying,
you can buy MQTT,
buy a message,
go to your mobile,
you don't have to think about it.
It's not about that.
It's about the fact that actually,
we are really excited
that we've got so many developers
who are really interested in this stuff.
Of course, we're on our sea.
So we've just got an IRC channel
MQTC on three nodes that we're going to talk about.
His own project is a launch pad
or it's a LIC,
where he's got some extra bits.
There are many ways to get this packaging wrong.
And loads of people writing about it online.
I went over it as I mentioned to Australia.
One of us there in the University of Brisbane
are doing some really cool stuff
around using MQTT to control things like microscopes
so that they can have used around the world,
send the messages to tell them,
actually, like the microscopes,
look at this slide for me
and send you the data back to somewhere in the US.
So things like that.
So that's it.
Really?
That's what I was talking about last morning.
I hope that's got an interesting bit of science here.
Got me thinking about how you're going to take a look
at some of these examples.
I have about one minute for questions
from Alan and the gentleman over there
before Laura comes and throws me on the stage.
So, Hemp Future 2,
does it run directly on the wire
or does it run over IP?
It runs very good question.
So, yes.
TTT, it sits on top of TTT,
so you need a TTT key to land with these advice.
Great.
So, a common question I have is,
okay,
what we bought the sensor system from Company Blob
and they give us a little box
and all these sensors and all these systems.
So, how will I get an empty teal to these sensors?
The answer is in focus.
You put in TTT onto the most convenient entry points.
It's about opening up the data server
to as wide range of people as possible, right?
So, if you've got a lid at the box,
as I have at home,
I've been aware this session,
which is connected to it over and over
in our effort connection,
and I've got my current system
which is connected over a serial connection,
my lid at the box is where I run in TTT.
I'm putting stuff up the ports,
scraping it or whatever,
and then republishing it up to
or if you're in our lab in the end.
Because that is more interesting
so there's a big amount of wide range of people.
So, one day it's just a good idea.
It's a great question.
There's a question there in the hour.
Sorry.
How does it compare to something like
a bit excellent question?
So, NPP is not an ADI,
it's a wide format.
Wide cruise control.
And NPP has a very complex,
a relatively complex operation model.
This is really simple.
And the other thing is,
NPP is relatively new
and is only just going through its 1-0 release.
We've got, we've actually versioned 3,
that's the one that's going to go forward probably,
the standardisation.
It's been in the market and happening for 11 or 12 years.
So, this is something that's really solid APP.
I'll say at the moment,
it's still really moving around and shifting.
That's how I, that's the answer.
And there's an answer.
NPP has no defined ADI,
and this does have done quite a bit of ADI.
I do agree, sorry.
How big is the time in the time
that you've been able to rely on?
Excellent question.
Pretty small as well, I can tell you.
There are a few things that you can have
to use on NPP 6,
more than the time I've been able to get.
I can see that you've been able to do it.
Yes, we can.
We came on ADI,
and I don't have an answer to be the size issue there.
I mean, that's a general problem
with the NPP 6 protocol,
and head, I believe it will,
rather than something.
I mean, a QTT will still...
Minimum on it.
Yes, I think it will.
Yes, I think I understand.
Yes, so,
there is a diminishing process,
but it will still be an advantage over something
likely to be the result.
OK, thank you very much.
And that was Andy Piper's presentation on MQTT.
The presentation,
messaging for the Internet of Awesome Things,
can be found on slideshare.net.
Andy's blog for MQTT,
the Lost Outpost, is also online.
Check the show notes.
OckCamp is a joint venture organized by those lovely podcasters,
the Linux Outlaws,
and the Ubuntu UK podcast.
We've more highlights of OckCamp coming up
on the full circle podcast very soon,
including Laura Chikofsky
and a quick debrief with Alan Pope.
For now, I'm Robin Kathleen.
Thank you for listening, and goodbye.
You have been listening to Hacker Public Radio
at Hacker Public Radio, does our.
We are a community podcast network
that releases shows every weekday,
Monday through Friday.
Today's show, like all our shows,
was contributed by an HPR listener like yourself.
If you ever consider recording a podcast,
then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the Digital.Pound
and the Infonomicom Computer Club.
HPR is funded by the binary revolution at binref.com.
All binref projects are crowd-responsive by linear pages.
From shared hosting to custom private clouds,
go to lunarpages.com for all your hosting needs.
Unless otherwise stasis,
today's show is released under creative comments,
attribution, share alike, digital's own license.