ESP8266 Community Forum

- Sat Sep 26, 2020 8:40 am #88906 In applications where you are not interested in individual reliability then why not use udp messaging direct from sensor to end point.

MQTT is there normally to provide reliability.

I guess there can be cases where you want to interface to standard mqtt server/client frameworks but not hold up the original 'sensor' client. That could just be an option not to wait for PUBACK.

- Sat Sep 26, 2020 8:51 am #88907 My main goal is not for my own purposes, for that I am already a satisfactory proprietary protocol. The main goal is to allow using a commonly used broker/server/service, like, apparently, many of us do. So that would probably dictate the use of TCP.

- Sat Sep 26, 2020 8:06 pm #88918 MQTT QoS0 discards messages on send so that's the one you may want to use. The reason to use other QoS levels is more on the command and control side where the broker is talking to the sensor units to give them commands.

MQTT can use raw TCP or WebSockets - UDP is normally not used.

You connect clients to a central broker, which provides the messaging only - it's then up to you what you do with the messages. Typically you'll create one or more MQTT client applications that will subscribe to the same topics your sensors publish on, and publish to the topics they subscribe to, and then the application will get your published sensor messages and be able to control them.

I think every single major cloud provider has an IoT portal that talks MQTT - I have used AWS, Google, Azure and IBM Cloud before - my fave is IBM Cloud in terms of security and simplicity, and also what they provide for management of devices. I have both a Kafka event streams application and a NoSQL database connected to the IoT Platform - with IBM it's done via an API, but what is actually happening is that the management platform, the database and the streams service are all attaching as MQTT client applications.

You can also really easily create a nodejs web application and a Node-RED message processing system and connect that to the IoT broker - they all use MQTT.

The ecosystem once you move to MQTT is *extensive* and so simple to use.

If you want your own broker then there are a lot out there - there's even one that runs on a Raspberry Pi. Mosquitto is a popular open source MQTT broker - I run that locally when needed but for the most part I just use the IBM IoT Platform and connect as an application client from my laptop or from cloud applications.

Last edited by davydnorris on Sat Sep 26, 2020 9:01 pm, edited 1 time in total.

- Sat Sep 26, 2020 8:10 pm #88919 Oh and you're right - MQTT messages are just binary, so you can send whatever you like - it's up to the subscribing application to unmarshall the messages.

Each major platform also has their own capability in place - most of them will take a JSON payload and unmarshall it automatically for you, and then their various consoles will let you play with the content to transform and graph it and put it on dashboards, or set up event rules etc.