search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.12k stars 4.79k forks source link

MQTT vs HTTP #2222

Closed Kepete closed 6 years ago

Kepete commented 6 years ago

I'm using Sonoff basic with homebridge and I can see a lot of ready made awesome plugins for Sonoff. Some of them work over MQTT and others over HTTP. Has one of them any better features than the other? HTTP is way easier to setup. MQTT needs a broker. What other am I missing? :)

arendst commented 6 years ago

MQTT is a message queueing solution where HTTP as implemented on Tasmota is more a point to point solution.

To access a device using HTTP you need to know it's address or have setup a DNS environment to address it by a name.

MQTT is way more superior over HTTP as:

Kepete commented 6 years ago

@arendst Thank you for your answer! The Tasamota firmware for Sonoff Basic is already running a webserver so I need only the IP address and I'm ready to go. Anyway, I'm going to look at the MQTT option as well and will see which fits my needs the best!

Frogmore42 commented 6 years ago

If you are using a single device http is easy. As soon as you get beyond a few or you want to also use NodeRed or some other software, MQTT becomes far superior and easier to manage.

ascillato commented 6 years ago

Hi

If your issue was solved, please close it. Thanks :+1:

hepcat72 commented 3 years ago

MQTT is a message queueing solution where HTTP as implemented on Tasmota is more a point to point solution.

Let me make a respectful counter argument...

I respect your opinion that MQTT is superior to HTTP, however, I think you a technically incorrect WRT the above statement about "point to point". I'm sure you know more than I do about MQTT, so take the following with a grain of salt, but as I understand it, the whole point of MQTT is that it's not a point to point solution (which HTTP is). MQTT has an intermediary (the message broker). A message gets sent to the broker from one point and the other point has to subscribe to those messages. Point 1: sender, Point 2: broker, Point 3: receiver. There are multiple advantages to this. The two main ones I see are:

  1. If a receiving device is offline or busy, the message will be reliably delivered once the end-point device is online.
  2. Multiple devices can subscribe to the messages, so the sender only needs to send one message (to the broker).

From a user perspective, who doesn't care about message delivery when a device is offline and only ever has 1 sender and 1 receiver, who is already familiar with webhooks, and whose devices already have a web server built-in, setting up and learning MQTT is a big hurdle for, what to them, seems like it should be a much simpler task. It took me a long time to learn the above 2 points reading about MQTT online.

Additionally, my Pi is already overloaded running node-red & homebridge, each with a bunch of plugins, and pilight (which is a resource hog). So as it is, my Pi is often too busy to service a request via Siri, so I sometimes have to issue a command multiple times before it works. (I have a new Pi 4 that I've yet to set up, so I know this is my own problem to solve, but...) Adding a new service (e.g. an MQTT broker), from my perspective, seems like an unnecessary additional burden on my Pi, when a point to point message is all I need.

To access a device using HTTP you need to know it's address or have setup a DNS environment to address it by a name.

TBF, knowing the DHCP address seems like an easier thing to know than learning how to set up an MQTT message broker. If a user has just set up an IoT device, they already know its DHCP address. I just set a static DHCP address for my sonoff and I use my mDNS address for my Pi under many contexts frequently, so knowing these addresses is not an additional thing to know whereas learning about MQTT is in many cases, a completely unfamiliar territory. New users of IoT schemes (I would guess) already know webhooks and URLs.

MQTT is way more superior over HTTP as:

  • Implementing a HTTP webserver on a device takes 50k more code than just using MQTT.

Completely fair point, though doesn't tasmota already send and receive web commands? POST isn't technically necessary, but I just set up rules that use WebSend and just learned today that I can turn my sonoff on/off with a GET. It's very easy for me to set up homekit to create a button that use these.

  • For a client there is no knowledge needed of physical addressing the device other than it's topic name

The concept of a topic is rather abstract and can seem rather daunting and vague to a new user. This was another seemingly magical thing to me until yesterday, in fact. I've been using my Pi and Node RED for a couple years and have been able to put off understanding the utility of topics until then. A user is typically familiar with a web address and thus represents a lesser technical hurdle/shallower learning curve. Using topics for target destinations/origins introduces a new paradigm on top of URLs that I would argue are foreign to most new users.

  • Multiple devices can be addressed with just one grouptopic command allowing bulk updates or bulk power off/on - I use a single command to update some 20 devices at once. - I use a single command to turn off all power at midnight.

This is the great advantage of MQTT. The only thing for me is, I don't have any need for this. In fact, this is a solution provided by everything: node-red allows me to do multiple things with a single command. Siri has scenes. My Broadlink RM Mini has sequences. In fact, there are too many ways of controlling multiple devices, to the point where it becomes difficult to edit automations. I have frequently had difficulty trying to remember which automation platform is controlling device X until I settled on having Node-RED do everything. So even if I end up setting up MQTT, I don't anticipate ever using its capability of multiple event subscribers.

  • I'm sure there are many more advantages over HTTP (or REST).

I totally respect the choice of focussing on MQTT, but I think that HTTP is more approachable to a broader user base.

My first learning of MQTT was a few years ago when I was trying to figure out a way to get garage door events into Node-RED. Every time I posted about it, someone suggested MQTT (without really knowing how it would actually work) and I kept asking question after question until I finally wrangled the details out of the person who suggested it. It required 1 of 2 things:

  1. Install new firmware on my opener that could send MQTT events
  2. Get an MQTT-aware door sensor to report the door state

So this first impression of MQTT was a poor one for me and I have not been a fan since.

Wanting a smaller code footprint is a totally valid point in and of itself and I concede that accommodating new (less knowledgeable) users is not necessarily a goal the tasmota project has. And I'm certain there are definitely more advantages to extol of MQTT, but I just thought I'd add my 2¢.

Frogmore42 commented 3 years ago

Umm, 2 year old and closed issue. Use discussions if you would like to have a discussion about the merits of http vs mqtt. Tasmota, at its core, is about providing mqtt to (originally Sonoff) devices. But, that doesn't mean mqtt is the right choice for all use cases.