RFC - Event Extras & Girder2Girder

[JohnHind]

Request For Comment: Event Extras & Girder2Girder

Updated to B4 26 October 2005

WARNING: There is a minor breaking change in this Beta - The old SetPassword has been replaced with ClientSetPassword and a new SetPassword added taking password only. This makes for consistency with the other functions.

This is something I've been tinkering with for a couple of weeks now. It provides an alternative and perhaps more flexible method of mapping events using GML files and a way of distributing events to other Girder machines over a network. No scripting is necessary, but it is there under the hood if you want something more flexible.

A beta is available for download. Please post any comments/suggestions here.

Installation:

Girder2Girder.lua -> %girder%luascript\
EventExtras.lua -> %girder%plugins\treescript\
EventExtras.xml -> %girder%plugins\UI\

Actions and Conditionals:

Event Translation (Event Extras Action Group): This action can generate a new event which may optionally include elements from the triggering event. For example, you
can map one eventstring onto another or change the device number.

Event Filter (Conditional): You can attach this to any node to block events from specified devices getting down that part of the tree. For example, you could block events from all mapping devices except one specified one, then you can change the mapping by editing just one node!

Event Pump (Event Extras Action Group): This action sends (pumps) any events which trigger it to another Girder machine. It can also broadcast events to all connected
machines. Use Event Translation to generate custom events to send, or just send all
the events from a remote to another machine.

Comserv Conditional: This conditional can switch actions on or off depending on
whether a specified remote Girder machine is on-line and available to the Event Pump.

Lua High-level Functions:

The Actions and Conditionals use a Lua library Girder2Girder.lua as an easy front end for the comserv plugin. This can also be used directly from scripting.

Put the command "require('Girder2Girder')" at the top of your script to ensure the
library is loaded. Now the following commands are available:

g2g.SendEvent([event], [device], [mod], [p1], [p2], [p3], [p4])
g2g.ClientSendEvent([name], [event], [device], [mod], [p1], [p2], [p3], [p4])

g2g.SendTable([table], [destname])
g2g.ClientSendTable([name],[table],[destname])

g2g.RunLua([chunk])
g2g.ClientRunLua([name],[chunk])

g2g.Ping()
g2g.ClientPing([name])

g2g.SetPassword([password])
g2g.ClientSetPassword([name],[password])

g2g.IsClientAvailable([name])
g2g.GetClients([all])

name: This can be the Server Name of the remote Girder machine, or the IP address.

SendEvent generates an event in the remote Girder(s) per the remaining parameters. ClientSendEvent targets a named machine, SendEvent broadcasts to all.

SendTable sends a table to the remote Girder(s) where it gets stored under
destname. ClientSendTable targets a named machine, SendTable broadcasts to all.

RunLua sends a chunk of Lua (in source text form) to the remote Girder(s)
where it gets run. ClientRunLua targets an named machine, RunLua broadcasts to all.

Ping is not normally needed, but ensures that the information about on-line clients
is up to date
.
SetPassword By default, the password "girder" is used which matches the default installation, but this can be changed prior to the first transaction using this function.

IsClientAvailable returns true if the named client is online.

GetClients returns a list (number-keyed table) of Server Names. With "all" false or
missing, the list contains only clients which are on-line. With "all" true, the list
contains all clients that are known about.

Lua Low-level Functions:

The g2g Lua library also includes a lower level interface to comserv which can be used
to send any of the Girder to Girder transactions asynchronously with automatic
connection management. See the source file for details.


John Hind

[Promixis]

very cool. looking forward to playing with this!

[Mastiff]

John, is this something that I want to implement in my setup, so I won't have to call a bunch of dead clients? It certainly seems that way.

[JohnHind]

Yes, Tor, I'd be very grateful if you could find time to give it a go. I've only got two computers here, so have not really stress-tested it. Make sure you can switch back though - it is still a little experimental.

One thing to be aware of - Ron has updated comserv to allow me to make connection tracking fully automatic, but this has not been released yet. With the current version, you can get round it by making the client send an event to the host on startup.

[bill.jessep]

John, Very cool I can’t wait to try this tonight. I have 3 systems running G4 and 1 iPAQ with NR. I use one system as the main server and run a GIPv2 Server along with the Standard Communication Server for the NR client and use the two remote G4s for Voice recoginition commands and one for Caller ID. The Caller ID system looks up the number and sends a message for the server to announce. So I needed to send two types of messages. One type is to simply send some text that the main server would simply announce. The other event was to mimic the NR X.10 control events and to send other events for the Media Centre, which was a problem.

I could not work how callback should work for the server or how the client could close the connection after sending the message. Lua is not my strength. So I am looking forward testing your code Thank you.

Bill

[Promixis]

John, this command runs but I do not get an event

g2g.SendEvent(true, 'girder', 18, 'TEST',0, 'ME')


I do see the receiving computer listed when I list the getclients (all) table but not in the getclients () table...

[bill.jessep]

John, I tried both the command line and the event pump and had the same problem. The receivers show no log for the event arriving.

On the event pump it would be nice if this could also be used to generate any event rather than just forward a trigger event. ie be able to specify a new event and send this to the remote/s. I did try the Event Translation to change the event before the Event Pump but only the translation was reported to run. Could be me so I will do some more testing.

Bill

[Mastiff]

John, I hope you don't mind, but I'm gonna wait for the release of that comserver, in other words the new beta. Right now I'm in a heap of work, but it should be OK by the end of the week. Then my wife and daughter's going to my in-laws, so I'll have time to play. My son will stay here, but as long as he has the TV and his PC I seldom see him... :wink:

[JohnHind]

Bill & Mike,

I'm at a bit of a loss as to what is going wrong. I have the following test script:

table.print(g2g.GetClients())
table.print(g2g.GetClients(true))
g2g.SendEvent(true, 'girder', 'TestEvent')

Running it immediately after a script reset, in the remote log I see "New Client Connection" followed a few seconds later by "TestEvent". Running it again, "TestEvent" is instantaneous because the connection is cached. In the local console, I see my client in both versions of the table (shutting down the remote Girder makes it disappear from the first table).
If the send fails (for example if the password is wrong), nothing is seen at the local end for about a minute while it processes retry attempts, then there is a log message "Connection failure -> name"

Bill: You will need to trigger the Event Pump with an Event Node set to recognise the event you are generating with Event Translation, it is not enough just to put them in sequence in a macro. I'll think about another Action that does both - advantage of the present scheme is that you can have one Event Pump transferring all the events you ever want to send, then you only need to change one node to reconfigure your network.

[JohnHind]

John, I hope you don't mind, but I'm gonna wait for the release of that comserver, in other words the new beta.

I understand Tor, no problem. Looking like there may be a few bugs to iron out anyway ...