Jim, I added the code for creating "First-Order/Top-Level" objects dynamically.  The result are variables that look like $upstairs_thermo_mode_item rather than $$upstairs_thermo{mode_item}.  It is around line 493:

On Mon, Mar 25, 2013 at 5:18 PM, Kevin Robert Keegan <kevin@krkeegan.com> wrote:
No problem, I did discover a way to dynamically create variables that are user friendly.  The discovery actually came from a 2007 post by Gregg which led me to x10_items_commands.pl.  It uses the eval command to allow the creation of the following variable structure:
$upstairs_thermo -- this is defined in the mht file
$upstairs_thermo_mode_item - These are all created automatically when the upstairs_thermo item is initialized.
$upstairs_thermo_humidity_item --same
$upstairs_thermo_setpoint_h_item --same

This seems to accomplish what I need for these items.  I think it works well for them because nothing else will need to be "linked" to these child items.  

There are other scenarios that this won't work for, such as a keypadlinc which has multiple buttons (technically my thermostat has multiple groups too).  In these cases the child items need to be populated much sooner than when the object is initialized.  This would likely have to be added to the read_table_a script.  But this problem is for another day.

On Mon, Mar 25, 2013 at 5:04 PM, Jim Duda <jim@duda.tzo.com> wrote:
On 03/24/2013 11:23 PM, Kevin Robert Keegan wrote:
> Jim,
> The example you are looking for are in this file:
> https://github.com/krkeegan/misterhouse/blob/insteon_thermo_i2/lib/Insteon/Thermostat.pm
> around line 487.


Thank you for the pointer, that's exactly what I wanted to see.  I too do very similar
child object population in my some of my objects.  I didn't however even consider attempting
to register them with MH as you did.  That's really cool.  I need to play with this some
myself to comment further.

I added extensions to the stuff I did for the android app to allow child objects to appear
on the android app, while they are not ever visible within MH or the web browser.  If I
had done the MH registration, as you did, I might not have had to go through the hoops I did.

I don't yet fully understand your entire list of possibly ways to handle child objects.
I promise to think about this in more detail when I get some time to play again.
I contend that it's important to take this further and find a way to allow child objects
to live within parent objects.  I think it would be beneficial to keep this in
hierarchical "containers".

Maybe (realize I haven't even looked or considered) it would be possible to somehow
extend the set label to make the names more use friendly.

I still haven't even had a chance to play with the other feature you showed me last
week in regards to being able to have object interface with each other as sub objects.
I still need to understand where all of the magic really happens.



Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365