Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MQTT turns 25

andypiper.co.uk

Post reply on HN
Print view View original

41–50 of 76 posts

Re: MQTT turns 25

#41

Post by clumsysmurf »

this_user wrote: post #16

Having recently used MQTT for a project, I can't say that I'm a huge fan. There are a lot of options in the protocol where it's not immediately clear what they do and why they are important, or in what combination they need to be used to make sure things work as intended, and the documentation is often not great at explaining. Part of this may also be on the Eclipse Mosquitto Python client that I had been using. I to…

The eclipse paho MQTT Java client is also terrible, lots of open bugs, terrible API, and no release in over 4 years. For my case, I was able to use NATS instead.

https://github.com/eclipse/paho.mqtt.java/issues

Re: MQTT turns 25

#43

Post by InDubioProRubio »

fartfeatures wrote: post #30
ronameels wrote: post #27

MQTT is being used a lot more in recent years inside of factories for sharing data between machines. Historically it's been used in Oil & Gas for SCADA (getting data from remote well sites). 10+ years ago we added it to Kepware (OPC server) and streamed tag values to "the cloud". I was at a conference giving a presentation on it when Arlen Nipper, one of the creators of MQTT, came up after the presentation and said I…

Is MQTT being used in places where previously Modbus would have been used?

There is also MQTT integrating bus-hardware- you basically plug in as bus-hardware replacement which allows to send data directly from the bus to the broker. The PLC never know what hit it.

https://www.ifm.com/de/de/product/AL1332

Pretty wild times.

PS: You can web GET/POST set and get ios with these. Robot experience that tragic irony POST {NOOO} and he just dropped it like its hot.

Re: MQTT turns 25

#44

Post by omani »

thebruce87m wrote: post #38
joezydeco wrote: post #9

I had a lot of fun on an embedded systems project recently where I used MQTT as an interprocess messaging system. Broker and clients on the same machine. If I needed to sniff or debug something it was as easy as putting the device on the network and using MQTT Explorer to record or inject messages. I could even let coworkers that were working remotely work with the system by opening the port outside the LAN.

We use ZeroMQ for this purpose. No broker needed.

this statement is a bit confusing. because with zeromq, one side plays the broker (I dont mean the broker pattern). I mean it in the sense that someone, somewhere, needs to listen on a port. which in the end is the same as having a central mqtt broker sitting somewhere listening on a port. hence the statement "no broker needed" is a bit confusing.

Re: MQTT turns 25

#45

Post by thebruce87m »

omani wrote: post #44
thebruce87m wrote: post #38

Earlier quoted context omitted.

We use ZeroMQ for this purpose. No broker needed.

this statement is a bit confusing. because with zeromq, one side plays the broker (I dont mean the broker pattern). I mean it in the sense that someone, somewhere, needs to listen on a port. which in the end is the same as having a central mqtt broker sitting somewhere listening on a port. hence the statement "no broker needed" is a bit confusing.

> one side plays the broker

Hopefully most people understand that I meant that you don’t need a stand-alone broker, which on embedded systems means one more thing to deploy and worry about the license for.

Edit: Also:

> The philosophy of ZeroMQ starts with the zero. The zero is for zero broker (ZeroMQ is brokerless)

https://zeromq.org/get-started/

Re: MQTT turns 25

#46

Post by eska »

ronameels wrote: post #27

MQTT is being used a lot more in recent years inside of factories for sharing data between machines. Historically it's been used in Oil & Gas for SCADA (getting data from remote well sites). 10+ years ago we added it to Kepware (OPC server) and streamed tag values to "the cloud". I was at a conference giving a presentation on it when Arlen Nipper, one of the creators of MQTT, came up after the presentation and said I…

I also work in that industry and am quite puzzled by the technological inferiority, scope creep and NIH syndrome of the OPC foundation’s standards. I wish they just used sparkplug b and implemented their specs on top of that for semantics.

Then again the async stuff they’re doing now is so over-engineered and terrible as well.. I took part in their teams meetings some time, only to find they had never read the mqtt spec (less than 50 easy to read pages) and didn’t understand what the headers are for for example (they wanted to put stuff in there that actually belongs in the payload). Some microsoft guy also took offense at my suggestion to first look at what competitors are doing with mqtt, because he wanted to create something new rather than copy. My company will just treat opc ua at the very edge and isolate it from our tech as much as possible on my suggestion.

Re: MQTT turns 25

#47

Post by accelbred »

vv_ wrote: post #33
DannyBee wrote: post #28

Earlier quoted context omitted.

So your client just sucks here. My experience with the eclipse clients (paho, etc) is similar to yours in both python and C++, - it makes it overly complicated and seems very low level. It also is somewhat buggy because of the architecture. I believe (perhaps wrongly), it's all basically maintained by one person or close to it (only one person has contributed to the C++ client in the past 6 months, for example, and n…

After reading your post, I went looking for good C/C++ implementations suitable for embedded development, and honestly, I couldn’t find many! MQTT is typically straightforward to implement, so most companies develop their own version to better adapt to the specific systems they use for data transmission. That said, maybe this is an opportunity to create a well-designed MQTT client implementation tailored specifically…

I work for the team that maintains coreMQTT (https://github.com/FreeRTOS/coreMQTT)

Its a C89 MQTT library intended for embedded devices.

Re: MQTT turns 25

#48

Post by sunshine-o »

I never understood why we don't use MQTT for simple systems monitoring, with a push model.

I mean it was almost designed for this use case.

Also if using NATS things become very simple to setup.

Re: MQTT turns 25

#49

Post by qudat »

this_user wrote: post #16

Having recently used MQTT for a project, I can't say that I'm a huge fan. There are a lot of options in the protocol where it's not immediately clear what they do and why they are important, or in what combination they need to be used to make sure things work as intended, and the documentation is often not great at explaining. Part of this may also be on the Eclipse Mosquitto Python client that I had been using. I to…

While not directly competing with mqtt, https://pipe.pico.sh is a great pubsub tool that leverages ssh for communication, effectively creating an authenticated, networked *nix pipe system.

It tries to be the simplest way to send and receive events.

Re: MQTT turns 25

#50

Post by Evidlo »

I remember one of the annoying things I found about actually using MQTT was that many clients didn't implement any sort of connect/disconnect callback and expected you to handle reconnection logic (e.g. exponential backoff) yourself. Also it didn't support RPC style requests for some reason.

Also since MQTT is TCP-based you can't natively speak the protocol from a webbrowser without the broker also listening on a websocket.

Ended up switching to WAMP-proto [0], which checked all my boxes and just did everything over websockets by default.

0: https://wamp-proto.org/

Post reply on HN