Who's running MQTT in production?

[martin]

Hi All,

I am considering implementing MQTT but I was wondering who else is
already using it? Are there any big success stories that can help
demonstrate that this stuff actually works in large scale production
deployments?

Martin

[Nicholas O'Leary]

Hi Martin,

we (IBM) have been using MQTT in solutions for the last 10 years with
great success.

A couple that I can reference:
- St Jude Medical, who use MQTT to remotely monitor patient implants
- http://www-03.ibm.com/press/us/en/pressrelease/19747.wss
- Consert, who are an energy utility company, use MQTT as a part of
their real-time home energy monitoring and management solution -
http://www-304.ibm.com/partnerworld/gsd/solutiondetails.do?solution=40405&lc=en&stateCd=P&page=1

There are obviously many that I am not able to share, but they cross
all industries.

Independently of IBM, Facebook Messenger uses MQTT -
http://mqtt.org/2011/08/mqtt-used-by-facebook-messenger

I'm sure there will be other's on this mailing list, outside of IBM,
who have stories to share.

Regards,
Nick

> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt

[holla2040]

here's some examples

http://mosquitto.org/2012/01/do-you-use-mqtt/

[Arlen Nipper]

Hello Martin,

We designed a family of Industrial Network Gateways that interface to end equipment (PLCs, RTU's, Gas Chromatographs, Smart Transmitters, Tank Gauges, etc, etc) in their native protocols and then publish the resulting parameters via MQTT. The Gateways also subscribe to "COMMAND" topics so that commands can be published via MQTT and then converted into the appropriate protocol resulting in true Command and Control use case scenarios.

We use these Industrial Network Gateways in large scale liquid pipeline SCADA system deployments and the initial systems have been in the field for over 10 years now achieving greater that 99.99% availability over that time frame. As you can imagine these are mission critical systems designed for 24/7/365 operation. Our customers have been very happy with the performance, reliability, and scaleability of the resulting SCADA systems and keep expanding and enhancing the system. This is one of the beauties of a MQTT based systems....  that you can keep adding topics and data to the infrastructure without having to do a complete rip and replace every time. I will note here that the typical life span of a SCADA/Telemetry system is around 4-6 years on average. Here we have customers who have run for over 10 years now on a 100% MQTT infrastructure and see no end of life to the capabilities of the system in sight.

Regards, Arlen

[holla2040]

Arlen,
Don't be shy, pass on URLs for your PLCs, transmitters and gauges with
MQTT.
Craig

[holla2040]

I found out about Arlen here, http://www.youtube.com/watch?v=WVWAXnbnV3w

So I'm answering my own question

http://www.eurotech-inc.com/embedded-mqtt-driver-modem-protocol.asp

[Arlen Nipper]

Ok, I guess my secret is out now :-)

Although I'm working on a much more complete description of how we use
MQTT in SCADA and Telemetry systems for this forum, I can provide some
insight as to why I wanted to co-develop MQTT with Andy Stanford Clark
originally. (And now everyone will know the dirty little secret that
MQTT was actually first designed for Real Time, Mission Critical,
Command & Control, SCADA systems. Which is why it is so cool !!!)

I pointed out in my post below that we had to interface to a variety of
systems including PLC's, RTU's, Smart Transmitters, etc. Well that
sounds pretty straight forward but let me provide an abbreviated list of
just a few of the device protocols we had to deal with:

Allen-Bradley DF1
Allen-Bradley DH+
Allen-Bradley EN/IP
Amocam
ARCNet
ATS
BITbus
CANbus
CA
CCM2
CDCI
CDCII
Conitel
DeviceNet
Daniel
DL130
DNP 3.0
Elliott
Enron Modbus
F&M
Ferranti MK2A
Galveston-Houston
GPE
GSI
Harris 5000/5500/6000
Hansa S002
HART (FSK & Wireless)
Hayes
Honeywell DE
J1939
Kodata
L&J
LANDAC
Landis & Gyr
Micromotion Flowscale
MODBUS ASCII
MODBUS RTU
MODBUS Plus
MODBUS TCP
MPS9000
MTS
Omron Host Link
Optomux
PERT 2631
Plessey TC6
RDACSII
REDAC 70H
RNIM
Siemens 3964R
Siemens RK512
SNET -I
SNET �II
GE SRTP
TANO Model 10
TANO Model 100
TCP/IP
Tejas
Total-Flow
Transit Bus
TRW 9550
Valmet Series 5
Transmitton MT700
TRW S-70
TRW S-703
Varec
Wesdac 4F
WISP
ZigBee

The problem here is that supersets and subsets of these protocols still
exist predominately in Industry today. Although 12 years ago we didn't
have the IP connectivity we have today, the desire is to still use "ONE"
transport protocol for all of the process variables and parameters if at
all possible. By providing the host drivers for each of these protocols
in the gateway devices (thereby eliminating any need for polling over a
SCADA network) we were able to write adapters to parse the process
variables and publish them using MQTT. Now "interested parties"
including SCADA host systems could subscribe to event driven process
data using a common transport protocol. But now the exclusivity to the
SCADA host application could be broken down so that other interested
data consumers could gain access directly to the operational process
data. In addition, data that normally would not flow to the SCADA system
could use the same network connection to publish field data. For example
the custody transfer report information from a flow computer (which the
SCADA system could care less about) could be published to the MQTT
broker and subscribed to by the accounts department. There are many,
many additional use cases that are quite interesting that I am in the
process of documenting.

Cheers, Arlen

[Andy Piper]

My goodness Arlen… that almost seems as though it belongs at http://mqtt.org/wiki/doku.php/history :-)

cheers, Andy

--
Andy Piper | Farnborough, Hampshire (UK)
blog: http://andypiper.co.uk | skype: andypiperuk
twitter: @andypiper | images: http://www.flickr.com/photos/andypiper

> SNET –II

> --
> To learn more about MQTT please visit http://mqtt.org
>

> To post to this group, send email to mq...@googlegroups.com (mailto:mq...@googlegroups.com)

> To unsubscribe from this group, send email to

> mqtt+uns...@googlegroups.com (mailto:mqtt+uns...@googlegroups.com)

[holla2040]

Arlen,

I've waited 20 years for a posting like this!!! I'm not kidding.

If you have what you say, its a 'universal translator' yay !

Are these planned or implemented?

Can you provide implementation details on something simple like

mqtt <-> modbus RTU.

with topic publishing to register mapping, register setting via mqtt
subscription, periodic polling resulting in mqtt publishes, etc.

Thanks for the fanastic post!

Craig
--
Dr. Craig Hollabaugh
System Architect at Brightleaf Technologies
choll...@rethinksun.com

[Jose Luis Carmona]

Martin,

We have MQTT running on a metering solution with a 802.16 backhaul and
seems stable enough implementation of both client and server side have
been developed at home, we chose it just to avoid the mess of
describing protocol ourselves and keep some interoperability at
feeding connector level with third parts.

MQTT is just a protocol, on our side the broker is some sort of
business rules, In my opinion MQTT, CoAP, HTTP or XMPP or whatever is
just an specification, the actual technologies you may need for a
large scale deployment may vary a lot and still keep MQTT.

IBM is using it on big things and in our case we are using it for a a
combined 100.000+ deployment in several countries but we aren't
advertising it as a MQTT solution, some other people have the same
situation. MQTT just came in time to save your team time in
documenting a protocol, and even some implementation effort at pilot
stage.

The absence of standards is one of the biggest obstacles for urban /
country contracts and having at least something with IBM on it and
having access to the huge Websphere ecosystem / Eclipse tools is
definitely an stepping stone.

[Sy]

Hello,

We use MQTT to send data from our units in the field.  MQTT is used to provide status information such as unit health and statistical averages.  We have also written an MQTT / OPC gateway that allows our clients to use the data in SCADA systems.

More recently we have developed a Web-Interface that allows clients to monitor they're units via a google map.  Our units have a GPS internally, the GPS data is sent via MQTT and the units appear on the map, clients can select units via the map and get information from the units directly from the web-interface.  Alarms are also provided via MQTT.

The interface to the broker uses a custom PHP script which I wrote myself.  All works very well and is very scalable.

[andyp...@gmail.com]

Hi

I'm very sorry that you didn't feel that your questions were answered by mqtt.org - we obviously have work to do. However, this list is largely not for comparisons (see you last question answered below), but for discussion of the protocol itself.

Answers inline below

On Sun, Mar 17, 2013 at 8:17 PM, vsolorza...@zebra.com <vsolorza...@zebra.com> wrote:

Hi Arlen,

I realize this post is from last year but I'm looking for comparison with other open standard protocols. From what I understand MQTT is not an open standard (yet). So here a summary of what I know of MQTT based on what I could find on http://mqtt.org/

• MQTT is not an Open Standard, meaning neither IETF, OMA or any Open Standards organization

MQTT is about to go to an OASIS Technical Committee - the closing date for requesting participation in the process is tomorrow (March 18) and the first face-to-face meeting of the TC is in 8 days' time in Boston at EclipseCon. This is stated in the news items on mqtt.org.

• MQTT specification is being provided by IBM, at least that's what I found after first going to http://mqtt.org and redirected to http://www.ibm.com/developerworks/webservices/library/ws-mqtt/index.html

It has been provided royalty-free by IBM and Eurotech (the co-inventors) for many years. Standardisation is the next step in the process. NB IBM and Eurotech have held to this approach so there have not been any issues for those implementing MQTT-based clients or servers.

• MQTT has being extensively used in IBM related projects, but I cannot find whether is it being used in non-IBM projects

Extensively used outside of IBM, for example by Eurotech, Facebook (for mobile messaging and alerting), Titanium mobile framework, and in many non-IBM projects and implementations.

• MQTT has several implementations (http://mqtt.org/software) and some are even open source
  

MOST are Open Source! There are very few that are commercial in fact.

• MQTT is a pub/sub based messaging protocol that relies on TCP, what about security. Is there support for TLS?

MQTT brokers that support SSL / TLS can support SSL clients. Examples would be Eclipse Paho Java or C clients connecting to e.g. IBM WebSphere MQ, or Mosquitto. MQTT is indeed a pub/sub messaging protocol based on topics and subscriptions.

• MQTT is a messaging protocol but it is not clear to me whether it has also a Data Representation protocol

MQTT explicitly does not do anything regarding the data representation. There are efforts underway at Eclipse (M2M-IWG) to look at data formats in this context. We find that MQTT is most useful and flexible without any constraints on data formats.

• Will MQTT support the traversal of corporate firewalls?

Not explicitly, but port forwarding could certainly be used to achieve this. 

From your point of view what are the advantages/disadvantages of MQTT vs CoAP/LWM2M?

Created nearly 15 years ago to cope with low bandwidth, high latency, high cost networks and continues to scale extremely efficiently today to modern systems and networks.

Flexible. Agnostic of payload. I position MQTT as "the UNIX utility of M2M" - deliberately simple, easy to plug in to other tools, languages, and techniques.

One-to-many. Many-to-one. Not synchronous or point-to-point.

Extremely simple to learn, use, few return codes.

In-built quality of service and Last Will and Testament simplify development and provide presence awareness features.

Many existing implementations; including many millions of existing clients if you factor in all Facebook mobile usage.

-- Andy

[Vinay Puli]

Martin,

We are using MQTT for our GPRS based meter reading solutions in production. Already 20K devicees installed on field and going good.

-Vinay Puli

[Ravi Kiran]

Hi Martin,

Most of the Mobile app companies are using for alternative to GCM(Google Cloud Messaging) and Apple Notifications.

Thanks

SRK

[Paul Fremantle]

Facebook said that messenger uses Mqtt a while ago. I've also heard about some major connected car projects.

Paul

--

To learn more about MQTT please visit http://mqtt.org

---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.