Use of wild card character in EG Main event

[theendisnye]

I am calling the EG program as a command line and passing a set of parameters which generates the following EG event

<Event Name="Main.CAM,Motion,04,Rat,Run,Special," />

and I wanted to execute a macro based on the first part of the message 'Main.CAM,Motion', so I created an event

<Event Name="Main.CAM,Motion*" />

however the macro is not getting invoked and I can't see what I am doing wrong as a similar event using wild cards on an xPL message works fine.

I wondered if the issue was that wild card characters were not supported on events created by command line calls?

Steve

[Pako]

Wildcards work for several years, exactly the same, unchanged.
There are a few rules that must be taken into account.
1. Event string may have several levels. These levels are fundamentally separated by "." (dot).
2. An asterisk can be used in two places:
2.1 Immediately after the first level
2.2 Instead of the last level
3. It is not practical to use more than three levels. Use payloads.

Example:
Suppose we have an event Main.First.Second.Third.
There are two ways you can place an asterisk:
1. Main.*
2. Main.First.Second.*

Pako

[theendisnye]

Thank you Pako, works like a dream now. Steve

[rdgerken]

Pako,

I can't say I totally agree with your comment "It is not practical to use more than three levels. Use payloads."

I'm not saying I can't be convinced, but let me throw down this scenario, and see what you think.

So I have a plugin that is for a lighting system. The events I had set up to this point in time returned several items in the event string. The format was PluginName.DeviceType.DeviceLocation.SomeAction [Value]. This worked nicely, because I can program macros for very specific events by dragging from the logger to the macro - never having to worry about the payload. I then got this idea of wanting to log all of these events to MySQL, and once I found this thread saying you can only wildcard the first or last part of the event, that is pretty limiting. I was wanting to do something like PluginName.DeviceType.* - and for all of those device types, I would run a macro to do my logging. Ok, so I found your note about using payloads... so then I modified my plugin to return payloads instead of a longer event string. I changed the format to PluginName.DeviceType [Location, Action, Value]. My thinking here was that I would then get PluginName.DeviceType [with some payloads] in the logger, so now I can just drag this to my macro, and then I would get all events of that devicetype to one macro to send to my database via python script or whatever. OK, so great, that works... except now, it's very difficult to use the events in a more "normal" manner like I described above. The only way I know how to do it, is to use python script to evaluate the payloads for very specific values to trigger the actions that I want. So, I essentially removed the ability to drag events over to my macros - and definitely not worth the tradeoff. Had I been able to use PluginName.DeviceType.* - I would have been able to have my cake, and eat it too.

Does this make sense? Is there an easier or better way? If I was a better programmer, I would just leave my plugin the way that I had it, and add the MySQL logging capability directly to the plugin, but I don't know if I can pull that off. That also wouldn't lend itself to be as flexible as dealing with it out in EG would be, unless you got really crazy with the configurability in the plugin.

I guess the only other option I can think of is to leave the plugin the way that I had it, and add an event to a MySQL logger macro that is PluginName.* - and then evaluate the eventstring in script to determine if it is something that should be logged or not, and then also parse the eventstring for the values to be logged in conjunction with the payloads.

I can see some use scenarios where it would be helpful to be able to put the wildcard in at different levels. Take another scenario, where maybe you have something like PluginName.Building.Floor.DeviceType.DeviceLocation.SomeAction [Value]. Again, this is a very helpful eventstring deeper than 3 levels, but because of the limitation of where you can place wildcards, there is no way to capture all events for MyPlugin.BuildingA.1stFloor.* without taking MyPlugin.* and then parsing the event string for "BuildingA.1stFloor".

Thanks