From: Tom M. <tma...@sa...> - 2008-09-29 14:31:53
|
Greetings! Sigh. Me again. More help please! 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. 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. I notice the modules use a slower ramp rate than I expected (when updated from the web), but that doesn't concern me. 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! In the logs I see lots of "Interface Extremely Busy" and then my "command:13; type:alllink; group: 01" -- this doesn't look familiar to me. Can anyone suggest what I might have done wrong? Thanks, Tom M. 09/29/08 08:44:02 AM [Insteon_PLM] Parsing serial data: 15 09/29/08 08:44:02 AM [Insteon_PLM] Interface extremely busy. Resending command after delaying for 1 second 09/29/08 08:44:03 AM [Insteon_PLM] Parsing serial data: 15 09/29/08 08:44:03 AM [Insteon_PLM] Interface extremely busy. Resending command after delaying for 1 second 09/29/08 08:44:04 AM [Insteon_PLM] Parsing serial data: 1515 09/29/08 08:44:04 AM [Insteon_PLM] Interface extremely busy. Resending command after delaying for 1 second 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02500c6736000001cb1300 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group: 01 09/29/08 08:44:05 AM [Insteon_Device] found: off 09/29/08 08:44:05 AM [Insteon_PLM] Processing message for $Kitchen_Sink 09/29/08 08:44:05 AM [Insteon_Device] $Kitchen_Sink::set(off, Insteon_Link=HASH(0xb2dc2ac)) 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02620d66bb0f130006 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02620d66bb0f130006 09/29/08 08:44:06 AM [Insteon_PLM] Parsing serial data: 15 09/29/08 08:44:06 AM [Insteon_PLM] Interface extremely busy. Resending command after delaying for 1 second |
From: Gregg L. <gr...@li...> - 2008-09-29 15:05:23
|
Tom MacLean wrote: > Sigh. Me again. More help please! http://misterhouse.wikispaces.com/Insteon+Devices+-+Quirks+and+Hints#gettinghelp |
From: Tom M. <tma...@sa...> - 2008-09-29 17:17:21
Attachments:
insteon.pl
insteon.mht
|
Command: mh Pgm path : . Pgm version: mh 2.104 R1505 Last updated: Tue Sep 2 08:07:46 2008 Perl version: 5.008008 OS version: linux linux Other : user=mh pid=9162 box=sonya.sandbox.ca cpu=- Read parameter files: ./mh.ini ./mh.private.ini /home/mh/mh.private.ini Debugging for insteon turned on Code Directories: - /home/mh/code - ./../code/common Loading other modules Starting setup - using simple Text distance function - reading previous log files - archiving previous /home/mh/data/logs/*.log files .... - read 2 trigger entries - creating http on tcp 8080 buffered - creating server mhsend on tcp 8084 buffered - creating server telnet on tcp 1234 raw - creating xap_send on udp 3639 send - creating xap_hub_listen on udp 3639 listen - mh in xAP Hub mode - creating xap_listen_core on udp 49152 listen - creating xap_send_49152 on udp 49152 send - creating xpl_send on udp 3865 send - creating xpl_listen on udp 49153 listen - creating xpl_hub_listen on udp 3865 listen - mh in xPL Hub mode - creating xpl_send_49153 on udp 49153 send 09/29/08 01:05:02 PM [Insteon_PLM] serial:/dev/ttyS0:19200 - creating Insteon PLM port on /dev/ttyS0 - process id 9162 written to /home/mh/data/mh.pid - external command file (xcmd_file): ./../house_cmd.txt - HTML file : ./../web/ia5/index.shtml Done with setup 09/29/08 01:05:02 PM Reading /home/mh/mh.private.ini and mh.ini html_alias alias /rrd dir does not exist, dir=/home/mh/data/rrd Voice names: female, male1, male2, male3 Read 4 entries from ./../data/pronouncable_words.list 09/29/08 01:05:02 PM Reading 1 .mht table files: insteon.mht 09/29/08 01:05:02 PM Translating insteon.mht -> /home/mh/code/insteon.mhp 09/29/08 01:05:02 PM Initialized read_table_A.pl Reading code_dirs: /home/mh/code ./../code/common 09/29/08 01:05:02 PM Reading 17 code files 09/29/08 01:05:02 PM Evaluating user code 09/29/08 01:05:02 PM [Insteon_PLM] setting default xmit delay to: 0.25 09/29/08 01:05:02 PM [Insteon_PLM] setting x10 xmit delay to: 0.5 Good code saved running: play ./../sounds/sound_click1.wav Restoring object states Object states restored Activating voice commands Starting monitor commands loop Latitude: 44.0817, Longitude: -92.5038, Time Zone: -6 sunrise=7:06 AM sunset=6:53 PM sunrise twilight=6:37 AM sunset twilight=7:22 PM The moon is New, 0% bright, and 0 days old The next full moon is on Thursday, November 13th 09/29/08 01:05:03 PM [Insteon_PLM] Parsing serial data: 026005e8a903055206 09/29/08 01:05:03 PM [Insteon_PLM] PLM id: 05e8a9 firmware: 52 09/29/08 01:05:03 PM Generating Voice commands for all Insteon objects 09/29/08 01:05:03 PM Rereading .menu code files. Display call with tk disabled (-tk 0). Text=MisterHouse restarted unexpectedly! 0 09/29/08 01:05:03 PM Organizer: Calendar matches target schema and does not require upgrading 09/29/08 01:05:03 PM Organizer: Todo matches target schema and does not require upgrading 09/29/08 01:05:03 PM Organizer: Reading updated organizer calendar file now 09/29/08 01:05:03 PM Evaluating code organizer_events 09/29/08 01:05:03 PM Organizer: Reading updated organizer todo file 09/29/08 01:05:03 PM Evaluating code organizer_tasks 09/29/08 01:06:00 PM: Saving object states ... done 09/29/08 01:07:00 PM: Saving object states ... done 09/29/08 01:07:45 PM menu_run: g=mh m=Insteon i=9 s=4 => action: myPLM 'log links' 09/29/08 01:07:45 PM Running: myPLM log links 09/29/08 01:07:45 PM [Insteon_PLM] responder record to $Kitchen_Sink(01) (d1=00, d2=00, d3=00) 09/29/08 01:07:45 PM [Insteon_PLM] responder record to $Kitchen_Potlights(01) (d1=00, d2=00, d3=00) 09/29/08 01:07:45 PM [Insteon_PLM] responder record to $Kitchen_Pendants(03) (d1=00, d2=00, d3=00) 09/29/08 01:07:45 PM [Insteon_PLM] responder record to $Kitchen_KP_4(04) (d1=00, d2=00, d3=00) 09/29/08 01:07:45 PM [Insteon_PLM] cntlr(a0) record to $Kitchen_Pendants (d1=01, d2=00, d3=03) 09/29/08 01:07:45 PM [Insteon_PLM] cntlr(a1) record to $Kitchen_KP_4 (d1=01, d2=00, d3=04) 09/29/08 01:08:00 PM: Saving object states ... done 09/29/08 01:08:19 PM menu_run: g=mh m=Insteon i=5 s=7 => action: Kitchen Sink 'log links' 09/29/08 01:08:19 PM Running: Kitchen Sink log links 09/29/08 01:08:19 PM [Insteon_Device] link table for $Kitchen_Sink (devcat: 0101): 09/29/08 01:08:19 PM [Insteon_Device] aldb 05e8a9011 [0x0FF8] contlr(01) record to $myPLM(01), (d1:fe, d2:1f, d3:00) 09/29/08 01:08:19 PM [Insteon_Device] adlb [0x0FF0] is empty 09/29/08 01:08:49 PM menu_run: g=mh m=Insteon i=4 s=7 => action: Kitchen Potlights 'log links' 09/29/08 01:08:49 PM Running: Kitchen Potlights log links 09/29/08 01:08:49 PM [Insteon_Device] link table for $Kitchen_Potlights (devcat: 0109): 09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a9011 [0x0FF8] contlr(01) record to $myPLM(01), (d1:fe, d2:1f, d3:01) 09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a903103 [0x0FF0] contlr(03) record to $myPLM(03), (d1:fe, d2:1f, d3:03) 09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a904104 [0x0FE8] contlr(04) record to $myPLM(04), (d1:fe, d2:1f, d3:04) 09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a9a0003 [0x0FE0] rspndr(03) record to $myPLM(a0): onlevel=on and ramp=none (d3:03) 09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a9a1004 [0x0FD8] rspndr(04) record to $myPLM(a1): onlevel=on and ramp=none (d3:04) 09/29/08 01:08:49 PM [Insteon_Device] aldb 0d6906031 [0x0FD0] contlr(03) record to $Kitchen_Pendants_module(01), (d1:ff, d2:1f, d3:01) 09/29/08 01:08:49 PM [Insteon_Device] adlb [0x0FC8] is empty 09/29/08 01:09:00 PM: Saving object states ... done 09/29/08 01:09:12 PM menu_run: g=mh m=Insteon i=3 s=10 => action: Kitchen Potlights module 'log links' 09/29/08 01:09:12 PM Running: Kitchen Potlights module log links 09/29/08 01:09:12 PM [Insteon_Device] link table for $Kitchen_Potlights_module (devcat: 0102): 09/29/08 01:09:12 PM [Insteon_Device] aldb 0e2dec010 [0x0FF8] rspndr(01) record to $Kitchen_Potlights(01): onlevel=100% and ramp=0.1s (d3:00) 09/29/08 01:09:12 PM [Insteon_Device] adlb [0x0FF0] is empty 09/29/08 01:10:00 PM: Saving object states ... done 09/29/08 01:10:19 PM menu_run: g=mh m=Insteon i=1 s=10 => action: Kitchen Pendants module 'log links' 09/29/08 01:10:19 PM Running: Kitchen Pendants module log links 09/29/08 01:10:19 PM [Insteon_Device] link table for $Kitchen_Pendants_module (devcat: 0102): 09/29/08 01:10:19 PM [Insteon_Device] aldb 0e2dec0301f [0x0FF8] rspndr(1f) record to $Kitchen_Potlights(03): onlevel=100% and ramp=0.1s (d3:1f) 09/29/08 01:10:19 PM [Insteon_Device] adlb [0x0FE8] is empty 09/29/08 01:10:19 PM [Insteon_Device] adlb [0x0FF0] is empty 09/29/08 01:10:25 PM menu_run: g=mh m=Insteon i=1 s=8 => action: Kitchen Pendants module 'status' 09/29/08 01:10:25 PM Running: Kitchen Pendants module status 09/29/08 01:10:25 PM [Insteon_PLM] Parsing serial data: 02620d69060f190006 09/29/08 01:10:26 PM [Insteon_PLM] Parsing serial data: 02500d690605e8a92b0000 09/29/08 01:10:26 PM [Insteon_PLM] Processing message for $Kitchen_Pendants_module 09/29/08 01:10:26 PM [Insteon_Device] received status request report for $Kitchen_Pendants_module with on-level: 0%, hops left: 2 09/29/08 01:11:00 PM: Saving object states ... done 09/29/08 01:12:00 PM: Saving object states ... done |
From: Gregg L. <gr...@li...> - 2008-09-30 01:01:53
|
Tom MacLean wrote: > Gregg pointed out that I didn't include enough information... so here we > are: FYI - I've tried repeatedly to respond via sf's list and no joy. So, I'll try to send you responses from here out to your private email. If that works, then at least it will benefit you. Gregg |
From: Gregg L. <gr...@li...> - 2008-09-30 03:42:41
|
Gregg Liming wrote: > Tom MacLean wrote: >> Gregg pointed out that I didn't include enough information... so here we >> are: > > FYI - I've tried repeatedly to respond via sf's list and no joy. So, > I'll try to send you responses from here out to your private email. If > that works, then at least it will benefit you. I see how the incredible sf content filters work... do not attempt to use a common phrase that begins with "smoking" and ends with a device that shoots bullets. Go figure. Gregg |
From: Tom M. <tma...@sa...> - 2008-09-30 14:03:18
|
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 |
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 > |
From: Thomas M. <tma...@sa...> - 2008-09-29 23:07:14
|
In another experiment, I notice that the Sink Light turns on/off all the lights even if MH isn't running. Is the output with "type:alllink" normal? I don't think I have seen this with other switches. -Tom M. > 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group: 01 > 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. > > Thanks, > > Tom MacLean > > _____ > > From: Tom MacLean [mailto:tma...@sa...] > Sent: Monday, September 29, 2008 10:31 AM > To: mis...@li... > Subject: [mh] insteon weirdness > > > Greetings! > > Sigh. Me again. More help please! > > 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. 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. > I > notice the modules use a slower ramp rate than I expected (when updated > from > the web), but that doesn't concern me. > > 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! In the logs I see lots of "Interface Extremely Busy" and > then my "command:13; type:alllink; group: 01" -- this doesn't look > familiar > to me. > > Can anyone suggest what I might have done wrong? > > Thanks, > > Tom M. > > > 09/29/08 08:44:02 AM [Insteon_PLM] Parsing serial data: 15 > 09/29/08 08:44:02 AM [Insteon_PLM] Interface extremely busy. Resending > command after delaying for 1 second > 09/29/08 08:44:03 AM [Insteon_PLM] Parsing serial data: 15 > 09/29/08 08:44:03 AM [Insteon_PLM] Interface extremely busy. Resending > command after delaying for 1 second > 09/29/08 08:44:04 AM [Insteon_PLM] Parsing serial data: 1515 > 09/29/08 08:44:04 AM [Insteon_PLM] Interface extremely busy. Resending > command after delaying for 1 second > 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: > 02500c6736000001cb1300 > 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group: 01 > 09/29/08 08:44:05 AM [Insteon_Device] found: off > 09/29/08 08:44:05 AM [Insteon_PLM] Processing message for $Kitchen_Sink > 09/29/08 08:44:05 AM [Insteon_Device] $Kitchen_Sink::set(off, > Insteon_Link=HASH(0xb2dc2ac)) > 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02620d66bb0f130006 > 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02620d66bb0f130006 > 09/29/08 08:44:06 AM [Insteon_PLM] Parsing serial data: 15 > 09/29/08 08:44:06 AM [Insteon_PLM] Interface extremely busy. Resending > command after delaying for 1 second > ------------------------------------------------------------------------- > 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 > > |
From: Gregg L. <gr...@li...> - 2008-09-30 01:07:32
|
Thomas Maclean wrote: > In another experiment, I notice that the Sink Light turns on/off all the > lights even if MH isn't running. Well, that pretty much sounds like the link databases for your devices are not what you expect. You might try scanning the link table for--at a minimum--the sink light. Also, try the others that are affected. Doing a log link table only shows what mh understands. It is always possible to impact the device link table external from mh and mh not see it unless it rescans the tables. > Is the output with "type:alllink" normal? I don't think I have seen this > with other switches. Yes--it is very normal and will always be seen when a switch is linked back to the plm (where the plm is the controller). Gregg p.s. Crossing fingers that sf hasn't munged this response as well. |
From: Thomas M. <tma...@sa...> - 2008-09-29 23:37:56
|
I had to factory-reset the switch and relink it to the controller. Previously I had tried "Unlink from interface" and then "scan links", "log links" (output of which I took to mean the device was not linked to anything), but the unit continued to control other devices it was not linked to. -tom m. 09/29/08 07:31:42 PM [Insteon_PLM] Processing message for $Kitchen_Sink 09/29/08 07:31:50 PM [Insteon_PLM] Parsing serial data: 02500c6736000001cb1100 09/29/08 07:31:50 PM [Insteon_Device] command:11; type:alllink; group: 01 09/29/08 07:31:50 PM [Insteon_Device] found: on 09/29/08 07:31:50 PM [Insteon_PLM] Processing message for $Kitchen_Sink 09/29/08 07:31:50 PM [Insteon_Device] $Kitchen_Sink::set(on, Insteon_Link=HASH(0x9781928)) 09/29/08 07:31:50 PM [Insteon_PLM] Parsing serial data: 02500c673605e8a9 09/29/08 07:31:50 PM [Insteon_PLM] Prepending prior data fragment: 02500c673605e8a9 09/29/08 07:31:50 PM [Insteon_PLM] Parsing serial data: 02500c673605e8a9411101 09/29/08 07:31:50 PM [Insteon_Device] command:11; type:cleanup; group: 01 09/29/08 07:31:50 PM [Insteon_Device] found: on > > In another experiment, I notice that the Sink Light turns on/off all the > lights even if MH isn't running. > > Is the output with "type:alllink" normal? I don't think I have seen this > with other switches. > > -Tom M. > >> 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group: >> 01 > > >> 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. >> >> Thanks, >> >> Tom MacLean >> >> _____ >> >> From: Tom MacLean [mailto:tma...@sa...] >> Sent: Monday, September 29, 2008 10:31 AM >> To: mis...@li... >> Subject: [mh] insteon weirdness >> >> >> Greetings! >> >> Sigh. Me again. More help please! >> >> 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. 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. >> I >> notice the modules use a slower ramp rate than I expected (when updated >> from >> the web), but that doesn't concern me. >> >> 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! In the logs I see lots of "Interface Extremely Busy" and >> then my "command:13; type:alllink; group: 01" -- this doesn't look >> familiar >> to me. >> >> Can anyone suggest what I might have done wrong? >> >> Thanks, >> >> Tom M. >> >> >> 09/29/08 08:44:02 AM [Insteon_PLM] Parsing serial data: 15 >> 09/29/08 08:44:02 AM [Insteon_PLM] Interface extremely busy. Resending >> command after delaying for 1 second >> 09/29/08 08:44:03 AM [Insteon_PLM] Parsing serial data: 15 >> 09/29/08 08:44:03 AM [Insteon_PLM] Interface extremely busy. Resending >> command after delaying for 1 second >> 09/29/08 08:44:04 AM [Insteon_PLM] Parsing serial data: 1515 >> 09/29/08 08:44:04 AM [Insteon_PLM] Interface extremely busy. Resending >> command after delaying for 1 second >> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: >> 02500c6736000001cb1300 >> 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group: >> 01 >> 09/29/08 08:44:05 AM [Insteon_Device] found: off >> 09/29/08 08:44:05 AM [Insteon_PLM] Processing message for $Kitchen_Sink >> 09/29/08 08:44:05 AM [Insteon_Device] $Kitchen_Sink::set(off, >> Insteon_Link=HASH(0xb2dc2ac)) >> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: >> 02620d66bb0f130006 >> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: >> 02620d66bb0f130006 >> 09/29/08 08:44:06 AM [Insteon_PLM] Parsing serial data: 15 >> 09/29/08 08:44:06 AM [Insteon_PLM] Interface extremely busy. Resending >> command after delaying for 1 second >> ------------------------------------------------------------------------- >> 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 >> >> > > > ------------------------------------------------------------------------- > 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 > |
From: Gregg L. <gr...@li...> - 2008-09-29 19:43:07
|
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 |
From: Gregg L. <gr...@li...> - 2008-09-30 00:20:58
|
For some reason, the first attempt to respond didn't make it through to the list. So, here goes again... 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 |
From: Gregg L. <gr...@li...> - 2008-09-30 03:39:11
|
For some reason, the first attempt to respond didn't make it through to the list. So, here goes again... 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 anything unusual. 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 |