You wrote:
The "Gate" is not complex, but the "trick" starts earlier.But i don't exactly understand the working of the gate.
The "set control" makes the commands for the gate. And the trigger is to keep the command high, otherwise it switches back to open.
As soon as data from the Shelly arrives the data is checked for specific wordings in the payload. Based on this check the different messages are routed to different outputs of the switch node. In this case, we are only interested in data with the topic "stat/DZ_SH_A/RESULT" AND with a payload of "{"Shutter1":{"Position":19,"Direction":1,"Target":100}}"
As we want to use the "Position" to control Domoticz, "Shutter1" is used as selector.
Here is directly something to keep in mind.
As soon as you want to use your 4 shutters you can collect these to use a wild card, "stat/+/RESULT" in the MQTT input node.
That means that you will have 4 possibilities, all going to the 1st output of the switch node. Not a problem, because we can handle that in the Function node, but all messages will start a trigger of the "Change node".
So, if one of the other messages is arriving, the gate is blocked, so we have to take care that it only blocks its own loop back.
This message from the Switch node triggers a flow (In principal the same as you use an Inject node). In the change node I set 2 variables:
1. msg.topic to "control"
2. msg payload to "close"
The gate works as follows:
In "open" condition all incoming messages are sent to the output, unless its msg.topic equals to "control". This message is not send to the output, but controls the gate.
In "close" condition all incoming messages are discarded.
If the incoming message has a topic "control", the payload sets the "Gate" in a specific condition. This can be "Open", "Close", "Toggle" or "Default".
In this case we don't use "Toggle". The "Default" value can be "Open"or "Closed" . We use "Open", so normally, when you start, the "Gate" is open.
However if a message arrives, that the Gate should be closed, the trigger node sends this message to the "Gate"
So when the message arrives it just send the complete message object to the "Gate" node, which consists of msg.topic:control and msg.payload:close.
The "Gate" closes and all messages are discarded. And then the trigger waits for a certain time (in your case 250 ms) and then sends a new payload of "open" and the Gate opens again. I have ticked the box " extend delay if new message arrives", just to be sure, that, if in those time frame another message comes, the time is extended.
No, I don't think a reliable calculation method exists.Is there a good way to define the trigger milliseconds. or is it just try to don't have a loop?
I picked up the trigger as early as possible in the chain, just after the switch node.
The message has to pass several other nodes before arriving in Domoticz. On its turn Domoticz has to trigger to loop back to MQTT out.
That you need 250 ms, while I was error free with 200ms, proves that e.g. the number of processes running on your Raspberry Pi and in Domoticz is maybe more important than the speed of the Pi.
The "Gate" has been placed at the end of the stream but can be places anywhere in the stream.
In theory, if you place it, just after the "Domoticz Out" node the time should be shorter, because the message arrives earlier.
So it is just try and error, and take a little margin.
The lower the time value, the earlier the "Gate" opens again.
If you start to implement the next 3 shutters give a message if you need support to modify some nodes.
Best regards,