MQTT Broker PlugIn - Option "Prevent Loop" - No echoing back of MQTT messages with set "False" / "Nein" Topic is solved

[007Steve]

Hi together,

since the last beta update the MQTT Broker Plugin Option "Prevent Loop" does not work properly any more ...

After installing the latest update ... see below, there is no more echoing back of MQTT messages, that come in to "domoticz/in" and have to be echoed back out to "domoticz/out".

My current setting of the "Prevent Loop" Option is set to "Nein" / "False", which echoed the MQTT messages before the update. There was no change in this setting during or after the update.

In my current environment working togehter with NodeRed, it es essential to get the messages echoed ... currently, many flows relaying on that needed function, does not work any more ...

Can you please check this and provide a solution as soon as possible ... looking forward to a reply on that.

Thanks ...

BR, Steve

Configuration:
Version: 2025.1 (build 16739)
Build Hash: c35b41d2d
Compile Date: 2025-07-07 13:32:28
dzVents Version: 3.1.8
Python Version: 3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0]
Domoticz is running in a docker environment on a RPI 5.
MQTT Broker is also setup in a separate docker envirenment.

[gizmocuz]

There have been no changes to the MQTT hardware for ages! (Except today, but this is not related to the prevent_loop function)
I guess something else has changed on your side.
Probably some device/service/plugin is changed?

[007Steve]

Sorry, but there is really no echoing back of the MQTT messages ... and there was no change elsewhere else ...

Probaboy, there is the value itself not in englisch any more = "false", but now in german ="nein" ... can this cause the problem ...

Prevent_Loop_Setting.jpg (14.24 KiB) Viewed 428 times

[jvdz]

Just tested this in a test docker instance and it's working fine 2025.1.
What is the exact Content of the Msg you send to domoticz/in?

[007Steve]

The message is initiated by a RPIZ PIR embedded in a nodered flow, that triggers the following simple payload to "domoticz/in", which is a domoticz virtual switch

{ "idx" : 107, "nvalue" : 1 }

In domoticz you can see the virtual switch reacting on that message value change.

In nodered there is a flow, that listens to the "domoticz/out" and where the debug node shows no echoed message ...

Just checking the mqtt broker settings, but find no change .. in what was set up before the domoticz upgrade ...

BR, Steve

[jvdz]

Just tested your scenario with a dummy switch in my test environment and I get a domoticz/out message for each message I publish on domoticz/in for the switch with loop protection switched off.
I used your simply JSON content for the test.

[FireWizard]

Hi @007Steve

I tested with your command:

{ "idx" : 107, "nvalue" : 1 }

And I have to confirm @jvdz observations.

If I configure "Prevent loop", being false, I always get the data of the virtual switch published at domoticz/out.

However, see the wiki: https://wiki.domoticz.com/MQTT#Update_S ... t_Setpoint

You will find:

Update Sensors/Thermostat Setpoint

Note: If "command" is not set, it defaults to "udevice". udevice only updates the device in domoticz and will not trigger action scripts. So normally do not use udevice for switches, scenes and groups, only for sensors.

The two following messages are equivalent:

{ "command": "udevice", "idx" : 7, "nvalue" : 0, "svalue" : "90;2975.00" }
{ "idx" : 7, "nvalue" : 0, "svalue" : "90;2975.00" }

So you are using a shortened version of { "command": "udevice", "idx" : 107, "nvalue" : 1, }
That is possible, as, if "command": "udevice" has been omitted, it defaults to "command": "udevice"

Some line further, I read:

To update in Domoticz only and to prevent event triggers (like MQTT domoticz/out messages) use additional "parse": false

{ "command": "udevice", "idx" : 7, "nvalue" : 0, "svalue" : "90;2975.00", "parse": false }

However, I have never used the "parse": false element, I noticed that either false, true or omitted has no impact on the MQTT output.
The MQTT output is only affected by the MQTT Loop setting (yes|no) and not by "parse" Is this a bug or an error in the Wiki?

And I also want to point you in the Wiki to:

Sending a Switch Command

Note: Do not use "command": "udevice" for switching. udevice only updates the device in domoticz and will not trigger action scripts. So normally do not use udevice for switches, scenes and groups, only for sensors.

{"command": "switchlight", "idx": 2450, "switchcmd": "On" }

I suggest, you test the following command¨:

Code: Select all

{"command": "switchlight", "idx": 107, "switchcmd": "On" }

instead of:

Code: Select all

{ "idx" : 107, "nvalue" : 1 }

Regards

[007Steve]

Thanks to all of you ... for your investigations ...

Checking it and come back ...

[waltervl]

@FireWizard,
Regarding the parse option in the payload, it could also be as the silent option in dzvents that it will not trigger additional scripts or events. But I am not sure as I do not use MQTT. Perhaps the option has been deleted from the source code long time ago....

[waltervl]

Also look at github issue https://github.com/domoticz/domoticz/issues/3863

This resulted into the mqtt prevent loop option but no clear status on the parse or parsetrigger payload options unfortunately. It seems to be in the code but not really functional.

[007Steve]

Hello together,

after testing your proposal message ...

{ "command": "udevice", "idx" : 107, "nvalue" : 1, }

instead of my simple one ...

{ "idx" : 107, "nvalue" : 1 }

there was no difference in my domoticz setup ... still no echoing back of MQTT messages to domoticz/out ... strange.

After this, I did basic work on the docker setup, saved the current domoticz container data, setup a new domoticz container with the same release state, Version: 2025.1 (build 16739) ...

=> and now, MQTT messages are echoed back to domoticz/out ... ?!

You don't happen to know what could be causing this?

The problem has been solved for now, but for a technician, this is rather unsatisfactory in the sense that the solution is unclear...

BR, Steve

[akamming]

Hello together,

after testing your proposal message ...

{ "command": "udevice", "idx" : 107, "nvalue" : 1, }

instead of my simple one ...

{ "idx" : 107, "nvalue" : 1 }

there was no difference in my domoticz setup ... still no echoing back of MQTT messages to domoticz/out ... strange.

After this, I did basic work on the docker setup, saved the current domoticz container data, setup a new domoticz container with the same release state, Version: 2025.1 (build 16739) ...

=> and now, MQTT messages are echoed back to domoticz/out ... ?!

You don't happen to know what could be causing this?

The problem has been solved for now, but for a technician, this is rather unsatisfactory in the sense that the solution is unclear...

BR, Steve

Is 107 a used device? Latest bèta only sends used devices to domoticz out topic

[007Steve]

Yes, id 107 is a virtual switch, that is in use …

Your information is new and very valuable in the current chat of my subject and good to know for us all … and me … to avoid futher investigations on probably similar MQTT messaging …

I had such a case lately before the new beta, searching for the „error“, and it was solved after switch the state of the device into a used one …
So, I think, this was the case already in the last beta ?!

Is there a description of all this knowledge about MQTT messaging, that covers all ?

And for my original problem, it there something known about docker container setup influences on domoticz messaging?

[gizmocuz]

https://wiki.domoticz.com/MQTT

And no, there should be no difference between native and a docker installation.

Best to run everything in docker containers for easy installation/migration

[007Steve]

Hello together,

then thanks to all of you for your quick reactinos, feedback and support ...

So we could close the post for now ... ...