Use of * in event name not working

If you have a question or need help, this is the place to be.
Post Reply
mrl72
Posts: 3
Joined: Sat Jun 19, 2010 12:20 pm

Use of * in event name not working

Post by mrl72 » Fri Apr 03, 2020 4:12 pm

If I understand correctly, you can use a wildcard in an event name such as Main.*.

I am using the Serial plugin that creates an event combined with the payload when it detects incoming data on the serial port. The name given will be something like myserialport.payload. What I want to do is run a script to pull the payload from the event name. So I create a macro with the event name myserialport.* but it does not work. I've tried everything from Main.myserialport.* to *.myserialport.* and nothing works.

Am I not understanding this correctly? Any help appreciated.

User avatar
Sem;colon
Plugin Developer
Posts: 731
Joined: Sat Feb 18, 2012 10:51 am
Location: Germany

Re: Use of * in event name not working

Post by Sem;colon » Fri Apr 03, 2020 6:28 pm

Hi mrl72,
What version of Eventghost are you using?
If you like my work, Image me a drink :wink:

V_J
Experienced User
Posts: 237
Joined: Tue Mar 04, 2014 9:00 am

Re: Use of * in event name not working

Post by V_J » Tue Apr 14, 2020 10:08 am

I think the issue is in Eventghost 0.5: when you use the serial port plugin, an event is logged when something arrives on the serial port. This event already has the payload hardcoded in it, there seems to be no way of having an event on "whatever arrives on the serial port"...

User avatar
kgschlosser
Site Admin
Posts: 5498
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Use of * in event name not working

Post by kgschlosser » Wed Apr 15, 2020 7:32 am

In the Serial Port plugin you have generate events checked off yes? and you have the prefix set to whatever it is you want to have it set to yes?

I ran a test and this was my setup.

I have Generate Events checked off.
I have Prefix set to "Serial"
I have the terminator set to "\r"

When I send "Test\r" to the port I get an event in eg "Serial.Test"

I created a macro and added The comment action. I change the name of the comment action to "Event Triggered"
Then I dragged and dropped the event "Serial.Test" into the macro. I renamed the event to "Serial.*"
I ten sent the packet again. and low and behold the macro ran because I can see the comment line in the log "Event Triggered".

Now You mentioned the term payload. are you trying to parse payload data? because the Serial Port plugin does not have any payload data. The data that is received by the plugin is set into the event suffix not the payload. because you are trying to access the payload I am also going to assume you are using a python script. well. you need to change whatever is in that script that states "eg.event.payload" to "eg.event.suffix" and then you should be off and running.

Set up a test like I did above and see if the comment line gets printed out in the log. It should without issue, If it isn't then double check your event in the macro and make sure there are no additional spaces before or after the event. we want to make sure that it is not white space that may be boogering it up. I have seen that happen before so i thought I should mention it.

you can set up a virtual loopback pair of com ports using a program called com0com you can sue this for testing. connect EG to one of the "pairs" and then connect a program like realterm to the other port and use realterm to send a test packet. make sure that if you have \r set as the terminator in the Serial Port plugin that you check off the +CR in the EOL portion of reaterm under the send tab.

This should provide you with enough information to get it running properly. If you are still having a problem PM me a copy of your save file. You will have to Zip it in order to attach it. This way I will be able to see how you have it set up and I can locate any problems in your tree possibly. If it is not an issue with your tree the only other thing is that you are not running EG v0.5 you MUST be running EG v0.5 in order to have the wildcard events feature. you can download the latest release from HERE
If you like the work I have been doing then feel free to Image

V_J
Experienced User
Posts: 237
Joined: Tue Mar 04, 2014 9:00 am

Re: Use of * in event name not working

Post by V_J » Wed Apr 15, 2020 7:54 am

I replied to the thread as I thought that was the original poster's issue...

I was thinking of using the serial port plugin as to communicate with my amplifier, before I found your marantz plugin. It is still possible with the serial port plugin, if I would generate full set of all events that the amplifier can generate (would be some work as e.g. each volume value would be a different event), but that is where I tried also to get the wildcard. So it was more a follow up for the original poster.

Anyway, I'll go with the Marantz plugin, so for me it is fine. And the suffix information is very valuable. Not sure if the original poster is still following the tread, but nice to see it resolved.

User avatar
kgschlosser
Site Admin
Posts: 5498
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Use of * in event name not working

Post by kgschlosser » Wed Apr 15, 2020 7:57 am

V_J wrote:
Tue Apr 14, 2020 10:08 am
I think the issue is in Eventghost 0.5: when you use the serial port plugin, an event is logged when something arrives on the serial port. This event already has the payload hardcoded in it, there seems to be no way of having an event on "whatever arrives on the serial port"...
You cannot have an event for "whatever arrives" on the port. The data is received from the port a single byte at a time. This means that If i sent a command of PWR to the port you would get 3 events in EG "Serial.P", "Serial.W" and "Serial.R" This simply would not work.

