EventGhost

Maybe we can get some more information when you run EventGhost with -debug commandline option.

Pako

I just ran the command line debug option and found the log file at:
C:\Users\Asus\AppData/Roaming\EventGhost

File attached

Hope you can see some useful things in there

Although I saw some errors in the file, I am not sure if it was using the 'right' (wrong) Eventghost XML file where there is the culprit UDP command in the Eventghost tree.
I have to go out now, but I will retry later in the afternoon and post a new log if needed.

I am back and 2nd logfile attached.

Some explanation:
I started Eventghost at around 10.36 with XML file 'aa', which is a backup file that does not have problems.
This started OK, although the log file shows some errors at startup (twice the message "SystemError: wxEntryStart failed, unable to initialize wxWidgets!")
Then it was running for some 2 hours (many OSD on screen displays of messages when camera's register movement).

Returned home at 12:41:50 and found Eventghost was still running.
In the debug-menu I played around a bit and chose a reset and a garbage collection (don't know what that is).

12:56:22: I restarted Eventghost to see if it would cause a problem. It restarted without a problem
I then issued the UDP command from my home automation PC and it was received OK in the Eventlog of EG.
I dragged it over to an OSD action and retriggered the UDP command. This gave me the OSD as expected.

I then saved the program from within EG (i.e. saving XML file 'aa') and then chose the 'restart option' from the debug menu within Eventghost.
Restart at 13:01:52 and this gives the same error messages in the debug-log that I got before, see attached.

I do not understand much of what is included in the logs. I hope you can find something in it.

Thank in advance!

It's hard to tell but it sounds to me like this has nothing to do with broadcaster, but instead is caused by this particular event you are assigning to a macro.

I looked at your logs but I think they were both logs made by trying to run EG after the xml file had been corrupted and could not be loaded. It would probably be more useful to look at the log file made while you were generating the event, assigning the event to a macro and then saving the configuration.

It might also help to look at the xml file before and after the event is assigned and the new xml saved. You can also try to copy and paste your macro after assigning the event to it. I believe this copy/paste action is done using xml. You could copy the macro and paste it into notepad to see if it looks normal.

I tried to recreate your situation using a blank tree. I was able to assign this event to an OSD command and test it by sending broadcasts from VoxCommando. I saved the tree and restarted EG with no problems. I tested this on the EG I was already running (0.4.1.r1572) and then upgraded to 0.4.1.r1700 and it still seemed fine. Config file with the macro and broadcaster plugin is attached.

Maybe you can try with this configuration and see if it fails on your system for some reason, or let me know if I did something different from what you described.

Maybe you can also try to recreate the problem you described using a blank tree. If you are able to recreate the problem you can send us more info without the issues of privacy and the confusion of all your other macros and plugins. Send us some logs and before, during and after xml files.

Otherwise I'm not sure what else to suggest. What you describe sounds very weird! Sometimes things will break at a certain point and we suspect the activity we were engaged in as the culprit only to find out later that it was something completely different, though still related, such as our xml file is too big too load when we add this one new command. I'm not saying it's that. Just an example.

Maybe you can also try to recreate the problem you described using a blank tree. If you are able to recreate the problem you can send us more info without the issues of privacy and the confusion of all your other macros and plugins. Send us some logs and before, during and after xml files.

Good idea, strange that i did not think of that myself However, I tried it and sure enough, it gave the same results (log 3 attached).

I tried to recreate your situation using a blank tree..........
Maybe you can try with this configuration and see if it fails on your system for some reason, or let me know if I did something different from what you described.
You can also try to copy and paste your macro after assigning the event to it. I believe this copy/paste action is done using xml. You could copy the macro and paste it into notepad to see if it looks normal.

Another great idea and thanks for making the effort of recreating and posting my situation.
This gives very interesting results.
First I opened your XML file without a problem and if I activate your macro manually, I get the OSD.
If I send my UDP command (by pressing my switch in my house), the UDP command is received in Eventghost and it looks exactly the same as your UDP event BUT IT DOES NOT TRIGGER THE OSD MACRO!!!!
So, on the surface your UDP command looks exactly like mine when looking at it in Eventghost. However, when copied and pasted into a wordpad file, there are some differences: my comand lacks quotation marks and some code ending.
Here is what the differences look like:

Copy-pastes of the UDP Event that Jitterjames dragged into the EG tree followed by the copy-paste of my own UDP event

Jitterjames' :

<?xml version="1.0" encoding="UTF-8" ?>
<EventGhost Version="1700">
<Event Name="Broadcast.sbwoonkuit" />
</EventGhost>

Mine:

<?xml version="1.0" encoding="UTF-8" ?>
<EventGhost Version="1700">
<Event Name="Broadcast.sbwoonkuit

Now the next question comes: what is going on here and how can I make sure my UDP is sent and received in EG like your UPD command?

Thanks for your patience!

aha!

So I think the problem is that your EIBPC is not sending a properly formatted UDP message.

If you use something like wireshark you might be able to figure out what is going on.

My guess is that it is either sending a bad character (example a null character or similar) or there is a problem in the header information (wrong packet length etc.). I don't know the UDP protocol too well so I would look it up and then maybe compare what you read with what you see in wireshark. I'll try to look into this a bit myself, but I don't have time for it right now.

For the heck of it, you can try adding && to the end of the message you are sending. That might trick it into working by sending an empty payload.

In case it is of any use to you, here is what the good message looks like in wireshark:

YOU ARE THE MAN!!!!

Your suggestion to try and add && to the end of the text string in the EIBPC did the trick!!

Now, when the message is received in the event log of Eventghost, it looks different than when dragged over to a macro in the Eventghost Tree, see below:

Received in EventGhost event log:
06:43:50 Broadcast.sbwoonkuit '\x00'

Copy-paste from the event when used in a macro in Eventghost:
<?xml version="1.0" encoding="UTF-8" ?>
<EventGhost Version="1700">
<Event Name="Broadcast.sbwoonkuit" />
</EventGhost>

The macro works and I can save and re-open the XML file without a problem. I am really happy the UDP command is working now.

I really appreciate your enthusiasm and the time you invested to help me get to the bottom of this problem.
Have a great day.
Regards,
Perry

Glad it works.

Looks like your messages are being null terminated which I'm pretty sure is incorrect. Instead of this workaround where we force the null character into a payload and then ignore it, it would be preferable:

1 To fix your udp sender if possible.

2 Possibly to modify the broadcaster plug in to strip null characters from the end of received messages.

If you want to try option 2 but you aren't sure how, let me know and I'll take a crack at it.

Although it may be ugly, I think the workaround with the '&&' will be easiest and 'future-proof'. If there are no other negative side-effects, I will keep using this.

1 To fix your udp sender if possible.

I might bring up the issue in the EIBPC forum sometime. However, I would be quickly out of arguments in a discussion, as I have little knowledge of the technical details behind the UDP communication.

2 Possibly to modify the broadcaster plug in to strip null characters from the end of received messages.

I lack the skills to mess with plugins. Even when done, it would require maintenance to keep it working with future updates.

Getting an error in Broadcaster from a WOL message from new version of Yatse android remote control app.

11:09:34 Broadcast listener on 192.168.0.106:7. Self broadcast is False.
11:09:34 error: uncaptured python exception, closing channel <eg.CorePluginModule.Broadcaster.Server connected 192.168.0.106:7 at 0x45a1fd0> (<type 'exceptions.UnicodeDecodeError'>:'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128) [asyncore.pyc|read|76] [asyncore.pyc|handle_read_event|414] [C:\Program Files (x86)\EventGhost\plugins\Broadcaster\__init__.py|handle_read|95] [C:\Program Files (x86)\EventGhost\eg\Classes\PluginBase.py|TriggerEvent|133] [C:\Program Files (x86)\EventGhost\eg\Classes\EventThread.py|TriggerEvent|78] [C:\Program Files (x86)\EventGhost\eg\Classes\EventGhostEvent.py|__init__|84])

 and these are the packets sent as copied from a monitor.

Packet recieved from 192.168.0.119 on port 42949
at 17:53:15 packet length : 102
00000000 : FF FF FF FF FF FF 48 5B 39 C3 EC 9C 48 5B 39 C3
00000010 : EC 9C 48 5B 39 C3 EC 9C 48 5B 39 C3 EC 9C 48 5B
00000020 : 39 C3 EC 9C 48 5B 39 C3 EC 9C 48 5B 39 C3 EC 9C
00000030 : 48 5B 39 C3 EC 9C 48 5B 39 C3 EC 9C 48 5B 39 C3
00000040 : EC 9C 48 5B 39 C3 EC 9C 48 5B 39 C3 EC 9C 48 5B
00000050 : 39 C3 EC 9C 48 5B 39 C3 EC 9C 48 5B 39 C3 EC 9C
00000060 : 48 5B 39 C3 EC 9C

Packet recieved from 192.168.0.119 on port 53082
at 17:53:15 packet length : 15
00000000 : 59 61 74 73 65 53 74 61 72 74 2D 58 62 6D 63

 the 15 length packet matches what was mentioned elsewhere in this thread as translating to YatseStart-Xbmc and Im not sure what the first packet is for. The port numbers shown in the packets above are a mystery to me as the monitor program displaying that output is set to port 9 and all messages are sent to port 9 so ignore that.

Does anyone see anything that would trigger the python exception?

Latest EG and latest Yatse app. EG loads fine with no errors. I have sent test messages over the network and they pop up fine in the EG log window via Broadcaster. I reported it to Yatse because their new update 5 days ago is when the problem started but they say nothing has changed in that code, and it does look like the 15 length packet is the same. Since it is the Broadcaster error message I should be able to gain insights on this forum.

Thanks for any help.

Hi,

I have just downloaded the latest version of EG (0.4.1.r1700) It is running on windows 7 SP1 64bit.

I am trying to respond to a number of events sent from an OSC software called Light Jams.

The string follows the OSC protocol & cannot be changed.

/lj/osc/199\00,i\00\00\00\00\00\ff this is one example of the string I have tried to do nothing more with it than register it with broadcaster.

I have broadcaster running listening to address 192.168.0.11:9002

I am then sending the string above from Packet Sender on a mac.

The first time the string is sent, broadcaster responds with an error (below) & fails to respond any further.

error: uncaptured python exception, closing channel <eg.CorePluginModule.Broadcaster.Server connected 192.168.0.11:9002 at 0x45f6eb8> (<type 'exceptions.UnicodeDecodeError'>:'ascii' codec can't decode byte 0xff in position 19: ordinal not in range(128) [asyncore.pyc|read|76] [asyncore.pyc|handle_read_event|414] [C:\Program Files (x86)\EventGhost\plugins\Broadcaster\__init__.py|handle_read|95] [C:\Program Files (x86)\EventGhost\eg\Classes\PluginBase.py|TriggerEvent|133] [C:\Program Files (x86)\EventGhost\eg\Classes\EventThread.py|TriggerEvent|78] [C:\Program Files (x86)\EventGhost\eg\Classes\EventGhostEvent.py|__init__|84])


Any help with this would be great, If I've missed any information out please tell me & i'll be happy to provide it.

Nik

Is it possible to send messages to TerRemote on android with this?

skribb wrote:Is it possible to send messages to TerRemote on android with this?

TerRemote is made to work with the Network Event Receiver plugin which uses a different protocol than this plugin. You should also be able to use the TCPEvents plugin viewtopic.php?t=2944 which I prefer over the Network Event Sender/Receiver plugins.