EventGhost

interesting. that leads me to think there may a problem with my plugin binding to a port in vista. unfortunately (or forunately depending on how you look at it ) i don't have vista to test with. but since the source code is there, maybe somebody can tweak it.

here's something fun i did using my xPL plugin, a SliMP3 music player, squeezecenter and an old tivo remote to control sagetv.

http://doghouselabs.blogspot.com/2009/0 ... d-xpl.html

That's really nice work,,,I would love to get such things a beautiful day and to make something similar. Currently I have Dreambox as sat receivers...and EG is not running on such a box

Besides, the Sage stuff doesn't seem to be that expensive either

I wonder if the Sage supports streaming from my Dreambox, then my sat receiver would still be useful

Best regards, Walter

somebody has gotten dreambox to work w/ sage according to the last post here: http://forums.sagetv.com/forums/showthread.php?t=36850

Damage,
I think that using EG & xPL would be cool to control home lighting (X-10). But, I have very complex scenes that I'd rather not try to hack out line by line. Is there any xPL gui based app that will allow you to setup complex scenes and timers, then EG can just trigger them?

thx

what do you currently use to set your lighting scenes?

I was using Homeseer 1.7 and changed to Girder 5 recently but the lighting scenes control is 'messy'. They may be fixing it soon, not sure.

If there is no easy way in EG that is fine. Girder is very powerful.

i am unaware of any xpl based gui that would help you. the only gui i know is mentioned here http://www.xpl-home.org/forums/viewtopic.php?t=788 but i haven't looked into it at all to know anything other than it's a gui.

I just took a short look at the current version of the plugin, regarding inclusion into the distribution with the installer. If you have a SourceForge account, PM me your account details and I can add you to the developer list, so you can update it directly on the SVN trunk.

Two things attracted my attention:
1. The plugin doesn't seem to shutdown properly or better say "not fast enough". I guess this is because your "main" Thread is blocking on the select.select call, so the mainThreadEvent can't be evaluated quick enough. One way around this might be to initiate a connection from your __stop__ method after you have set the mainThreadEvent, just to wake up the select.select loop.

2. You use multiple wx.TextCtrls to gather the xPL message from the user. Wouldn't it be easier and more flexible to just use a single multiline wx.TextCtrl for this?

Bitmonster wrote: 1. The plugin doesn't seem to shutdown properly or better say "not fast enough". I guess this is because your "main" Thread is blocking on the select.select call, so the mainThreadEvent can't be evaluated quick enough. One way around this might be to initiate a connection from your __stop__ method after you have set the mainThreadEvent, just to wake up the select.select loop.

2. You use multiple wx.TextCtrls to gather the xPL message from the user. Wouldn't it be easier and more flexible to just use a single multiline wx.TextCtrl for this?

the __stop__ method issues a "heartbeat stop" message. is that what you mean by initiating a connection?

i'll take a look at cleaning up TextCtrl.

thanks

No. The "SendHeartbeat" thread looks OK, because it is wait()-ing on the hbThreadEvent and therefore gets the change of the event immediately.

But the "main" thread might stay blocked, because select.select() only returns after something has changed on the sockets (or after the timeout of 60 seconds). And only after such a change it can detect mainThreadEvent.isSet(). So I suggest to create another socket in the __stop__ method, to connect to your self.UDPSock, just to wake up the select.select() call, so this thread can see the change of mainThreadEvent immediately. A smaller timeout for select is no real solution, as it only would uselessly consume CPU-cycles if set small enough (like under a second).

__stop__ looks like this: doesn't hbSock.sendto(msg,("255.255.255.255",3865)) qualify as making a connection? it's issuing the same kind of udp message the main thread is waiting to receive.

Not exactly (even though I have overlooked this piece of code). It is sending to the fixed port 3865 and not the self.port the self.UDPSock is listening to. So this doesn't trigger the self.UDPSock and therefore the select() doesn't terminate. (Tested on Vista32.)

BTW: Isn't it important for the users setup to have a fixed port for the UDP socket, as this is the port he has to setup all other xPL equipment to? So shouldn't this be a user option instead of finding the next free one by code?

an xPL hub listens on port 3865 and rebroadcasts the packet to all xpl listeners on the machine. each xPL app will bind to an unused port 50000 or higher and the hub will forward packets to those ports. ( http://wiki.xplproject.org.uk/index.php ... cification ). so xPL apps will send packets to port 3865 and the hub will retransmit to all apps on the machine @ ports 50000+. i think you don't have a hub installed ( http://www.xplmonkey.com/xplhub.html ).

damage wrote:i think you don't have a hub installed.

Actually I haven't installed any xPL thingy.
But now it makes sense. So you don't see this blocking, as actually your xPL hub is triggering the select loop. OK, but I think you should add another socket.sendto(... self.port)), just to make sure the plugin closes down nicely even if no hub is available.