From: George C. <ge...@fe...> - 2014-02-22 16:34:49
|
Hi all, I'm trying and failing to understand the xPL basics. I'm trying to define a basic sensor with the states on/off controlled by xPL messages. Can anyone point to an example of configuring a sensor and sending a simple on/off to it? Or give me an idea of what I'm doing wrong here? The examples in the wiki and common code files are mostly related to interfacing to existing devices, and suggest working backwards from captured messages. But I don't have an existing device to capture. Thanks, George # XPL_SENSOR, <xpl_address>:<device_id>, <mh_item_name>, <mh_grouplist>, <sensor_type> XPL_SENSOR, arduino-test.basement:1, test_1, Sensors, input and a bit of user code: if ($test_1->state_now) { print_log "========== test_1 state=$state"; } And I'm trying to set the state by sending xPL messages from a message generator script. Usage: sendxplmsg.py <msg_type> <target> <schema> <body> sendxplmsg.py "arduino-basement:1" "*" sensor.basic "name=\$test_1\\ndevice=1\\nstate=on" I've tried sensor.basic, control.basic, and various combinations of state, current, and other settings. I'm just not understanding something somewhere, and I'm running out of ideas. If I set debug xpl to 4, I can see the message come in and be parsed, but it doesn't tie back to the item. Here is the message with the source section named for the source. When I send the message this way, the source doesn't appear to get picked up, so the parse routine returns a null source. I've also tried changing the message type to xpl-stat. That seems to get a little closer as it picks up the source, but it still doesn't tie to the item. Below are debug messages from several different attempts. (I added some debug prints to the db4 parse code, to show the section being parsed, and at the end, the data being returned to the caller: db4 xPL data: arduino-test.basement { hop=1 source=arduino-test.basement target=* } control.basic { name=$test_1 device=1 current=on } Switch to section arduino-test.basement db4 xpl parsed c=arduino-test.basement k=hop v=1 db4 xpl parsed c=arduino-test.basement k=source v=arduino-test.basement db4 xpl parsed c=arduino-test.basement k=target v=* Switch to section control.basic db4 xpl parsed c=control.basic k=name v=$test_1 db4 xpl parsed c=control.basic k=device v=1 db4 xpl parsed c=control.basic k=current v=on XPL - from source: , class control.basic target *, type arduino-test.basement db4 xPL data: xpl-stat { hop=1 source=arduino-test.basement:1 target=* } sensor.basic { name=$test_1 device=1 current=on } Switch to section xpl-stat db4 xpl parsed c=xpl-stat k=hop v=1 db4 xpl parsed c=xpl-stat k=source v=arduino-test.basement:1 db4 xpl parsed c=xpl-stat k=target v=* Switch to section sensor.basic db4 xpl parsed c=sensor.basic k=name v=$test_1 db4 xpl parsed c=sensor.basic k=device v=1 db4 xpl parsed c=sensor.basic k=current v=on XPL - from source: arduino-test.basement:1, class sensor.basic target *, type xpl-stat hdb4 xPL data: xpl-stat { hop=1 source=arduino-test.basement:1 target=* } control.basic { name=$test_1 device=1 current=on } Switch to section xpl-stat db4 xpl parsed c=xpl-stat k=hop v=1 db4 xpl parsed c=xpl-stat k=source v=arduino-test.basement:1 db4 xpl parsed c=xpl-stat k=target v=* Switch to section control.basic db4 xpl parsed c=control.basic k=name v=$test_1 db4 xpl parsed c=control.basic k=device v=1 db4 xpl parsed c=control.basic k=current v=on XPL - from source: arduino-test.basement:1, class control.basic target *, type xpl-stat |
From: Johan B. <lis...@ce...> - 2014-02-25 20:12:29
|
Hi there, I use xPL and it should work with MisterHouse. First check if the IP address of MisterHouse and the broadcast address for your network is defined correctly in your mh-private.ini file and xPL is enabled. I think this is OK for you, but checking again doesn't hurt. ;-) See http://misterhouse.wikispaces.com/xAP+and+xPL+-+Getting+Started Do you use/need an xPL hub on your network? I don't know about the script that generates your xPL messages, but xPL is very picky about newlines. There should be a newline at the very end of your xPL message. Secondly, here is something that works: Please note that my definitions are a little different. The problem might be that MisterHouse refuses to parse your messages as they seem to come from the same source that is a target within MisterHouse. (This is just a guess as it has been a long time since I checked the code.) Item definition: XPL_SENSOR, bnz-nc.*:WindGustSpeed, OW_WindGustSpeed, , input xPL message in network: 21:00:01.252109 IP 192.168.42.5.40461 > 192.168.42.255.3865: UDP, length 111 0x0000: 4500 008b cf49 4000 4011 94c3 c0a8 2a05 E....I@.@.....*. 0x0010: c0a8 2aff 9e0d 0f19 0077 d6dd 7870 6c2d ..*......w..xpl- 0x0020: 7374 6174 0a7b 0a68 6f70 3d31 0a73 6f75 stat.{.hop=1.sou 0x0030: 7263 653d 626e 7a2d 6e63 2e64 6f6d 7573 rce=bnz-nc.domus 0x0040: 0a74 6172 6765 743d 2a0a 7d0a 7365 6e73 .target=*.}.sens 0x0050: 6f72 2e62 6173 6963 0a7b 0a64 6576 6963 or.basic.{.devic 0x0060: 653d 5769 6e64 4775 7374 5370 6565 640a e=WindGustSpeed. 0x0070: 7479 7065 3d69 6e70 7574 0a63 7572 7265 type=input.curre 0x0080: 6e74 3d33 342e 3233 0a7d 0a nt=34.23.}. Best regards, Johan Braeken. Quoting George Clark <ge...@fe...>: > Hi all, > > I'm trying and failing to understand the xPL basics. I'm trying to > define a basic sensor with the states on/off controlled by xPL messages. > > Can anyone point to an example of configuring a sensor and sending a > simple on/off to it? Or give me an idea of what I'm doing wrong > here? The examples in the wiki and common code files are mostly > related to interfacing to existing devices, and suggest working > backwards from captured messages. But I don't have an existing device > to capture. > > Thanks, > George > > > # XPL_SENSOR, <xpl_address>:<device_id>, <mh_item_name>, <mh_grouplist>, > <sensor_type> > XPL_SENSOR, arduino-test.basement:1, test_1, Sensors, input > > and a bit of user code: > > if ($test_1->state_now) { > print_log "========== test_1 state=$state"; > } > > > And I'm trying to set the state by sending xPL messages from a message > generator script. > > Usage: sendxplmsg.py <msg_type> <target> <schema> <body> > > sendxplmsg.py "arduino-basement:1" "*" sensor.basic > "name=\$test_1\\ndevice=1\\nstate=on" > > I've tried sensor.basic, control.basic, and various combinations of > state, current, and other settings. I'm just not understanding > something somewhere, and I'm running out of ideas. If I set debug xpl > to 4, I can see the message come in and be parsed, but it doesn't tie > back to the item. > > Here is the message with the source section named for the source. When > I send the message this way, the source doesn't appear to get picked > up, so the parse routine returns a null source. I've also tried > changing the message type to xpl-stat. That seems to get a little > closer as it picks up the source, but it still doesn't tie to the > item. Below are debug messages from several different attempts. > > (I added some debug prints to the db4 parse code, to show the section > being parsed, and at the end, the data being returned to the caller: > > db4 xPL data: > arduino-test.basement > { > hop=1 > source=arduino-test.basement > target=* > } > control.basic > { > name=$test_1 > device=1 > current=on > } > > Switch to section arduino-test.basement > db4 xpl parsed c=arduino-test.basement k=hop v=1 > db4 xpl parsed c=arduino-test.basement k=source v=arduino-test.basement > db4 xpl parsed c=arduino-test.basement k=target v=* > Switch to section control.basic > db4 xpl parsed c=control.basic k=name v=$test_1 > db4 xpl parsed c=control.basic k=device v=1 > db4 xpl parsed c=control.basic k=current v=on > XPL - from source: , class control.basic target *, type > arduino-test.basement > > > > db4 xPL data: > xpl-stat > { > hop=1 > source=arduino-test.basement:1 > target=* > } > sensor.basic > { > name=$test_1 > device=1 > current=on > } > > Switch to section xpl-stat > db4 xpl parsed c=xpl-stat k=hop v=1 > db4 xpl parsed c=xpl-stat k=source v=arduino-test.basement:1 > db4 xpl parsed c=xpl-stat k=target v=* > Switch to section sensor.basic > db4 xpl parsed c=sensor.basic k=name v=$test_1 > db4 xpl parsed c=sensor.basic k=device v=1 > db4 xpl parsed c=sensor.basic k=current v=on > XPL - from source: arduino-test.basement:1, class sensor.basic target > *, type xpl-stat > > > > > > > hdb4 xPL data: > xpl-stat > { > hop=1 > source=arduino-test.basement:1 > target=* > } > control.basic > { > name=$test_1 > device=1 > current=on > } > > Switch to section xpl-stat > db4 xpl parsed c=xpl-stat k=hop v=1 > db4 xpl parsed c=xpl-stat k=source v=arduino-test.basement:1 > db4 xpl parsed c=xpl-stat k=target v=* > Switch to section control.basic > db4 xpl parsed c=control.basic k=name v=$test_1 > db4 xpl parsed c=control.basic k=device v=1 > db4 xpl parsed c=control.basic k=current v=on > XPL - from source: arduino-test.basement:1, class control.basic target > *, type xpl-stat > > > > > > > > > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: > https://lists.sourceforge.net/lists/listinfo/misterhouse-users |
From: George C. <ge...@fe...> - 2014-02-25 20:23:22
|
Hi Johan, Thanks! I'll do a bit more testing, you've given me a few things to try. I don't doubt that it works. I'm just not finding the right combination. I'm running mh with the built in hub, and the xpl debug level 4 is showing that the messages appear to be successfully parsed. My production mh server also logs the messages, so the broadcast seems to be getting out on the net. I'm just not getting them to tie back to the defined object. Your comment about the source is interesting. I was running mh and the test script on the same laptop - easier to test that way. I'll separate them onto separate systems. And I'll see about using a different test tool as well just in case the one I found has issues. I've definitely gone through the wiki - including the getting started and some of the other examples. Thanks, George On 02/25/2014 03:12 PM, Johan Braeken wrote: > Hi there, > > > I use xPL and it should work with MisterHouse. > > > First check if the IP address of MisterHouse and the broadcast address > for your network is defined correctly in your mh-private.ini file and > xPL is enabled. > I think this is OK for you, but checking again doesn't hurt. ;-) > > See http://misterhouse.wikispaces.com/xAP+and+xPL+-+Getting+Started > > > Do you use/need an xPL hub on your network? > > > I don't know about the script that generates your xPL messages, but > xPL is very picky about newlines. > There should be a newline at the very end of your xPL message. > > > Secondly, here is something that works: > Please note that my definitions are a little different. > > The problem might be that MisterHouse refuses to parse your messages > as they seem to come from the same source that is a target within > MisterHouse. (This is just a guess as it has been a long time since I > checked the code.) > > > Item definition: > XPL_SENSOR, bnz-nc.*:WindGustSpeed, OW_WindGustSpeed, , input > > xPL message in network: > 21:00:01.252109 IP 192.168.42.5.40461 > 192.168.42.255.3865: UDP, length 111 > 0x0000: 4500 008b cf49 4000 4011 94c3 c0a8 2a05 E....I@.@.....*. > 0x0010: c0a8 2aff 9e0d 0f19 0077 d6dd 7870 6c2d ..*......w..xpl- > 0x0020: 7374 6174 0a7b 0a68 6f70 3d31 0a73 6f75 stat.{.hop=1.sou > 0x0030: 7263 653d 626e 7a2d 6e63 2e64 6f6d 7573 rce=bnz-nc.domus > 0x0040: 0a74 6172 6765 743d 2a0a 7d0a 7365 6e73 .target=*.}.sens > 0x0050: 6f72 2e62 6173 6963 0a7b 0a64 6576 6963 or.basic.{.devic > 0x0060: 653d 5769 6e64 4775 7374 5370 6565 640a e=WindGustSpeed. > 0x0070: 7479 7065 3d69 6e70 7574 0a63 7572 7265 type=input.curre > 0x0080: 6e74 3d33 342e 3233 0a7d 0a nt=34.23.}. > > > > Best regards, > > Johan Braeken. > > Quoting George Clark <ge...@fe...>: > >> Hi all, >> >> I'm trying and failing to understand the xPL basics. I'm trying to >> define a basic sensor with the states on/off controlled by xPL messages. >> >> Can anyone point to an example of configuring a sensor and sending a >> simple on/off to it? Or give me an idea of what I'm doing wrong >> here? The examples in the wiki and common code files are mostly >> related to interfacing to existing devices, and suggest working >> backwards from captured messages. But I don't have an existing device >> to capture. >> >> Thanks, >> George >> >> >> # XPL_SENSOR, <xpl_address>:<device_id>, <mh_item_name>, <mh_grouplist>, >> <sensor_type> >> XPL_SENSOR, arduino-test.basement:1, test_1, Sensors, input >> >> and a bit of user code: >> >> if ($test_1->state_now) { >> print_log "========== test_1 state=$state"; >> } >> >> >> And I'm trying to set the state by sending xPL messages from a message >> generator script. >> >> Usage: sendxplmsg.py <msg_type> <target> <schema> <body> >> >> sendxplmsg.py "arduino-basement:1" "*" sensor.basic >> "name=\$test_1\\ndevice=1\\nstate=on" >> >> I've tried sensor.basic, control.basic, and various combinations of >> state, current, and other settings. I'm just not understanding >> something somewhere, and I'm running out of ideas. If I set debug xpl >> to 4, I can see the message come in and be parsed, but it doesn't tie >> back to the item. >> >> Here is the message with the source section named for the source. When >> I send the message this way, the source doesn't appear to get picked >> up, so the parse routine returns a null source. I've also tried >> changing the message type to xpl-stat. That seems to get a little >> closer as it picks up the source, but it still doesn't tie to the >> item. Below are debug messages from several different attempts. >> >> (I added some debug prints to the db4 parse code, to show the section >> being parsed, and at the end, the data being returned to the caller: >> >> db4 xPL data: >> arduino-test.basement >> { >> hop=1 >> source=arduino-test.basement >> target=* >> } >> control.basic >> { >> name=$test_1 >> device=1 >> current=on >> } >> >> Switch to section arduino-test.basement >> db4 xpl parsed c=arduino-test.basement k=hop v=1 >> db4 xpl parsed c=arduino-test.basement k=source v=arduino-test.basement >> db4 xpl parsed c=arduino-test.basement k=target v=* >> Switch to section control.basic >> db4 xpl parsed c=control.basic k=name v=$test_1 >> db4 xpl parsed c=control.basic k=device v=1 >> db4 xpl parsed c=control.basic k=current v=on >> XPL - from source: , class control.basic target *, type >> arduino-test.basement >> >> >> >> db4 xPL data: >> xpl-stat >> { >> hop=1 >> source=arduino-test.basement:1 >> target=* >> } >> sensor.basic >> { >> name=$test_1 >> device=1 >> current=on >> } >> >> Switch to section xpl-stat >> db4 xpl parsed c=xpl-stat k=hop v=1 >> db4 xpl parsed c=xpl-stat k=source v=arduino-test.basement:1 >> db4 xpl parsed c=xpl-stat k=target v=* >> Switch to section sensor.basic >> db4 xpl parsed c=sensor.basic k=name v=$test_1 >> db4 xpl parsed c=sensor.basic k=device v=1 >> db4 xpl parsed c=sensor.basic k=current v=on >> XPL - from source: arduino-test.basement:1, class sensor.basic target >> *, type xpl-stat >> >> >> >> >> >> >> hdb4 xPL data: >> xpl-stat >> { >> hop=1 >> source=arduino-test.basement:1 >> target=* >> } >> control.basic >> { >> name=$test_1 >> device=1 >> current=on >> } >> >> Switch to section xpl-stat >> db4 xpl parsed c=xpl-stat k=hop v=1 >> db4 xpl parsed c=xpl-stat k=source v=arduino-test.basement:1 >> db4 xpl parsed c=xpl-stat k=target v=* >> Switch to section control.basic >> db4 xpl parsed c=control.basic k=name v=$test_1 >> db4 xpl parsed c=control.basic k=device v=1 >> db4 xpl parsed c=control.basic k=current v=on >> XPL - from source: arduino-test.basement:1, class control.basic target >> *, type xpl-stat >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Managing the Performance of Cloud-Based Applications >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >> ________________________________________________________ >> To unsubscribe from this list, go to: >> https://lists.sourceforge.net/lists/listinfo/misterhouse-users > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users > |
From: Joel D. <jr...@pr...> - 2014-02-25 20:28:32
|
George- I can't remember who said it, but a while back someone suggested that we NOT use the built-in hub in mh, and recommended a different one. I took a quick look through my saved emails and I can't find the note, but you may want to doublecheck on the wiki or in the archives. Good luck. I'm interested to hear about your progress as I want to move some stuff in the direction of xpl as soon as I get some time. Whenever that is... Joel On Tue, 25 Feb 2014, it would appear that George Clark wrote: > Hi Johan, > > Thanks! I'll do a bit more testing, you've given me a few things to > try. I don't doubt that it works. I'm just not finding the right > combination. > > I'm running mh with the built in hub, and the xpl debug level 4 is > showing that the messages appear to be successfully parsed. My > production mh server also logs the messages, so the broadcast seems to > be getting out on the net. I'm just not getting them to tie back to the > defined object. > > Your comment about the source is interesting. I was running mh and the > test script on the same laptop - easier to test that way. I'll separate > them onto separate systems. And I'll see about using a different test > tool as well just in case the one I found has issues. > > I've definitely gone through the wiki - including the getting started > and some of the other examples. > > Thanks, > George > > On 02/25/2014 03:12 PM, Johan Braeken wrote: >> Hi there, >> >> >> I use xPL and it should work with MisterHouse. >> >> >> First check if the IP address of MisterHouse and the broadcast address >> for your network is defined correctly in your mh-private.ini file and >> xPL is enabled. >> I think this is OK for you, but checking again doesn't hurt. ;-) >> >> See http://misterhouse.wikispaces.com/xAP+and+xPL+-+Getting+Started >> >> >> Do you use/need an xPL hub on your network? >> >> >> I don't know about the script that generates your xPL messages, but >> xPL is very picky about newlines. >> There should be a newline at the very end of your xPL message. >> >> >> Secondly, here is something that works: >> Please note that my definitions are a little different. >> >> The problem might be that MisterHouse refuses to parse your messages >> as they seem to come from the same source that is a target within >> MisterHouse. (This is just a guess as it has been a long time since I >> checked the code.) >> >> >> Item definition: >> XPL_SENSOR, bnz-nc.*:WindGustSpeed, OW_WindGustSpeed, , input >> >> xPL message in network: >> 21:00:01.252109 IP 192.168.42.5.40461 > 192.168.42.255.3865: UDP, length 111 >> 0x0000: 4500 008b cf49 4000 4011 94c3 c0a8 2a05 E....I@.@.....*. >> 0x0010: c0a8 2aff 9e0d 0f19 0077 d6dd 7870 6c2d ..*......w..xpl- >> 0x0020: 7374 6174 0a7b 0a68 6f70 3d31 0a73 6f75 stat.{.hop=1.sou >> 0x0030: 7263 653d 626e 7a2d 6e63 2e64 6f6d 7573 rce=bnz-nc.domus >> 0x0040: 0a74 6172 6765 743d 2a0a 7d0a 7365 6e73 .target=*.}.sens >> 0x0050: 6f72 2e62 6173 6963 0a7b 0a64 6576 6963 or.basic.{.devic >> 0x0060: 653d 5769 6e64 4775 7374 5370 6565 640a e=WindGustSpeed. >> 0x0070: 7479 7065 3d69 6e70 7574 0a63 7572 7265 type=input.curre >> 0x0080: 6e74 3d33 342e 3233 0a7d 0a nt=34.23.}. >> >> >> >> Best regards, >> >> Johan Braeken. >> >> Quoting George Clark <ge...@fe...>: >> >>> Hi all, >>> >>> I'm trying and failing to understand the xPL basics. I'm trying to >>> define a basic sensor with the states on/off controlled by xPL messages. >>> >>> Can anyone point to an example of configuring a sensor and sending a >>> simple on/off to it? Or give me an idea of what I'm doing wrong >>> here? The examples in the wiki and common code files are mostly >>> related to interfacing to existing devices, and suggest working >>> backwards from captured messages. But I don't have an existing device >>> to capture. >>> >>> Thanks, >>> George >>> >>> >>> # XPL_SENSOR, <xpl_address>:<device_id>, <mh_item_name>, <mh_grouplist>, >>> <sensor_type> >>> XPL_SENSOR, arduino-test.basement:1, test_1, Sensors, input >>> >>> and a bit of user code: >>> >>> if ($test_1->state_now) { >>> print_log "========== test_1 state=$state"; >>> } >>> >>> >>> And I'm trying to set the state by sending xPL messages from a message >>> generator script. >>> >>> Usage: sendxplmsg.py <msg_type> <target> <schema> <body> >>> >>> sendxplmsg.py "arduino-basement:1" "*" sensor.basic >>> "name=\$test_1\\ndevice=1\\nstate=on" >>> >>> I've tried sensor.basic, control.basic, and various combinations of >>> state, current, and other settings. I'm just not understanding >>> something somewhere, and I'm running out of ideas. If I set debug xpl >>> to 4, I can see the message come in and be parsed, but it doesn't tie >>> back to the item. >>> >>> Here is the message with the source section named for the source. When >>> I send the message this way, the source doesn't appear to get picked >>> up, so the parse routine returns a null source. I've also tried >>> changing the message type to xpl-stat. That seems to get a little >>> closer as it picks up the source, but it still doesn't tie to the >>> item. Below are debug messages from several different attempts. >>> >>> (I added some debug prints to the db4 parse code, to show the section >>> being parsed, and at the end, the data being returned to the caller: >>> >>> db4 xPL data: >>> arduino-test.basement >>> { >>> hop=1 >>> source=arduino-test.basement >>> target=* >>> } >>> control.basic >>> { >>> name=$test_1 >>> device=1 >>> current=on >>> } >>> >>> Switch to section arduino-test.basement >>> db4 xpl parsed c=arduino-test.basement k=hop v=1 >>> db4 xpl parsed c=arduino-test.basement k=source v=arduino-test.basement >>> db4 xpl parsed c=arduino-test.basement k=target v=* >>> Switch to section control.basic >>> db4 xpl parsed c=control.basic k=name v=$test_1 >>> db4 xpl parsed c=control.basic k=device v=1 >>> db4 xpl parsed c=control.basic k=current v=on >>> XPL - from source: , class control.basic target *, type >>> arduino-test.basement >>> >>> >>> >>> db4 xPL data: >>> xpl-stat >>> { >>> hop=1 >>> source=arduino-test.basement:1 >>> target=* >>> } >>> sensor.basic >>> { >>> name=$test_1 >>> device=1 >>> current=on >>> } >>> >>> Switch to section xpl-stat >>> db4 xpl parsed c=xpl-stat k=hop v=1 >>> db4 xpl parsed c=xpl-stat k=source v=arduino-test.basement:1 >>> db4 xpl parsed c=xpl-stat k=target v=* >>> Switch to section sensor.basic >>> db4 xpl parsed c=sensor.basic k=name v=$test_1 >>> db4 xpl parsed c=sensor.basic k=device v=1 >>> db4 xpl parsed c=sensor.basic k=current v=on >>> XPL - from source: arduino-test.basement:1, class sensor.basic target >>> *, type xpl-stat >>> >>> >>> >>> >>> >>> >>> hdb4 xPL data: >>> xpl-stat >>> { >>> hop=1 >>> source=arduino-test.basement:1 >>> target=* >>> } >>> control.basic >>> { >>> name=$test_1 >>> device=1 >>> current=on >>> } >>> >>> Switch to section xpl-stat >>> db4 xpl parsed c=xpl-stat k=hop v=1 >>> db4 xpl parsed c=xpl-stat k=source v=arduino-test.basement:1 >>> db4 xpl parsed c=xpl-stat k=target v=* >>> Switch to section control.basic >>> db4 xpl parsed c=control.basic k=name v=$test_1 >>> db4 xpl parsed c=control.basic k=device v=1 >>> db4 xpl parsed c=control.basic k=current v=on >>> XPL - from source: arduino-test.basement:1, class control.basic target >>> *, type xpl-stat >>> |
From: Johan B. <lis...@ce...> - 2014-02-26 14:50:09
|
Hi there, Quoting Joel Davidson <jr...@pr...>: > I can't remember who said it, but a while back someone suggested that > we NOT use the built-in hub in mh, and recommended a different one. > I took a quick look through my saved emails and I can't find the note, > but you may want to doublecheck on the wiki or in the archives. I also do NOT use the xPL hub of MH. The messagethread you are looking for is probably: "xPL Hub: Repair or Rip Out?" It was started by Micheal Stovenour on 2011/12/27 and should be retrievable in the archives of this mailinglist. Johan. |