MQTT is a "messenger" between devices:
your device measures at time T a temperature of X degrees
it connects (itself or via the zwave hub) to the MQTT broker
it create a message with the topic /domotics/myplace/mydevice/temperature
within the message it just puts X (as the "payload")
Elsewhere in your house:
your Raspberry Pi is connected to the MQTT ...
The question setting here is little bit misleading, because actually these protocols cannot at all be compared together. They are like TCP and IP, layers above each other. 
Websockets is a low level protocol to provide things that its 'competitor' RESTful http that is on same level does not provide: an always open channel without need for open and close ...
MQ Telemetry Transport Protocol known as MQTT is designed for devices which run on low power and low bandwidth. It is a lightweight publish/subscribe messaging protocol which means any other device can subscribe to a particular topic.
HTTP/HTTPS is designed as a request-response protocol for client-server computing which never bother about power usage and ...
Yes, it is possible to subscribe to a topic that is created by itself.
An MQTT client can be both a publisher & subscriber at the same time. In MQTT terms, a client includes both subscribers and publishers.
I am interested in what are the uses cases of this feature?
A possible use case (I assume) is that, suppose if there are three clients (x,y,z) ...
MQTT has to run over TCP/IP (I can't remember if it's actually in the spec or if just enough assumptions are made to make it so) but its sister protocol MQTT-SN can be run over nearly any protocol that can pass data, I've seen implementations in UDP and serial.
Having said that I'm not sure what you gain by running either over BLE, BLE's built in ...
Yes, Mosquitto does support multiple brokers.
Mosquitto uses MQTT Bridges to connect multiple brokers thus routing messages between these mosquitto brokers. This way a bridge between your primary broker to a fallback system can be established. Avoid creating loops though. If both brokers run your clients publish to the primary broker which then publishes ...
A Raspberry Pi 3 is a pretty serious bit of kit when you think about it
Quad core Arm Cortex
1gb of RAM
a onboard GPU
That is a huge amount of memory, easily more than enough to run a MQTT broker and something like Node-RED to interface between a LoRa radio and the broker.
We have a commercial gateway (MultiTech MultiConnect Conduit) in the office which ...
Some ideas - I've not covered all combinations of with/without username/TLS, hopefully you can see where they are missing.
Can a client connect anonymously, no TLS?
mosquitto_sub -t test/topic -h <broker address>
Can a client connect if it provides a username but no password, no TLS?
mosquitto_sub -t test/topic -u <username> -h <broker ...
a similar system (extension/plugin) for the mosquitto broker
As far as I know there is no plugin/extension for mosquitto broker ( at least no opensource one )
another recommended method that works with mosquitto
Well I can say per my experience with Mosquitto broker and AWS IoT, you can just directly subscribe to '#'
After looking ...
MQTT (Message Queue Telemetry Transport) seems to be well suited for the proposed application.
It is lightweight both with respect to bandwidth (smallest packet size with a header of just 2 bytes) and client code footprint (enabling it to run on thin clients like the ESP8266, typical IoT client). Reduced transmitted data is beneficial to longer battery life ...
Is it possible to implement MQTT on this device?
Any device that has TCP/IP layer can implement MQTT.
What requirements should a microcontroller match to be able to use/run MQTT?
You need to ask the following questions to know whether your device runs MQTT.
Is my device having TCP/IP or networking support?
Is there some memory and disk space available ...
Does this mean that if a Client subscribes, then it remains connected to the server while the subscription is valid even though there are no data flow in most of the time?
Yes, once the connection is made the client will wait for messages, however it will also send PING messages to the server regularly based upon the keepalive value. If a PING message is ...
This discussion on the openHAB mailing list seems to suggest there's no issue with using # as a subscription to receive all messages:
Whilst troubleshooting MQTT devices, it occurred to me that sometimes I
wish I could see all MQTT messages that the Mosquitto broker sees, instead
of a on a specific topic. Is there a way to do this?
The mbed mmqt library doesn't seem to document any memory requirements as likely to be limiting, and can reasonably be assumed to be targetted at this sort of small-footprint device as an endpoint. You could fairly trivially import the library into a similar device platform using the online compiler and check the code footprint at least.
Imagine your network as a Venn diagram where one set is LoraWan and the other is MQTT.
Elements in the sets should know only about their set(s).
So nodes using LoraWan (are in the LoraWan set) do not have to bother with MQTT or with the server. They just send/receive data to/from the Gateway. The Gateway is the end of their world.
The Gateway is in the ...
Arguably, you'd be better off doing a simple mapping of the data from BLE paradigms to MQTT, rather than trying to literally send MQTT over BLE.
BLE generally exchanges data in the form of characteristics. These have various BLE-unique mechanisms for discovering value change that you may find useful. But they have a maximum data length of 20 bytes.
It is ...
As you say, it depends on the server implementation, especially the QoS of the transmitted message if it is "at least once".
IMHO MQTT is a broadcasting system, not a end-to-end protocol between two machines so we don't absolutely need a subscriber every time we create a subject.
I can post anything (temperature,...) and two months later implement ...
I think it is important to consider that there are many different use cases for MQTT brokers, as with any piece of software.
Handling chat messages for a billion users (many users, relatively low message rate per user) is different to a system with few clients but a high message rate, and they are both different to a home automation system (few clients, low ...
Turns out there is no broker running on the Arch system whereas installing mosquitto on Raspbian automatically starts it. Simply enable and start the broker.
Start the systemd service.
systemctl start mosquitto
Enable the systemd service to run on boot.
systemctl enable mosquitto
In .NET the implementation allows to connect one client to one broker, so I'd say why not...
string broker = ini.getData("MQTT", "hostname");
mqtt = new MqttClient(broker);
mqtt.MqttMsgPublishReceived += mqtt_received;
Thing is, you must manage duplicates in case of a fallback when the other broker ...
I think Mosquitto saves the in-memory messages to disk.
persistence [ true | false ]
If true, connection, subscription and message data will be written to the disk in mosquitto.db at the location dictated by persistence_location. When mosquitto is restarted, it will reload the information stored in mosquitto.db. The data will be written to disk when ...
A little bit of context
Since you're using MQTT with AWS IoT, you're expected to use X.509 certificates for authentication and security. Amazon have a little bit of guidance about how you should secure your certificates, so I'll quote that here:
Certificates enable asymmetric keys to be used with devices. This means you can burn private keys into secure ...
A few things:
The mosquittto_pub and mosquitto_sub commands do not support WebSockets at all.
When you run mosquitto from the command line you have to explicitly point to the config file with the -c option
mosquitto -v -c /path/to/mosquitto.conf
The Windows builds available from the mosquitto.org download pages don't support WebSockets, so the only way ...
They're comparable in that both allow you to have full-duplex communication such that the server can immediately pass data to the client, without the client polling for it (as might be with HTTP).
However, Websockets is designed for a simple point-to-point connection between a client and a server. MQTT layers extra abstractions on top of basic message ...
I wouldn't expect the difference to be too significant, once the connection is set up.
A breakdown of the overhead that TLS produces in general can be found here. The important bits are:
The total overhead to establish a new TLS session comes to about 6.5k bytes on average
The total overhead to resume an existing TLS session comes to about 330 bytes ...
You basically have 3 options if you don't want to forward a port.
Use a broker in the cloud so client from home always connect out to it. Use TLS and authentication so others can't eavesdrop or inject unwanted messages
Use a cloud broker and set up a bridge between the internal broker and cloud broker (you still want to encrypt and set username/password on ...
Technically speaking, yes, an ESP8266 could act as an MQTT broker. In fact, someone has already tried it! By the end of their project, they claimed to have a broker that can bridge to a cloud MQTT broker, with a web interface and a decent amount of uptime. In the comments, they say that their code is proprietary, so you won't be able to use their code ...
I am unaware of any such standards.
As pointed out in the answers to the other question, pub/sub doesn't lend itself to RPC but it can be bent to fit.
One of MQTT's strengths is that the payload can be anything at all, allowing a developer to make the best choice for their project.