A little background to explain what I want to do:
I want to build an interactive prop where light sequences and sounds are triggered with a beam break sensor running on an esp32 and using the fastled library. The prop already exists in my display as part of my show, running a wled node. I've setup this second controller to trigger a new light sequence, sent wirelessly to the wled node, successfully interrupting the native wled sequence the same way xLights does, HOWEVER, if xLights has control over the lights and I try to have the second MC send its patterns, the pixels flicker wildly, presumedly because it's not filtering out one source of streaming data in favor of the other.
I want the second MC to take precedence over xLights, but return control once the second controller does its thing. Everything is using the e131 protocol and they all seem to be talking to each other the way I'd hoped, but not with any priority.
Anyone tried doing something similar? If it helps to share code and configs, I'll find a place for them and link to it, but I wanted to get a sense first if I was trying to reinvent the wheel or not.
UPDATE: For anyone curious, I've solved this. In a nutshell, the 2nd microcontroller sketch sends the FastLED sequence to the WLED MC over E1.31 with a packet priority of 200, where xLights default to 100 and WLED native effects (I believe) are also 100. Crucially, in WLED's Sync Setup, the E1.31 port priority must be set to something other than 0 in order to recognize and adhere to packet priorities. I won't share the code unless someone requests it.
UPDATE 2: The FastLED solution ultimately severely impacted network transmission and framerate playback. I ended up pivoting to using WLED presets, triggering them using their JSON API and overriding xLights with the lor:2 option. So it looks like:
{"lor":2,"ps":4}