MQTT qos parameter has no effect - mqtt

I have installed a mosquitto server on a raspberry server.
This server works fine: I have test with mosquitto_sub and mosquitto_pub commands.
I have write this python script:
import paho.mqtt.client as mqtt
import time
client = mqtt.Client('module_test_4')
client.connect('127.0.0.1', 1883, 10)
client.loop_start()
for i in range(10):
client.publish('topic_2', "valeur %d" % i, qos=0)
time.sleep(1)
client.loop_stop()
client.disconnect()
I have launched this script twice on 2 consoles:
mosquitto_sub -h 127.0.0.1 -i module_test_2 -t topic_2
It works fine: I see messages on each console.
Now, i have tried to change qos parameter to 0,1 and 2.
I have tried to run my python script without lauching any occurence of mosquitto_sub.
I was thinking mosquitto will buffer messages and send it again when mosquitto_sub will be launched but this does not work.
So i am wondering how qos works...
Thanks

QOS only applies to one leg of the connection at a time.
This means the QOS can be different between the publisher/broker and broker/subscriber.
So in the example you have posted you set QOS to 2 between the publisher and the broker, but it is still the default 0 between the subscriber and the broker. This means that as far as the broker is concerned the subscribing client only wants QOS 0.
If you want to test with mosquitto_sub you need to include a higher QOS on the command line as well. You need to have established a subscription at QOS 2 before disconnecting like so:
mosquitto_sub -h 127.0.0.1 -i module_test_2 -t topic_2 -q 2
You also need to tell mosquitto_sub not to ask for a clean session when it reconnects:
mosquitto_sub -h 127.0.0.1 -i module_test_2 -t topic_2 -q 2 -c

Related

Display of the missed messages from the publisher with a new subscriber connection (MQTT / Mosquitto)

Publusher sends a message -m "hello" to the topic -t hello using the command mosquitto_pub -h 172.17.*.* -t hello -m "hello" -d. The subscriber sees the message -m "hello" only if the connection to the topic -t hello is active. However, if the subscriber is not subscribed to the -t hello topic and the publisher still sends messages on the -t hello topic, then when you try to subscribe to this topic mosquitto_sub -h 172.17. *. * -t hello subscriber does not receive sent messages from publisher.
After reading the documentation, breaking a couple of brokers, I achieved only the fact that you can see the last message if you put the flag on the publisher -r like this - -mosquitto_pub -h 172.17. *. * -r -t hello -m "hello". I configured mosquitto.conf, because I thought that the main changes, an example of the current problem, can only be achieved through it.
How can I solve such a problem, I would like to see all missed messages from publisher when i resubscribe to the topic?
You need to use the QOS (Quality of Service) values for the messages. By default QOS is set to 0 which is basically fire and forget, QOS 1 is ensure delivery (but could mean delivered more than once). QOS 2 is ensured delivery only once.
It's needs pointing out that QOS is between 1 client and the broker, so this can be between the publisher and the broker, or the broker and a subscriber independently. (e.g. you can publish at QOS 0 and then subscribe to the topic at QOS 2).
For message queuing for offline clients, the client needs to have been subscribed at QOS 1 or QOS 2 and when it reconnects it needs to have it's cleanSession flag set to false and use the same client id.
MQTT brokers will not queue messages for clients that have never connected before.
With mosquitto_sub and mosquitto_pub you can set the QOS level with -q option and you can set the client id with the -i option. To set the clean session flag to false for mosquitto_sub you should use the -c option

How to use client id in Mosquitto MQTT?

I am new to Mosquitto. I have installed Mosquitto and Mosquitto Client in Ubuntu. I am trying to subscribe with client-id also publish with client-id, please look the command that I have run in console, but unfortunately, the subscriber is not receiving the message.
Subscription
mosquitto_sub -h localhost -t temp/city1 -c -q 2 --id client-one
Publish
mosquitto_pub -h localhost -t temp/city1 -m "32 Celsius" -q 2 --id client-one
but if I Publish message without client id the subscriber is receiving message, so please help me where I did the mistake?
As mentioned in the comment, clientIds are just that, they are a unique identifier for each client connected to the broker.
ClientIds need to be totally unique, if a second client tries to connect with a clientid that is already connected the broker must disconnect the first client to allow the second to connect (this is dictated by the specification). In the example you have given the subscriber will be disconnected before it receives the message published by the second.
Messages are published to topics and clients can subscribe to these topics (or patterns of topics with wildcards)
So using the mosquitto command line tools you can do the following:
mosquitto_sub -v -t 'foo/bar'
This will subscribe to the topic foo/bar and will print out the topic and then message when ever a message is published to that topic. To publish a message containing the string testing you would use:
mosquitto_pub -t 'foo/bar' -m 'testing'
The mosquitto command line tools will generate random clientids if none are provided on the command line.

