Triggering external events or actions

[CaptainMurdoch]

I debated whether to post this here or in the Nutcracker forum since Nutcracker and xLights have merged, but I figured it would be of more interest to the xLights users than users just using the Nutcracker portion.

I started working on a patch to xLights/Nutcracker to add a new feature and wanted to get some comments to see what people thought of the idea.

First, here's a little background.

I have an external LED sign that uses the ALPHA sign protocol to allow displaying of text and/or graphics via a RS232 or RS485 interface.  I want to use this in my show as my 'tune to' sign as well as to display things like the name of the current song being played, etc..  I'd never expect xLights/Nutcracker to talk directly to the sign, but I can easily display messages on it via a Perl script I have.

As a MythtV developer, one of the features I added to MythTV was what I called 'system events' and 'system event handlers'.  Basically, this feature allowed a MythTV user to setup one or more system event handler scripts for events that would be generated by the various MythTV applications at various times.  For instance, one user has setup a handler script to automatically dim the lights in his living room when he starts watching a recording or video.  Other users use the RECORDING_STARTED event to notify them via email or text message whenever a certain show records.

I'd like to extend this event handler concept to xLights/Nutcracker to allow me to update my LED sign during the show, but I can also see other uses for this ability as well.

Basically I'm looking at something like the following set of events for now but it could be extended later if it made sense:

PLAYLIST_STARTED [PlaylistName]
PLAYLIST_FINISHED [PlaylistName]
PLAYLIST_ITEM_STARTED [SequenceName]
PLAYLIST_ITEM_FINISHED [SequenceName]
LIGHTS_OFF

As an example, if you were running Linux and configured your event handler script to be /usr/local/bin/xLights_event_handler, then xLights would run commands such as this during a show:

/usr/local/bin/xLights_event_handler PLAYLIST_STARTED PlaylistName
/usr/local/bin/xLights_event_handler PLAYLIST_ITEM_STARTED Carol_of_the_Bells.xseq
/usr/local/bin/xLights_event_handler PLAYLIST_ITEM_FINISHED Carol_of_the_Bells.xseq
/usr/local/bin/xLights_event_handler PLAYLIST_ITEM_STARTED Little_Town.xseq
/usr/local/bin/xLights_event_handler PLAYLIST_ITEM_FINISHED Little_Town.xseq
/usr/local/bin/xLights_event_handler PLAYLIST_FINISHED PlaylistName
/usr/local/bin/xLights_event_handler LIGHTS_OFF

In my case, the handler script would know that when it saw "Carol_of_the_Bells.xseq" start that it needed to display a certain message on the LED sign, etc..  The LIGHTS_OFF action might tell my LED sign to power itself off or send an X10 event via my firecracker serial dongle to remove power from the LED sign.

So, the reason for my post.  Does anyone else think that this kind of feature would be useful in their shows?

[arw01]

Very much yes.

Even as a newbie who has not done a single thing yet with the sequencing yes.

I bought a Raspberry Pi to get the events from lircd and use the same concept with its various dameons to advise when I hit the play button on my tivo three times to turn up the lights in the movie room.  Also turn down the lights on a slow fade with 3 clicks of play.

Integration with a motion sensor could be one use of the events so you could maybe tame down the show if no-one was around, don't know that the neighbors need to be blasted every night with full power if no one is watching the show in a pouring rain or who knows what else could be figured out.

Perhaps a little doo dad to tell you some lights are not working and then getting an email or text to the phone from a handler.

Would you mind if I asked a perl related question of you occassionally?  I've been struggling with a module someone else wrote for a while and it bends my little head about some of the perl tricks it pulls.

[smeighan]

I debated whether to post this here or in the Nutcracker forum since Nutcracker and xLights have merged, but I figured it would be of more interest to the xLights users than users just using the Nutcracker portion.

I started working on a patch to xLights/Nutcracker to add a new feature and wanted to get some comments to see what people thought of the idea.

First, here's a little background.

I have an external LED sign that uses the ALPHA sign protocol to allow displaying of text and/or graphics via a RS232 or RS485 interface.  I want to use this in my show as my 'tune to' sign as well as to display things like the name of the current song being played, etc..  I'd never expect xLights/Nutcracker to talk directly to the sign, but I can easily display messages on it via a Perl script I have.

