- Replaced threading code to fix issues with socket delaying Eventghost exit.
- Added checkbox to toggle "self" broadcasts
- Other minor bug fixes and configuration dialog improvement.
UPDATED: 9/29/09 - Better support for payloads
UPDATED: 6/27/08 - Now Broadcaster uses a single plugin for send and receive.
I've got several PC's at the house and they act as part of my overall automation system. Not only do they all run Eventghost so that they can trigger various events, but in many cases, I want to send commands to all of them at once. The existing "Network Sender" is good for many things, but it has some shortcomings:
- For each PC you want to target, you need to have a Network Sender plugin added to your Eventghost file
- For each command you send, you have to send it as many times as you have PC's
- In some cases, PC's may not be on and you'll get a delay and an error when the Network Sender doesn't work.
One key example of how this is limiting for me is my distributed OSD. My computers are near my main TV/Living room where the stereo is typically playing. I have the capability to change the volume of the stereo through my PC's using Eventghost, programmed to media keys on my keyboard. In order to see the current volume level (using my HK receiver plugin I previously contributed), I send that information back to my other PC's. But this means for every volume change, I have to send the same thing 5 times - once to each PC - and this can take longer than it does for the actual volume to change.
With this pair of plugins, you can simply broadcast informational messages like this over your network, and anyone who's listening can pick them up. You wouldn't want to have this turn your oven on or do dangerous actions since it lacks the basic security of the Network Sender, but it works great for general low impact items.
Another example of how I use this ties into my overall movie watching scheme. If you're in the main room and you hit the "movie" button, it dims all of my insteon lights, turns on some hallway lighting, switches media center to DVD, turns on the receiver, and the projector. With this plugin I also send a "Not Busy Off" broadcast, and any of my PC's which don't have a user actively working on them will switch their monitor off and go into minimal power mode. More darkness+quiet = better movies. =)
I've got a bunch of other esoteric uses, but enough about that. Here are the plugins. Simply provide a port and a broadcast address (the default will work for most people) and you're all set.
- (3.03 KiB) Downloaded 725 times
Is there a specific process I must go through or anything to modify to get this running?
I am using version 3.6.941
This is the error I get
Code: Select all
Can't read __init__.py for plugin "BroadcastListener" Traceback (most recent call last) (941): File "C:\Program Files\EventGhost\eg\PluginTools.py", line 262, in GetPluginInfo File "plugins/BroadcastListener/__init__.py", line 25, in <module> File "C:\Program Files\EventGhost\eg\Init.py", line 285, in __getattr__ AttributeError Can't read __init__.py for plugin "BroadcastSender" Traceback (most recent call last) (941): File "C:\Program Files\EventGhost\eg\PluginTools.py", line 262, in GetPluginInfo File "plugins/BroadcastSender/__init__.py", line 25, in <module> File "C:\Program Files\EventGhost\eg\Init.py", line 285, in __getattr__ AttributeError
Not sure if that's an option for you to upgrade or not, but unfortunately is probably the only way it would work.
Thanks for all the kind words - a plugin like this that doesn't require complex handshaking or even check for a device to be on is very useful for certain things in my environment, and I'm glad to hear it sounds useul to someone else as well.
Using UDP is a nice idea, but actually I would like to stay with TCP/IP (because UDP won't work with Girder/Netremote). One approach to achieve a similar functionality would be to create some list of computer names in the Network Sender configuration dialog. There the user can define a bunch of single IPs and give them more readable names. The action dialog would then get a checkbox list with these names, where the user can enable/disable individual machines that should receive the event.
Sure you wouldn't want to have "a half dozen plugins" for networking, but TCP is not necessarily the answer. You definitely want to keep the secured handshaking girder compatible version too, but it doesn't solve every problem.
I'd also point out that there's not a lot of code releases coming from the devs at the moment, so I wouldn't recommend be too rough on those of us in the community that have come up with unique solutions unless you plan on sitting down and incorporating this directly in the product. The whole point of solutions like this is to be
open and flexible.
My post was not intended to offend you. I just wanted to collect ideas to get a "Network V2 Plugin" someday, that could supersede the current implementations of the Network plugins. For example Pako also had some ideas regarding the limited payload support of the protocol, that are surely missing in the current implementation. It is fine, if there is a plugin for every special case, but I like to unify things, so one plugin can solve many special cases.kingtd wrote:I'd also point out that there's not a lot of code releases coming from the devs at the moment, so I wouldn't recommend be too rough on those of us in the community that have come up with unique solutions unless you plan on sitting down and incorporating this directly in the product. The whole point of solutions like this is to be
open and flexible.
UDP absolutely has its elegance, because it uses little resources on multicast and it is easy and readable to implement. It would also be possible to add a "use UDP" checkbox to the current Network plugins for example and merge your code into them. But using multiple TCP requests with threading wouldn't be impossible I guess, since most users will never control more than a handful of machines in their setup. And it would have the benefit of a more "unified" way. But it might have a bad impact on CPU consumption for example that needs to be checked.
Pako made another enhancement request here.
There are also some modifications from owagner regarding bi-directional Netremote support, that need to be merged someday.
I had been using a custom Java command-line implementation that talked to my ISY-26, so if you've just got a standard PLC/PLM - my stuff isn't going to help you too much. I had tons of problems with reliability with the USB based PLC that I had, to the point where things would be broken more often than they were working.
Earlier today I posted my latest Insteon integration focus - the EventGhost plugin for the ISY-26. Probably doesn't help unless you own one, but so far for me it's been fantastic.
I added this pugin and everything worked correctly right off the bat, no settings I had to change. I have control of both computers again.
How do I broadcast an event that is a constantly changing variable (like tuner frequency or volume level)?
I was hoping it passed the event + payload intact.
For example, in my Onkyo plugin, I fire a MVL event and the payload is a hexidecimal string representing the volume level I want to jump to. Broadcaster doesn't transmit the payload instead sending the IP address of the sending computer's IP as the payload.