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

51–60 of 76 posts

Re: MQTT turns 25

#51

Post by doctoboggan »

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…

We are currently using the Kepware IoT plugin to stream around 800k tags per second via MQTT ultimately into a Victoria metrics DB. It's a little clunky and requires more processing steps than I would like. I am currently moving away from this solution (since Kepware charges a reoccurring license fee every year for the IoT plugin), and toward using telegraf to read the OPC-UA data directly from kepware without the IoT plugin.

Do/Did you work at Kepware?

Re: MQTT turns 25

#52

Post by happosai »

formerly_proven wrote: post #15
miljen wrote: post #12

Fun fact: at the same time, the most famous C++ library, Boost, is reviewing the `async-mqtt5` implementation ( https://github.com/mireo/async-mqtt5 ) to be included in Boost as Boost.MQTT: https://lists.boost.org/Archives/boost/2024/10/index.php

Is Boost still something people reach for in newer projects? Anecdotally most adoption I've seen happened in the 00s and very early 2010s (pre everyone mandating C++0x/C++11), I only rarely see it around these days. edit: boost.org is a blast from the past, still looks exactly like I remember it from like 2008. Down to the "Get Boost" shopped on an emergency off button!

Boost appears to have become some kind of staging area for stdlib. Stuff that becomes popular in boost get eventually included in stdlib.

Re: MQTT turns 25

#53

Post by jpfr »

eska wrote: post #46
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 s…

Umm. There is a deep integration between OPC UA and MQTT since ca. 2017.

For binary and JSON payloads, and with encryption and group key management features.

I see quite a bit of unsubstantiated bashing lately. Especially advocating 20% solutions that solve the easy parts with less effort.

What are you missing from OPC UA?

Re: MQTT turns 25

#54

Post by red-iron-pine »

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…

> 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).

This is where I first encountered it too -- chemical production. Also saw a lot of it in aviation and railroad control systems.

That said, seeing a lot more Kafka and RabbitMQ crowding into MQTT's marketspace.

Re: MQTT turns 25

#55

Post by remram »

gorbypark wrote: post #31

I think my first project that's still "in production" and used daily was taking an existing SVG map of a water distribution system (snowmaking and fire suppression pipelines/pumps/valves/etc at a major ski resort). I made a MQTT topic for each pump, valve and section of pipe along with some state for each (water direction, pump or valve on/off, pressures, etc). It's a website, so I used mqtt.js and jQuery to update t…

Holy shit Docker is 11 years old.

Re: MQTT turns 25

#56

Post by ClumsyPilot »

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…

> There are a lot of options in the protocol where it's not immediately clear what they do and why they are important

I totally disagree, your expectations for the protocol seems unusual. They are not frameworks, and need to game many options.

MQTT specification is like 3 pages.

For comparison try to read specification of HTTP3, or AMQP - those are hideously complicated.

Re: MQTT turns 25

#57

Post by brian-gilmore »

gorbypark wrote: post #31

I think my first project that's still "in production" and used daily was taking an existing SVG map of a water distribution system (snowmaking and fire suppression pipelines/pumps/valves/etc at a major ski resort). I made a MQTT topic for each pump, valve and section of pipe along with some state for each (water direction, pump or valve on/off, pressures, etc). It's a website, so I used mqtt.js and jQuery to update t…

aaah I love me some AJAM ;)

Re: MQTT turns 25

#58

Post by pjbk »

Evidlo wrote: post #50

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 web…

MQTTv5 now has RPC. You can specify a response topic in the request message, and also add 'correlation' data to track the context of the call.

Re: MQTT turns 25

#59

Post by tcshit »

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…

There is a very nice MQTT client C++ implementation that works great on embedded devices too. As it so happens, it is right now under formal review for inclusion into Boost. It is called async-mqtt5 and can be found at: https://github.com/mireo/async-mqtt5/

Re: MQTT turns 25

#60

Post by kerblang »

I don't buy the b.s. around MQTT being so lightweight/efficient/etc. It's just using TCP/IP. Maybe by the standards of the day that was comparatively special, but I've never seen any real evidence for the claim besides this constant bragging.

I guess it's nice that MQTT is a standard and so you have a way to connect to off-the-shelf devices that are enabled. I still think there are better options for pub/sub and message queues, esp. if you need to failover on the consumer side.

Post reply on HN