EventGhost

Or it might be also working if you just call self.UDPSock.close() in __stop__ and catch the resulting error in the "main" loop. The .close() also seems to awake the select().

the plugin wouldn't function properly without a hub, but i see your point. i'll make changes when i get a chance. i don't have a sourceforge account but when i create one, i'll PM you.

Bitmonster wrote:

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.

i made this change & the multiline as well. http://doghouselabs.com/downloads/eg-xPL-0.1.zip let me know if that works for you.

this will break previous users' scripts and actions (sendxPL only takes 1 argument instead of 5) so backup your EG directory before you switch over to this.

There is one trick you can use to make it compatible with older configs:

1. Grab all remaining parameters with the "*" syntax: 2. Join them to the xPLMsg1: 3. Do the same for your Configure() before you feed it into the multiline TextCtrl.

sorry for the late reply, i was on vacation for a few days. i'm tempted to leave it as it is now. i don't know if there's many people actually using the plugin... if anybody objects to rewriting their scripts, etc (as mentioned here http://www.eventghost.org/forum/viewtop ... 8108#p8108 ) that depend on this plugin, please speak up now.

I'm using the latest version you made and I changed my scripts. For me it works ok as is but I did not have too much to "migrate"

Best regards, Walter

Some time ago, I did write a plugin for the Velleman K8055 experimental board. For those interested, I have found there is also a xPL service for it available here

http://www.xplmonkey.com/k8055.html

It worked at once with your xPL plugin when I installed and configured it

Best regards, Walter

I just noticed two little problems with the current code:

1. The socket is bound in the __init__ method. Please do any "hot" code, only in the __start__ method, as __init__ is called even if the user actually doesn't want to add the plugin. And after disabling the plugin, it should leave the system in a state that is identical to not using the plugin. So the socket should be unbound in the __stop__ method.

2. There are some unneeded print statements.

And we have a new SVN server: http://www.eventghost.org/forum/viewtop ... 8474#p8474

i've finally gotten around to updating the plugin with your suggestions. new code here:
http://www.doghouselabs.com/downloads/eg-xPL-0.2.zip

i'll have to figure out SVN when i get some free cycles. thanks.

messed something up in the previous version & was on vacation so i just found out about it. sorry about that.

new plugin code here http://www.doghouselabs.com/downloads/eg-xPL-0.2.1.zip

if you find this useful, click on some ads on my site or blog. thanks!

Hi damage,

I modified your plug-in a little bit. I added a new action that allows you to catch xPL messages from specifed sender and then create an EG event with desired name. It is based partly on the python script you once provided.

For me it works simpler to have possibilities to add actions for different xPL messages instead of creating/editing python scripts for each and every sender/event

Hope you can accept my proposal,

Best regards, Walter

Walter,

not quite sure i understand what you need to add this for. can't you drag xpl messages from the log window to the right side to make macros that trigger on those events?

Hi,
Yes, basically you are right, this is what I could do and the end function would be the same

The action is just allowing me to organize the structure and configuration work a bit different
- assume I already have a lot of macros (with defined actions and events inside)
- I get a better overview of what xPL messages are affecting (collecting them in one specific place)
- I do not have to test the xPL messages during configuration
- mapping xPL messages to my internally already defined (and to me well known) event names
- most important, it handles xPL message sent from various devices/locations (xPL messages looks different when I send them from various devices like my mobile and from my computer at work)

But that's all, the other (default) way is of course also working

Best regards, Walter

Hello,

I would like to thank damage for his work, and warn everybody that some rules from the XPL protocol are broken, therefore I had to change some things within the script for it to work with the Domogik software :

- The source is currently :
Two problems :

First : "doghouse" is not a valid vendor ID (check here), so it is not seen by some apps. I had to revert it back to the default value : "xpl".
Second : all characters must be lowercase

So your plugin should be changed to
(or you can ask for a vendor id at xplproject.org)

These are minor changes but it took me some time to find what was wrong, so I hope you will update your useful plugin.

doghouse is a valid vendor id. Ian at the xplproject already approved it several years ago. the list you are referring to are vendors that supply xml files for use with xPLHal, which i don't. i no longer support this plugin and haven't for a number of years as i've stopped using EG, and i don't think it works with the new fork of EG anyway.