From: Tom V. d. B. <tv...@sc...> - 2006-09-22 06:24:34
|
Hi Everybody, I've been playing around with home automation, especially under linux for a year now. I recently bought myself the Linux Smarthomes for Dummies book and only then realised the power of mh. Thus I have downloaded the latest stable release and it's currently up and running with x10 devices configured and some basic scripts to turn some lights on and off at certain times. Last night I also played around a bit with the examples and got my 1wire devices working with mh and digitemp so thats cool too. Some questions though: (a) can anybody tell me whats the state of the xPL interface and how I can use it? I have written xPL gateways for most of my other devices and it would be nice if I can just get the info into mh. (b) I've got a velleman k8000 running and I read somewhere that mh has support for this. Is this true? I'll probably be asking alot of dumb questions so I hope nobody gets mad at me :) Regards, Tom van den Bon |
From: Gregg L. <gr...@li...> - 2006-09-22 11:12:10
|
Hi Tom, Quoting Tom Van den Bon (9/22/06 2:23 AM): > Some questions though: > > (a) can anybody tell me whats the state of the xPL interface and how I > can use it? I have written xPL gateways for most of my other devices and > it would be nice if I can just get the info into mh. Here's a very quick synopsis of xPL support: 1) the mh xPL lib is enabled by default 2) the mh xPL is also enabled by default; to disable set xpl_nohub=1. I tend to prefer Gerry D.'s linux hub over mh's built in. mh will auto-disable it's hub if it sees another one; relying on this is a very bad idea 3) mh does not yet implement any of the xPL auto-discovery/config protocol 4) adding an xPL "listener" works like this: # declare a new xPL item and set the source name # note that mh fully supports wildcarding; so, "xplmedia-client.*" # broadens the scope of "listening". Likewise, it is possible # to wildcard your local universe by just setting to "*" $xpl_listener = new xPL_Item("xplmedia-client.basement"); # now set the class name; use the #noloop to keep from # doing this over and over and ... $xpl_listener->class_name('media.basic'); # noloop # now, do something useful .... if ($xpl_listener->state_now) { # then xpl_listener heard something # if interested in only xpl-cmnd messages ... if ($xpl_listener->state_now_msg_type eq 'cmnd') { # data is stored in a hash, for example: my $cmd = $$xpl_listener{'media.basic'}{'command'}; # note that the section name and keys are always low-case # the data is left alone } } # there are a lot of other convenience methods that could # be useful. Either look at xAP_Items.pm in the xAP_Item and # xPL_Item (yes, xPL_Item isa xAP_Item or just ask # sending can be a lot easier ... # the first arg is the target and the second is the data # sent as a hash $xpl_listener->send_cmnd($xpl_listener->source, 'media.basic' => { command => "play" }); 5) There is built in support for routing mh speak to xPL TTS clients. To use, add a line such as the following into your ini file: PA, xplmedia-client.outside, outside_tts, all|default, tts.basic, xpl # xplmedia-client.outside is the target (do NOT use wildcards here) # outside_tts is the room name # tts.basic is the schema # xpl is the protocol 6) I've recently committed mods to permit similar display based routing of messages to OSD devices. For example, adding the following into your ini: display_apps=cid => display_rooms=basement_rio|family_room duration=30, test => display_rooms=basement_rio duration=20 display_rooms=family_room => schema=osd.basic address=slimdev-slimserv.squeezebox device=xpl, basement_rio => schema=osd.basic address=xplmedia-client.basementdesk device=xpl # then, you can do the following in your usercode &main::display("app=cid Call from $cidnumber"); # app=cid allows for automatic lookup of rooms to be routed to # to cause automatic echo of speak messages, add the echo tag: speak_apps=system => rooms=none mode=mute, echo=xpl display_rooms=basement_rio # note: adding echo and NOT adding display_rooms will cause a # broadcast osd.basic message to be sent > (b) I've got a velleman k8000 running and I read somewhere that mh has > support for this. Is this true? I think Matt wrote a module for this. Since you're running a lot of xPL gateways, you are aware of the xPLk8000 gateway (http://sourceforge.net/projects/xplk8000)? I've not used either as I don't have one of these boards. |
From: Tom V. d. B. <tv...@sc...> - 2006-09-22 13:38:09
|
Thanks for all the answers. I'll be testing it this weekend. >> (b) I've got a velleman k8000 running and I read somewhere that mh has >> support for this. Is this true? >> > > I think Matt wrote a module for this. Since you're running a lot of xPL > gateways, you are aware of the xPLk8000 gateway > (http://sourceforge.net/projects/xplk8000)? I've not used either as I > don't have one of these boards. > > hehe, Yes I know about the xPLk8000 module, its my project. I just asked because I read somewhere about the integration of the k8000 into mh and I wanted to test it, but the xPL support seems good so I'm going to try it out this weekend. Thanks for all the help, Regards, Tom Van den Bon |
From: Gregg L. <gr...@li...> - 2006-09-22 14:01:28
|
Quoting Tom Van den Bon (9/22/06 9:36 AM): > hehe, Yes I know about the xPLk8000 module, its my project. (embarrassed).. I guess I could have made the leap of tvdbon = Tom ... > because I read somewhere about the integration of the k8000 into mh and > I wanted to test it, but the xPL support seems good so I'm going to try > it out this weekend. Do let me know if you run into problems and/or would like to see additional support of some sort. I've been a bit remiss in getting more specific xPL support into mh. FWIW: I am working on support for MediaNet (Tony's project) which can hopefully also morph into much full-featured support for the squeezebox than what currently exists in mh. |
From: Matthew W. <mat...@us...> - 2006-09-22 21:39:14
|
Tom Van den Bon wrote: > Thanks for all the answers. I'll be testing it this weekend. >>> (b) I've got a velleman k8000 running and I read somewhere that mh has >>> support for this. Is this true? >>> >> I think Matt wrote a module for this. Since you're running a lot of xPL >> gateways, you are aware of the xPLk8000 gateway >> (http://sourceforge.net/projects/xplk8000)? I've not used either as I >> don't have one of these boards. >> Take a look at http://misterhouse.wikispaces.com/K8055 for information on the K8055 stuff that I wrote. It is a two part interface, a server daemon and two clients, one integrated into mh and a standalone client as well. Let me know if you have more questions. Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Neil C. <nc...@co...> - 2006-09-22 15:55:37
|
Gregg Liming wrote: > Hi Tom, > > Quoting Tom Van den Bon (9/22/06 2:23 AM): > >> Some questions though: >> >> (a) can anybody tell me whats the state of the xPL interface and how I >> can use it? I have written xPL gateways for most of my other devices and >> it would be nice if I can just get the info into mh. > > Here's a very quick synopsis of xPL support: > > 1) the mh xPL lib is enabled by default Greg, I had the users turn it off in my book. This eliminated the error messages that would come up. Tom, if you turn to page 275 (Chapter 15: Controlling Your Home with MisterHouse), under Server you'll see: xap_disable=1 xpl_disable=1 Change xpl_disable to 0. Do we need XAP with XPL? -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog http://home.comcast.net/~ncherry/ Backup site |
From: Tom V. d. B. <tv...@sc...> - 2006-09-26 13:14:59
|
Hi Greg and everybody else, Thanks for all the replies so far. I played around with it this weekend and I manager to get half of it working. * When mh starts up it sends out the correct xPL heartbeat message to show it's presence according to DCM (java app from Gerry). * I can send out xPL messages as from your code example, it works very nicely. However: I seems that I can't receive any xPL messages in my mh code, i tried the following basic example # declare a new xPL item $xpl_listener = new xPL_Item( "*" ); # set the class name $xpl_listener->class_name('sensor.basic'); # noloop print( "Testing" ); # if xPL heard something if ( $xpl_listener->state_now ) { print "xPL Sensor Message Received"; } * but I'm not receiving anything, but the "Testing" string keeps repeating so it's running this code. Am I doing something wrong? * Can I wildcard the class name? ie. $xpl_listener->classname('*'); # noloop Thanks for all the help sofar, greatly appreciated. Regards, Tom Gregg Liming wrote: > Hi Tom, > > Quoting Tom Van den Bon (9/22/06 2:23 AM): > > >> Some questions though: >> >> (a) can anybody tell me whats the state of the xPL interface and how I >> can use it? I have written xPL gateways for most of my other devices and >> it would be nice if I can just get the info into mh. >> > > Here's a very quick synopsis of xPL support: > > 1) the mh xPL lib is enabled by default > 2) the mh xPL is also enabled by default; to disable set xpl_nohub=1. I > tend to prefer Gerry D.'s linux hub over mh's built in. mh will > auto-disable it's hub if it sees another one; relying on this is a very > bad idea > 3) mh does not yet implement any of the xPL auto-discovery/config protocol > 4) adding an xPL "listener" works like this: > > # declare a new xPL item and set the source name > # note that mh fully supports wildcarding; so, "xplmedia-client.*" > # broadens the scope of "listening". Likewise, it is possible > # to wildcard your local universe by just setting to "*" > > $xpl_listener = new xPL_Item("xplmedia-client.basement"); > > # now set the class name; use the #noloop to keep from > # doing this over and over and ... > $xpl_listener->class_name('media.basic'); # noloop > > # now, do something useful .... > if ($xpl_listener->state_now) { # then xpl_listener heard something > # if interested in only xpl-cmnd messages ... > if ($xpl_listener->state_now_msg_type eq 'cmnd') { > # data is stored in a hash, for example: > my $cmd = $$xpl_listener{'media.basic'}{'command'}; > # note that the section name and keys are always low-case > # the data is left alone > } > } > > # there are a lot of other convenience methods that could > # be useful. Either look at xAP_Items.pm in the xAP_Item and > # xPL_Item (yes, xPL_Item isa xAP_Item or just ask > > # sending can be a lot easier ... > # the first arg is the target and the second is the data > # sent as a hash > $xpl_listener->send_cmnd($xpl_listener->source, > 'media.basic' => { command => "play" }); > > 5) There is built in support for routing mh speak to xPL TTS clients. > To use, add a line such as the following into your ini file: > > PA, xplmedia-client.outside, outside_tts, all|default, > tts.basic, xpl > > # xplmedia-client.outside is the target (do NOT use wildcards here) > # outside_tts is the room name > # tts.basic is the schema > # xpl is the protocol > > 6) I've recently committed mods to permit similar display based routing > of messages to OSD devices. For example, adding the following into your > ini: > > display_apps=cid => display_rooms=basement_rio|family_room duration=30, > test => display_rooms=basement_rio duration=20 > display_rooms=family_room => schema=osd.basic > address=slimdev-slimserv.squeezebox device=xpl, basement_rio => > schema=osd.basic address=xplmedia-client.basementdesk device=xpl > > # then, you can do the following in your usercode > > &main::display("app=cid Call from $cidnumber"); > # app=cid allows for automatic lookup of rooms to be routed to > > # to cause automatic echo of speak messages, add the echo tag: > > speak_apps=system => rooms=none mode=mute, echo=xpl > display_rooms=basement_rio > > # note: adding echo and NOT adding display_rooms will cause a > # broadcast osd.basic message to be sent > > >> (b) I've got a velleman k8000 running and I read somewhere that mh has >> support for this. Is this true? >> > > I think Matt wrote a module for this. Since you're running a lot of xPL > gateways, you are aware of the xPLk8000 gateway > (http://sourceforge.net/projects/xplk8000)? I've not used either as I > don't have one of these boards. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > > |
From: Gregg L. <gr...@li...> - 2006-09-26 13:36:13
|
Hi Tom, Quoting Tom Van den Bon (9/26/06 9:13 AM): > I seems that I can't receive any xPL messages in my mh code, i tried the > following basic example This sounds like a hub is not running. Are you using mh's built-in hub or another one? There's a bunch of socket errata that is output to the console at startup. Can you copy and paste it? I can confirm from that what is occuring/not occurring. > # declare a new xPL item > $xpl_listener = new xPL_Item( "*" ); > > # set the class name > $xpl_listener->class_name('sensor.basic'); # noloop That should work just fine (as an anonymous sensor.basic listener); definitely seems to be a hub absence or hub registration problem. > print( "Testing" ); > > # if xPL heard something > if ( $xpl_listener->state_now ) > { > print "xPL Sensor Message Received"; > } That also looks good. > * but I'm not receiving anything, but the "Testing" string keeps > repeating so it's running this code. Am I doing something wrong? No--not from a coding stand-point anyway. Let's focus on the hub. It may be useful (at some point) to set debug=xpl in your ini parms--especially if you're convinced that your hub is setup properly. Be forewarned, however, that once your receive/hub problem is resolved, this debug will render a "fire-hose" of errata if you have a semi-busy xPL deployment. > * Can I wildcard the class name? ie. $xpl_listener->classname('*'); # noloop Yep (but use the proper method: class_name vice classname). You can use "*" or partial wildcarding like "sensor.*" or *.basic" (not sure that either of those are useful, but...). The same thing also applies to the source. Just so you know, the actual comparison is done w/ regex where "*" is replaced w/ ".*" and "." is replaced with "\.". So, you can actually use more sophisticated "wild-carding" than the xPL spec suggests (assuming you're fluent w/ regexs and watch that what you think is legit isn't getting substituted prior to the regex compare). |
From: Tom V. d. B. <tv...@sc...> - 2006-09-26 13:54:40
|
> >> I seems that I can't receive any xPL messages in my mh code, i tried the >> following basic example >> > > This sounds like a hub is not running. Are you using mh's built-in hub > or another one? There's a bunch of socket errata that is output to the > console at startup. Can you copy and paste it? I can confirm from that > what is occuring/not occurring. > I'm using an Gerry's Hub, been using it for all my other xPL applications. I'm pretty sure its working fine. I'll have to check tonight what exactly it is showing on startup since I don't have it at work, but from what I can remember it does actually connect to my external hub. Whilst playing around with the problem I had my external hub on debug and it did show something connecting when mh was started. > No--not from a coding stand-point anyway. Let's focus on the hub. It > may be useful (at some point) to set debug=xpl in your ini > parms--especially if you're convinced that your hub is setup properly. > Be forewarned, however, that once your receive/hub problem is resolved, > this debug will render a "fire-hose" of errata if you have a semi-busy > xPL deployment. > > I'll give it a shot and see if I can more information for you tomorrow from mh and my hub logs. Regards, Tom |
From: Gregg L. <gr...@li...> - 2006-09-26 16:00:10
|
Quoting Tom Van den Bon (9/26/06 9:53 AM): >>> I seems that I can't receive any xPL messages in my mh code, i tried the >>> following basic example >>> >> This sounds like a hub is not running. Are you using mh's built-in hub >> or another one? There's a bunch of socket errata that is output to the >> console at startup. Can you copy and paste it? I can confirm from that >> what is occuring/not occurring. >> > I'm using an Gerry's Hub, been using it for all my other xPL > applications. I'm pretty sure its working fine. I'll have to check > tonight what exactly it is showing on startup since I don't have it at > work, but from what I can remember it does actually connect to my > external hub. Whilst playing around with the problem I had my external > hub on debug and it did show something connecting when mh was started. There was a bug in the binding of the xPL application socket (vice the hub socket). The fix is now committed. Also, you will need to manually turn off the xPL hub and set the listening socket's address as: xpl_nohub=1 xpl_address=<xpl_bind_address> # e.g., xpl_address=10.20.1.5 |
From: Tom V. d. B. <tv...@sc...> - 2006-09-27 05:54:15
|
Hi Greg, > There was a bug in the binding of the xPL application socket (vice the > hub socket). The fix is now committed. > Thanks, is this available to me or do I have to wait for the next release? I'd like to test it and see how it works. Thanks, Tom |
From: Gregg L. <gr...@li...> - 2006-09-27 10:13:56
|
Hi Tom, Quoting Tom Van den Bon (9/27/06 1:53 AM): > Hi Greg, >> There was a bug in the binding of the xPL application socket (vice the >> hub socket). The fix is now committed. >> > > Thanks, is this available to me or do I have to wait for the next > release? I'd like to test it and see how it works. > Anyone may get the latest via svn. However, I've sent you a copy of the affected lib (xAP_Items.pm) off-list to speed things along. Gregg |
From: Tom V. d. B. <tv...@sc...> - 2006-09-27 11:22:57
|
> Anyone may get the latest via svn. However, I've sent you a copy of the > affected lib (xAP_Items.pm) off-list to speed things along. > > Thanks, I'll try it out tonight and see if I can get it to work. Regards, Tom |
From: Tom V. d. B. <tv...@sc...> - 2006-09-28 05:43:40
|
Hi Gregg and everybody, Good News, I'm receiving xPL messages in mh. I had alot of fun creating all kinds of short code snippets. My house feels more alive !! with mh. However, with my all the success my 'things-I-want-to-do' list is just getting bigger and bigger so I have some more questions. Thanks for all the help from everybody, I really appreciate it. My Questions: (1) I have created generic items to keep the status (via xPL) of certain items in and around the house. I have created a custom webpage for these alarms and I can display the status of these items via the <!--#include var="$zone1_movement->state"--> tags. But what I would like to do is to display a picture to represent the state. Is there already something available to do this or would I need to write my own pl code ? (2) Can I sort my generic items into groups, like I did with the x10 lights? The idea is that when I browse my groups it will show these generic items too. (3) If (1) is possible, will I be able to toggle these items and then because of that send an xPL message? Thanks for the great support so far. Regards, Tom Gregg Liming wrote: > Hi Tom, > > Quoting Tom Van den Bon (9/27/06 1:53 AM): > >> Hi Greg, >> >>> There was a bug in the binding of the xPL application socket (vice the >>> hub socket). The fix is now committed. >>> >>> >> Thanks, is this available to me or do I have to wait for the next >> release? I'd like to test it and see how it works. >> >> > > Anyone may get the latest via svn. However, I've sent you a copy of the > affected lib (xAP_Items.pm) off-list to speed things along. > > Gregg > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > > |
From: Gregg L. <gr...@li...> - 2006-09-28 10:43:51
|
Hi Tom, Quoting Tom Van den Bon (9/28/06 1:42 AM): ... good to hear you have working listeners now. Sorry about the early failed start on using the external hub. > (1) I have created generic items to keep the status (via xPL) of certain > items in and around the house. I have created a custom webpage for these > alarms and I can display the status of these items via the <!--#include > var="$zone1_movement->state"--> tags. But what I would like to do is to > display a picture to represent the state. Is there already something > available to do this or would I need to write my own pl code ? I just don't use the web interface that much. Hopefully, someone else knows. > (2) Can I sort my generic items into groups, like I did with the x10 > lights? The idea is that when I browse my groups it will show these > generic items too. Yes. You might look at the derived .mhp file for plenty of samples. But, nominally: my $genx = new Generic_Item; my $some_group = new Group; $some_group->add($genx); or, the .mht way ... GENERIC, genx, Some_group|Another_group > (3) If (1) is possible, will I be able to toggle these items and then > because of that send an xPL message? ... assuming it is possible, then just "tie an event" to the item's state like so: $genx->tie_event('xpl_send_hook()'); sub xpl_send_hook { # send an osd basic message the ol' fashioned away xAP::sendXpl('*','stat', 'osd.basic' => { command => 'write', delay => '10', text => "State of " . $genx->{object_name} . " is $state"}); # or, the new "cool" way (if you have the latest out of svn) # &main::display_xpl("State of " . $genx->{object_name} # . " is $state"); } There are really a lot of options for implementing #3. The tie_event just provides an easy "event" handler. Note, however, that it will fire *anytime* $genx's state is set (regardless of the method used (i.e., not from web) and whether the state has actually changed). Additional logic would be required to qualify the event if needed/desired. As an example, you could embed some variant of the following in your event "hook": # find out who set genx: my $setter_name = $genx->get_set_by(); # see if it was set by a web user... if ($setter_name =~ /^web/i) { # do something when a web user set genx } |
From: Matthew W. <mat...@us...> - 2006-09-28 12:56:03
|
Gregg Liming wrote: > Hi Tom, >> (1) I have created generic items to keep the status (via xPL) of certain >> items in and around the house. I have created a custom webpage for these >> alarms and I can display the status of these items via the <!--#include >> var="$zone1_movement->state"--> tags. But what I would like to do is to >> display a picture to represent the state. Is there already something >> available to do this or would I need to write my own pl code ? > > I just don't use the web interface that much. Hopefully, someone else > knows. Gregg answered your other questions. I can handle this one. The key to the standard button page is mh/web/bin/list_buttons.pl. Starting around line 25 are some lines that load the $state variable depending on the type of object being looked at. You can see that the object needs to be of a specific type in order for the code to work. Currently, and I'm not sure why, Generic_Items are not included. Perhaps this is because the list of states for a Generic_Item is not standardized (i.e. they are commonly overridden). Looking at line 35, you'll see that for objects that are more than a simple on/off, you need to put in custom logic for the new state in the case that the button is pressed. Now, there is an opportunity here for you to add some super spiffy code to support Generic Items, no matter what the possible states. I would suggest adding : $state=$object->state if $object->isa('Generic_Item') And then replace the "my $state_new" with logic like this: my @possible_states=$object->get_states; if there are possible_states, then search @possible_states for the current state make state_new the next state in the list, wrapping if at the last state else next state = $state, cause we don't know the valid states end if Another (better) option for that second block of pseudo code would be to create a new method in lib/Generic_Item.pm that returns the next valid state. Search for "toggle" in Generic_Item.pm and you'll see that the code is already there. It's just a matter of making that block into a method and having the toggle stuff call the method. This has two advantages - there may be other places where knowing the next possible state is useful and the method can be easily overridden by child classes. Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Gregg L. <gr...@li...> - 2006-09-28 13:06:23
|
Quoting Matthew Williams (9/28/06 8:55 AM): > Another (better) option for that second block of pseudo code would be to > create a new method in lib/Generic_Item.pm that returns the next valid > state. Search for "toggle" in Generic_Item.pm and you'll see that the code > is already there. It's just a matter of making that block into a method and > having the toggle stuff call the method. This has two advantages - there > may be other places where knowing the next possible state is useful and the > method can be easily overridden by child classes. My (unsolicited) opinion is that adding the additional method is a very good idea; but, the forced use of it in toggle changes the expected (or at least current) semantics of the toggle method. I'm not much in favor of changing the semantics (where toggle would now mean "jump to next state" vice "change to off if on and on if off") of an existing and widely used method. If you can make the application of "next state" use in toggle optional (makes no difference what the default is to me), then I am for that. Gregg |
From: Matthew W. <mat...@us...> - 2006-09-28 13:10:01
|
Gregg Liming wrote: > Quoting Matthew Williams (9/28/06 8:55 AM): > > My (unsolicited) opinion is that adding the additional method is a very > good idea; but, the forced use of it in toggle changes the expected (or > at least current) semantics of the toggle method. I'm not much in favor > of changing the semantics (where toggle would now mean "jump to next > state" vice "change to off if on and on if off") of an existing and > widely used method. If you can make the application of "next state" use > in toggle optional (makes no difference what the default is to me), then > I am for that. > Gregg, here's the current toggle code from Generic_Item: my $state_current = $$self{state}; # If states are defined, toggle will pick the next one if ($$self{states}) { my @s = @{$$self{states}}; my $i = 0; while ($i < @s) { last if $s[$i] eq $state_current; $i++; } $i++; $i = 0 if $i > $#s; $state = $s[$i]; } else { $state = ($state_current eq 'on') ? 'off' : 'on'; } As you can see, the current behaviour is already to pick the next state in the list if the states have been defined. Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Gregg L. <gr...@li...> - 2006-09-28 13:16:40
|
Quoting Matthew Williams (9/28/06 9:09 AM): > As you can see, the current behaviour is already to pick the next state in > the list if the states have been defined. Thanks for that clarification; obviously I hadn't looked and was reacting to your suggestion to a change. IMO, it's too bad that the on/off check doesn't occur first. But, as stated earlier, I wouldn't suggest mod-ing that method to change it's semantics. |
From: Matthew W. <mat...@us...> - 2006-09-28 13:35:07
|
Gregg Liming wrote: > Thanks for that clarification; obviously I hadn't looked and was > reacting to your suggestion to a change. IMO, it's too bad that the > on/off check doesn't occur first. But, as stated earlier, I wouldn't > suggest mod-ing that method to change it's semantics. No problem. The good news for your concerns is that the default "state" is for a Generic_Item to not have any states predefined so the default action for toggle is on/off. Your question did raise another point in my head though. An X10_Item, as an example, has many states, including on, off, brighten, etc. The changes to list_buttons.pl need to be made carefully. The search for the next state should only be made if the object is a Generic_Item and isn't one of the already predefined objects. These objects need to retain the current on/off behaviour. Of course, the current special case for the Fan_Motor will become redundant. Tom, If you don't feel up to these changes, let me know and I can look after them. Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Tom V. d. B. <tv...@sc...> - 2006-09-28 14:08:35
|
Hi Gregg & Matt, Thanks for all the answers, it definitely got me thinking about a couple of things. > Tom, > > If you don't feel up to these changes, let me know and I can look after them. > Thanks for offer Matt, but I'm still learning and I would like to try it out first. I'll ask more questions if I get stuck. I don't know much perl - first time playing with perl, but this is a good way to learn. I've got enough info to keep me busy again tonight. Regards, Tom |
From: Tom V. d. B. <tv...@sc...> - 2006-09-28 14:15:03
|
Hi Gregg, > ... good to hear you have working listeners now. Sorry about the early > failed start on using the external hub. > Not a problem - I'm glad it is working, makes mh seem alot more usefull if you have some hardware bringing in data and events. >> (2) Can I sort my generic items into groups, like I did with the x10 >> lights? The idea is that when I browse my groups it will show these >> generic items too. >> > > Yes. You might look at the derived .mhp file for plenty of samples. > But, nominally: > > my $genx = new Generic_Item; > my $some_group = new Group; > $some_group->add($genx); > > or, the .mht way ... > > GENERIC, genx, Some_group|Another_group > So if I have some lights in a group called 'outside', I can add the generic items to this group - or can I only create a group for certain items? > >> (3) If (1) is possible, will I be able to toggle these items and then >> because of that send an xPL message? >> > > ... assuming it is possible, then just "tie an event" to the item's > state like so: > > $genx->tie_event('xpl_send_hook()'); > > sub xpl_send_hook { > # send an osd basic message the ol' fashioned away > xAP::sendXpl('*','stat', > 'osd.basic' => { command => 'write', delay => '10', > text => "State of " . $genx->{object_name} . " is $state"}); > # or, the new "cool" way (if you have the latest out of svn) > # &main::display_xpl("State of " . $genx->{object_name} > # . " is $state"); > > } > I've got subversion installed on my box - but I'm not exactly sure what I need to run to get the latest version - couldn't find anything on the wiki, any ideas ? > There are really a lot of options for implementing #3. The tie_event > just provides an easy "event" handler. Note, however, that it will fire > *anytime* $genx's state is set (regardless of the method used (i.e., not > from web) and whether the state has actually changed). Additional logic > would be required to qualify the event if needed/desired. As an > example, you could embed some variant of the following in your event "hook": > > # find out who set genx: > my $setter_name = $genx->get_set_by(); > # see if it was set by a web user... > if ($setter_name =~ /^web/i) { > # do something when a web user set genx > } > So it will call this method(hook) even if I set the state to the same value again ? I don't think it should be too big a problem. Is there a way that I can find out what the previous state was before the hook method was called ? Thanks for all the help, Regards, Tom |
From: Matthew W. <mat...@us...> - 2006-09-28 14:21:27
|
Tom Van den Bon wrote: > I've got subversion installed on my box - but I'm not exactly sure what > I need to run to get the latest version - couldn't find anything on the > wiki, any ideas ? Here is a link to the misterhouse subversion wiki page: http://misterhouse.wikispaces.com/Subversion Let me know if you want more info. Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Tom V. d. B. <tv...@sc...> - 2006-09-28 14:29:43
|
Hi Matt, Thanks for the info - don't know how I could have missed that. Thanks, Tom Matthew Williams wrote: > Tom Van den Bon wrote: > >> I've got subversion installed on my box - but I'm not exactly sure what >> I need to run to get the latest version - couldn't find anything on the >> wiki, any ideas ? >> > > Here is a link to the misterhouse subversion wiki page: > > http://misterhouse.wikispaces.com/Subversion > > Let me know if you want more info. > > Matt > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > > |
From: Gregg L. <gr...@li...> - 2006-09-28 14:28:29
|
Hi Tom, Quoting Tom Van den Bon (9/28/06 10:14 AM): >> ... good to hear you have working listeners now. Sorry about the early >> failed start on using the external hub. >> > Not a problem - I'm glad it is working, makes mh seem alot more usefull > if you have some hardware bringing in data and events. agreed. For the record, the issue was specific to external hubs that I had not tested against; the (normal) use of the in-built mh xPL hub was unaffected. > So if I have some lights in a group called 'outside', I can add the > generic items to this group yep > - or can I only create a group for certain > items? no such limit exists > So it will call this method(hook) even if I set the state to the same > value again ? I don't think it should be too big a problem. Is there a > way that I can find out what the previous state was before the hook > method was called ? #one way is to declare a var outside of the hook that is updated by the hook: my $prior_state = '?????????'; # initialize to a state that is invalid # note, $prior_state's value won't be preserved across reloads # if this is important, then consider using the $Save hash. # then, in your "hook" sub: if ($state ne $prior_state) { # then, the state has changed # be sure to update $prior_state $prior_state = $state; } |