Re: [mh] Development Guidance Needed for Insteon::Thermostat

[Kevin R. K. <ke...@kr...>]

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:
https://github.com/krkeegan/misterhouse/blob/insteon_thermo_i2/lib/Insteon/Thermostat.pm



On Mon, Mar 25, 2013 at 5:18 PM, Kevin Robert Keegan <ke...@kr...>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 <ji...@du...> 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.
>>
>> Kevin,
>>
>> 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.
>>
>> Regards,
>>
>> Jim
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>