Messages not received on first time connection

I am unable to receive messages on first time connection. for in more detail,user A is connected and publishing messages,but user B is not connected to that topic.So when user B will connect,he will not get any message from user A because there is first time connection b/w user a and user b.
How we can resolve this issue ?
Thanks
A principle of pub/sub is that the publisher and subscriber are decoupled, so you shouldn't really be thinking in terms of user a being connected to user b.
If you want a client to receive messages when they are not connected (leaving retained messages to one side), the only way to do this is:
Connect beforehand with cleansession=false
Subscribe with QoS>0 (or on mosquitto use the queue_qos0_messages option)
Ensure that messages are published with QoS>0
When the client reconnects, use cleansession=false
To test this, try:
mosquitto_sub -i prajbot-singh -h test.mosquitto.org -t prajbot-singh -c -q 1
Then quit from mosquitto_sub and run:
mosquitto_pub -h test.mosquitto.org -t prajbot-singh -m hello -q 1
And run mosquitto_sub again:
mosquitto_sub -i prajbot-singh -h test.mosquitto.org -t prajbot-singh -c -q 1

IOT Mosquitto mqtt how to test on localhost

I'm just playing around with mosquitto ans mqtt protocol
following the very good video
https://www.youtube.com/watch?feature=player_embedded&v=WE7GVIFRV7Q
trying to test it on my localhost
in a terminal window I run :
mosquitto_sub -t "nodeconf/eu" -v
but when I run this snippet:
var mqtt = require('mqtt');
var client = mqtt.connect();
client.on('connect', function () {
client.subscribe('nodeconf/eu');
client.publish('nodeconf/eu','Hello');
});
client.on('message', function (topic, message) {
// message is Buffer
console.log(message.toString());
client.end();
});
I don't see (in my terminal window) any Hello.
What's wrong, please ?
BTW
I'm also looking for good tutorial and guide on the topic thanks.
You have to add a console.log to your second (the javascript) client to see why it doesn't publishes the Hello properly.
But you can do a typical test with the mosquitto clients:
1) Subscribing to a topic:
mosquitto_sub -d -h localhost -p 1883 -t "myfirst/test"
2) Other client publishes a message content to that topic:
mosquitto_pub -d -h localhost -p 1883 -t "myfirst/test" -m "Hello"
3) All the subscribed clients to this topic will automatically get the message.

Inform me when site (server) is online again

When I ping one site it returns "Request timed out". I want to make little program that will inform me (sound beep or something like that) when this server is online again. No matter in which language. I think it should be very simple script with a several lines of code. So how to write it?
Some implementations of ping allow you to specify conditions for exiting after receipt of packets:
On Mac OS X, use ping -a -o $the_host
ping will keep trying (by default)
-a means beep when a packet is received
-o means exit when a packet is received
On Linux (Ubuntu at least), use ping -a -c 1 -w inf $the_host
-a means beep when a packet is received
-c 1 specifies the number of packets to send before exit (in this case 1)
-w inf specifies the deadline for when ping exits no matter what (in this case Infinite)
when -c and -w are used together, -c becomes number of packets received before exit
Either can be chained to perform your next command, e.g. to ssh into the server as soon as it comes up (with a gap between to allow sshd to actually start up):
# ping -a -o $the_host && sleep 3 && ssh $the_host
Don't forget the notify sound like echo"^G"! Just to be different - here's Windows batch:
C:\> more pingnotify.bat
:AGAIN
ping -n 1 %1%
IF ERRORLEVEL 1 GOTO AGAIN
sndrec32 /play /close "C:\Windows\Media\Notify.wav"
C:\> pingnotify.bat localhost
:)
One way is to run ping is a loop, e.g.
while ! ping -c 1 host; do sleep 1; done
(You can redirect the output to /dev/null if you want to keep it quiet.)
On some systems, such as Mac OS X, ping may also have the options -a -o (as per another answer) available which will cause it to keep pinging until a response is received. However, the ping on many (most?) Linux systems does not have the -o option and the kind of equivalent -c 1 -w 0 still exits if the network returns an error.
Edit: If the host does not respond to ping or you need to check the availability of service on a certain port, you can use netcat in the zero I/O mode:
while ! nc -w 5 -z host port; do sleep 1; done
The -w 5 specifies a 5 second timeout for each individual attempt. Note that with netcat you can even list multiple ports (or port ranges) to scan when some of them becomes available.
Edit 2: The loops shown above keep trying until the host (or port) is reached. Add your alert command after them, e.g. beep or pop-up a window.

Resources