MQTT - is it a fad which will move on? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: February 09, 2022, 08:57:38 am
content: It is supposed to be a simplified version of TCP/IP with some special features for embedded devices with online access (what is today fashionably called "IOT") and for remote management of large numbers of devices.https://mqtt.org/However they say it uses TLS for security which means it will be anything but efficient. Even on a 168MHz ARM, TLS takes a few seconds to set things up.

author: nfmax
author_rank: Super Contributor
timestamp: February 09, 2022, 09:40:59 am
content: MQTT is definitely not a fad, it's been around for more than 20 years and is widely used. It doesn't replace TCP/IP as it is a higher-level protocol, running on top of it (or indeed on top of any other protocol providing ordered, lossless, bi-directional connections). The MQTT protocol itself is lightweight, both in terms of network traffic, and the software needed to implement a client - or even a broker (server).MQTT supports authentication, but not encryption. Where encryption is needed (i.e. anywhere on the public Internet) this can be provided at a lower level, using TLS, or by sending encrypted payloads in the MQTT messages (or both). You rightly point out this adds considerable overhead. This is the unfortunate price we all have to pay for the current state of the Internet. If you are on a private network, or a network safely firewalled off from the public Internet, you can avoid it and MQTT will allow you to do so.Note the TLS connection is set uponce, when the client connects to the broker: this persistent connection is used for all subsequent MQTT messages in either direction.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 09, 2022, 12:07:30 pm
content: Quote from: peter-h on February 09, 2022, 08:57:38 amNo! Forget marketing, look at specs. I was also given a marketing lecture how MQTT is so superior compared to TCP.Yet, in reality, MQTT is (almost always)on TCP. It can't solve problems of TCP when it's on TCP, so marketing about this is BS.But, it's quite simple and it works, so use it if appropriate? I have no big problem with it. It solves the problem of collecting different data sources on a server, and subscribing on a chosen set or subset of message types, and it does this fairly well. If it's exactly what you need, then... use it.

author: m98
author_rank: Frequent Contributor
timestamp: February 09, 2022, 12:32:16 pm
content: Uhm, first and foremost, look at your protocol architecture. MQTT is at OSI-Layer 7, 6 and 5, while TCP/IP is at layer 4 and 3. It's an alternative to using HTTP, not an alternative to TCP/IP. If you want to go even more light-weight, consider using CoAP, based on UDP.

author: peter-h
author_rank: Super Contributor
timestamp: February 09, 2022, 02:15:05 pm
content: Thank you all.On a quick read-up, it looks like MQTT is intended to address the management of (and obtaining data from) a number of IOT devices, each of which is a client (not a server). In nearly all cases, IOT devices are clients, not least because a server implies some sort of open port on a router, fixed IP for it, etc.To see how the server (called "broker") part is done, I did a google on "free mqtt server" and found loads. I wonder how e.g.https://mosquitto.org/makes money? Are they offering open source stuff and charge for implementation consultancy (same business model as e.g. Magento)?

author: ataradov
author_rank: Super Contributor
timestamp: February 09, 2022, 03:51:53 pm
content: Quote from: peter-h on February 09, 2022, 02:15:05 pmRight on the front page they say "Mosquitto is part of the Eclipse Foundation, is an iot.eclipse.org project and is sponsored by cedalo.com." And cedalo offers hosted service starting from 15 euro/month.This is a very common business model for MQTT providers. There is no way to make money on the actual implementation, as the market is flooded with good free solutions. So your only option is to offer a service.

author: peter-h
author_rank: Super Contributor
timestamp: February 09, 2022, 04:37:46 pm
content: QuoteHence my question about it being a bit of a fashion, looking for applications.Is a sizeable manufacturer of IOT hardware going to be renting somebody else's server, when their product line depends totally on the uptime and general reliability of that server?And nobody is going to make money out of low volume / hobby stuff. Especially as a lot of that can be run as a server and behind an open port and then you cut out all this "broker" stuff.

