[solved] berry: mqtt.publish not working from the script, but from berry-console

[git5any]

Hi,
I have a WT32-ETH with tasmota 14.4.1.3 (tasmota32) and a display running and everything works so far (8xDS18B20, a counter in scripting and a lightsensor to drive display background).
receiving commands via mqtt is also working. The final step I try to integrate is the sending of the temperatur and counter-values via mqtt to my homeautomation.
I need the data in a json-like format. For that I put together the values "volume" and "flow" from "Wasseruhr" in a map:

                                var watermeStr = f"{zWtVol:%4.3f}"
				payloadWM["Wasseruhr"] = {}
				payloadWM["Wasseruhr"]["volume"] = watermeStr
				payloadWM["Wasseruhr"]["flow"] = f"{zWtFlw:%.1f}"
				topic = "tele/DVES_6A1234/WASSERUHR"

zWtVol is the volume and this is formatted in watermeStr to see 3 digits, flow is formatted to 1 digit

print(json.dump(payloadWM))
{"Wasseruhr":{"flow":"7.1","volume":"1235.385"}}

that looks good so far.
In the berryconsole I can type payloadWM or topic and get the values of these variables. When I type

mqtt.publish(topic, json.dump(payloadWM))

the data is published and received from the broker.
But from the berry-script just nothing happens. I print the values just before the publish and see it in the console, but the mqtt.publish does nothing.

                        if mqtt.connected()
				print(topic ,payloadWM, str(payloadWM), json.dump(payloadWM))
				mqtt.publish(topic, json.dump(payloadWM))
			end	

I searched a lot and looked at a lot of examples that I found but I can't find out why its not working from inside the berryscript.

Thanks for any help!

[sfromis]

You told nothing about what's done around the short bit of Berry code you posted as "does nothing", hence no basis for really guessing might be happening.

Anyway, I condensed your lines into an operational test case, and unsurprisingly I'm seeing both the print and the publish work as expected, both from the console and when started via autoexec.be

var zWtVol=1235.385
var zWtFlw=7.1
var watermeStr = f"{zWtVol:%4.3f}"
var payloadWM={}
payloadWM["Wasseruhr"] = {}
payloadWM["Wasseruhr"]["volume"] = watermeStr
payloadWM["Wasseruhr"]["flow"] = f"{zWtFlw:%.1f}"
var topic = "testing/testing/testing"
import mqtt, json
if mqtt.connected()
  print(topic ,payloadWM, str(payloadWM), json.dump(payloadWM))
  mqtt.publish(topic, json.dump(payloadWM))
end

An operational example triggering the behavior you post about would be useful. And do make sure to read the Tasmota console (not the Berry REPL console) when it executes, to check for any error messages and so on.

[git5any]

Thank you for your answer. I tested your example an it works, so the binary seams to work. It is self-compiled to use scripting for SML counter together with berry, display and haspmota.

here is an operational example with the problem, without all the rest (display-handling, DS18B20 handling, lightsensor)

I have a SML counter in tasmota scripting which calls a tasmota-command for the Watermeter-handling.

berry-code:

import json
import string
import mqtt

tasmota.cmd('timezone 99')

var sensors
sensors = json.load(tasmota.read_sensors())
print(sensors)

#- find the topic from tasmota, so it is still configurable. 
(https://tasmota.github.io/docs/Berry-Cookbook/#build-mqtt-topic-string-based-on-fulltopic-configuration) -#
var topic = string.replace(string.replace(
              tasmota.cmd('FullTopic',true)['FullTopic'],
              '%topic%', tasmota.cmd('Topic',true)['Topic']),
              '%prefix%', tasmota.cmd('Prefix',true)['Prefix3'])
            + 'SENSOR'



var zWtVol
var zWtFlw

var waterFlow = false
var millisNew = 0
var millisOld = 0
var flowresetTime = 15000
var bootFinished = false
var mqttconnected = false  # is set true after MQTT connect and subscription is finished
var payloadWM = {}



#- handling of Watermeter ********************************************************************************-#


def t1()
	waterFlow = false
	zWtFlw = 0
	flowresetTime = 15000
	#showWaterFlow(0)
end
def t2()
	bootFinished = true
	print("bootFinished")
end


def handle_Watermeter()
    sensors = json.load(tasmota.read_sensors())
    if sensors.contains("Waterme")
		zWtVol = sensors["Waterme"]["volume"]
		print(sensors["Waterme"])
		var watermeStr = f"{zWtVol:%.3f}"
		print("WaterCounterVolume triggered from scripting in berry: " , watermeStr)
			
		payloadWM["Wasseruhr"] = {}
		payloadWM["Wasseruhr"]["volume"] = watermeStr
		payloadWM["Wasseruhr"]["flow"] = 0.0
		topic = "tele/DVES_6A1234/WASSERUHR"

		if !bootFinished 
           tasmota.set_timer(2000, t2, "2s_timer") # gibt 2sec nach bootup die flow-Messung frei
            
		elif bootFinished
			#- Zeitmessung für flow -#
			# 15 Ablauftimer löschen
			tasmota.remove_timer("15s_timer")
			if waterFlow == false
				waterFlow = true
				millisOld = tasmota.millis()
			else
				millisNew = tasmota.millis()
				zWtFlw = 60.0 / ((millisNew - millisOld) / 1000.0)
				print(zWtFlw)
			#	showWaterFlow(zWtFlw)
				payloadWM["Wasseruhr"]["flow"] = f"{zWtFlw:%.1f}"
				if zWtFlw < 6
					flowresetTime = int(60.0 / zWtFlw * 1000 * 2)
					print("flowresetT: ",flowresetTime)
				else
					flowresetTime = 15000
				end
				millisOld = millisNew

				tasmota.set_timer(flowresetTime, t1, "15s_timer") # waterFlow auf false stzen nach 15 sec
				
				#- MQTT Publish after flow-calculation -#
			end
			if mqtt.connected()
				print(topic , json.dump(payloadWM))
				mqtt.publish(topic , json.dump(payloadWM))
			end	

		end

	end
end
tasmota.add_cmd("handleWatermeter", handle_Watermeter)

tasmota script:

>D


ctWM  =0 ; counter watermeter
cTmp  =0 ; tempVariable für waterCounter 
c_old =0 ; old counter Value

>B	; at boot
tper = 900       ; Teleperiod auf 900sec = 15min

;disable publishing at MQTT teleperiod, on boot
smlj=0
}

