From: Michel v. O. <mi...@bi...> - 2004-05-23 22:30:08
|
Hi, > I'm looking for a XAP Hub for linux. I read that that I could > download it here: http://patrick.lidstone.net/ This site has been > down for the last days. Does anybody have a copy for me? The website is up again and I found out that this is already incorporated= in Mister House. Which is very nice offcourse :) I'm trying to get Mister House and xPLHal to work together but I can't he= t it running. I do have a couple of machines talking to each other and ev= en a link with my Home Vision Pro. Can anyone get me started here? I would like Mister House to talk to the = Home Vision Pro over xap of xpl. Michel > > Yours sincerely, > Michel van Osenbruggen > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g= . > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id149&alloc_id?66&op=CC=AB > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?grou= p_id=1365 > > > -- Met vriendelijke groet, BIT BV, Michel van Osenbruggen |
From: Michel v. O. <mi...@bi...> - 2004-05-24 06:56:00
|
Hi Greg, > xPLHal listens on the xpl port 3865. Currently, mh's xAP > and xPL classes listen on the same port--originally defined for > xAP (3639). That explains :-) Thanks for the enlightment! > If xPL is all that you really want, then consider redefining your > xpl port in your parms file as xap_port=3D3865 (be forewarned--I've > not tried this). I will try it. > The most obvious downside is that the two protocols are > currently tied to the same port (inside mh); so--doing this would > mean ceasing your ability to communicate w/ xAP apps. That is indeed a downside. Wouldn't it be wiser then to make xpl and xap = in Mister House run on different ports? I suppose that the port xPLHal us= es is the standard for xpl? Michel > > Gregg > > > Quoting Michel van Osenbruggen (5/23/04 6:33 PM): > > Hi, > > > > > >>I'm looking for a XAP Hub for linux. I read that that I could > >>download it here: http://patrick.lidstone.net/ This site has been > >>down for the last days. Does anybody have a copy for me? > > > > > > The website is up again and I found out that this is already incorpor= ated in Mister House. Which is very nice offcourse :) > > > > I'm trying to get Mister House and xPLHal to work together but I can'= t het it running. I do have a couple of machines talking to each other an= d even a link with my Home Vision Pro. > > > > Can anyone get me started here? I would like Mister House to talk to = the Home Vision Pro over xap of xpl. > > > > Michel > > > > > > > >>Yours sincerely, > >>Michel van Osenbruggen > >> > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by: Oracle 10g > >>Get certified on the hottest thing ever to hit the market... Oracle 1= 0g. > >>Take an Oracle 10g class now, and we'll give you the exam FREE. > >>http://ads.osdn.com/?ad_id149&alloc_id?66&op=CC=AB > >>________________________________________________________ > >>To unsubscribe from this list, go to: http://sourceforge.net/mail/?gr= oup_id=1365 > >> > >> > >> > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g= . > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id149&alloc_id?66&op=CC=AB > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?grou= p_id=1365 > > > -- Met vriendelijke groet, BIT BV, Michel van Osenbruggen |
From: Michel v. O. <mi...@bi...> - 2004-05-24 19:15:33
|
Him > classes listen on the same port--originally defined for xAP (3639). > If xPL is all that you really want, then consider redefining your > xpl port in your parms file as xap_port=3D3865 (be forewarned--I've > not tried this). But it does work :) Another problem though is that xPLHal doesn't know th= e Misterhouse scheme and therefor doesn't accept messages from it. Could = someone encourage the developer to support Mister House :-) -- Met vriendelijke groet, BIT BV, Michel van Osenbruggen |
From: Bruce W. <br...@mi...> - 2004-05-29 14:00:57
|
> > classes listen on the same port--originally defined for xAP (3639). > > If xPL is all that you really want, then consider redefining your > > xpl port in your parms file as xap_port=3D3865 (be forewarned--I've > > not tried this). =20 >=20 > But it does work :) Another problem though is that xPLHal doesn't=20 > know the Misterhouse scheme and therefor doesn't accept messages=20 > from it. Could someone encourage the developer to support Mister House = :-) This might be more of a MisterHouse issues. I've used and debuged a = number of xAP/xPL clients that SEND data to mh, but not many that = RECEIVE data from mh. It could be the syntax of the data packet needs = to debuged a bit. =20 What kind of data were you trying to send from mh? Some things like X10 = and callerid have schemes already defined, so all we should have to do = is match up to that. Other things we would need to come up with a = scheme and have xPLHal support it. Also, the uid mh defaults to is a generic FF123400, not one that = officially designates the source of the data as mh. Now that we have = some interest and users of the xAP and xPL data, I'll apply for official = xAP and xPL uids we can use. =20 Bruce |
From: Ian L. <ia...@wi...> - 2004-05-29 16:17:01
|
Hi Bruce, (and hello list, as this is my first post here)=20 I'm one of the xPL team, and just signed up here to see if we can help - Misterhouse already has an xPL Vendor ID assigned - MHOUSE, this is used in the Source and target fields of the xPL message. It's worth getting some separation in place between xAP and xPL - we forked from the xAP project over 18 months ago and the protocols have separated far enough that they need to be handled (both in protocol terms, and in operation) separately. xPL has an IANA assigned port - 3865, and doesn't have the concept of a UID (our message header is much simpler) To integrate with existing systems, we do need an XML vendor description file for Misterhouse - the various configuration and scripting tools all use this xml description to identify the commands accepted by an app, and the triggers that it can generate. I have to confess to not knowing much about MH, but I'd imagine that the xml fragments we already have in place for xPL devices would be of use in integration with MH. I'm happy to spend some time getting MH's xPL support up to scratch using the currently defined Schemas. Ian. -----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Bruce Winter Sent: 29 May 2004 15:16 To: mis...@li... Subject: RE: [misterhouse-users] XAP Hub website down > > classes listen on the same port--originally defined for xAP (3639). > > If xPL is all that you really want, then consider redefining your > > xpl port in your parms file as xap_port=3D3865 (be forewarned--I've > > not tried this). =20 >=20 > But it does work :) Another problem though is that xPLHal doesn't=20 > know the Misterhouse scheme and therefor doesn't accept messages=20 > from it. Could someone encourage the developer to support Mister House :-) This might be more of a MisterHouse issues. I've used and debuged a number of xAP/xPL clients that SEND data to mh, but not many that RECEIVE data from mh. It could be the syntax of the data packet needs to debuged a bit. =20 What kind of data were you trying to send from mh? Some things like X10 and callerid have schemes already defined, so all we should have to do is match up to that. Other things we would need to come up with a scheme and have xPLHal support it. Also, the uid mh defaults to is a generic FF123400, not one that officially designates the source of the data as mh. Now that we have some interest and users of the xAP and xPL data, I'll apply for official xAP and xPL uids we can use. =20 Bruce |
From: Bruce W. <br...@mi...> - 2004-05-30 23:41:36
|
> Hi Bruce, (and hello list, as this is my first post here) > > I'm one of the xPL team, and just signed up here to see if we can help - Good deal! > Misterhouse already has an xPL Vendor ID assigned - MHOUSE, this is used > in the Source and target fields of the xPL message. Ok, good deal. Will use MHOUSE > It's worth getting some separation in place between xAP and xPL - we > forked from the xAP project over 18 months ago and the protocols have > separated far enough that they need to be handled (both in protocol > terms, and in operation) separately. > > xPL has an IANA assigned port - 3865, and doesn't have the concept of a > UID (our message header is much simpler) I think I have both protocols covered, sharing as much common code as possible. We have both xAP_Item and xPL_Item objects. Here are 2 examples from code/common/test_xap.pl: $outside_light_xap = new xAP_Item( 'xap-x10.request', '*', 'xap-x10.request' => {command => '$state', device => 'A1'}); $outside_light_xpl = new xPL_Item( 'ACME-LAMP.outside', 'lamp.basic' => {action => '$state'}); So currently it is set up so both protocol are controled and monitored from the same port. So for if you are mostly using xPL, you can change that port to 3865 and override any xAP clients you might want to use to use the 3865 port. Or we could maybe update the code to monitor both ports separately, although that would be a bit more code. > To integrate with existing systems, we do need an XML vendor description > file for Misterhouse - the various configuration and scripting tools all > use this xml description to identify the commands accepted by an app, > and the triggers that it can generate. > > I have to confess to not knowing much about MH, but I'd imagine that the > xml fragments we already have in place for xPL devices would be of use > in integration with MH. > > I'm happy to spend some time getting MH's xPL support up to scratch > using the currently defined Schemas. Ok, thanks for the offer! Any other xPL users want to get this working? Bruce |
From: John G. <joh...@ho...> - 2004-05-31 09:22:00
|
>>I'm happy to spend some time getting MH's xPL support up to scratch >>using the currently defined Schemas. > > > Ok, thanks for the offer! Any other xPL users want to get this working? I am preparing for getting my home automation setup and will be using a Linux box. As MH will be the first home automation controller using XPL under linux this would be a fantastic plus point of MH. Whilst I won't be able to help getting XPl and MH working (as I don't even know how to control MH yet!) I think this would increase the userbase of MH as there are always people asking on forums if there is a linux based XPL controller. Cheers |
From: Jim F. <fl...@co...> - 2004-05-31 00:33:33
|
----- Original Message ----- From: "Ian Lowe" To: <mis...@li...> Sent: Saturday, May 29, 2004 12:18 PM Subject: RE: [misterhouse-users] XAP Hub website down >It's worth getting some separation in place between xAP and xPL - we >forked from the xAP project over 18 months ago and the protocols have >separated far enough that they need to be handled (both in protocol >terms, and in operation) separately. Can you tell us or point us to a web page that talks about the differences between xAP and xPL and why they forked? Also, are there situations were xAP or xPL is a better fit? Thanks Jim |
From: Ian L. <ia...@wi...> - 2004-05-31 09:56:36
|
-----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Jim Flagg >Can you tell us or point us to a web page that talks about the differences >between xAP and xPL and why they forked? Also, are there situations were >xAP or xPL is a better fit? There isn't a page with that sort of description (yet) - both xAP and xPL have been developed in the main by members of the UKHA community, and there's still enough general bad feeling about the fork (and the arguments that lead up to it) that serious discussions about the technical reasons for the split tend to disintegrate.=20 In order to maintain good spirit in the community, we (both sides) have had to essentially bite our tongues. It's not necessarily a bad thing, as it has forced us to become more "results oriented". That being said, I'll summarise the xPL position here - xAP went through a few revisions as the concept was originally thrashed out - the key version of the protocol specification being the v0.9 document. Development from this point resulted in the v1.2 protocol document - which was largely unacceptable to those of us who went on to become the xPL team. xAP (and xPL) have similar semantics - messages are in human readable ASCII text, and the messages are enclosed in { } braces. The key differences are - 1) Distinct message types - to xAP, all messages are created equal - a message's intent can only be determined by fully parsing it. Within xPL, three specific message types exist xpl_cmnd, xpl_trig and xpl_stat. A message can be a command to a device (or group of devices), a trigger indicating a state change, or a status update (with info such as temperature etc). A single byte test (byte 5 of the xPL message =3D c, s or t) can determine the message intent. 2) Strict Header - The elements within an xPL message header are fixed order, and only these elements (hopcount, source device, target device) can be present. In contrast, xAP allows developer added fields to be placed in the header. xPLs view the header as an addressing block, xAP views it as "frequently used info" 3) Size limits - structural elements are tightly size limited in xPL - to keep message size down, and also to assist Microcontrollers in parsing the protocol. In "item=3Dvalue" tags, the "item" name cannot be longer than 16 bytes. xAP places no restriction on this length, essentially making every element delimited. 4) Character Set - only lower case Alphanumeric characters are permissible as structural elements in an xPL message. xAP used to allow pretty much any character, apart from the actual delimiters, making for some pretty awkward device names. (note: this was the case until about 8 months ago, it appears to have been changed, but the xAP protocol document remains at v1.2) 5) Message Body - xPL messages have two sections - header, and data, also viewable as address and payload. xAP supports multiple message bodies, that may, or may not, contain the same sort of information, or be "intended" for the same device. 6) "Pure Broadcast" vs "Targetting" - which brings us nicely to one of the key issues to cause the split between xAP and xPL. The fact that both protocols use UDP datagrams on Ethernet (inherently a broadcast environment) has lead to the statement by xAP developers that "it's all broadcast anyway".=20 Whereas a xAP message is supposedly sent with no intent and simply broadcast into the ether for whoever wants it (in theory, all xAP messages are simply status messages, and nodes are pre-programmed to react to given messages/message types/source addresses etc), xPL makes a distinction between status, triggers and commands. =20 xPL uses the contents of the header target address to determine how to handle a given message - "if a message is targeted at me, I must act on it, if it is broadcast, I may act on it, if it is targeted at someone else, I must not act on it". I say "supposedly" because it's pretty clear that you quite often *want* to send a message to a specific device, and that some messages are placed on the wire with the specific intention of being acted on by a given device. The "Target=3D" element within a xAP message is optional (and tellingly, most of the examples within the xAP protocol document do not have it included). The xPL developers felt that a non mandatory "target" field (developers do not have to even implement it) weakened the protocol immensely. 7) End node intelligence, vs Central Network intelligence - a further issue was the overall design philosophy - xPL unashamedly states that a centralised intelligence on the network is needed - xplHal performs this function, although other systems (such as MH) could easily do so. xPL end nodes send status messages and triggers, and act on commands - an intelligence on the network acts on the status/triggers and issues commands. xAP adopts a distributed intelligence model - end nodes are responsible for all processing decisions.=20 Take the example of a display oriented environment - you have several LCD displays around the house, an OSD for your video feed, a popup application on your PC desktop - you wish to add a new information source to this environment.=20 In xPL, you install your new info source, then configure xPLHal to send the information received to each of the display devices using a script. If you wish to add additional factors, such as time of day or occupancy, you simply script these in. Also, if you wish to reformat the data, it's trivial to do so, and send different versions of the data to different devices. In xAP, if you wish every device to display the information exactly as it comes from the new device, you do nothing - it will appear everywhere at once. If you prefer a more intelligent behaviour, then each end node must be configured individually to react to only certain messages. If you want the end nodes to react to certain messages at certain times (ie, daytime/nightime), then each end node must support the functionality you wish to use as a criterion. In practice it's very difficult to get a xAP node to react one way to given message at a given time, and another way at others. Similarly, sending differently formatted data to each device requires the end node to be configured each time. This list isn't exhaustive, but it's a good starting position. I guess the final key difference to mention is the open source angle - all of the development frameworks produced by the xPL team (and indeed the protocol document itself) are released under the lesser GPL. xAP otoh has "no commercial use" clauses on much of the released code.=20 On the issue of suitability, you must remember that I'm partisan, and therefore biased. That being said, I think Occam's Razor applies -=20 "Of two equivalent theories or explanations, all other things being equal, the simpler one is to be preferred." We have found nothing within the HA environment that can be done with xAP, that cannot be done equally as well (and usually better) by xPL, with the benefits of more compact and strict messages. Ian. PS> If the ole "spidey sense" is working, there'll be a xAP developer along in about 2ms to explain why this is wrong, and xAP is actually the better protocol to use ;) |
From: Gregg L. <gr...@li...> - 2004-05-24 02:43:51
|
Michel, xPLHal listens on the xpl port 3865. Currently, mh's xAP and xPL classes listen on the same port--originally defined for xAP (3639). If xPL is all that you really want, then consider redefining your xpl port in your parms file as xap_port=3D3865 (be forewarned--I've not tried this). The most obvious downside is that the two protocols are currently tied to the same port (inside mh); so--doing this would mean ceasing your ability to communicate w/ xAP apps. Gregg Quoting Michel van Osenbruggen (5/23/04 6:33 PM): > Hi, >=20 >=20 >>I'm looking for a XAP Hub for linux. I read that that I could >>download it here: http://patrick.lidstone.net/ This site has been >>down for the last days. Does anybody have a copy for me? >=20 >=20 > The website is up again and I found out that this is already incorporat= ed in Mister House. Which is very nice offcourse :) >=20 > I'm trying to get Mister House and xPLHal to work together but I can't = het it running. I do have a couple of machines talking to each other and = even a link with my Home Vision Pro.=20 >=20 > Can anyone get me started here? I would like Mister House to talk to th= e Home Vision Pro over xap of xpl.=20 >=20 > Michel >=20 >=20 >=20 >>Yours sincerely, >>Michel van Osenbruggen >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: Oracle 10g >>Get certified on the hottest thing ever to hit the market... Oracle 10g= .=20 >>Take an Oracle 10g class now, and we'll give you the exam FREE. >>http://ads.osdn.com/?ad_id149&alloc_id?66&op=CC=AB >>________________________________________________________ >>To unsubscribe from this list, go to: http://sourceforge.net/mail/?grou= p_id=1365 >> >> >> >=20 >=20 |