author: ataradov
author_rank: Super Contributor
timestamp: February 09, 2022, 06:04:17 pm
content: Quote from: peter-h on February 09, 2022, 04:37:46 pmSure, happens all the time. IoT is a carpfest of poor decisions.But also, most "IoT" companies are better off outsourcing that stuff anyway.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 10, 2022, 08:45:33 am
content: This is like confusing git and GitHub.You don't need to buy server hosting from any particular company. You can run mqtt server anywhere you want, including your own physical computer.mqtt is really simple. Run a server (broker), connect some content producers it with descriptive topic names, connect some listeners to the broker, subscribe on the topics of interest. Simple tools like mosquitto_sub that allow you to subscribe, using wildcards for example, are handy.The only gripe I have with mqtt are some fanboys who can't even explain what mqtt is (despite it being so simple) and assuming it needs to be glued to every project, regardless of what that project is doing.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: February 10, 2022, 09:20:01 am
content: MQTT isn't TCP it's a lightweight publish/subscribe mechanism and works just fine. In fact I use it at home for collecting temperature data from a number of sensors for my hibernating tortoises!I run Mosquitto on a RPi that has a radio link and the sensors contribute... I don't really think much about it... set it up many years ago and it just works.MQTT is very lightweight so suits small devices but given the amazing power of the average embedded device these days it is not necessarily the only solution.

author: ejeffrey
author_rank: Super Contributor
timestamp: February 10, 2022, 04:32:56 pm
content: Quote from: peter-h on February 09, 2022, 04:37:46 pmSure, I would guess the majority of them do.QuoteWell the broker is fundamental to the architecture of MQTT. You can run it yourself or use a 3rd party, but you can't really "cut out all this broker stuff". The point of the pub/sub architecture is that the producers and consumers of data don't need to even know about each other much less maintain connections to each other. They just need to be able to locate the broker. For instance a temperature sensor device only needs to publish readings to the broker and doesn't care if the subscriber is a cell phone app, a cloud logging service, or some other application server, or all three. It allows a many-many relationship, so multiple subscribers can receive messages from multiple publishers, and is bidirectional, so devices can not only publish their data but also subscribe to configuration updates or alerts.For a DIYer it makes sense to just run your own broker locally and you probably don't care about 100% uptime. For a device manufacturer who wants to sell turnkey devices preconfigured to work over the public internet you have to be very large before you can approach the reliability, scalability, and resilience of a commercial offering at the same price point. You can get a broker either from a IoT focused service like cedalo or from one of the large cloud service providers.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 10, 2022, 05:49:02 pm
content: OK so let's concentrate the idea here:You have 57 temperature sensors and 38 solar inverters, producing statistics all the time. They are connected to a network, private or Internet, doesn't matter.You want a user interface where you can look at all the values. Or you want to look at just the temperature in Bob's room. Or you want to look at solar production at the Fucking (the place name) branch office, there are 13 inverters there.So what do you do? You give some labels to all those data sources, and tell them: send the data to server at 12.34.56.78.Then you connect with your mobile app or whatever to the same server, to read out the data.Completely trivial. Except that you need to come up and implement aprotocolto do that. And write the server software which collects the data, and sends it forward to the subscribers. You know, make a list of connections that are subscribers, remember what each of them requested, and every time you get Bob's room temperature, send it to client #123. And send all the Fucking results to that another client. And to make the Fucking use case easier, accept a wildcard so that you can ask for Fucking/* inverters in one go, instead of listing all 13 separately.You can do all of this yourself, or you can use MQTT. If it's the right tool, use it. Else, don't use.If you have no idea why in the world would you like to have a server, it sounds like you don't need MQTT.

author: ejeffrey
author_rank: Super Contributor
timestamp: February 10, 2022, 08:51:16 pm
content: And you want to do it when all the client devices (publishers and possibly subscribers) have intermittent or unreliable network access -- for instance they are using cellular modems or zigbee gateways, or they are low power devices that only turn on their radio periodically.The downside to this is that the publisher only knows that the messages has made it to the broker, not when or if any subscribers receive the message. If you want real-time 2-way, point-to-point communication MQTT might not be right for your application.