From: Michael S. <mi...@st...> - 2011-12-25 20:46:27
|
I was playing with MH under Cygwin and noticed that I needed to manually set the broadcast address for xPL. I had to go digging around in the lib/xPL_Items.pm code to find the parameters. Ideally the config_parms{} settings are documented in mh.ini so that users know the available options and so that the web interface INI editor displays the parameters and help text. I noticed quite a few items that are not documented in mh.ini. Does anyone think I should "not" add all of these to mh.ini? Already documented in mh.ini - no action needed lib/Generic_Item.pm: xpl_enable_items lib/Generic_Item.pm: xap_enable_items lib/xPL_Items.pm: xpl_disable lib/xAP_Items.pm: xap_disable Not documented in mh.ini - I think these are the most important lib/xPL_Items.pm: xpl_nohub lib/xPL_Items.pm: ipaddress_xpl_broadcast lib/xPL_Items.pm: ipaddress_xpl lib/xAP_Items.pm: xap_nohub lib/xAP_Items.pm: ipaddress_xap_broadcast lib/xAP_Items.pm: ipaddress_xap Not documented in mh.ini - I'll also add these if no one thinks it is a bad idea lib/xPL_Items.pm: xpl_port lib/xPL_Items.pm: xpl_hbeat_interval lib/xPL_Items.pm: xpl_title lib/xPL_Items.pm: xpl_address --> same as ipaddress_xpl ?? depricated? _process_incoming_xpl_hub_data() doesn't consider xpl_address, just ipaddress_xpl lib/xPL_Items.pm: title lib/xAP_Items.pm: xap_port lib/xAP_Items.pm: xap_hbeat_interval lib/xAP_Items.pm: xap_title lib/xAP_Items.pm: xap_send_interval lib/xAP_Items.pm: xap_hub_echo lib/xAP_Items.pm: xap_uid lib/xAP_Items.pm: xap_disable_target code/common/xAP_send.pl: xap_echo_all code/common/xAP_send.pl: xap_echo_weather code/common/xAP_send.pl: xap_echo_x10 code/common/xAP_send.pl: xap_echo_speech code/common/xAP_send.pl: xap_echo_mhspeech code/common/xAP_send.pl: xap_echo_speech code/common/xAP_send.pl: xap_echo_mhspeech Sincerely, Michael |
From: Lieven H. <li...@li...> - 2011-12-26 08:12:48
|
Hi Michael. Op 25-dec.-2011, om 21:27 heeft Michael Stovenour het volgende geschreven: > I was playing with MH under Cygwin and noticed that I needed to manually set the broadcast address for xPL. I had to go digging around in the lib/xPL_Items.pm code to find the parameters. Ideally the config_parms{} settings are documented in mh.ini so that users know the available options and so that the web interface INI editor displays the parameters and help text. I noticed quite a few items that are not documented in mh.ini. Does anyone think I should “not” add all of these to mh.ini? > > Already documented in mh.ini – no action needed > lib/Generic_Item.pm: xpl_enable_items > lib/Generic_Item.pm: xap_enable_items > lib/xPL_Items.pm: xpl_disable > lib/xAP_Items.pm: xap_disable > > > Not documented in mh.ini – I think these are the most important > lib/xPL_Items.pm: xpl_nohub > lib/xPL_Items.pm: ipaddress_xpl_broadcast > lib/xPL_Items.pm: ipaddress_xpl > lib/xAP_Items.pm: xap_nohub > lib/xAP_Items.pm: ipaddress_xap_broadcast > lib/xAP_Items.pm: ipaddress_xap > I agree with you that the above settings are required to get a working xPL setup (I have no experience with xap). I do find it a bit strange that it is required to set ip_address_xpl. Is there anybody who knows why that is required? It should default to the ip address of the machine where MH is running on if it is not set (with the option to override it of course on machines with multiple network interfaces). > > Not documented in mh.ini – I’ll also add these if no one thinks it is a bad idea For the other settings you mention: I think it doesn't hurt to have them in the list. I don't think xpl_port should be set (this port is assigned to the protocol and should not be changed because else it breaks compatibility with other xPL devices). Best regards, Lieven. |
From: Michael S. <mi...@st...> - 2011-12-27 04:45:25
|
On December 26, 2011 2:13 AM, Lieven Hollevoet wrote: >Hi Michael. > >Op 25-dec.-2011, om 21:27 heeft Michael Stovenour het volgende geschreven: .... >> Not documented in mh.ini - I think these are the most important >> lib/xPL_Items.pm: xpl_nohub >> lib/xPL_Items.pm: ipaddress_xpl_broadcast >> lib/xPL_Items.pm: ipaddress_xpl >> lib/xAP_Items.pm: xap_nohub >> lib/xAP_Items.pm: ipaddress_xap_broadcast >> lib/xAP_Items.pm: ipaddress_xap > >I agree with you that the above settings are required to get a working xPL setup (I have no experience with xap). > Thanks for the feedback. I'll add these to mh.ini. >I do find it a bit strange that it is required to set ip_address_xpl. Is there anybody who knows why that is required? It should default to the ip address of the machine where MH is running on if it is not set (with the option to override it of course on machines with multiple network interfaces). I haven't had this experience. I don't need to specify the ipaddress_xpl parameter but in Windows I "do" need to specify the broadcast address. This has to do with MH using 255.255.255.255 for the broadcast address. Windows does not send a broadcast message onto the wire when using that address. Other xPL implementations I've seen (e.g. xPL-Perl) use the network broadcast (e.g. 192.168.1.255) when sending. That seems to work for both Linux and Windows. However finding the network broadcast or even the network mask can be a real pain. The xPL-perl library is written only for Linux and parses the output from `ifconfig` to get the broadcast address. I modified that code to work under windows (and Cygwin) using `ipconfig` but it is fragile; (e.g. windows vista/7 broke my parsing logic requiring updates). I think it is ok to require manual configuration of the broadcast address. >> >> Not documented in mh.ini - I'll also add these if no one thinks it is a bad idea > >For the other settings you mention: I think it doesn't hurt to have them in the list. I don't think xpl_port should be set (this port is assigned to the protocol and should not be changed because else it breaks compatibility with other xPL devices). I'll add *_heartbeat_interval and *_title as well. The others are probably not generally useful. >Best regards, > Lieven. |
From: Marc M. <ma...@me...> - 2011-12-27 09:02:17
|
On Mon, Dec 26, 2011 at 10:45:20PM -0600, Michael Stovenour wrote: > On December 26, 2011 2:13 AM, Lieven Hollevoet wrote: > >Hi Michael. > > > >Op 25-dec.-2011, om 21:27 heeft Michael Stovenour het volgende geschreven: > .... > >> Not documented in mh.ini - I think these are the most important > >> lib/xPL_Items.pm: xpl_nohub > >> lib/xPL_Items.pm: ipaddress_xpl_broadcast > >> lib/xPL_Items.pm: ipaddress_xpl > >> lib/xAP_Items.pm: xap_nohub > >> lib/xAP_Items.pm: ipaddress_xap_broadcast > >> lib/xAP_Items.pm: ipaddress_xap > > > >I agree with you that the above settings are required to get a working xPL > setup (I have no experience with xap). > > > > Thanks for the feedback. I'll add these to mh.ini. If you don't have commit access, send me a diff, and I'll put it in. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Lieven H. <li...@li...> - 2011-12-27 13:11:51
|
Hi, Op 27-dec.-2011, om 05:45 heeft Michael Stovenour het volgende geschreven: > > Thanks for the feedback. I'll add these to mh.ini. > Thank you. >> I do find it a bit strange that it is required to set ip_address_xpl. Is > there anybody who knows why that is required? It should default to the ip > address of the machine where MH is running on if it is not set (with the > option to override it of course on machines with multiple network > interfaces). > > I haven't had this experience. I double-checked this. I forgot my MH machine has two network interfaces: a wired and a wireless one (I'm not using the wireless, hence I forgot about it). This is probably the reason I had to specify the interface to use. So I take back my statement. > I don't need to specify the ipaddress_xpl > parameter but in Windows I "do" need to specify the broadcast address. This > has to do with MH using 255.255.255.255 for the broadcast address. Windows > does not send a broadcast message onto the wire when using that address. > Other xPL implementations I've seen (e.g. xPL-Perl) use the network > broadcast (e.g. 192.168.1.255) when sending. That seems to work for both > Linux and Windows. I'm experiencing problems using 255.255.255.255 on Mac OS X also, so the problem might not be Windows-only :-) > However finding the network broadcast or even the > network mask can be a real pain. The xPL-perl library is written only for > Linux and parses the output from `ifconfig` to get the broadcast address. I > modified that code to work under windows (and Cygwin) using `ipconfig` but > it is fragile; (e.g. windows vista/7 broke my parsing logic requiring > updates). I think it is ok to require manual configuration of the broadcast > address. There were a few Linux-specific things in the xpl-perl code, but the author (beanz) is very open to modifications that make the library more cross-platform (you can submit patches through github). I'm using xpl-perl on OS X as my main xPL-related code base with only minor changes to the official release. Regards, Lieven. |
From: Michael S. <mi...@st...> - 2011-12-27 18:41:06
|
On December 27, 2011 7:12 AM, Lieven Hollevoet wrote: >> However finding the network broadcast or even the network mask can be >> a real pain. The xPL-perl library is written only for Linux and >> parses the output from `ifconfig` to get the broadcast address. I >> modified that code to work under windows (and Cygwin) using `ipconfig` >> but it is fragile; (e.g. windows vista/7 broke my parsing logic >> requiring updates). I think it is ok to require manual configuration >> of the broadcast address. > >There were a few Linux-specific things in the xpl-perl code, but the author (beanz) is very open to modifications that make the library more cross-platform (you can submit patches through github). I'm using xpl-perl on OS X as my main xPL-related code base with only minor changes to the official release. Until I added the ipconfig option for the network parameter discovery when $^O =~ /^MSWin|^cygwin/, xpl-perl would not start on windows at all. With that change some of the apps run fine. However anything that needs access to a serial port will still not run because xpl-perl directly accesses the *nix serial port device. I started working on that a while back but never finished. I'll let beanz know and see if he is interested in the changes. |
From: Lieven H. <li...@li...> - 2011-12-27 23:40:00
|
Hi Michael, in recent versions of the framework Beanz integrated a patch from me to use Device::SerialPort instead of the direct stty calls. This should allow you to easily integrate Win32::Serialport (this module uses the same syntax as Device::SerialPort) and submit a patch to beanz for windows-compatibility. The file you're looking after is IOHandler.pm https://github.com/beanz/xpl-perl/blob/master/lib/xPL/IOHandler.pm Best regards, Lieven. Op 27-dec.-2011, om 19:40 heeft Michael Stovenour het volgende geschreven: > On December 27, 2011 7:12 AM, Lieven Hollevoet wrote: > >>> However finding the network broadcast or even the network mask can be >>> a real pain. The xPL-perl library is written only for Linux and >>> parses the output from `ifconfig` to get the broadcast address. I >>> modified that code to work under windows (and Cygwin) using `ipconfig` >>> but it is fragile; (e.g. windows vista/7 broke my parsing logic >>> requiring updates). I think it is ok to require manual configuration >>> of the broadcast address. >> >> There were a few Linux-specific things in the xpl-perl code, but the author > (beanz) is very open to modifications that make the library more > cross-platform (you can submit patches through github). I'm using xpl-perl > on OS X as my main xPL-related code base with only minor changes to the > official release. > > Until I added the ipconfig option for the network parameter discovery when > $^O =~ /^MSWin|^cygwin/, xpl-perl would not start on windows at all. With > that change some of the apps run fine. However anything that needs access > to a serial port will still not run because xpl-perl directly accesses the > *nix serial port device. I started working on that a while back but never > finished. I'll let beanz know and see if he is interested in the changes. > > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: lincoln f. <lin...@gm...> - 2011-12-28 02:55:30
|
On Dec 27, 2011, at 5:39 PM, Lieven Hollevoet <li...@li...> wrote: > Hi Michael, > > in recent versions of the framework Beanz integrated a patch from me to use Device::SerialPort instead of the direct stty calls. > > This should allow you to easily integrate Win32::Serialport (this module uses the same syntax as Device::SerialPort) and submit a patch to beanz for windows-compatibility. > > The file you're looking after is IOHandler.pm > https://github.com/beanz/xpl-perl/blob/master/lib/xPL/IOHandler.pm > > Best regards, > Lieven. > > Op 27-dec.-2011, om 19:40 heeft Michael Stovenour het volgende geschreven: > >> On December 27, 2011 7:12 AM, Lieven Hollevoet wrote: >> >>>> However finding the network broadcast or even the network mask can be >>>> a real pain. The xPL-perl library is written only for Linux and >>>> parses the output from `ifconfig` to get the broadcast address. I >>>> modified that code to work under windows (and Cygwin) using `ipconfig` >>>> but it is fragile; (e.g. windows vista/7 broke my parsing logic >>>> requiring updates). I think it is ok to require manual configuration >>>> of the broadcast address. >>> >>> There were a few Linux-specific things in the xpl-perl code, but the author >> (beanz) is very open to modifications that make the library more >> cross-platform (you can submit patches through github). I'm using xpl-perl >> on OS X as my main xPL-related code base with only minor changes to the >> official release. >> >> Until I added the ipconfig option for the network parameter discovery when >> $^O =~ /^MSWin|^cygwin/, xpl-perl would not start on windows at all. With >> that change some of the apps run fine. However anything that needs access >> to a serial port will still not run because xpl-perl directly accesses the >> *nix serial port device. I started working on that a while back but never >> finished. I'll let beanz know and see if he is interested in the changes. >> >> >> ------------------------------------------------------------------------------ >> Write once. Port to many. >> Get the SDK and tools to simplify cross-platform app development. Create >> new or port existing apps to sell to consumers worldwide. Explore the >> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join >> http://p.sf.net/sfu/intel-appdev >> ________________________________________________________ >> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 >> > > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Michael S. <mi...@st...> - 2011-12-28 03:24:38
|
> On December 27, 2011 5:40 PM, Lieven Hollevoet wrote: > >Hi Michael, > >in recent versions of the framework Beanz integrated a patch from me to use Device::SerialPort instead of the direct stty calls. > >This should allow you to easily integrate Win32::Serialport (this module uses the same syntax as Device::SerialPort) and submit a patch to beanz for windows-compatibility. > >The file you're looking after is IOHandler.pm https://github.com/beanz/xpl-perl/blob/master/lib/xPL/IOHandler.pm Hi Lieven, That's great news; when I looked at it last I started doing something similar. It should make it much easier. I'll pull the latest code and take a look. Sincerely, Michael >Best regards, > Lieven. |