There is an action to read whatever data is on the port. This is the mechanism you would use. You install the timer plugin and set up a timer to repeat over and over again at a set interval. you have the timer started using the Main.OnInit action. create a macro with the event from the timer and in that macro add the action Serial/Read Data. in here you can read whatever bytes are available or specify a number of bytes to receive and a duration to wait for those bytes to be available before it will stop waiting.

from there if you want to trigger an event you can. add the action Trigger Event. in the suffix field you would enter "{eg.result}" (without the double quotes). This is going to tell EG to grab the data from the Read Data action and to make it the suffix of the event you are generating.

Any time you deal with any form of communications between devices there is going to be a structure (API) for the data stream. Some of these structures are set to specific lengths, others are set to specific characters. There is a third way it can also be done, this one is my personal favorite (NOT) using duration of time between bytes of data.

Most API's will use character delimiters to tell us when a packet is complete. You will have to spend the time to watch what is happening on the serial port in order to locate that delimiter. You can use a program like realterm to do this. realterm is going to output the data that is received as hex, this is a good thing because most times delimiting characters are not in the ordinal range of 32-127 which is the section of the ASCII chart that is the "human readable" section. some of the "characters" in the ASCII table are not characters at all, there is no graphical representation of the. These are the ones that are typically used for delimiters. in the Serial Port plugin you would enter "\x{HEX CODE}" replacing {HEX CODE} with the 2 character pairings you will see in realterm. each character in the pair can have any of the following 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, a, b, c, d, e, f

The data that is attached to the event for the Serial Port plugin is not a "payload" The data is append to the event name as the suffix. I explain this in the previous post.
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 5498
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Use of * in event name not working

Post by kgschlosser » Wed Apr 15, 2020 7:59 am

sorry about the post.. I missed your comment before I keyed it out. But it is good information to have available for anyone who goes looking.
If you like the work I have been doing then feel free to Image

V_J
Experienced User
Posts: 237
Joined: Tue Mar 04, 2014 9:00 am

Re: Use of * in event name not working

Post by V_J » Wed Apr 15, 2020 8:31 am

kgschlosser wrote:
Wed Apr 15, 2020 7:57 am
You cannot have an event for "whatever arrives" on the port. The data is received from the port a single byte at a time. This means that If i sent a command of PWR to the port you would get 3 events in EG "Serial.P", "Serial.W" and "Serial.R" This simply would not work.
Actually, it does how me the single event that was sent by the amplifier (so it shows "Serial.@VOL:-44", not byte per byte), I guess because of the delimiter \r... :)

User avatar
kgschlosser
Site Admin
Posts: 5498
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Use of * in event name not working

Post by kgschlosser » Wed Apr 15, 2020 9:39 am

Denon/Marantz happen to use the carriage return "\r" or "\x0D" as the terminator/delimiter between packets
If you like the work I have been doing then feel free to Image

V_J
Experienced User
Posts: 237
Joined: Tue Mar 04, 2014 9:00 am

Re: Use of * in event name not working

Post by V_J » Wed Apr 15, 2020 1:00 pm

In the old specification, yes... (I don't know about the new specification), so that is probably why the serial plugin manages to group the bytes nicely.

User avatar
kgschlosser
Site Admin
Posts: 5498
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Use of * in event name not working

Post by kgschlosser » Wed Apr 15, 2020 1:35 pm

OK the Serial specification and the IP specification are one in the same. They only differ in the connection. otherwise they are identical. So whatever command work over Serial on your AVR will also work over IP. They are still using the \r as the delimiter. The only changes they have made over the past 15 years or so to the Serial API is the addition if the IP connection and also adding in new commands. Now... That being said. There are command that existed some 10 or 12 years ago that are no longer in the documentation. The commands however have not been removed from the actual devices. So the current devices also support old commands. And this is where I run into problems. when they release a new model they often do add new features to it. Usually in the form of processing ability. whether is be additional DSP sound fields.. Things like that.. These electronics companies do not reengineer the wheel each model year. Often times all they do is give the new model a software boost and they update the model number as well. But the internals are identical to the previous year. well they aren't going to maintain multiple firmwares if the hardware is identical. so more often then not the firmware for the newer model ends up being released and it can be downloaded for the old model. well. This adds that "new" functionality to the old model. It will also add Serial/IP commands. They tend not to update the documentation when this happens. This is probably why you have commands that are available when they "shouldn't" be.. well those commands should be available because you have the firmware that supports them.
If you like the work I have been doing then feel free to Image

Post Reply