General > General Technical Chat

MQTT - is it a fad which will move on?

<< < (3/3)

ejeffrey:

--- Quote from: peter-h on February 09, 2022, 04:37:46 pm ---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?

--- End quote ---

Sure, I would guess the majority of them do. 


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

--- End quote ---

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

Siwastaja:
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 a protocol to 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.

ejeffrey:
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.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod