There is a sub in lib/Group.pm called aggregate_states. I wrote this years ago when I re-did the Web interface. As you browse groups in the "explorer", the group icon at the top of each page has a dropdown menu, which displays all states for the contained items (and items within contained groups, etc.)
The tk groups menu needs to be updated to use these actual states, instead of using the standard X10 states (x10_menu_states parameter.) Speaking of this parameter, there needs to be at least two (the other one is for house code commands and has on, off, all off, all lights on, all light off, dim and bright.)
Of course, X10_Items still needs updating to make house code commands initialize properly. Currently "all off" is mapped to "off" and "all lights on" is mapped to "on" (which makes no sense.) Look at the buttons on a maxi-controller or IR remote and realize that there are buttons for "on" and "off" (which affect all addressed units.)
Consider these two methods of turning three units on and then off (all on house code A, units 1-3.)
1. set $unit1 'manual'; set $unit2 'manual'; set $unit3 'manual'; set $house_code_a 'on'; set $house_code_a 'off';
You can't do that at all currently, and even if you could, the states of the units would not end up right (because MH doesn't call process_serial_data on sends.)
2. Serial_Item::send_x10_data(undef, 'XA1'); Serial_Item::send_x10_data(undef, 'XA2'); Serial_Item::send_x10_data(undef, 'XA3'); Serial_Item::send_x10_data(undef, 'XAJ'); Serial_Item::send_x10_data(undef, 'XAK');
This one will work (for all "fancy" X10 controllers), but as above the states aren't updated.
In send_x10_data, you have to call process_serial_data to match states (use a source of "transmit.") Otherwise the glass is only half full (state matches only happen on reception.) And obviously, the house code commands have to have proper states!
And speaking of send_x10_data, you need something like this at the top:
if (!defined $interface) {
if ($main::Serial_Ports{cm11}{object}) {
$interface = 'cm11';
}
elsif ($main::Serial_Ports{cm17}{object}) {
$interface = 'cm17';
}
elsif ($main::Serial_Ports{ti103}{object}) {
$interface = 'ti103';
}
elsif ($main::Serial_Ports{Homevision}{object}) {
$interface = 'homevision';
}
elsif ($main::Serial_Ports{HomeBase}{object}) {
$interface = 'homebase';
}
elsif ($main::Serial_Ports{Stargate}{object}) {
$interface = 'stargate';
}
elsif ($main::Serial_Ports{Lynx10PLC}{object}) {
$interface = 'lynx10plc';
}
}
That one lunkhead who tried to rearrange all of the X10 code (over the last few months, since he locked out my changes), has done nothing positive at all. His justification for the rewrites was to support the CM15a. Too bad that doesn't work as the CPAN CM15a module is far from finished. I submitted a complete treatment for the CM15a (Windows only) a month and a half ago, but have yet to see it posted to the test version. It may not have been perfect, but it was very simple to drop in, compatible with all of the previous MH X10 code (even the new crap) and is based on the approved SDK, not a bunch of guesswork. How many years until this app supports ActiveHome Pro? Certainly the CM11a is out of style at this point and the Lynx is discontinued.