>E	;by Event
;print ===event===

>S	;every second


;re-enable publishing at MQTT teleperiod, after 10 seconds of uptime
if upsecs>10 {
smlj|=1
}


>F	; every100ms
cTmp = sml[1]
if chg[cTmp]>0 {
print %3cTmp%
dp3
->handleWatermeter	;Watermeter data to berry
c_old = cTmp
}

>T	; at teleperiod


cTmp = Waterme#volume
if cTmp!=ctWM {
;->disup   ; DisplayUpdate Call nach Berry
print new volume %3cTmp%

ctWM=cTmp
}




>M 1
+1,35,c,1,-80,Watermeter
1,=h==============
1,1-0:1.8.0*255(@1000,counter,m³,volume,3)
;1,1-0:1.7.0*255(@1,flow,ltr/min,flow,0)  ;(does not work for my needs)
#

to simulate the script you have to increase counter1 by 1, lets say after some seconds. Its a counter for pulses with 1liter per pulse. The berry-function calculates the flowrate if a second pulse comes in within a reasonable time (here 15sec).
I could imagine that mqtt doesn't work because of the call from within the created tasmota.add_cmd.
Maybe you can point me in the right direction.
In fact, its my first berry-programming and I guess the code looks ugly.... and there are till some variables and prints that are not needed or just to understand whats going on.

[sfromis]

To me, it is not really an "operational" example when I can't run it without having a lot of other stuff around it, like getting sensor payloads. Anyway, removing the sensor part, again letting the values be constants, the Berry code does work to the point of both the print and the publish being successfully executed when I invoke the code via a command.

This means that there seems to be no conflict between it being a command handler, and using mqtt.publish. The thing you should at least make sure to avoid in a command handler is to execute other commands. You can defer code out of the command handler like this:
tasmota.defer(/->mqtt.publish(topic , json.dump(payloadWM)))
Then, it will be executed right after return from the command handler.

BTW. To have a "good" command handler, you should have it provide a response, using a call like tasmota.resp_cmnd_done() (or one of the similar calls with details).
https://tasmota.github.io/docs/Berry/#functions-to-create-custom-tasmota-command

[git5any]

Once again, thank you very much for the answer. I already read about the tasmota.resp_cmnd_done(). But the defer sounds really interesting, I'll give it a try tomorrow and report.

To me, it is not really an "operational" example when I can't run it without having a lot of other stuff around it, like getting sensor payloads.

It is always difficult to give a working example by removing a lot of stuff that makes the example work. At some point it is hard to distinguish what causes the problem.

In my case I use scripting, berry, haspmota which all interfer. And it is working, except the publish. Lets see tomorrow......

[git5any]

Good morning,

its working now. I have to use tasmota.set_timer(0, /->mqtt.publish(topic , json.dump(payloadWM))) instead of the defer because my binary is version 14.4.1.3 and I found out that the tasmota.defer exists since 14.5. No problem in this case.
(The reason for the "old" version is that I had compile-errors with newer versions. Maybe here is a solution for that: https://github.com/arendst/Tasmota/discussions/23402. I have to try this....)

Another thing (if i might ask) is the topic variable: at the beginning of my code-snippet I use
var topic = string.replace(string.replace( tasmota.cmd('FullTopic',true)['FullTopic'], '%topic%', tasmota.cmd('Topic',true)['Topic']), '%prefix%', tasmota.cmd('Prefix',true)['Prefix3']) + 'SENSOR'
(later in the code I override it with the right value, that was for testing the publish-thing)
In the mqtt-configuration panel is the default topic DVES_%06X which I thought would be translated to DVES_6A1234 like in the tele-messages. How can this be done?

Once more, thank you very much for your time and detailed explanations.

[sfromis]

I'd suggest against using those DVES names in topics, as the MQTT Client value is only meant as identification against the broker as such, while what you have in Topic is meant to be used in, well, MQTT topics. If you made the unusual choice of replacing the Topic by the DVES name, that's up to you to manage.

While the default for the Topic is tasmota_%06X, those defaults are not meant as "this is what you should use", but mainly for the purpose of not having overlapping names if connecting multiple devices without device-specific configurations. The %06X expansions are only there for this default naming scheme, and is not a feature with any wider support in Tasmota. I'm always using my own naming scheme for topics, allowing for things like hardware replacement without this affecting what topics may be used elsewhere.

Basically, I see what you can create with the long topic-constructing line as "the right value", but you can of course change parts as you see fit, like replacing the 'SENSOR' part with what you prefer, and tasmota.cmd('Prefix',true)['Prefix3']) in case you prefer something different than tele from the standard set of prefixes. Or roll your own.

Or shorter, whatever rocks your boat ... but dont expect %06X to work anywhere but for the initial default config.

Still, if you actually want the MQTT client value to be used for the non-intended purposes of being in topics, in Berry you can pick lots of values in the same way as you already have in the topic build, like this:
tasmota.cmd('Status 6')['StatusMQT']['MqttClient']