Since I had asked about this on different forums before and no one particularly had a solution, I thought I'd document this.
The problem:
For Halloween, I have some lightning effects that I coded in Arduino that are highly randomized. They don't fit nicely into Xlights, and they're different every time you play it. However, they are supposed to play at very specific times within the show. I could run them asynchronously, but I couldn't figure out how to integrate them into sequences. This solution can apply to any effect that doesn't quite fit into Xlights.
Solution:
There is no rule which says that E1.31 can only be used to run lights. Or motors, or on/off switches, or smoke.... You can integrate ESP32's into your show and code them to listen to E1.31--at which point, you can wire up the ESP's to do anything. There are multiple example sketches out there which demonstrate how to do this. Often these examples will marry together E1.31 with FastLED or WLED, but you can just delete the WLED part and keep only the E1.31. The incoming network packets will consist of short integer values on a bunch of channel numbers. Every ESP32 listening in will hear all these values on the network. From there, instead of thinking of these channels and values as lights, think of them as commands (ultimately, the network packets are nothing more than just 1's and 0's, which you can interpret any way you want). Value 127 on channel 7 is a command. 128 is another. You define what that command is. In your sketch, you basically have a gigantic switch() statement which dispatches off these various integer values to various callback functions which you define. The value can also serve as a parameter you can pass on to a function (e.g. in my case, to control the speed and intensity of the lightning, and to steer its randomness).
To integrate into Xights, Vixen...whatever...place down a DMX effect, with the appropriate channel number and value. Configure your controller/channel such that the DMX effect gets broadcast over E1.31 on your show network. Probably, you should give all custom effects of this sort their own universe (mostly because there is no reason not to). The ESP32's, of course, are listening in on the show network, on that universe.
You need to "debounce" your callback functions, since the DMX effect will repeatedly broadcast the same value over and over, for the duration of the effect. In essence, just ignore DMX traffic for that channel until that command you're already running completes, and until the DMX value at least changes to something else first. This repeat-broadcast feature of DMX is actually nice on unreliable wireless networks, since it makes them more reliable (albeit the timing might be slightly off if it takes 5 tries to finally receive the command).
Normally, this would be an application more suited to MQTT than E1.31, except that we are trying to integrate into Xlights (or Vixen, et. al.). Xlights supports outputting a "prop" to E1.31 on the network.
Other possibilities using this method that I'm currently testing:
- attach color macros to certain DMX values, so the effect just plays locally and reduces your network bandwidth. And to function more robustly in an unreliable wireless network, since only the start signal alone relies on the network.
- randomize other effects so they are different every playthrough
- respond to sensors or buttons over a certain time window, within a song. You can tie INPUTS to Xlights effects this way.
- play back effects differently based on sensor values.
- packing 8 non-dimmable elements into a single channel (such as mechanical relays)
- don't turn on certain GPIO's at all if that relay channel is known to have GFCI problems, and the moisture sensor is detecting moisture
- Nothing. Just echo out the network packets to your Serial Monitor and watch what's going on. Debug.
In case I made all this sound harder than it really is, I'll put it another way: in Xlights, you place down an effect which says, "Broadcast value 127 on channel 7 at this time...", and your ESP32's run an E1.31 program you can download from Github which says, "Whenever I hear a 127 on channel 7 on the network, run this custom command...." And that command can be whatever unorthodox, random thing you can dream of, that would never fit into Xlights. The ESP32 doesn't have to be an ESPixelStick, doesn't have to run FPP, nothing. A vanilla ESP32 will do.
The problem:
For Halloween, I have some lightning effects that I coded in Arduino that are highly randomized. They don't fit nicely into Xlights, and they're different every time you play it. However, they are supposed to play at very specific times within the show. I could run them asynchronously, but I couldn't figure out how to integrate them into sequences. This solution can apply to any effect that doesn't quite fit into Xlights.
Solution:
There is no rule which says that E1.31 can only be used to run lights. Or motors, or on/off switches, or smoke.... You can integrate ESP32's into your show and code them to listen to E1.31--at which point, you can wire up the ESP's to do anything. There are multiple example sketches out there which demonstrate how to do this. Often these examples will marry together E1.31 with FastLED or WLED, but you can just delete the WLED part and keep only the E1.31. The incoming network packets will consist of short integer values on a bunch of channel numbers. Every ESP32 listening in will hear all these values on the network. From there, instead of thinking of these channels and values as lights, think of them as commands (ultimately, the network packets are nothing more than just 1's and 0's, which you can interpret any way you want). Value 127 on channel 7 is a command. 128 is another. You define what that command is. In your sketch, you basically have a gigantic switch() statement which dispatches off these various integer values to various callback functions which you define. The value can also serve as a parameter you can pass on to a function (e.g. in my case, to control the speed and intensity of the lightning, and to steer its randomness).
To integrate into Xights, Vixen...whatever...place down a DMX effect, with the appropriate channel number and value. Configure your controller/channel such that the DMX effect gets broadcast over E1.31 on your show network. Probably, you should give all custom effects of this sort their own universe (mostly because there is no reason not to). The ESP32's, of course, are listening in on the show network, on that universe.
You need to "debounce" your callback functions, since the DMX effect will repeatedly broadcast the same value over and over, for the duration of the effect. In essence, just ignore DMX traffic for that channel until that command you're already running completes, and until the DMX value at least changes to something else first. This repeat-broadcast feature of DMX is actually nice on unreliable wireless networks, since it makes them more reliable (albeit the timing might be slightly off if it takes 5 tries to finally receive the command).
Normally, this would be an application more suited to MQTT than E1.31, except that we are trying to integrate into Xlights (or Vixen, et. al.). Xlights supports outputting a "prop" to E1.31 on the network.
Other possibilities using this method that I'm currently testing:
- attach color macros to certain DMX values, so the effect just plays locally and reduces your network bandwidth. And to function more robustly in an unreliable wireless network, since only the start signal alone relies on the network.
- randomize other effects so they are different every playthrough
- respond to sensors or buttons over a certain time window, within a song. You can tie INPUTS to Xlights effects this way.
- play back effects differently based on sensor values.
- packing 8 non-dimmable elements into a single channel (such as mechanical relays)
- don't turn on certain GPIO's at all if that relay channel is known to have GFCI problems, and the moisture sensor is detecting moisture
- Nothing. Just echo out the network packets to your Serial Monitor and watch what's going on. Debug.
In case I made all this sound harder than it really is, I'll put it another way: in Xlights, you place down an effect which says, "Broadcast value 127 on channel 7 at this time...", and your ESP32's run an E1.31 program you can download from Github which says, "Whenever I hear a 127 on channel 7 on the network, run this custom command...." And that command can be whatever unorthodox, random thing you can dream of, that would never fit into Xlights. The ESP32 doesn't have to be an ESPixelStick, doesn't have to run FPP, nothing. A vanilla ESP32 will do.