How to set QOS 1 or QOS 2 level in tasmota for publishing

[Shanmukha B]

Hi Everyone ,
I'm using Sonoff PowR2 for calculating energy consumed by each AC.

and I'm receiving the information through mqttx .

I have connected with persistence connection , I'm using Hivemq broker .

1) when I close the mqttx application and published from tasmota , then after some min      I opened the mqttx once again , but I didn't received any messages that where sent            when mqttx was closed.

then I used mqtt box application for publishing instead of tasmota with QOS 2 and did the same (first point ). I received messages when I opened the mqttx .

then I confirmed that tasmota is not publishing with  QOS  level more than 0.

(I have seen in some GitHub pages regarding the publishing  QOS  level before confirming ,that tasmota is sending using  QOS  0 level)

Is there any way to change this  QOS  level 

Regards 

Shanmukha

[Stephan Hadinger]

The pubsub library Tasmota is using states the following:

"It can only publish QoS 0 messages. It can subscribe at QoS 0 or QoS 1."

Generally speaking, sending QoS 1 messages needs local memory which ESP8266 lacks. It could probably be done on ESP32 but it's not in our roadmap.

QOS 2 is rarely supported anyways.

Best

Stephan

[Philip Knowles]

I may be misunderstanding here but isn’t your issue with hive not Tasmota? Tasmota is sending the message to hive – hive, as the broker, is responsible for sending it on – that’s the whole point of MQTT. QOS ensures that the message gets to the broker – the broker is then responsible for forwarding to the recipient.

 

A description of the actual use case might be helpful.

 

Sent from Mail for Windows

--
You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/990d481f-b778-48c9-a576-fb2dbd4c2d33n%40googlegroups.com.

 

[Shanmukha B]

thanks guys for your time

To stephan:

From what you have said ,tasmota supports only QOS 0 level of publishing.

1) Can it be changed? 

2) In QOS 1 why does the messages need local memory?

To knowles:

To be clear i will once again give the details :

The connection between tasmota and broker is solid and no connection problem between them. The problem is with subscriber(here in my case mqttx application) and broker .

As you know for  the persistence type connection , both the subscriber  should subscribe using QOS level higher than 0 and publisher should publish using QOS level higher than 0.

So here in my case subscriber ( me with mqttx application) is subscribing using QOS level 2 , but since the tasmota(publisher) is publishing with QOS level 0 ,the hivemq broker is not queueing those messages .

[Shanmukha B]

QOS 1 while publishing will solve the problem 

Is there any way to make it ?

[mohan RatiRam]

we observed that broker (Mosquitto) will queue messages for "eligible" persistent subscribers only if the publisher published the messages at QoS > 0 . If the messages were published at QoS 0 it will not be queued , no matter how "qualified" the persistent subscriber is.  We understand it is the limitation of the pub sub library Tasmorta is using. Is there anyway we can customize Tasmota to use another library that supports our requirements ? In our deployment, a single subscriber will listen to MQTT messages from 100s of device and is therefore crucial we don't loose any valuable info just in case the subscriber (Spring Boot app) goes down. Any pointers , how-to guide is greatly appreciated. 
best,

mohan

[Stephan Hadinger]

There is no simple change to publish with QoS 1. First the client must track the Message Ids, second it needs to republish any unconfirmed message. It also generates additional traffic on the network.

It might be possible to add only Message Ids with a monotonic counter, and drop the resending of lost messages. But even doing this would require massive testing.