Domoticz

@hoeby

You wrote:

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.

The "Gate" is not complex, but the "trick" starts earlier.

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.

Is there a good way to define the trigger milliseconds. or is it just try to don't have a loop?

No, I don't think a reliable calculation method exists.
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,

Thanks for the nice explanation.

Untill now i only have 1 shelly shutter device.
It first need to prove itself of it could work right with domoticz. Otherwise i would go for z-wave devices, but i don't prefer them.

I will first test this one. And when 100% satisfied, then i order the other 3.

Is of best to have 1 flow with all devices in it?
I could make 4 flows, for each device one.

When making one flow for all devices. I don't know how to get it working. And prevent that device 1 blocks device 2, because the gate is closed and blocking messages

@hoeby

As soon as you have decided to purchase the other 3 devices, it is quite easy to implement these.
Put a request in this thread.

The chance that you move a slider of one shutter in Domoticz exactly in the same 250 ms that you move another shutter in Shelly is not very big.
I don't think it will happen in practice, but even that, we can avoid.

Regards

FireWizard wrote: ↑Tuesday 02 June 2020 21:48 The chance that you move a slider of one shutter in Domoticz exactly in the same 250 ms that you move another shutter in Shelly is not very big.
I don't think it will happen in practice, but even that, we can avoid.

I think it could be happening in practice.

How is the practice situation of 1 room:
- 2 shutters with each there own shelly tasmota shutter.
- 1 zigbee remote control.

When pushing up on the zigbee remote control, than domoticz needs to trigger both shutters.
Don't know the executing time that domoticz needs for this. But it could be a possibility

Another possibility. The smokedetectors will automatic move all 4 shutters up, when smoke is detected.
This means, 4 commands in short time.

@hoeby

How is the practice situation of 1 room:
- 2 shutters with each there own shelly tasmota shutter.
- 1 zigbee remote control.

When pushing up on the zigbee remote control, than domoticz needs to trigger both shutters.
Don't know the executing time that domoticz needs for this. But it could be a possibility

In this case the message comes from Domoticz and goes to the Shelly. The Gate is open
The Gate is only closed a very short time (250 ms) if Node Red receives a message from Shelly.

Another possibility. The smoke detectors will automatic move all 4 shutters up, when smoke is detected.
This means, 4 commands in short time.

Good solution, but here again, the message comes from Domoticz and not from the Shelly.

But nevertheless, we can avoid it.

Regards

Your right, they come from domoticz.
But when received at shelly and it starts to work, it gives an update back. This update will close the gate.

But as mentioned, i don't know the executing time die 4 messages from domoticz. Maybe all 4 messages are already tru the gate, and there is no block at the gate

Hello,

@hoeby

But when received at shelly and it starts to work, it gives an update back. This update will close the gate.

Does it? In this case it is not only Domoticz, that gives a "loop-back" (in the old version) but also the Shelly.
What is the message content of that "update"? Do we need to block that, as well?

But if it works now, we can wait with a modification, until you have 4 Shellies.

Regards

Hello Paul,

@hoeby

Are you aware that special Node Red nodes exist for Shelly devices?

If you want to look into these, install them through the palette and try them.
Search for: node-red-contrib-shelly

See: https://flows.nodered.org/node/node-red-contrib-shelly

Could be interesting, if you want to implement more Shellies.

Regards

I didn't know about the shelly devices for node-red.

The integration went to a stop early this month. This because of setting up a fresh install with buster and the latest stable 2020.2
Everything is installed and yesterday i stopped the 4.9717 server and went to the 2020.2 server. The 4.9717 is backup, just in case.
There are minor settings which needs to be done, but nothing serious.

The 2020.2 gives the loop option in the mqtt domiticz cliënt.
Also will look to the shelly devices for node red. Maybe the also have the loop option in them.

I looked at the Shell devices in nodered.
It looked like this is made for the standard shelly firmware, not the tasmota firmware.

Hi,

@hoeby

You can have a look at this one:

https://flows.nodered.org/node/node-red-contrib-tasmota

Regards

FireWizard wrote: ↑Tuesday 16 June 2020 21:38 Hi,

@hoeby

You can have a look at this one:

https://flows.nodered.org/node/node-red-contrib-tasmota

Regards

I looked at it, but never used it.
When installing i get this error Your flow works that good, that i now have 4 flashed shelly devices
Controlling it works like it should

I just copy/paste the flow and modified the idx/topic and it works

Hello @hoeby

I looked at it, but never used it.
When installing i get this error

I Installed it on Node Red version 1.1.0 and it installed error free.

Your flow works that good, that i now have 4 flashed shelly devices
Controlling it works like it should

I just copy/paste the flow and modified the idx/topic and it works

As it works to your satisfaction, there should be no reason to experiment with another solution.
But that the installation failed, might be caused by something, that is specific in your case, as in my case it installed without any problem.

Best regards.

I am on version 1.1.3
Running on a Pi4, but on the nodered page that shoudn't be a problem

Hi,

@hoeby,

I upgraded to version 1.1.3, but it is still OK with the Tasmota nodes.
I use it on a Pi1 with nodeJS version 11.15, as a Pi 1 is ARM v6 architecture, so I cannot update nodeJS > 11.15
So why the error during installation, I cannot answer.

Regards

FireWizard wrote: ↑Thursday 20 August 2020 18:29 I upgraded to version 1.1.3, but it is still OK with the Tasmota nodes.
I use it on a Pi1 with nodeJS version 11.15, as a Pi 1 is ARM v6 architecture, so I can update nodeJS > 11.15
So why the error during installation, I cannot answer.

Don't ask why, but it is installed.
After diner i tried it again, now it is installed.
Have the extra blocks. Will have a look what i can do with them, in combination with shelly 2.5

@hoeby,

Interesting what that nodes can do extra or simpler.

Correction
I said I can update, I mean I cannot update NodeJS > 11.15

Regards