MQTT Mapper conflicting with Tasmota switches

[eddieb]

Hi,
I have a couple of Tasmota switches that turn my lights on/off in domoticz.
All worked well UNTIL I enabled the MQTT Mapper plugin to read the data of my Marstek Battery ...
It seem that the domoticz/in and domoticz/out commands somehow conflict with MQTT Mapper ...
The switches don't respond the commands from domoticz, or with some huge delay, sometimes HOURS
Did anyone else see this kind of issues ?

where should I start fixing this ?

[waltervl]

Seems some issue with the connection to your MQTT broker.
How do you switch your tasmota lights with mqtt?
Do you have a topic of Domoticz in or out in the MQTT mapper config?

[eddieb]

Seems some issue with the connection to your MQTT broker.
How do you switch your tasmota lights with mqtt?

Broker is on localhost ...
yes, the default "tasmota" setup where in the device the idx of the domoticz is defined.
so publishing to domoticz/out with a payload for a tasmota devices causes the device to switch.
from MQTT Explorer

Code: Select all

2025-08-09 10:04:53
{
	"Battery" : 255,
	"LastUpdate" : "2025-08-09 10:01:21",
	"RSSI" : 12,
	"description" : "",
	"dtype" : "Light/Switch",
	"hwid" : "3",
	"id" : "0001411B",
	"idx" : 203,
	"name" : "R01S2 licht woonkamer voor",
	"nvalue" : 0,
	"org_hwid" : "3",
	"stype" : "Switch",
	"svalue1" : "0",
	"switchType" : "On/Off",
	"unit" : 1
}

As you can see, there is a huge delay allready from +3 minutes (10min after rebooting the rpi) and that delay grows into hours during the day.
So YES, domoticz pushes a command to MQTT for this tasmota device.
IF I disable MQTT Mapper that command is pushed within a second ...

Do you have a topic of Domoticz in or out in the MQTT mapper config?

NO, there are no domoticz/in or out definitions in the MQTT mapper config just the in other topic discussed Marstek.json

Code: Select all

 cat Marstek.json
{
	"MPWR": {
		"topic": "Marstek",
                "key":"MPWR",
		"type": "243", "subtype": "29", "switchtype": "0",
		"mapping": {"item": "params/r_data/2/value;~0", "multiplier": -1, "digits": 1}
	},
	"MSOC": {
		"topic": "Marstek",
		"key":"MSOC",
		"type": "243", "subtype": "6", "switchtype": "0",
		"mapping": {"item": "params/r_data/1/value", "multiplier": 1, "digits": 1}
	},
	"MTCE": {
		"topic": "Marstek",
		"key":"MTCE",
		"type": "113", "subtype": "0", "switchtype": "3",
		"mapping": {"item": "params/r_data/3/value", "multiplier": 0.01, "digits": 2}
	},
	"MTDE": {
		"topic": "Marstek",
		"key":"MTDE",
		"type": "113", "subtype": "0", "switchtype": "3",
		"mapping": {"item": "params/r_data/4/value", "multiplier": 0.01, "digits": 2}
	},
	"MIT": {
		"topic": "Marstek",
		"key":"MIT",
		"type": "80", "subtype": "5", "switchtype": "0",
		"mapping": {"item": "params/r_data/5/value", "multiplier": 0.1, "digits": 1}
	},
	"Battery": {
		"topic": "Marstek",
		"key":"Battery",
		"type": "250", "subtype": "1", "switchtype": "0",
		"mapping": {"item" : "params/r_data/3/value;~0;params/r_data/4/value;~0;~0;~0", "multiplier": 10, "digits": 2}
	}
}

[jvdz]

Check with mqtt Explorer whats coming in & out as it might be you created a floodding of messages with retained looping messages maybe?

[RNEE]

Did you already set the sending time from the DR134 to a slower rate ?
I have 1 second, but with a slower Mqtt broker choose a longer time?

[eddieb]

A couple of hours ago I set the DR134 to 5 sec .
no improvement ...

[RNEE]

And what @jvdz mentioned?

Maybe port 1883 conflict?
How long is keep-alive on mqttmapper and your tasmota?

Ai answer :
Port 1883, the default port for unencrypted MQTT communication, remains occupied for as long as the MQTT client and server maintain an active connection. The duration of this connection, and therefore the occupation of the port, depends on the Keep Alive interval set by the client and the server's configuration for session expiry.
Factors influencing the duration of port 1883 occupation:
Keep Alive Interval:
Clients send MQTT control packets (like PINGREQ) within a specified interval (Keep Alive) to indicate they are still connected. If no packets are received within 1.5 times the Keep Alive interval, the broker might assume the client is disconnected.
Session Expiry:
MQTT allows for persistent sessions. When a client connects, it can request a session expiry interval. If the client disconnects, the session can persist for the specified duration or indefinitely, depending on the broker's configuration.
Server-side Configuration:
The broker can also enforce a maximum session expiry interval. For example, in RabbitMQ, this parameter is configurable, and setting it to 0 will force all sessions to end as soon as the network connection ends.

[eddieb]

Ok, I hope I solved this issue ...

it is in MQTT Client Gateway with LAN interface (which handles domoticz/out)
before using the Marstek thru MQTT Mapper I never had any (noticable) issues.

domoticz/out was indeed flooded by outgoing messages.

Before I did not use the "Setup" of MQTT Client Gateway with LAN interface so by default all is sent to domoticz/out
Now I limited it by selecting only the devices that actually NEED domoticz/out (and that excludes all MQTTAD and MQTT mapper devices)

I hope this helps others with this kind of issues ...

question : the logging of MQTT Client Gateway with LAN interface does not provide much help, I could not find any logging of domoticz/out. Is it possible to improve this ?

[gizmocuz]

You can use MQTT Explorer to see the MQTT traffic.
Aldo with debug info it logs more in Domoticz, it is not desired to log that much traffic

[eddieb]

besides in MQTT explorer I could nog find any place to see domoticz/out

the problem is that MQTT Client Gateway with LAN interface is flooded BEFORE the msg was send to domoticz/out ...

it is not visible in MQTT exporer, it just gets there with the delay

No warning, nothing, just a huge delay in processing ...

domoticz queues this msg for MQTT Client Gateway with LAN interface and there somewhere is the delay ...

[jvdz]

Not really, domoticz simply reads all incoming messages from mosquito, like MQTT Explorer does, so you will see exactly what needs to be read by domoticz when you open mosquito with MQTT Explorer!
The reason the system slows down is that it needs to process the events triggered by the read messages and when the messages are added faster to mosquito than domoticz can process you will see the slowdown.