I wrote this module in early 2005 (change logs don't reflect anything as they keep sloppy records.)
@item_states = @{$ref->{states}} if $ref and $ref->{states} and !$ref->isa('X10_Sensor') and !$ref->isa('X10_Item'); #***Use the first item found with states for the moment (Need to fix this to aggregate states!)
That comment is ancient. &aggregate_states is in the module and should be called on startup. You don't use the states from the first item in the group for the entire group.
sub fancy_controller { #check if controller is type to combine
}
sub include_in_group { #check if X10 item is affected by group
#check that length > 2 (don't set controllers)
#check it is not a transmitter (?)
}
These are orphaned (as well as empty.) They aren't needed, but would have made the code easier on the eyes. I admit this code is messy, but I wrote it right after I downloaded MH (the old group code was typically brain-dead.) And of course, a general cleanup of this module was on the agenda before the "twit rebellion" of Spring 2006.
$can_combine = ($ref->{interface} =~ /cm11|ncpuxa|homebase|stargate|lynx/i) if is_group_x10_item($ref);
Add cm15 to that list. Obviously it supports manual addressing.
Interesting that the one guy's "claim to fame" is the addition of the X10_Interface module, which was supposed to allow support for USB controllers (which were alleged to be very different from the old serial controllers.) Hmmm. What does the /S/ in USB stand for again? I didn't use any calls to this new module in my CM15a implementation. It works exactly like the CM11a, Lynx10PLC, etc. Stands to figure that X10_Interface was a complete waste of time (and unthinkably added right before last Fall's interim release.)
One other note: once the "N" command (all lights off) is added to the various X10 controller modules (one of these years I guess), this can be further optimized. Only caveat is that X10_Items need a property to determine if they are wall switches or lamps (wall switches respond to "N", lamps do not.)
