From: Gregg L. <gr...@li...> - 2008-09-30 14:32:10
|
Tom MacLean wrote: > 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. That will not be guaranteed to be accurate. Only the module should reflect 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. Not possible. > How would you have done this (with these constraints)? You can't. > Expose only the > module item and hide the KP button? I would definitely do that. > 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 > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |