MessageSink and parallel execution

Hi Paresy,

Recently I ran into a performance issue related to MessageSink.

I have a lighting controller that consists of the following module instances:

  • Lighting Control: contains on/off state, global intensity level and some other settings of a lighting zone. Uses MessageSink to respond to a short press of a button to toggle the on/off state and responds to a long button press to increase or decrease the global intensity level.
    – Luminaire: defines and controls a lighting fixture. Uses MessageSink to respond to a change of lighting state.
    – Lighting Scene: defines a scene name
    ---- Luminaire Scene: defines on/off state, color or intensity of a luminaire in a specific scene.

This is what the object tree looks like:

A Lighting Control instance usually contains multiple luminaires. I primarily use ArtNet/DMX controlled lights but I also have some Z-Wave devices. My Z-Wave network has a few nodes with low signal quality at the edges of the mesh network. Sometimes these devices do not respond at all, in other cases it takes a few seconds for a dimmer to respond to a command.

By using independent instances to control luminaires I was hoping to create a lighting control system that would degrade gracefully in case of a communication failure. Unfortunately this is not how it works in practice.

If a lighting zone uses ArtNet/DMX lighting, the response is instant. If a lighting zone contains a Z-Wave device that is difficult to reach, the response time is several seconds. This is also the case for the DMX lights. I assume this is because MessageSink calls to multiple module instances that are registered to a specific message are executed sequentially instead of in parallel.

In my opinion this case is well suited for multi-threaded execution. Parallel execution should improve response times, avoid blocking I/O and enable more effective use of resources.

I haven’t tried IPS_RunScriptEx yet to control the Luminaire instance from the Lighting Control instance. In this case this should work well because there is a direct relation between a Lighting Control instance and underlying Luminaire instances. In other situations there is no such relation, when instances of unrelated modules act on a change of a variable. So I think it is still a good idea to enable parallel execution of MessageSink calls.


you need to make sure that any long-running execution is never done inside the MessageSink. This will totally block your IP-Symcon in the background. As you suggested, you might want to decouple this by using a timer or a call to any of the IPS_RunScript* functions. I already thought about making MessageSink run in parallel but this has so many implications in the background that i refrained from doing it. You can enable MessageQueueWatch in the special options to see which modules are blocking the „MessageSink“ too long.


Ok thanks for the info. I wasn’t aware of MessageSink limitations.

I’m now using RunScriptTextEx and it works wonderfully well. Dimming up/down via push buttons also works well know.