EventGhost

I fixed this a while back, but apparently I never got around to posting the version I actually use. Give this one a shot and see if it handles payload properly for you.

~K

(edit: attachment removed, newer version at the top of the thread).

Did I tell you I love you? !!!

One request. I'm firing broadcast events on a wildcard (HTTP.*)

My command I put in the input is {eg.event.string}
My payload I put in the input is (eg.event.payload[0]}

Could you test the input to see if it is valid before parsing it?

Only some of the events I'm firing have a payload. If there is no payload I get a parseString error triggered from line 134 of the plugin.

I moved the eg.ParseString (which does tend to be pretty picky about its input) a little lower after the check to see if there was a payload defined. See if this does the trick. If so I'll remove the other version from the previous post.

~K

(edit: removed file, newer version in the first post of this thread).

If an event is fired by calling eventghost directly the format is something like

HTTP.ONKYOVOLUMEZ1 [u'2d']

If I fire the same event on another machine and it is broadcast the format comes across like

Broadcast.HTTP.ONKYOVOLUMEZ1 "[u'32']"

The quotes are preventing the payload from working like I would expect.

--------------------

On the above revision it sends "NONE" as the payload if there is no payload present. Would it be possible to not fire a payload at all if it isn't present?

THANKS!!!

To clarify the above after playing with your plugin and my onkyo plugin

I have a volume slider. When you set the volume I call eventghost via HTTP with a URL like

http://192.168.2.103:81/index.html?ONKYOVOLZ1&37

Eventghost webserver puts the 37 in as eg.event.payload[0] which shows up in the event log as

HTTP.ONKYOVOLUMEZ1 [u'37']

When broadcaster refires the event, it treats each character of the entire payload string as one element of the eg.event.payload array.

Broadcast.HTTP.ONKYOVOLUMEZ1 "[u'37']"

So, when refired by broadcaster if I have [u'37'] as my payload
eg.event.payload[0] is [
eg.event.payload[1] is u
eg.event.payload[2] is '
so on and so forth.

I just configured one of my systems here for the same thing you're doing - wildcard capture of events and rebroadcast. Let me play around with it and find the sharp edges.

~K

kingtd wrote:I just configured one of my systems here for the same thing you're doing - wildcard capture of events and rebroadcast. Let me play around with it and find the sharp edges.

~K

Thanks,

This plugin is going to be huge for my home automation projects.

So I've played with it a little bit between projects this morning. There are two things that still hold it up, one you can try out a little to test, one that's got me stumped.

1. Use eg.event.payload instead of eg.event.payload[0]
Because there are so many different types of payloads you might be pushing, there's no way of knowing if that payload is going to have multiple parts or not. If it doesn't and it's a string, you're going to get just the first letter. Better to pass the full payload and sort it out on the other end of the broadcast. I've tested this out myself and it seems to work pretty well as long as you drop the [0].

2. The "None" problem.
When you pass {eg.event.payload} to the plug-in, that string is taken literally until it's run through the eg.ParseString function that is built into eventghost. ParseString generally returns the value as a string. The problem here is that there is no way to determine if the {eg.event.payload} is actually empty without running ParseString on it, and if it IS empty, ParseString returns "None". But there are scenarios where the payload might actually be the string "None", so I can't just filter on that. Well I guess I could, but it wouldn't be a very elegant answer.

If anyone has thoughts on #2, I'd be happy to implement. This isn't the first time that I've had issues with the way ParseString is built, but it's core functionality so you don't want to monkey with it too much.

~K

kingtd wrote: 2. The "None" problem.
When you pass {eg.event.payload} to the plug-in, that string is taken literally until it's run through the eg.ParseString function that is built into eventghost. ParseString generally returns the value as a string. The problem here is that there is no way to determine if the {eg.event.payload} is actually empty without running ParseString on it, and if it IS empty, ParseString returns "None". But there are scenarios where the payload might actually be the string "None", so I can't just filter on that. Well I guess I could, but it wouldn't be a very elegant answer.

Couldn't you save the string before you pass it to ParseString, then test to see if ParseString changed the result?

Brett

stottle wrote: Couldn't you save the string before you pass it to ParseString, then test

Code: Select all

if inputString != outputString and outputString == "None":

to see if ParseString changed the result?

Brett

In all cases (at least the ones Fiasco cares about) the inputString would be "{eg.event.payload}". We don't get to see what's inside the string until it's been parsed. It would make life a lot easier if ParseString returned "" instead of "None" when the value passed is empty.

I may just re-implement ParseString in my plugin to avoid this issue. It's not the first time I've had to do it. =)

~K

passing the entire payload array is fine with me.

I was using payload[0] and joining the array in my plugin into a single string. A natural regurgitation of the payload by broadcaster would, of course, be preferred.

Thanks!!

I love this plugin, couldn't live without it! Whether it is integrated with the TCP plugin or kept separate I think it should absolutely be part of the standard install.

One thing I noticed and maybe you can figure out what is causing it. For a long time now I've noticed that eventGhost takes a long time to close. This is particularly annoying when developing plugins because I'll test something, make a change to my plugin and then need to close and restart eventGhost to test the change.

I just realized recently that the broadcast plugin is the culprit. I've got a pretty huge macro tree using many plugins, but if I remove the broadcaster plugin the problem goes away. With the broadcaster it takes about 4-5 seconds for EG to shut down. I assume it has something to do with the listener thread not shutting down right away, but I don't know enough about that stuff to help.

Also (probably unrelated) if I change the port number I get errors after closing the options dialogue. Once I save and restart it works fine and keeps the new port setting. I only mention it in case it is related somehow to the other problem.

Thanks for the plugin, it is really useful.

P.S. a feature request: I would like to see an option to listen to commands coming from the local computer instead of automatically ignoring them. I have my reasons!!! For myself I have just modified the if statement that check the addr, but others might find the option useful too.

J

I took a look at this today and replaced some of the threading code that seemed to be causing the problem with an asyncore model similar to the network sender. This took care of the delay on exit. I'm glad you brought this up, because I had noticed this delay on exit but never suspected it might be Broadcaster that was doing it (since I always have it installed on all my Eventghost machines, I had nothing to compare against).

While I was in there, I straightened up some things including making the dialog box for the send command a little bigger so that it's easier to see some of those longer variable names in the configuration page. Also contains the payload enhancements I made last week.

And to your feature request - I added a checkbox that lets you toggle "Self Broadcasts". It's off by default. If you turn it on, you will see broadcasts from your local machine. I know there are some folks that use Broadcaster to rebroadcast events, so be careful - you can get stuck in a loop pretty easily that way if you have self broadcast enabled.

You can download it from the first post in this thread.

~K

PS. I also see the "not a socket" errors occasionally when I use the configuration page as well. Couldn't figure out why that's happening.

ya, it took me a long time to realize it was broadcaster too.

It's great now, excellent work.

Thanks

how can I send multiple payloads to the broadcaster?

Does the current version of this plugin suport multiple payloads?

I'm generating udp messages with c#. For a single payload I construct a udp message for broadcaster with a string like this:

commandString,payload=payloadString

which generates the EG event: Broadcast.commandString'payloadString'

how do I do it if I want multiple payloads?

I would like to end up with an event that looks like this, for example:
Broadcast.Move ['Up', '5']

I had already modified a previous version of this plugin to work with multiple payloads, but I'm thinking it would be better to 'consolidate' and get everything working with a more standard setup.

tia