From: Garry D. <gar...@sh...> - 2007-10-19 23:44:56
|
I feel a little embarassed... The bulb in the lamp connected to the Lamplinc burned out! I never thought to check the obvious before jumping to the conclusion it was the Insteon device. DOH! Sorry guys, false alarm. Garry -----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Gregg Liming Sent: Friday, October 19, 2007 4:26 PM To: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon Lamplinc Quit Working Gregg Liming wrote: > Garry Doucette wrote: >> I'm not sure what to do now but my first thought is to unplug the >> device and try relinking it again. > > Relinking it? Is this a switchlinc or keypadlinc? If not, then > there's no real need to link it unless you are experimenting w/ scenes > or set ramp rates. Perhaps you could elaborate what you did in the way of linking? Doh! Your title says Lamplinc. Ok, that makes me really suspicious about what link you did attempt to create and separately how you've declared this device in items.mht. Could you post the relevant portions? Gregg ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Garry D. <gar...@sh...> - 2007-10-20 00:32:45
|
Gregg I can only do Test #1 until I find a replacement bulb for my halogen desk lamp. Here's the results with the lamp physically switched off. 10/19/07 05:24:03 PM [Insteon_PLM] Parsing serial data: 026205cafe0f190006 10/19/07 05:24:03 PM Generating Voice commands for all Insteon objects 10/19/07 05:24:03 PM Rereading .menu code files. 10/19/07 05:24:03 PM [Insteon_PLM] Parsing serial data: 02620965aa0f190006025005cafe05e8262b0100 10/19/07 05:24:03 PM [Insteon_PLM] DELEGATE:05cafe:05e826:05cafe05e8262b0100: 10/19/07 05:24:03 PM [Insteon_PLM] Processing message for $lights_office_lamp 10/19/07 05:24:03 PM [Insteon_Device] received status request report for $lights_office_lamp with on-level: 0 10/19/07 05:24:04 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 10/19/07 05:24:04 PM [Insteon_PLM] PLM id: 05e826 firmware: 06 10/19/07 05:24:04 PM [Insteon_PLM] Parsing serial data: 02500965aa05e8262b0000 10/19/07 05:24:04 PM [Insteon_PLM] DELEGATE:0965aa:05e826:0965aa05e8262b0000: 10/19/07 05:24:04 PM [Insteon_PLM] Processing message for $lights_under_deck 10/19/07 05:24:04 PM [Insteon_Device] received status request report for $lights_under_deck with on-level: 0 Garry -----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Gregg Liming Sent: Friday, October 19, 2007 5:17 PM To: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon Lamplinc Quit Working Gregg Liming wrote: > Garry Doucette wrote: >> I feel a little embarassed... >> >> The bulb in the lamp connected to the Lamplinc burned out! >> >> I never thought to check the obvious before jumping to the conclusion >> it was the Insteon device. >> >> DOH! >> >> Sorry guys, false alarm. > > ... ummm no--not false alarm. You still should not have seen those > messages in the log. Something is still amiss. I did note that your > original log messages looked like a forced restart followed by the > "normal" startup messages. I'd still like to know what may have > caused this flury of busy messages given your relatively modest > insteon network. I'm still considering this an issue. ... so, I'm trying to do a bit of testing remotely and noticed something somewhat similar with a Lamplinc that I happened to be using for test purposes *and* that where I also happened to physically turn off the light light. Physically turning off the light is no different than a burned out bulb. So, now this is really making me wonder whether the lamplinc defers an insteon ack on interrogation if it's connected lamp has infinite impedance. The bad news is that I'm not at home and I therefore can't physically turn the device back on and off. So, here's what I'm hoping you will do... Will you perform a series of tests w/ debug=insteon where test #1 is w/ your desk lamp physically off (or just hit the bulb w/ a hammer ;) ) and test #2 is w/ the desk lamp physically on. Perform each just after a forced mh restart and watch the log. I'm wondering if you see the messages suggesting that the device is stalled when the device is physically off? BTW: This is sufficiently concerning me that I wanted to offer a way of disabled the automatic scan at startup. You can set Insteon_PLM_scan_at_startup=0 if you grab the latest from svn. Please do not set it while running the experiments above if you are willing. Gregg ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Gregg L. <gr...@li...> - 2007-10-20 00:38:45
|
Garry Doucette wrote: > Gregg > > I can only do Test #1 until I find a replacement bulb for my halogen desk > lamp. > > Here's the results with the lamp physically switched off. > > 10/19/07 05:24:03 PM [Insteon_PLM] Parsing serial data: 026205cafe0f190006 > 10/19/07 05:24:03 PM Generating Voice commands for all Insteon objects > 10/19/07 05:24:03 PM Rereading .menu code files. > 10/19/07 05:24:03 PM [Insteon_PLM] Parsing serial data: > 02620965aa0f190006025005cafe05e8262b0100 > 10/19/07 05:24:03 PM [Insteon_PLM] > DELEGATE:05cafe:05e826:05cafe05e8262b0100: > 10/19/07 05:24:03 PM [Insteon_PLM] Processing message for > $lights_office_lamp > 10/19/07 05:24:03 PM [Insteon_Device] received status request report for > $lights_office_lamp with on-level: 0 > 10/19/07 05:24:04 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 > 10/19/07 05:24:04 PM [Insteon_PLM] PLM id: 05e826 firmware: 06 > 10/19/07 05:24:04 PM [Insteon_PLM] Parsing serial data: > 02500965aa05e8262b0000 > 10/19/07 05:24:04 PM [Insteon_PLM] > DELEGATE:0965aa:05e826:0965aa05e8262b0000: > 10/19/07 05:24:04 PM [Insteon_PLM] Processing message for $lights_under_deck > 10/19/07 05:24:04 PM [Insteon_Device] received status request report for > $lights_under_deck with on-level: 0 Thanks, Gary. No need for test #2 as (arguably unfortunate) test #1 is flawless. So, now I'm at a loss for explanation. Please do not hesitate to flag anything else that might seem amiss--preferably w/ accompanying logs. Thanks again for your efforts. Gregg |
From: Garry D. <gar...@sh...> - 2007-10-20 00:46:40
|
OK I thought I would try pounding away on the on off icon for the desk lamp on my N770. I think I may have reproduced it. 10/19/07 05:36:36 PM Insteon_Device: $lights_office_lamp::set(on, web) 10/19/07 05:36:36 PM [Insteon_PLM] Parsing serial data: 026205cafe0f11ff06 10/19/07 05:36:36 PM [Insteon_PLM] Parsing serial data: 025005cafe05e826ab11fe 10/19/07 05:36:36 PM [Insteon_PLM] DELEGATE:05cafe:05e826:05cafe05e826ab11fe: 10/19/07 05:36:36 PM [Insteon_PLM] Processing message for $lights_office_lamp 10/19/07 05:36:36 PM [Insteon_Device] WARN!! ia a nack message for $lights_office_lamp ... skipping 10/19/07 05:36:38 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/19/07 05:36:38 PM [Insteon_PLM] Parsing serial data: 026205cafe0f130006 10/19/07 05:36:39 PM [Insteon_PLM] Parsing serial data: 025005cafe05e826ab13fe 10/19/07 05:36:39 PM [Insteon_PLM] DELEGATE:05cafe:05e826:05cafe05e826ab13fe: 10/19/07 05:36:39 PM [Insteon_PLM] Processing message for $lights_office_lamp 10/19/07 05:36:39 PM [Insteon_Device] WARN!! ia a nack message for $lights_office_lamp ... skipping 10/19/07 05:36:39 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/19/07 05:36:39 PM [Insteon_PLM] Parsing serial data: 026205cafe0f130006 10/19/07 05:36:39 PM [Insteon_PLM] Parsing serial data: 025005cafe05e826 10/19/07 05:36:39 PM [Insteon_Device] command:; type:direct; group: 10/19/07 05:36:39 PM [Insteon_PLM] DELEGATE:05cafe:05e826:05cafe05e826: 10/19/07 05:36:39 PM [Insteon_PLM] Processing message for $lights_office_lamp 10/19/07 05:36:39 PM Insteon_Device: $lights_office_lamp::set(, Insteon_PLM=HASH(0x95221a8)) 10/19/07 05:36:40 PM [Insteon_PLM] Parsing serial data: ab13fe 10/19/07 05:36:42 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/19/07 05:36:42 PM [Insteon_PLM] Prepending prior data fragment: ab13fe 10/19/07 05:36:42 PM [Insteon_PLM] Parsing serial data: ab13fe026205cafe0f130006 10/19/07 05:36:42 PM [Insteon_PLM] Prepending prior data fragment: ab13fe026205cafe0f130006 10/19/07 05:36:42 PM [Insteon_PLM] Parsing serial data: ab13fe026205cafe0f130006025005cafe05e826ab13fe 10/19/07 05:36:42 PM [Insteon_PLM] DELEGATE:05cafe:05e826:05cafe05e826ab13fe: 10/19/07 05:36:42 PM [Insteon_PLM] Processing message for $lights_office_lamp 10/19/07 05:36:42 PM [Insteon_Device] WARN!! ia a nack message for $lights_office_lamp ... skipping 10/19/07 05:36:44 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/19/07 05:36:46 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/19/07 05:36:49 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/19/07 05:36:51 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/19/07 05:36:53 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/19/07 05:37:09 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Trying next command if queued. 10/19/07 05:37:09 PM Insteon_Device: $lights_office_lamp::set(on, web) 10/19/07 05:37:24 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend 10/19/07 05:37:39 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend 10/19/07 05:37:54 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Trying next command if queued. The lamp is physically turned off. Obviously, this is a pretty unusual circumstance but it makes sense now. When it happened the first time the button didn't turn the lamp on (the bulb was burnt - same as being turned off) so in my frustration I hit the button a bunch of times which resulted in the above. Garry -----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Gregg Liming Sent: Friday, October 19, 2007 5:21 PM To: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon Lamplinc Quit Working Neil Cherry wrote: > Gregg Liming wrote: >> Garry Doucette wrote: >>> I feel a little embarassed... >>> >>> The bulb in the lamp connected to the Lamplinc burned out! >>> >>> I never thought to check the obvious before jumping to the >>> conclusion it was the Insteon device. >>> >>> DOH! >>> >>> Sorry guys, false alarm. >> ... ummm no--not false alarm. You still should not have seen those >> messages in the log. Something is still amiss. I did note that your >> original log messages looked like a forced restart followed by the >> "normal" startup messages. I'd still like to know what may have >> caused this flury of busy messages given your relatively modest >> insteon network. I'm still considering this an issue. >> >> Gregg > > I don't know it sounds like the LampLinc was sending a NAK. I wonder > what values were being returned with it? > Given the pattern shown by the log messages, it was likely a "busy" NAK--not one appended to the end of a serial command. However, we don't know w/o a debug log. BTW: The symptoms of PLM lockups are that the NAKs *never* stop (until the PLM is unplugged and mh restarted). I've personally seen that and it's not what Gary's log (albeit sparse) showed. Gregg ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Gregg L. <gr...@li...> - 2007-10-20 00:52:27
|
Garry Doucette wrote: > I thought I would try pounding away on the on off icon for the desk lamp on > my N770. I think I may have reproduced it. Thanks Gary! I'll work on ways to throttle (figuratively) those w/ heavy fingers (likely, limiting repeat commands per some sliding time window and, optionally, limiting repeat states). I've seen this type of behavior in different ways and wondered if it could happen. Obviously, frustrated users are quite capable of causing it! You seem to be the first insteon DOS attacker ;) [ please stay clear of my house ] Gregg |
From: Gregg L. <gr...@li...> - 2007-10-20 02:10:45
|
... not quite content, I've been further scrutinizing your logs and ... Quoting Garry Doucette <gar...@sh...>: > I thought I would try pounding away on the on off icon for the desk lamp o= n > my N770. I think I may have reproduced it. > > 10/19/07 05:36:36 PM Insteon_Device: $lights_office_lamp::set(on, web) > 10/19/07 05:36:36 PM [Insteon_PLM] Parsing serial data: 026205cafe0f11ff06 > 10/19/07 05:36:36 PM [Insteon_PLM] Parsing serial data: > 025005cafe05e826ab11fe > 10/19/07 05:36:36 PM [Insteon_PLM] > DELEGATE:05cafe:05e826:05cafe05e826ab11fe: > 10/19/07 05:36:36 PM [Insteon_PLM] Processing message for > $lights_office_lamp > 10/19/07 05:36:36 PM [Insteon_Device] WARN!! ia a nack message for > $lights_office_lamp ... skipping This is really interesting! It seems that the LampLinc realizes that=20 it can't actually turn on the real device. I need to test this more=20 (when I return home) as I can see some real potential for leveraging=20 this info. You see, the PLM happlily accepted the command and=20 forwarded it to the Lamplinc. In turn, the LampLinc responded w/ a=20 NACK--which I've not personally seen before--but, then again all my=20 lights are fully functioning. The reason for possible excitement is=20 that I may be able to expose such a condition to some alert (e.g.,=20 speak, display, etc.) to notify you when your light has been turned off=20 or a lamp burned out. Obviously, you don't want such alerts=20 universally enforced, but I would quite like it if mh told me when I=20 had a bulb outside burned out. [...snip...] uh-oh, trouble ahead... > 10/19/07 05:36:39 PM Insteon_Device: $lights_office_lamp::set(off, web) > 10/19/07 05:36:39 PM [Insteon_PLM] Parsing serial data: 026205cafe0f130006 > 10/19/07 05:36:39 PM [Insteon_PLM] Parsing serial data: 025005cafe05e826 > 10/19/07 05:36:39 PM [Insteon_Device] command:; type:direct; group: > 10/19/07 05:36:39 PM [Insteon_PLM] DELEGATE:05cafe:05e826:05cafe05e826: > 10/19/07 05:36:39 PM [Insteon_PLM] Processing message for > $lights_office_lamp Darn it, don't blindly accept whatever comes across since--as in this=20 case--the message was fragmented. I have been meaning to add=20 validation code to restict and detect invalid fragments. Now, I know I=20 must. > 10/19/07 05:36:39 PM Insteon_Device: $lights_office_lamp::set(, > Insteon_PLM=3DHASH(0x95221a8)) The first argument above and in front of the set comma should have been=20 state--instead undef exists. Bad. > 10/19/07 05:36:40 PM [Insteon_PLM] Parsing serial data: ab13fe And, here's why... the fragment finally shows up. So, while I did add=20 early fragment detection (you'll see an attempt from your original=20 message), I need to detect late fragments as well. This is really a key find as it does impact reliability in high traffic=20 conditions. Thanks so much Gary! Once I am able to work a solution=20 and test it, I'll let you know that you can resume your insteon abusing=20 behaviors. Gregg |
From: Garry D. <gar...@sh...> - 2007-10-20 01:01:42
|
LOL That's two houses I've told to steer clear, yours and the wife's! :-) Garry -----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Gregg Liming Sent: Friday, October 19, 2007 5:52 PM To: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon Lamplinc Quit Working Garry Doucette wrote: > I thought I would try pounding away on the on off icon for the desk > lamp on my N770. I think I may have reproduced it. Thanks Gary! I'll work on ways to throttle (figuratively) those w/ heavy fingers (likely, limiting repeat commands per some sliding time window and, optionally, limiting repeat states). I've seen this type of behavior in different ways and wondered if it could happen. Obviously, frustrated users are quite capable of causing it! You seem to be the first insteon DOS attacker ;) [ please stay clear of my house ] Gregg ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Garry D. <gar...@sh...> - 2007-10-30 15:47:50
|
Hi Guys I had a hard drive crash in my server and I reinstalled everything from scratch. My Insteon devices were working perfectly for awhile and now they stopped working again. Items.mht: # A switchLinc module for my PLM to control IPLD, 05.CA.FE, lights_office_lamp, All_Lights|Office, myPLM IPLD, 09.65.AA, lights_under_deck, All_Lights|Exterior, myPLM mh.private.ini entry: Insteon_PLM_serial_port=/dev/ttyS2 I haven't used any user code yet. I'm using the IA5 web interface. Log printout: The next full moon is on Saturday, November 24th 10/30/07 09:37:54 AM [Insteon_PLM] Parsing serial data: 026205cafe0f190006 10/30/07 09:37:54 AM Generating Voice commands for all Insteon objects 10/30/07 09:37:54 AM Rereading .menu code files. 10/30/07 09:37:54 AM [Insteon_PLM] Parsing serial data: 02620965aa0f190006025005cafe05e8262b00fe 10/30/07 09:37:54 AM [Insteon_PLM] DELEGATE:05cafe:05e826:05cafe05e8262b00fe: 10/30/07 09:37:54 AM [Insteon_PLM] Processing message for $lights_office_lamp 10/30/07 09:37:54 AM [Insteon_Device] received status request report for $lights_office_lamp with on-level: 254 10/30/07 09:37:54 AM [Insteon_PLM] Parsing serial data: 026005e82603055206c8906200 10/30/07 09:37:54 AM [Insteon_PLM] PLM id: 05e826 firmware: 06 10/30/07 09:37:54 AM [Insteon_PLM] Prepending prior data fragment: c8906200 10/30/07 09:37:54 AM [Insteon_PLM] Parsing serial data: c8906200f8 10/30/07 09:38:00 AM: Saving object states ... done 10/30/07 09:38:09 AM [Insteon_Device] WARN: queue timer on $lights_under_deck expired. Attempting resend 10/30/07 09:38:24 AM [Insteon_Device] WARN: queue timer on $lights_under_deck expired. Attempting resend 10/30/07 09:38:39 AM [Insteon_Device] WARN: queue timer on $lights_under_deck expired. Trying next command if queued. 10/30/07 09:38:44 AM menu_run: g=mh m=Insteon i=0 s=1 => action: lights office lamp 'off' 10/30/07 09:38:44 AM Running: lights office lamp off 10/30/07 09:38:44 AM Insteon_Device: $lights_office_lamp::set(off, Voice_Cmd=HASH(0x94fb450)) 10/30/07 09:38:58 AM menu_run: g=mh m=Insteon i=0 s=0 => action: lights office lamp 'on' 10/30/07 09:38:58 AM Running: lights office lamp on 10/30/07 09:38:58 AM Insteon_Device: $lights_office_lamp::set(on, Voice_Cmd=HASH(0x94fb450)) 10/30/07 09:39:00 AM: Saving object states ... done 10/30/07 09:39:07 AM menu_run: g=mh m=Insteon i=1 s=0 => action: lights under deck 'on' 10/30/07 09:39:07 AM Running: lights under deck on 10/30/07 09:39:08 AM Insteon_Device: $lights_under_deck::set(on, Voice_Cmd=HASH(0x9448c50)) 10/30/07 09:39:11 AM menu_run: g=mh m=Insteon i=1 s=1 => action: lights under deck 'off' 10/30/07 09:39:11 AM Running: lights under deck off 10/30/07 09:39:11 AM Insteon_Device: $lights_under_deck::set(off, Voice_Cmd=HASH(0x9448c50)) 10/30/07 09:39:13 AM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend 10/30/07 09:39:28 AM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend 10/30/07 09:39:43 AM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Trying next command if queued. 10/30/07 09:40:00 AM: Saving object states ... done 10/30/07 09:41:00 AM: Saving object states ... Done Any ideas? Garry |
From: Gregg L. <gr...@li...> - 2007-10-30 17:10:25
|
Quoting Garry Doucette (10/30/07 11:46 AM): > Hi Guys > > I had a hard drive crash in my server and I reinstalled everything from > scratch. > > My Insteon devices were working perfectly for awhile and now they stopped > working again. So, are you saying that they have been working fine for a while *after* you have reinstalled your server or *before*? I'm trying to understand if there might be a difference in your environment (e.g., plugging in some new signal "sucker") or your re-installation. [... snip ...] > 10/30/07 09:37:54 AM [Insteon_PLM] Parsing serial data: > 026005e82603055206c8906200 > 10/30/07 09:37:54 AM [Insteon_PLM] PLM id: 05e826 firmware: 06 > 10/30/07 09:37:54 AM [Insteon_PLM] Prepending prior data fragment: c8906200 That looks *very* suspicious as I can't place that set of chars w/ any reasonable fragment of an insteon message. I have seen cases where a message get's fragmented across serial reads. However, this looks more like "junk". > 10/30/07 09:37:54 AM [Insteon_PLM] Parsing serial data: c8906200f8 ...pretty much the same comment. A "f8" by itself??? I'm going to suggest that you svn update the insteon libs (Insteon_PLM, Insteon_Device, Insteon_Link) again as I just committed the latest. They include among other things improvements with fragment handling. I'm not convinced that it will help this; but, just in case. You will also get a bit more detailed diagnosis that may help (me--if not yourself). > 10/30/07 09:38:00 AM: Saving object states ... done > 10/30/07 09:38:09 AM [Insteon_Device] WARN: queue timer on > $lights_under_deck expired. Attempting resend > 10/30/07 09:38:24 AM [Insteon_Device] WARN: queue timer on > $lights_under_deck expired. Attempting resend > 10/30/07 09:38:39 AM [Insteon_Device] WARN: queue timer on > $lights_under_deck expired. Trying next command if queued. > 10/30/07 09:38:44 AM menu_run: g=mh m=Insteon i=0 s=1 => action: lights > office lamp 'off' > 10/30/07 09:38:44 AM Running: lights office lamp off > 10/30/07 09:38:44 AM Insteon_Device: $lights_office_lamp::set(off, > Voice_Cmd=HASH(0x94fb450)) > 10/30/07 09:38:58 AM menu_run: g=mh m=Insteon i=0 s=0 => action: lights > office lamp 'on' > 10/30/07 09:38:58 AM Running: lights office lamp on > 10/30/07 09:38:58 AM Insteon_Device: $lights_office_lamp::set(on, > Voice_Cmd=HASH(0x94fb450)) I believe that the recent mods should keep missing prior problems (i.e., those specific to your deck lights) from impacting sending good signals (e.g., your desk light). BTW: I've just started to implement logic for "throttling" outbound sends so that you don't overwhelm the PL "network"--which can easily happen if you have a number of devices. In the mean time, please continue to space out your on/off commands (as you did above) and not "rapid-fire" sending. Gregg |
From: Garry D. <gar...@sh...> - 2007-10-30 19:32:16
|
Hi Gregg >So, are you saying that they have been working fine for a while *after* you have reinstalled your server or *before*? I'm trying to understand if there might be a difference in your environment (e.g., plugging in some new signal "sucker") or your re-installation. I decided to be adventuresome and set up a LinuxMCE server this time. I installed Misterhouse afterward and the Insteon devices were working fine. The next morning when I tried the lights they didn't work anymore. I've learned my lesson about banging away at the on/off button when things don't work. ;-) >> 10/30/07 09:37:54 AM [Insteon_PLM] Parsing serial data: >> 026005e82603055206c8906200 >> 10/30/07 09:37:54 AM [Insteon_PLM] PLM id: 05e826 firmware: 06 >> 10/30/07 09:37:54 AM [Insteon_PLM] Prepending prior data fragment: >> c8906200 >That looks *very* suspicious as I can't place that set of chars w/ any reasonable fragment of an insteon message. I have seen cases where a message get's fragmented across serial reads. However, this looks more like "junk". I'm wondering if there is some kind of conflict with LinuxMCE and the serial port. >I'm going to suggest that you svn update the insteon libs (Insteon_PLM, Insteon_Device, Insteon_Link) again as I just committed the latest. >They include among other things improvements with fragment handling. >I'm not convinced that it will help this; but, just in case. You will also get a bit more detailed diagnosis that may help (me--if not yourself). OK. Updated to latest SVN and still no change. Garry |
From: Gregg L. <gr...@li...> - 2007-10-30 19:55:10
|
Quoting Garry Doucette (10/30/07 3:31 PM): > I decided to be adventuresome and set up a LinuxMCE server this time. I > installed Misterhouse afterward and the Insteon devices were working fine. > The next morning when I tried the lights they didn't work anymore. I've > learned my lesson about banging away at the on/off button when things don't > work. ;-) > > I'm wondering if there is some kind of conflict with LinuxMCE and the serial > port. ... don't know ... if there's a way to shut it down/off, then that may be worthwhile. > OK. Updated to latest SVN and still no change. Ok--there may be no change noticeable by you; but, I'm pretty sure there *will* be changes (possibly subtle) to the debug statements that might be useful in a diagnosis. I'm quite willing to take another look if you want to either send the log off-list or repost. Also, you mentioned above that the lights worked for a while and suddenly didn't. Is that still the case? If so, providing a log of working and up to the point of not working may be quite useful. If you're still seeing/getting strange message fragments, then that is definitely an area of concern. Separately, can you try commenting out the deck lights declaration in items.mht and bang away on just your desk light? Does this work w/o problem for an extended period of time? If you do the reverse (uncomment deck lights and comment out desk lamp) do you no useful operation? Is the deck light's lamplinc on the same phase as your PLM? If not, can you easily move it "closer" for testing? If so, can you try another socket likely to be closer? Gregg |
From: Garry D. <gar...@sh...> - 2007-10-30 21:16:11
|
Gregg Quoting Garry Doucette (10/30/07 3:31 PM): >> I decided to be adventuresome and set up a LinuxMCE server this time. >> I installed Misterhouse afterward and the Insteon devices were working fine. >> The next morning when I tried the lights they didn't work anymore. >> I've learned my lesson about banging away at the on/off button when >> things don't work. ;-) >> >> I'm wondering if there is some kind of conflict with LinuxMCE and the >> serial port. >... don't know ... if there's a way to shut it down/off, then that may be worthwhile. I'm not sure there's any way to shut it down. I did some experimentation though. If I use the commands rs232 -d /dev/ttyS2 -b 19200 2 -s "\h02 62 05 CA FE 0F 11 FF" --hex --verbose -r9 --wait .4 rs232 -d /dev/ttyS2 -b 19200 2 -s "\h02 62 05 CA FE 0F 13\n" --hex --verbose -r9 --wait .4 my desk lamp goes on and off perfectly. >> OK. Updated to latest SVN and still no change. >Ok--there may be no change noticeable by you; but, I'm pretty sure there *will* be changes (possibly subtle) to the debug statements that might be useful in a diagnosis. I'm quite willing to take another look if you want to either send the log off-list or repost. Also, you mentioned above that the lights worked for a while and suddenly didn't. Is that still the case? If so, providing a log of working and up to the point of not working may be quite useful. Here's debug messages after loading latest SVN. The next full moon is on Saturday, November 24th 10/30/07 02:54:00 PM [Insteon_PLM] Parsing serial data: 026205cafe0f190006 10/30/07 02:54:00 PM Generating Voice commands for all Insteon objects 10/30/07 02:54:00 PM Rereading .menu code files. 10/30/07 02:54:00 PM [Insteon_PLM] Parsing serial data: 026005e82603055206025005cafe05e8262b01ff 10/30/07 02:54:00 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 10/30/07 02:54:00 PM [Insteon_PLM] DELEGATE:05cafe:05e826:05cafe05e8262b01ff: 10/30/07 02:54:00 PM [Insteon_PLM] Processing message for $lights_office_lamp 10/30/07 02:54:00 PM [Insteon_Device] received status request report for $lights_office_lamp with on-level: 255 10/30/07 02:55:00 PM: Saving object states ... done 10/30/07 02:56:00 PM: Saving object states ... done 10/30/07 02:56:16 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/30/07 02:56:31 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend 10/30/07 02:56:46 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend 10/30/07 02:57:00 PM: Saving object states ... done 10/30/07 02:57:01 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Trying next command if queued. 10/30/07 02:57:29 PM Insteon_Device: $lights_office_lamp::set(on, web) 10/30/07 02:57:44 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend 10/30/07 02:57:59 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend 10/30/07 02:58:00 PM: Saving object states ... done 10/30/07 02:58:14 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Trying next command if queued. >If you're still seeing/getting strange message fragments, then that is definitely an area of concern. >Separately, can you try commenting out the deck lights declaration in items.mht and bang away on just your desk light? Does this work w/o problem for an extended period of time? If you do the reverse (uncomment deck lights and comment out desk lamp) do you no useful operation? Tried the above no lights. >Is the deck light's lamplinc on the same phase as your PLM? Yes. They're about 6 feet apart on the same circuit. I'm not sure where to look next... Garry |
From: Gregg L. <gr...@li...> - 2007-10-30 22:32:16
|
Hi Gary, Quoting Garry Doucette (10/30/07 5:15 PM): > I'm not sure there's any way to shut it down. I did some experimentation > though. If I use the commands > > rs232 -d /dev/ttyS2 -b 19200 2 -s "\h02 62 05 CA FE 0F 11 FF" --hex > --verbose -r9 --wait .4 > rs232 -d /dev/ttyS2 -b 19200 2 -s "\h02 62 05 CA FE 0F 13\n" --hex --verbose > -r9 --wait .4 > > my desk lamp goes on and off perfectly. >From your previous recent log, I'm not seeing fragments nor suspecting the problem to be non-mh related. >> Separately, can you try commenting out the deck lights declaration in > items.mht and bang away on just your desk light? Does this work w/o problem > for an extended period of time? If you do the reverse (uncomment deck > lights and comment out desk lamp) do you no useful operation? > > Tried the above no lights. > >> Is the deck light's lamplinc on the same phase as your PLM? > > Yes. They're about 6 feet apart on the same circuit. > > I'm not sure where to look next... Given an analysis of your log, I'm suspecting a condition that apparently never happens at my house. So, I've made some minor mods to Insteon_Device and Insteon_PLM that I just committed. I hate to sound like a broken record, but could you update and retest--posting your log if problems persist? Thanks for your patience. Gregg |
From: Garry D. <gar...@sh...> - 2007-10-30 22:46:43
|
Gregg >Given an analysis of your log, I'm suspecting a condition that apparently never happens at my house. So, I've made some minor mods to Insteon_Device and Insteon_PLM that I just committed. I hate to sound like a broken record, but could you update and retest--posting your log if problems persist? >Thanks for your patience. No problem at all. I really hope I'm helping out and haven't just overlooked something simple. Her ya go... 10/30/07 04:40:51 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 10/30/07 04:40:51 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 10/30/07 04:40:51 PM [Insteon_PLM] num commands in past 1 seconds: 1 10/30/07 04:40:51 PM Generating Voice commands for all Insteon objects 10/30/07 04:40:51 PM Rereading .menu code files. 10/30/07 04:40:52 PM [Insteon_PLM] Parsing serial data: 026205cafe0f190006 10/30/07 04:40:52 PM [Insteon_PLM] Parsing serial data: c8626200 10/30/07 04:41:00 PM: Saving object states ... done 10/30/07 04:41:06 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend: status_request 10/30/07 04:41:06 PM [Insteon_PLM] num commands in past 1 seconds: 0 10/30/07 04:41:22 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend: status_request 10/30/07 04:41:34 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/30/07 04:41:37 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Trying next command if queued. 10/30/07 04:41:42 PM Insteon_Device: $lights_office_lamp::set(on, web) 10/30/07 04:41:57 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend: on 10/30/07 04:42:00 PM: Saving object states ... done 10/30/07 04:42:08 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/30/07 04:42:14 PM Insteon_Device: $lights_office_lamp::set(on, web) 10/30/07 04:42:29 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend: on Regards, Garry |
From: Gregg L. <gr...@li...> - 2007-10-31 17:50:51
|
Hi Garry, First, an apology, as I just realized your proper first name spelling. As someone w/ extra consonants, I should be more aware. Quoting Garry Doucette (10/30/07 6:45 PM): > 10/30/07 04:40:51 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 > 10/30/07 04:40:51 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 > 10/30/07 04:40:51 PM [Insteon_PLM] num commands in past 1 seconds: 1 > 10/30/07 04:40:51 PM Generating Voice commands for all Insteon objects > 10/30/07 04:40:51 PM Rereading .menu code files. > 10/30/07 04:40:52 PM [Insteon_PLM] Parsing serial data: 026205cafe0f190006 > 10/30/07 04:40:52 PM [Insteon_PLM] Parsing serial data: c8626200 ... another "junk" fragment. > 10/30/07 04:41:00 PM: Saving object states ... done > 10/30/07 04:41:06 PM [Insteon_Device] WARN: queue timer on > $lights_office_lamp expired. Attempting resend: status_request > 10/30/07 04:41:06 PM [Insteon_PLM] num commands in past 1 seconds: 0 > 10/30/07 04:41:22 PM [Insteon_Device] WARN: queue timer on > $lights_office_lamp expired. Attempting resend: status_request The above should be expected if you don't get a valid insteon acknowledge. Although you did receive a serial ack--one from the actual device coming over the powerline was never received. Possibly, the "junk" fragment was some left over. > 10/30/07 04:41:34 PM Insteon_Device: $lights_office_lamp::set(off, web) > 10/30/07 04:41:37 PM [Insteon_Device] WARN: queue timer on > $lights_office_lamp expired. Trying next command if queued. Ok--the above is definitely a problem that I introduced w/ Insteon_PLM. I've found and corrected problems w/ not properly clearing and in some cases, over clearing the command buffer. In addition, I added a timeout to attempt to avoid deadlocks like above. Can you please svn update and resend a latest log if still no improvements? Regards, Gregg |
From: Neil C. <nc...@li...> - 2007-10-31 18:46:01
|
Gregg Liming wrote: > Hi Garry, > > First, an apology, as I just realized your proper first name spelling. > As someone w/ extra consonants, I should be more aware. > > Quoting Garry Doucette (10/30/07 6:45 PM): > >> 10/30/07 04:40:51 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 >> 10/30/07 04:40:51 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 >> 10/30/07 04:40:51 PM [Insteon_PLM] num commands in past 1 seconds: 1 >> 10/30/07 04:40:51 PM Generating Voice commands for all Insteon objects >> 10/30/07 04:40:51 PM Rereading .menu code files. >> 10/30/07 04:40:52 PM [Insteon_PLM] Parsing serial data: 026205cafe0f190006 >> 10/30/07 04:40:52 PM [Insteon_PLM] Parsing serial data: c8626200 > > ... another "junk" fragment. > >> 10/30/07 04:41:00 PM: Saving object states ... done >> 10/30/07 04:41:06 PM [Insteon_Device] WARN: queue timer on >> $lights_office_lamp expired. Attempting resend: status_request >> 10/30/07 04:41:06 PM [Insteon_PLM] num commands in past 1 seconds: 0 >> 10/30/07 04:41:22 PM [Insteon_Device] WARN: queue timer on >> $lights_office_lamp expired. Attempting resend: status_request > > The above should be expected if you don't get a valid insteon > acknowledge. Although you did receive a serial ack--one from the actual > device coming over the powerline was never received. Possibly, the > "junk" fragment was some left over. > >> 10/30/07 04:41:34 PM Insteon_Device: $lights_office_lamp::set(off, web) >> 10/30/07 04:41:37 PM [Insteon_Device] WARN: queue timer on >> $lights_office_lamp expired. Trying next command if queued. > > Ok--the above is definitely a problem that I introduced w/ Insteon_PLM. > I've found and corrected problems w/ not properly clearing and in some > cases, over clearing the command buffer. In addition, I added a timeout > to attempt to avoid deadlocks like above. > > Can you please svn update and resend a latest log if still no improvements? I'll be downloading your new code today or tomorrow also. Thanks -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies |
From: Gregg L. <gr...@li...> - 2007-10-31 19:14:51
|
Quoting Neil Cherry (10/31/07 2:45 PM): > Gregg Liming wrote: >> Can you please svn update and resend a latest log if still no improvements? > > I'll be downloading your new code today or tomorrow also. That would help a lot as I'm having difficulties replicating Garry's problems. So, having more test points would help. The latest code implements a couple of features intended to improve reliability (assuming that they don't break other things): (1) basic message throttling and (2) timeouts. The concept behind basic message throttling is to begin delaying message delivery as bandwidth is consumed (i.e., multiple messages w/i short period of time) while also keeping latency extremely low. What this does is to begin delaying things if a rapid fire setup of commands are sent, but send out the very first one very fast (i.e., no delay at all). The reason for this is that insteon's power-line ack as well as hop-based routing causes bandwidth consumption and the collision detect/avoidance begins creating delays the more bandwidth that is introduced. The end effect is the possibility of a dropped powerline ack--which you don't want as the code will requeue the command and the problem can start over. I am now making explicit use of the powerline ack to provide a programmatic validation of the device's real state. If you have a moderately-complex lighting scheme, you definitely want to leverage links (aka scenes) because the powerline bandwidth is *much* more efficiently used and a large number of the above problems are avoided. Something else that I discovered the hard way is that while the peer-routing (via hop count) and RF access points do provide some level of noise immunity, insteon is still susceptible to power "suckers". Furthermore, some of my large ACT noise filters are apparently narrowly centered around the x10 freq and provide no coverage for insteon noise suppression--whereas the newest FilterLinc filters do. Ordinarily this does not become a problem for me (since the peer-routing does work) *unless* I really flood the system w/ lots of discrete messages. The bottom line is that I personally do not think it is affective to maintain the x10 way of thinking when you migrate over to insteon--something that I had been guilty of until discovering some of this the hard way. Once linking is adopted, all of these issues just go away. Gregg |
From: Garry D. <gar...@sh...> - 2007-10-31 23:42:45
|
Gregg Apology accepted. We can blame my parents for wanting to be 'a little different'! ;-) OK. Updated to latest SVN and still no lighting control but different messages... 10/31/07 05:35:49 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 10/31/07 05:35:49 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 10/31/07 05:35:49 PM Generating Voice commands for all Insteon objects 10/31/07 05:35:49 PM Rereading .menu code files. Playing WAVE './../sounds/sound_click1.wav' : Unsigned 8 bit, Rate 22050 Hz, Mono 10/31/07 05:35:52 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:35:55 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:35:59 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:36:00 PM: Saving object states ... done 10/31/07 05:36:02 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:36:04 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend: status_request 10/31/07 05:36:05 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:36:08 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:36:11 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:36:15 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:36:18 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 05:36:19 PM [Insteon_Device] WARN: queue timer on $lights_office_lamp expired. Attempting resend: status_request Garry -----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Gregg Liming Sent: Wednesday, October 31, 2007 10:51 AM To: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon Lamplinc Quit Working Hi Garry, First, an apology, as I just realized your proper first name spelling. As someone w/ extra consonants, I should be more aware. Quoting Garry Doucette (10/30/07 6:45 PM): > 10/30/07 04:40:51 PM [Insteon_PLM] Parsing serial data: > 026005e82603055206 > 10/30/07 04:40:51 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 > 10/30/07 04:40:51 PM [Insteon_PLM] num commands in past 1 seconds: 1 > 10/30/07 04:40:51 PM Generating Voice commands for all Insteon objects > 10/30/07 04:40:51 PM Rereading .menu code files. > 10/30/07 04:40:52 PM [Insteon_PLM] Parsing serial data: > 026205cafe0f190006 > 10/30/07 04:40:52 PM [Insteon_PLM] Parsing serial data: c8626200 ... another "junk" fragment. > 10/30/07 04:41:00 PM: Saving object states ... done > 10/30/07 04:41:06 PM [Insteon_Device] WARN: queue timer on > $lights_office_lamp expired. Attempting resend: status_request > 10/30/07 04:41:06 PM [Insteon_PLM] num commands in past 1 seconds: 0 > 10/30/07 04:41:22 PM [Insteon_Device] WARN: queue timer on > $lights_office_lamp expired. Attempting resend: status_request The above should be expected if you don't get a valid insteon acknowledge. Although you did receive a serial ack--one from the actual device coming over the powerline was never received. Possibly, the "junk" fragment was some left over. > 10/30/07 04:41:34 PM Insteon_Device: $lights_office_lamp::set(off, > web) > 10/30/07 04:41:37 PM [Insteon_Device] WARN: queue timer on > $lights_office_lamp expired. Trying next command if queued. Ok--the above is definitely a problem that I introduced w/ Insteon_PLM. I've found and corrected problems w/ not properly clearing and in some cases, over clearing the command buffer. In addition, I added a timeout to attempt to avoid deadlocks like above. Can you please svn update and resend a latest log if still no improvements? Regards, Gregg ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Gregg L. <gr...@li...> - 2007-11-01 00:13:07
|
Quoting Garry Doucette (10/31/07 7:41 PM): > 10/31/07 05:35:49 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 > 10/31/07 05:35:49 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 Well, at least one command was ack'd back correctly. > 10/31/07 05:35:49 PM Generating Voice commands for all Insteon objects > 10/31/07 05:35:49 PM Rereading .menu code files. > Playing WAVE './../sounds/sound_click1.wav' : Unsigned 8 bit, Rate 22050 Hz, > Mono > 10/31/07 05:35:52 PM [Insteon_PLM] WARN: Problem with your PLM requires > forced abort of current command. Please investigate your environment. > 10/31/07 05:35:55 PM [Insteon_PLM] WARN: Problem with your PLM requires > forced abort of current command. Please investigate your environment. This message is sent every timeout on an ack not being received by your PLM. It's definitely not a good indicator; I never see it w/ 20+ devices. Can you try setting Insteon_PLM_scan_at_startup=0 in your mh.ini (watch case) and restart? Doing so will prevent the automatic scanning of your (1) device(s). If you don't see the error messages above on startup, then start web clicking the device. Gregg |
From: Garry D. <gar...@sh...> - 2007-11-01 00:30:07
|
OK mh.private.ini... # Misterhouse configuration file generated by iniedit.pl code_dir=/opt/misterhouse/code lib_dir=/opt/misterhouse/mh/lib data_dir=/opt/misterhouse/data sound_dir=/opt/misterhouse/sounds sound_program=aplay html_alias_web=$Pgm_Root/web web_refresh= voice_text=festival Continue=Continue Insteon_PLM_serial_port=/dev/ttyS2 Insteon_PLM_scan_at_startup=0 Log... 10/31/07 06:26:14 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 10/31/07 06:26:14 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 Playing WAVE './../sounds/sound_click1.wav' : Unsigned 8 bit, Rate 22050 Hz, Mono 10/31/07 06:26:14 PM Generating Voice commands for all Insteon objects 10/31/07 06:26:14 PM Rereading .menu code files. 10/31/07 06:26:28 PM Insteon_Device: $lights_office_lamp::set(on, web) 10/31/07 06:26:31 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 06:26:34 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 06:26:36 PM Insteon_Device: $lights_office_lamp::set(off, web) 10/31/07 06:26:38 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 06:26:41 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 06:26:44 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 06:26:47 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. 10/31/07 06:26:50 PM [Insteon_PLM] WARN: Problem with your PLM requires forced abort of current command. Please investigate your environment. Garry -----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Gregg Liming Sent: Wednesday, October 31, 2007 5:13 PM To: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon Lamplinc Quit Working Quoting Garry Doucette (10/31/07 7:41 PM): > 10/31/07 05:35:49 PM [Insteon_PLM] Parsing serial data: > 026005e82603055206 > 10/31/07 05:35:49 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 Well, at least one command was ack'd back correctly. > 10/31/07 05:35:49 PM Generating Voice commands for all Insteon objects > 10/31/07 05:35:49 PM Rereading .menu code files. > Playing WAVE './../sounds/sound_click1.wav' : Unsigned 8 bit, Rate > 22050 Hz, Mono > 10/31/07 05:35:52 PM [Insteon_PLM] WARN: Problem with your PLM > requires forced abort of current command. Please investigate your environment. > 10/31/07 05:35:55 PM [Insteon_PLM] WARN: Problem with your PLM > requires forced abort of current command. Please investigate your environment. This message is sent every timeout on an ack not being received by your PLM. It's definitely not a good indicator; I never see it w/ 20+ devices. Can you try setting Insteon_PLM_scan_at_startup=0 in your mh.ini (watch case) and restart? Doing so will prevent the automatic scanning of your (1) device(s). If you don't see the error messages above on startup, then start web clicking the device. Gregg ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Gregg L. <gr...@li...> - 2007-11-01 00:45:46
|
Quoting Garry Doucette (10/31/07 8:29 PM): > OK > > mh.private.ini... > > # Misterhouse configuration file generated by iniedit.pl > code_dir=/opt/misterhouse/code > lib_dir=/opt/misterhouse/mh/lib > data_dir=/opt/misterhouse/data > sound_dir=/opt/misterhouse/sounds > sound_program=aplay > html_alias_web=$Pgm_Root/web > web_refresh= > voice_text=festival > Continue=Continue > Insteon_PLM_serial_port=/dev/ttyS2 > Insteon_PLM_scan_at_startup=0 > > Log... > > 10/31/07 06:26:14 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 > 10/31/07 06:26:14 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 > Playing WAVE './../sounds/sound_click1.wav' : Unsigned 8 bit, Rate 22050 Hz, > Mono > 10/31/07 06:26:14 PM Generating Voice commands for all Insteon objects > 10/31/07 06:26:14 PM Rereading .menu code files. > 10/31/07 06:26:28 PM Insteon_Device: $lights_office_lamp::set(on, web) > 10/31/07 06:26:31 PM [Insteon_PLM] WARN: Problem with your PLM requires > forced abort of current command. Please investigate your environment. I was afraid of that--setting scan_at_startup=0 only delays what seems to be inevitable for you. I will try to think of something else; but any attempt that I make to reproduce your problems is simply not occurring. It would obviously really help if *anyone* else could report whether latest svn is or is not working for them. I will happily send you the files that existed some time ago if you can tell me a rough time frame when you think that you last used them. That would help confirm/deny whether your current environment is somehow flawed. Gregg |
From: Jason S. <ja...@sh...> - 2007-11-01 04:06:48
|
Just tried out your latest svn. Was able to turn on and off my only test insteon device. Turning ON happened right away. Turning OFF happened about a minute later (as seen by the extremely busy message). In my experience extremely busy means that the PLM is being jammed by PLC noise. Insteon really doesnt like me in my home. What I find odd though is that the few X10 devices that are at farther distances are bulletproof. Wasnt there an issue with the boosterlinc / signallinc stuff jamming Insteon. Is that still the case? I have a few X10 keypads that might have that technology. BTW: Love the rework you have been doing on the code! 10/31/07 11:55:14 PM [Insteon_Device] WARN: queue timer on $ipld_office expired. Attempting resend: status_request 10/31/07 11:55:14 PM [Insteon_PLM] Prepending prior data fragment: f72b0000 10/31/07 11:55:29 PM [Insteon_Device] WARN: queue timer on $ipld_office expired. Attempting resend: status_request 10/31/07 11:55:45 PM [Insteon_Device] WARN: queue timer on $ipld_office expired. Trying next command if queued. 10/31/07 11:56:09 PM $upb_front_south::set(20%, Light_Item=HASH(0x9910f6c)) 10/31/07 11:56:10 PM $upb_front_north::set(20%, Light_Item=HASH(0x991084c)) 10/31/07 11:56:21 PM [Insteon_PLM] Processing message for $ipld_office 10/31/07 11:56:22 PM [Insteon_PLM] Processing message for $ipld_office 10/31/07 11:57:41 PM [Insteon_PLM] Processing message for $ipld_office 10/31/07 11:58:04 PM [Insteon_Device] WARN: queue timer on $ipld_office expired. Attempting resend: off 10/31/07 11:58:20 PM [Insteon_Device] WARN: queue timer on $ipld_office expired. Attempting resend: off 10/31/07 11:58:20 PM [Insteon_PLM] Interface extremely busy. Resending command. ..... 10/31/07 11:58:34 PM [Insteon_PLM] Interface extremely busy. Resending command. 10/31/07 11:58:35 PM [Insteon_Device] WARN: queue timer on $ipld_office expired. Trying next command if queued. 10/31/07 11:58:36 PM [Insteon_PLM] Interface extremely busy. Resending command. ..... 10/31/07 11:58:55 PM [Insteon_PLM] Interface extremely busy. Resending command. 10/31/07 11:58:55 PM [Insteon_PLM] Processing message for $ipld_office 10/31/07 11:58:57 PM [Insteon_PLM] Interface extremely busy. Resending command. On Wed, 31 Oct 2007, Gregg Liming wrote: > Quoting Garry Doucette (10/31/07 8:29 PM): >> OK >> >> mh.private.ini... >> >> # Misterhouse configuration file generated by iniedit.pl >> code_dir=/opt/misterhouse/code >> lib_dir=/opt/misterhouse/mh/lib >> data_dir=/opt/misterhouse/data >> sound_dir=/opt/misterhouse/sounds >> sound_program=aplay >> html_alias_web=$Pgm_Root/web >> web_refresh= >> voice_text=festival >> Continue=Continue >> Insteon_PLM_serial_port=/dev/ttyS2 >> Insteon_PLM_scan_at_startup=0 >> >> Log... >> >> 10/31/07 06:26:14 PM [Insteon_PLM] Parsing serial data: 026005e82603055206 >> 10/31/07 06:26:14 PM [Insteon_PLM] PLM id: 05e826 firmware: 52 >> Playing WAVE './../sounds/sound_click1.wav' : Unsigned 8 bit, Rate 22050 Hz, >> Mono >> 10/31/07 06:26:14 PM Generating Voice commands for all Insteon objects >> 10/31/07 06:26:14 PM Rereading .menu code files. >> 10/31/07 06:26:28 PM Insteon_Device: $lights_office_lamp::set(on, web) >> 10/31/07 06:26:31 PM [Insteon_PLM] WARN: Problem with your PLM requires >> forced abort of current command. Please investigate your environment. > > I was afraid of that--setting scan_at_startup=0 only delays what seems > to be inevitable for you. I will try to think of something else; but > any attempt that I make to reproduce your problems is simply not > occurring. It would obviously really help if *anyone* else could report > whether latest svn is or is not working for them. > > I will happily send you the files that existed some time ago if you can > tell me a rough time frame when you think that you last used them. That > would help confirm/deny whether your current environment is somehow flawed. > > Gregg > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > > |
From: Neil C. <nc...@li...> - 2007-11-01 05:09:45
|
For about 6 months after I wrote my book I had a blackhole that ate X10 and Insteon on one phase. That phase was the same phase as the PC interface. I also have an X10 amplifying bridge to bridge the phases. I couldn't control anything on the phase with the PC interface but could send signals from the PC interface to the devices on the other phase. I finally found the culprit a filtering power strip behind and FilterLinc (???). I'v since removed it and both X10 and Instoen are much happier. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies |
From: Gregg L. <gr...@li...> - 2007-11-01 11:13:28
|
Hi Jason, Quoting Jason Sharpee (11/1/07 12:07 AM): > Just tried out your latest svn. Was able to turn on and off my only test > insteon device. Turning ON happened right away. Turning OFF happened > about a minute later (as seen by the extremely busy message). Thanks for trying this out as it provides a very useful test point. Your results show that things are working as expected--albeit some environmental issues in your house as you noted. FWIW: There are two levels of queues now--the PLM and the device. The device will re-queue each 15 seconds (or as set by Insteon_PLM_max_queue_time) for up to 3 times before moving on. The requeue logic is looking for the ack back from the physical device--which can be lost in high-noise or truly very busy situations. > In my > experience extremely busy means that the PLM is being jammed by PLC noise. I tend to cause it by over-flooding it w/ lots of messages--hence the reason for the dynamic throttling on the PLM queue as an attempt to prevent such situations. W/o it, I can--on occasion--force the dreaded "NAK lockup". When NAKs are encountered, the PLM queue logic will requeues up to 3 times w/ an extra 1 second timer delay-- explaining some of your log messages. > Insteon really doesnt like me in my home. What I find odd though is that > the few X10 devices that are at farther distances are bulletproof. We have a reverse problem--now, one of my two remaining x10 devices tends to only occasionally work. I had heard/read that x10 operation decays as the number of Insteon devices increases and had doubted it. I was wrong. > Wasnt there an issue with the boosterlinc / signallinc stuff jamming > Insteon. Is that still the case? I have a few X10 keypads that might > have that technology. I don't know. I do know that not all filters help Insteon; apparently, only the latest FilterLinc does. > BTW: Love the rework you have been doing on the code! Thanks! It's easy to build on your foundation and very much appreciated as the difference in my house's lighting control is amazing. Gregg |
From: Neil C. <nc...@li...> - 2007-11-01 00:50:57
|
Garry Doucette wrote: > OK > > mh.private.ini... > > # Misterhouse configuration file generated by iniedit.pl > code_dir=/opt/misterhouse/code > lib_dir=/opt/misterhouse/mh/lib > data_dir=/opt/misterhouse/data > sound_dir=/opt/misterhouse/sounds > sound_program=aplay > html_alias_web=$Pgm_Root/web > web_refresh= > voice_text=festival > Continue=Continue > Insteon_PLM_serial_port=/dev/ttyS2 > Insteon_PLM_scan_at_startup=0 I remember you said that LinuxMCE or something else was loaded. As root do the command: lsof | fgrep ttyS Give us the results. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies |