Berry MQTT subscription gets lost after few hours.

[Mape24]

Hi,
I got MQTT subscription running smoothly in Berry for the first few hours. After ~12h the engine simply stops calling the MQTT callback function. Berry continues to work without MQTT data. It seems to be a bug. Debugging is time consuming. I will add more information over the next weeks.

import json
import mqtt
import string
var init=0                       # wir müssen MQTT verzögert initialisieren
var Batt_Volt=0

# ----- MQTT callback function:
def PowMr_MQTT_data(topic, idx, payload, bindata)
	if string.find(topic,"PowMr") > 0
		Batt_Volt    = json.load(payload)['Batt']['Batt_Volt']
		print("+++ MQTT received from", topic, payload, Batt_Volt)
	end
end

def f_10sec() 
# ----- Initialisierung:
	if init == 0                          # verzögert starten!
		init = 1
		mqtt.subscribe("stat/PowMr/RESULT", PowMr_MQTT_data)         # MQTT muß man verzögert starten!
	end
end

tasmota.add_cron("*/10 * * * * *", f_10sec, "every_10_s")

HW: ESP32C3
FW: Tasmota 14.6.0.1 self compiled

[sfromis]

Actually, you do not need to delay the MQTT subscribe, since a long time ago the mqtt module will accept a mqtt.subscribe any time, and make the broker call when relevant, including after reconnecting. I'd recommend to not have that cron timer, and just do the mqtt.subscribe right away.

And if you actually needed the delay, a more robust approach would be new new feature of tasmota.when_network_up, to provide a function to be executed when networking is available. But not needed for MQTT subscriptions.

Back to the topic, one step in debugging could be to inspect the list mqtt.topics (like just printing it) which should contain one listener entry per subscription. It could also be relevant to check the uptime, like if there was a restart for some reason.

[Mape24]

This suggested version of code (see below) does not work. So I went back to the code version above.
Meanwhile I use FW Tasmota 14.6.0.2 self compiled. MQTT still gets lost after 12-20h.
Recurrent entering
<mqtt.subscribe("stat/PowMr/RESULT", cb_MQTT_data)
does not fix the issue. I will try mqtt.topics next time it happens.

none working code:

# rename to autoexec.be 

import json
import mqtt
import string

var Batt_Volt=0

# ----- MQTT callback function for battery data:
def cb_MQTT_data(topic, idx, payload, bindata)
	if string.find(topic,"PowMr") > 0  && string.find(payload,"Batt") > 0
		Batt_Volt    = json.load(payload)['Batt']['Batt_Volt']
		print("+++ MQTT from", topic, payload, Batt_Volt)
	end
end

mqtt.subscribe("stat/PowMr/RESULT", cb_MQTT_data)

[sfromis]

Doing a test with your "none working code" (with different strings to match my setup), I saw the subscription work as expected, without that fluff about wrapping in a cron timer.

Right after boot, I'm getting MQT: Subscribe to xxxx (but obviously no live subscription yet), and after connecting:

BRY: mqtt subscribe all registered topics
MQT: Subscribe to xxxx

Detail: If you want to check if a string contains some substring, it would be more reliable with > -1 as the result will be 0 if the substring is contained in the start.

[Mape24]

I tried "none working code" again. Indeed it works if you only restart Berry. If you reboot Tasmota it does still not work! The code with cron timer works also for reboots.
With a reboot of "none working code" mqtt.topics shows this answer:

[<instance: mqtt_listener('stat/PowMr/RESULT')>]

but it seems to be wrong as Tasmota is actually not listening in this case. So, we follow 2 different bugs at the moment.

I have another offline topic: I could implement a simple fix for me if I knew the command for Reboot 1 within Berry. tasmota.cmd("Reboot 1") is not recognized here.

[sfromis]

My testing was specifically with a Tasmota restart (both the Restart command and power cycling); not merely restarting the Berry VM. Worked just like already stated. While this discrepancy might seem immaterial on the surface level, I'm suspecting that whatever is different for you might be the deeper explanations.

https://tasmota.github.io/docs/Commands/#management indeed has no Reboot command, what you are probably looking for is the command Restart.

[Mape24]

Another detail: On my -C3 devices the "none working code" version works only when restarting Berry with the red button, but not when using BrRestart command and not when restarting Tasmota.

On my production system I have a version now with watchdog and tasmota.cmd("BrRestart") and with cron timer. I didnt find any pure Restart command. With some luck this "works around" these 2 above reported bugs. However, the bugs are not fixed with that work around.

I will keep you updated with this long term bug.

[Mape24]

I have another detail and probably bug #3. You suggested using tasmota.when_network_up but it also doesn't work for MQTT. I get the same behavior like for the "none working code" above.

def loadmqtt()
	mqtt.subscribe("stat/PowMr/RESULT", cb_MQTT_data)
end
tasmota.when_network_up(loadmqtt)    # start when network is connected

[Mape24]

The following information is about the original Bug report "MQTT subscription gets lost" at ESP32C3.
Once in the lost state (after 12...36h) I get this answer on the Berry-console:

mqtt.topics
[<instance: mqtt_listener('stat/PowMr/RESULT')>]

after re-entering mqtt.subscribe("stat/PowMr/RESULT", PowMr_MQTT_data) , the Berry-console output is the same and still no MQTT messages come in. This "lost" state is similar to the state I'm entering when using this tasmota.when_network_up command - which just happens immediately.

[sfromis]

Until you can make it work with tasmota.when_network_up, you have a more basic issue needing debugging, and much easier to debug when you do not have to wait hours for it to happen. Since you get reasonable output from mqtt.topics, Tasmota does not appear to have "lost" anything there.

[Mape24]

What kind of debugging do you recommend? So far I was just user of Tasmota. I cannot (yet) help making tasmota.when_network_up command work.

[Mape24]

Tasmota version 15.0.0 did not solve the issue.