Endless loop with external broker (client mode)

[WolfspiritM]

Describe the bug
Hi,

I currently for some reason end up in an endless loop with this adapter.

I have an external broker and try to listen to changes on there to generate iobroker objects in mqtt.0. ("patterns": "hpm/#, senec/#")
I've also set publish to "hm-rpc.0.*" to also publish homematic state to mqtt.

For some reason sometimes the adapter decides to not only publish state from "hm-rpc.0" but also from "mqtt.0" which then ends up in an infinite loop. This can even be forced by setting it to not only publish changes but instead publish always.
I think there are two issues here and I think I found at least one of them here:

ioBroker.mqtt/main.js

Lines 46 to 49 in bf6976c

	if (this.config.type === 'client') {
	await this.subscribeForeignStatesAsync(`${this.namespace}.*`);
	await this.readStatesForPattern(`${this.namespace}.*`);
	}

If the adapter is set to client then it subscribes to changes for mqtt.0.. It is also set to subscribe to topic hpm/# so if someone else publishes a message e.g. hpm/readings/test, then a state is created in mqtt.0.readings.test resulting in a state change for mqtt.0. and the adapter then publishes this state again. The state has the native property "topic" set to "hpm/readings/test" which means iobroker will publish to the same topic again, then receive that change from the broker, change the local state and publish that change to the broker again....and again...and again.

I've now removed the above code piece completely and the loop is gone. I can't set states this way anymore but I don't need that.

The second issue I noticed is that it even happens when "publish only changes" is checked but it only happens irregularily. Either there is a problem in the change detection here:

ioBroker.mqtt/main.js

Line 241 in bf6976c

if (!this.config.onchange || oldVal !== state.val || oldAck !== state.ack || state.binary) {

...or it happens when two messages for the same state is in the queue. That would mean it will flip flop from one state to the other.

Maybe there is also some issue with setting the new state to acknowledge which prevents change detection.

To Reproduce
Steps to reproduce the behavior:

1. Enable mqtt client. Don't include "mqtt.0.*" into publish states. Disable "only on change".
2. subscribe to a topic
3. Loop

Expected behavior
No sudden loop of messages

Versions:

• Adapter version: 5.1.0
• JS-Controller version: 5.0.17
• Node version: v18.19.0
• Operating system: linux/docker

[schnti]

I have the same problems. After a certain time, the broker is flooded with the same messages over and over again.

Is there already a solution to this?

[Hencor93]

Same problem here.
The mqtt client publishing the topic mqtt.0.*, even if it's not enabled in the settings.
Which then of course means creating a loop.
V5.2.0

[SpikeNbg]

I tried really a lot of different settings. And i have another test instance of ioBroker running. Same behaviour there as wll.

After a (short) while it begins with the loops and my ioBroker as well as my MQTT Broker use insane cpu and can't be used any more.

Therefore i sadly stopped using the adapter completely. Even other versions didn't help.

[Apollon77]

Please post details of your configuration and debug logs please

[Hencor93]

Plattform: docker (official image - v9.1.1) on Raspberry Pi 4
Node.js: v18.19.0
NPM: 10.2.3

MQTT Broker/Client: 5.2.0

Log:
MQTT Log.txt

Settings:

1. Very interesting is, that the adapter log shows that the adapter publishing states (e.g. mqtt.0.homeasstistant.# or mqtt.0.domoticz.out.Haus) that are not mentioned in any setting. These objects are also not showing up in the iobroker objects tab.
   Further the topic mqtt.0.domoticz.out.Haus is not showing up in MQTT explorer. So it seems that the adapter publishing on domoticz.out.Haus (without mqtt.0.) instead.

2. At around 15:00:23:553 the log shows that after each stateChange there is a send2Server and a send to server, with mqtt.0. or the prefix iobtest_ in front. But also here it seems that the adapter publishing without these parts in front.

Hopefully this helps. If there are more information that I can provide please let me know.

[WolfspiritM]

I moved away from the internal mqtt broker cause of this error and am using emqx now. So not sure if I remember correctly but here is what I think what happens:

For me it looked like there is a general problem of how this adapter is supposed to work. It seems to have two features that work against each other.

• Everything published on a topic is saved in mqtt.0.*
• Every change to mqtt.0.* is published per default cause it contains an attribute (forgot which one it was, probably the topic)

That means it publishes it's own messages again. This shouldn't be a problem in general as it's not publishing the same message if it didn't change, which is why it works at first, but if there happens to be quick changes after each other it flip flops back and forth as it receives both state changes.

[schnti]

Is there any news on this, I have the problem every few days and then have to restart the adapter.

[schnti]

Unfortunately, the problem still exists and makes it impossible to use this adapter!