As a MythtV developer, one of the features I added to MythTV was what I called 'system events' and 'system event handlers'.  Basically, this feature allowed a MythTV user to setup one or more system event handler scripts for events that would be generated by the various MythTV applications at various times.  For instance, one user has setup a handler script to automatically dim the lights in his living room when he starts watching a recording or video.  Other users use the RECORDING_STARTED event to notify them via email or text message whenever a certain show records.

I'd like to extend this event handler concept to xLights/Nutcracker to allow me to update my LED sign during the show, but I can also see other uses for this ability as well.

Basically I'm looking at something like the following set of events for now but it could be extended later if it made sense:

PLAYLIST_STARTED [PlaylistName]
PLAYLIST_FINISHED [PlaylistName]
PLAYLIST_ITEM_STARTED [SequenceName]
PLAYLIST_ITEM_FINISHED [SequenceName]
LIGHTS_OFF

As an example, if you were running Linux and configured your event handler script to be /usr/local/bin/xLights_event_handler, then xLights would run commands such as this during a show:

/usr/local/bin/xLights_event_handler PLAYLIST_STARTED PlaylistName
/usr/local/bin/xLights_event_handler PLAYLIST_ITEM_STARTED Carol_of_the_Bells.xseq
/usr/local/bin/xLights_event_handler PLAYLIST_ITEM_FINISHED Carol_of_the_Bells.xseq
/usr/local/bin/xLights_event_handler PLAYLIST_ITEM_STARTED Little_Town.xseq
/usr/local/bin/xLights_event_handler PLAYLIST_ITEM_FINISHED Little_Town.xseq
/usr/local/bin/xLights_event_handler PLAYLIST_FINISHED PlaylistName
/usr/local/bin/xLights_event_handler LIGHTS_OFF

In my case, the handler script would know that when it saw "Carol_of_the_Bells.xseq" start that it needed to display a certain message on the LED sign, etc..  The LIGHTS_OFF action might tell my LED sign to power itself off or send an X10 event via my firecracker serial dongle to remove power from the LED sign.

So, the reason for my post.  Does anyone else think that this kind of feature would be useful in their shows?

Have you looked at the scripting language that matt created? It is a basic interpreter. While you are running shows, you can send ascii strings out the serial ports. it can be used to do things like sending text to RDS units.

it can also be scripted to do things like run show, play sound, send string to serial port.

go to "Play List", "Custom Script" in xLights you will see the BASIC script that is used to run a show.

[CaptainMurdoch]

Integration with a motion sensor could be one use of the events so you could maybe tame down the show if no-one was around, don't know that the neighbors need to be blasted every night with full power if no one is watching the show in a pouring rain or who knows what else could be figured out.

Perhaps a little doo dad to tell you some lights are not working and then getting an email or text to the phone from a handler.

These two suggestions make me wonder if I wasn't clear enough.  These events are triggered by xLights, they're not triggering xLights (although I've seen that idea mentioned as well).

I would like to see a stand alone scheduler with a web services API or other interface which could be used to trigger sequences, start/stop shows, etc..  I've seen others talk about this as well.  Having the ability to run this on a PogoPlug or Pi would be something I'd also be interested in, but those are other topics.

Would you mind if I asked a perl related question of you occassionally?  I've been struggling with a module someone else wrote for a while and it bends my little head about some of the perl tricks it pulls.

Feel free to PM me if you want, I can try to help.

[CaptainMurdoch]

Have you looked at the scripting language that matt created? It is a basic interpreter. While you are running shows, you can send ascii strings out the serial ports. it can be used to do things like sending text to RDS units.

Yes, my (untested) patch actually uses the EXEC command that Matt has added to the language.  EXEC calls and external script in the background.  EXEC is currently unused and seemed a perfect fit for this idea.  I prefer the idea of allowing a generic script to be executed and allow the user to decide what action they want to take when a certain event occurs.  With a generic script, you could easily create a single script that would take the name of the sequence, parse the artist and title from the mp3 id3 info and display it on the LED sign.  No need for custom scripts for each individual show.

it can also be scripted to do things like run show, play sound, send string to serial port.

go to "Play List", "Custom Script" in xLights you will see the BASIC script that is used to run a show.

I've looked at the custom script interface and know that the EXEC command could be called from here.  I was looking for a way to automatically call the EXEC commands if the event handler script was configured rather than having to create custom scripts to begin with.  When the event handler script is defined my patch actually modifies the default script to insert these EXEC commands to call the event handler script.

If this seems like something that only I would use then I can always keep my patch on my show computer, but if others see a use for the feature then I might propose it's inclusion.