Hue pro delay and double script unexpected behavior question

[zicht]

Hi,

I noticed something strange.

Philips hue and also the pro bridge have a delay for actions on motion sensors.
This is expected as there is a long flow path with a lot of things :
motion sensor --> Bridge --> domoticz --> event read and action don in the script --> domoticz --> Hue bridge --> lamp bulb

every step has a delay and that is expected.
Now the strange part :
I accidently had two exactly the same scripts running during debuging an error i introduces.
What i noticed was that when running the two device scripts in parralell the delay feels smaller.
How is that possible ? I would expect 2 scripts = more runtime = more delay ?
I suppose it has to do with the way the lua VM works in domoticz, but i am curious about this ...

Is there anyone that has a good explanation for this ? (As in all theoritcal things i could think of the delay should be the same or larger.)

Thanks !

[waltervl]

Perhaps give this test a try with dzvents as it could have a better device change trigger mechanism. You have to go through old dzvents discussions why they started with dzvents on lua to find out. I believe what you experience was one of the reasons.

Quote from the dzvents wiki

And on top of that, script performance has increased a lot if you have many scripts because Domoticz will fetch all device information only once for all your device scripts and timer scripts.

[Deanm]

I can confirm since the Hue hub was updated few weeks ago my motion sensors don’t seem to respond like they used to. Sometimes there is a delay of about 5 seconds, sometimes I would say they don’t respond at all.

They seem to be fine in the Hue app.

As a work around I removed them from the Hue Hub and added them to my Zigbee2Mqtt network and they work perfectly now. Would even go as far as saying they are even more responsive.

Deanm

[zicht]

The problem is that hue changed the way the motion sensors are managed in the hue firmware. There seems to be a different "event path"
There is much overhead that has to be handled and hue bridge seems now to bundle/cache events shortly. Found this by empiric tests outside domoticz. The motion sends motion, lux, temp and some other fields .

On the roundtrip [[zigbee mesh -> hue pro -> domoticz -> hue pro -> zigbee mesh]] this creates a delay.
Further i discovered my mesh is heavy populated, the hue pro can handle this but the mesh can get very busy and the bulbs are bad/slow/nasty routers. This all cumulates towards a delay that is noticable. So even if the bridge can handle it as promoted, the mesh can get into a traffic jam.

One of the easiest test i did to confirm my suspicion was using an rfx motion sensor (so i have only the outgoing route to the bulb).
That has almost no noticable delay. So the single incomming route to domoticz seems fine, the single outgoing route seems fine.
But as soon as you combine shortly incomming + outgoing, domoticz reacts instantly but the bridge seems to insert a delay.
In my tests this seems not to be the case for the doorswitch.

I also noticed that a bulb behaves differenly on a warm command vs an cold command --> meaning if you just switched to lets say 10% (cold) and shortly after that to 80% (warm) the reactions from the bridge is slower than when doing an instant (cold) to 80%.
Based on all my test there seems to be some "loadbalancing" going on inside the bridge for the zigbee network part

Still testing (when i have time) to see how to come around this.
One thing i am now totaly convinced of : its not domoticz, its hue thats changed, its a small change but noticable.