setting keepalive via setConfiguration sends owntracks into a tight MQTT connect/disconnect loop.

[JuliusFruitfly]

Setting 'keepalive' in setConfiguration sends owntracks into a tight MQTT connect/disconnect loop.

Log attached

• App build number: 2.5.3
• Android version: 12
• Device: Huawei P30 lite
• Installation source: Google Play

• owntracks-log crazy 0410.txt

[growse]

What QoS / retention settings are you publishing that command message on? OT's reconnecting constantly because it's constantly receiving the command message from the broker. Every time it receives a command to set the configuration which includes a connection-relevant preference change (e.g. keepalive), it'll reconnect.

It smells a little bit like you published the message with retention = true. This would cause OT to consume the message, reconnect, and then when it reconnects it receives all the retained messages, meaning that it consumes the command message again, causing it to reconnect etc.

There's probably something we can do to avoid this trap (I've done this loads of times by mistake), will have a think.

[JuliusFruitfly]

I do indeed set retain=True, because, eh, don't know. Sounded like a good idea to retain a config message so it was available when the client first connected. I don't know much about MQTT.

Could you only reconnect if the value changes?

Thanks for your quick response, as always

[growse]

Could you only reconnect if the value changes?

I think this is a good idea.

[JuliusFruitfly]

Thinking about this some more, a setConfiguration only makes sense if it is retained, as the client status is unknown. This is especially true in my scenario where I want to update the config when I transition between home/away and this is exactly when the client is guaranteed to disconnect as it switches between WiFi and mobile data. (Subject to my hazy understanding of MQTT)

[ckrey]

Hazy yes. No, don‘t persist any command. Use qos > 0 if you want to make sure a device picks up a command when it comes online eventually.