[SOLVED] Incorrect MQTT value when reset ESP

Add-ons Bindings
1

Hi,
I’m using an ESP-12 to activate a relay using MQTT topics from openhab switch.
All is working well, except that when i reset the ESP, it always powers up with the state = 0, regardless of what the state is in openhab.
My reconnect to MQTT function generates an initial subscribe, and its getting the value of 0 at this point.
Any ideas how the relay can be mapped to the state of the openhab switch when its restarted/powered down/or reset.
thanks

2

You can use a qos of 2 with a retention policy. This will cause the broker to retain the last message and when the ESP comes up it will get the last message redelivered.

At least that is what I experienced when my garage doors would open every time my pi rebooted with these mqtt settings. You may only need the retention policy.

3

Thanks Rich.
I have had a pretty good search but I can’t find how to set retain flag. Can you describe or post a link,

4

No, but I know it is one of the flags in mqtt.cfg.

5

Thanks rich, seems to work. I changed retain = true in mttq.cfg and does as you describe, thanks heaps

6

On a similar topic.
When the broker is busy and more data is coming in, the data is ignored and lost. Is there a way to make sure that data comes through and is say queued so it gets through the broker to openhab? I have looked at pubsub but it doesn’t seem to have qos capability higher than 1,

thanks

7

What broker are you using that exhibits this terrible behavior? Typically the most common broker used around here is Mosquitto and I’ve never encountered any reports of it dropping messages when it is “busy”, whatever that means.

Any queueing will be implemented on the broker (there are settings for Mosquitto at least) and since your broker is broken I’m not sure it would help.

8

I am using mosquitto with an openhabian setup on rpi
When monitoring the broker with mqtt, "busy"is when there is a bunch of data coming from other sensors in quick succession. (through wifi). I have a sensor that Im testing posting data (via ethernet shield + arduino) every 10 secs, and if the timing corresponds to the data from the other sensors, it isnt reported on mqtt.

9

I can’t explain that behavior. I’ve never seen Mosquitto lose a message and I have lots of sensors that report once a second or faster and by that measure Mosquitto is always busy. Haven’t missed a message yet and I use QOS 0.

By default Mosquitto is configured to support 20 QOS 1 or QOS 2 inflight messages per client and a maximum of 100 QOS 1 or 2 messages in a queue (i.e. not inflight).

By default it does not queue any QOS 0 messages though but there is a setting to enable that:

queue_qos_messages true

I think it is more likely that the messages are not getting to the broker than it is that the broker is unable to handle them. Even on a Pi 0 a Mosquitto broker should be able to handle hundreds to thousands of messages at the same time. But if the network is spotty and the messages never get transmitted to Mosquitto then there is nothing the broker can do about it. But with a QOS 1 the client should keep on trying to send the message until the Broker acknowledges its receipt.