Re: [mh] KPLs and surrogates

[Gregg L. <gr...@li...>]

Marc MERLIN wrote:
> On Sun, Apr 26, 2009 at 11:37:07PM -0400, Gregg Liming wrote:
>>> That said, it sounds like if I need one scene per button per KPL, that would
>>> already be 32 scenes just for the buttons, and it's not worth it,
>> Arriving late at the conversation, but the PLM can handle 2016 links. 
>> So, designating 32 scenes for buttons would leave you with 1984.  I'm 
>> guessing/assuming that might be enough for anything else?
> 

... not sure what I was thinking.  Yes, the link table is that big; but, 
the all-link group part of the all-link message sent by the PLM is just 
a byte.  So, that pretty much limits the number of distinct links where 
the PLM is a controller to 255.

> Yes, it sure is. I guess I felt my insteon.mht file was getting a bit out of
> hand, but I think I'll just need to get over that and move on :)

So, the worst case for your four KPLs if none of them are cross-linked 
is 28 (not 32) scenes used as "surrogates".  But, let's suppose that 
seven of the buttons (the non-root ones) are cross-linked.  Then, my 
approach would be to create 7 PLM-controlled scenes (not 28).  This will 
somewhat reduce your mht "bloat" and (IMO) more importantly, cut down on 
excess powerline spamming.

>> Something that I should probably consider in the revision is to allow a 
>> multi-element "surrogate".  This way, a multi-way, KPL set could be 
>> controlled w/ a single scene.  On the other hand, I've never yet heard 
>> of anyone running out of PLM scenes.
>  
> Understood. So for now, if I have 4 KPL buttons linked to one lamp, I need
> to create 4 separate surrogates, ties all 4 to my lamp, and switching lamp
> status in mh would then automatically update the status of my 4 kpls. Right?

You can.  But, note my suggested approach above.  If it were me, I'd 
create just one scene to control the button lights.  And, of course this 
doesn't make sense to use the "surrogate" keyword here since you'd be 
trying to control the PLM scene rather than thinking of setting state 
for a single button.  You'd have a single tie between the one plm scene 
and your lamp.

>>> I think I got it, thanks for the explanations.
>>> Sounds like I'm either going to have to create a bunch of dummy scenes and
>>> then tie all those KPL buttons to whichever device they're linked on, or
>>> just change all my code that accesses devices directly and replace some
>>> calls to talk to scenes instead of the device name instead.
>> The current implementation and the one(s) following will permit the 
>> level of flexibility to permit either option.  Personally, I don't just 
>> create surrogate scenes unless I know they're needed.  Likewise, I don't 
>> sweat the number of allowed PLM scenes (as I can't possibly conceive of 
>> a house that I wish to pay the electric bill for w/ 2016/8 KPLs).  In 
>> general, the design is to allow the user the flexibility to do as they 
>> wish; and, that philosophy will continue.
> 
> That's quite fair. Both options are fine, I was mostly making sure/half
> thinking aloud what the options were and which would work the best for me.
> 
> If I tie surrogate scenes to $some_lamp, and I do $some_lamp->request_status
> (I have a cron job that does that every 15mn to make sure mh didn't get out
> of sync with reality), if request_status causes a state_change event, would
> that also call the surrogates, or would every request_status trigger the
> surrogates even if there is no state change?

Yes, if using a "simple" tie because a successful request_status will 
cause a state update (even if the value is the same).  If it were me, 
I'd make sure that there was a state change to reduce any further 
powerline spamming.

> (both would work for me, and if
> at least one is true, I'll definitely want to go the surrogate way).

If it were me, I'd be quite worried about introducing the amount of 
powerline traffic that you're considering every 15 minutes.

Gregg