Re: [mh] insteon weirdness

My goal in using tie_items to link the keypad and the inline module is to
keep the states consistent.  Ideally, in the MH web interface, I would want
only a single object to represent each light.  I have hidden the module so
that now only the keypad button represents the light state.  (The keypad
itself does not control any load.)  It did mean that when I change the state
of the "light" (kp button) in the web interface though, the module didn't
follow.

I guess another goal is to avoid having additional scenes that don't
correspond to a physical button (i.e. plm scenes) -- to keep the physical to
logical mapping as clear as possible to non-programmers.

How would you have done this (with these constraints)?  Expose only the
module item and hide the KP button?

If this isn't the proper use of tie_items(), what is it for?

-tom


-----Original Message-----
From: Gregg Liming [mailto:gr...@li...] 
Sent: Monday, September 29, 2008 9:04 PM
To: tma...@sa...
Subject: Re: [mh] insteon weirdness

Tom MacLean wrote:
 > Gregg pointed out that I didn't include enough information... so here 
we are:
 >
 > I'm using a recent svn version:  1505 (Sep 13, 2008)
 >
 > My (only) table and code files are attached.
 >
 > I don't have access to my logs right now.  They're scrolling on the 
terminal at home, and as far as I can tell, not being logged to a file. 
  The snippet when I press the Sink Light controller and all the other 
lights come on is in the email below.  A logfile with all the log links 
output is attached.

This info helps a good deal.  However, seeing the command(s) that is 
sent in advance of the spew of "15"s is needed.  More comments below:


 > Just yesterday I had an electrician in to install some potslights and 
pendant lights in my kitchen.  In order to facilitate independant 
control of the two, I removed the old switch (hard wiring the circuit 
ON) and replaced it with a keypad link.  I then used two inline dimmer 
modules to control the potlights and pendants seperately.  I had 
previously linked them to the keypad using misterhouse -- and they 
seemed to work.  In fact, once installed, it all seemed to work.  There 
was one glitch that when I updated the switch condition from the web, 
the module didn't also update.

That doesn't make sense to even attempt.  These "switch"(es) 
($Kitchen_Pendants and $Kitchen_Potlights) are both buttons.  You can't 
rationally attempt to control their state from the web (even though it 
is possible to try).  Their definitions (as you have included in the 
insteon.mht) assume that the buttons are locally pushed (i.e., via a 
human--not via mh and it's web interface).  So, of course there won't be 
any updating of your responders (the "modules") because the actual 
device (button) was not being depressed.  If you want an equivalent 
scene, then you will have to separately create new scenes where the plm 
is the controller (vice one of the keypadlinc buttons).

 > I added
 >
 > $Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
 > $Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
 >
 > to my insteon.pl code file ... and I think that fixed that little 
detail.

That is going to backfire on you.  Possibly, it's a part of the problem 
that you are experiencing.  While it seemed to resolve what you 
perceived as a problem, the real problem is that you were trying to 
abuse keypadlinc buttons in ways that aren't intended and can't work. 
Instead, use plm-controlled scenes if you want to control things via a 
web interface.

My suggestion is that you immediately get rid of the above tie_items code.

 > I notice the modules use a slower ramp rate than I expected (when 
updated from the web), but that doesn't concern me.

That makes perfect sense.  The scene definitions w/ the shorter ramp 
rate weren't being used--as discussed above.  Instead, the tie items 
code took over and issued direct commands which honor the local ramp 
rate (whatever it is set to).  Again, ditch the tie items code and don't 
try to set keypadlinc buttons from the web interface.

 > This morning weirdness broke out...
 >
 > I also have a dimmer on a light over my kitchen sink.  It's not 
linked to anything, except the PLM.  I turned on the Sink light this 
morning and all the potlights and pendants came on too! I notice the 
slower ramp rate occurs here too.  I have no idea why the Sink light 
controller is turning everything on!

 From your link logs, I don't yet see any "smoking gun".  But, I do want 
you to get rid of your insteon.pl code and do a full restart (not a 
reload).  Then, see if you can repeat the problem by turning on the sink 
light.  Be sure to include the entire log from mh startup (as you had 
recently included) up to the point of the problem (actually, a few 
seconds later).

 > In the logs I see lots of "Interface Extremely Busy"

It seems as though your other lights are being coupled in and the 
tie_items code is going to queue commands real fast--which doesn't help 
anything.

 > and then my "command:13; type:alllink; group: 01" -- this doesn't 
look familiar to me.

That actually does look correct as it is the received scene command that 
your sink switch is sending back to the plm.  It's everything else which 
seems a bit off.

Gregg