Insteon Lockup After set_trigger??

[Jim Duda]

This post is somewhat related to my last post.

I've been getting Insteon PLM lockups on a much more regular basis the past couple of weeks.
When the PLM "locks up", all of my insteon activity halts.  I find that the PLM activity light
is a rock solid blue.  I have to power cycles the insteon PLM to get back.

I've now noticed a consistent occurrence related to set_trigger operations.  With the new
tv shows the past two weeks, we've been using tv_grid to schedule pvr recordings.  Each
recording results in a set_trigger.  I've noticed quite a few times that when these triggers
come active, it appear to coincide with an Insteon lockup.  Its seems now to be more than
just a coincidence.  It's happened too many times.

Could the insteon lockups be somehow related to a misterhouse restart condition?

These lockups are coming much more frequently here.  I have been using insteon for about a year
now.  I never had a lockup until I put a KeypadLinc into service.  I'm considering deactivating
the KeypadLinc, or at least the reverse surrogates, to see if that might have something to
do with what has changed in my installation.  Could the KeypadLinc be an issue causing the
PLM to get wedged?

Food for thought.

Jim


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

[Marc MERLIN-7]

On Tue, Oct 13, 2009 at 09:23:52PM -0400, Jim Duda wrote:

> This post is somewhat related to my last post.
>
> I've been getting Insteon PLM lockups on a much more regular basis the past couple of weeks.
> When the PLM "locks up", all of my insteon activity halts.  I find that the PLM activity light
> is a rock solid blue.  I have to power cycles the insteon PLM to get back.
>
> I've now noticed a consistent occurrence related to set_trigger operations.  With the new
> tv shows the past two weeks, we've been using tv_grid to schedule pvr recordings.  Each
> recording results in a set_trigger.  I've noticed quite a few times that when these triggers
> come active, it appear to coincide with an Insteon lockup.  Its seems now to be more than
> just a coincidence.  It's happened too many times.
>
> Could the insteon lockups be somehow related to a misterhouse restart condition?
>
> These lockups are coming much more frequently here.  I have been using insteon for about a year
> now.  I never had a lockup until I put a KeypadLinc into service.  I'm considering deactivating
> the KeypadLinc, or at least the reverse surrogates, to see if that might have something to
> do with what has changed in my installation.  Could the KeypadLinc be an issue causing the
> PLM to get wedged?

For what it's worth, I have 4 keypadlincs in use all the time and and no
lockups, although one keypadlinc was misbehaving and sending incorrect
codes (it was quite old), so I had it replaced.

Assuming your PLM isn't under warranty anymore, get a new one from
Smarthome, try it and return the right one accordingly and/or ask for some
kind of return deal if your old out of warranty one is misbehaving.

If you're under warranty, pay to get an advanced replacement so that you can
do an instant switch.

I'm not guaranteeing this is your problem, but there is a good chance.

Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ 

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

[John R.]

Jim Duda wrote:

[snip]

Could the KeypadLinc be an issue causing the
> PLM to get wedged?

I have not any lock ups before or after adding my 2 KeypadLincs.

John

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

[bauereri]

Hello,

I recently had a HDD failure in my MH box, so I had to replace it and build a new system.  I am now running Fedora 11.  I was able to copy my entire installation of MH from the old HDD before it died, but now I am having a problem with the Local Weather screen and the graphs.  This might be two problems, I am not sure. 

First, I am not getting any data plotted to any of the graphs.  Nothing on outdoor temp, indoor temp, wind speed, etc...  However, if I go to my data directory/rrd, I can see that every one of the graph files is being updated regularly.  I've verified that rrdtool and rrdtool-perl are installed.

Second, the TK interface is showing a logfile entry every couple of minutes that says this:

weather_metar:couldn't find a valid metar report.  Retrieved data can be found in ./../mystuff/mydata.web.weather_metar.html

If I look at that file, it looks OK to me.  I compared it to a backup copy of that file I had from last year when this system was working and it looks the same.

Any Ideas?

Thanks,

Eric
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

[Gregg Liming]

Hi Jim,

Jim Duda wrote:

> This post is somewhat related to my last post.
>
> I've been getting Insteon PLM lockups on a much more regular basis the past couple of weeks.
> When the PLM "locks up", all of my insteon activity halts.  I find that the PLM activity light
> is a rock solid blue.  I have to power cycles the insteon PLM to get back.
>
> I've now noticed a consistent occurrence related to set_trigger operations.  With the new
> tv shows the past two weeks, we've been using tv_grid to schedule pvr recordings.  Each
> recording results in a set_trigger.  I've noticed quite a few times that when these triggers
> come active, it appear to coincide with an Insteon lockup.  Its seems now to be more than
> just a coincidence.  It's happened too many times.
>
> Could the insteon lockups be somehow related to a misterhouse restart condition?

First, I can't remember--does a set_trigger result in a reload or a
restart?  This is perhaps pertinent only in whether or not the automatic
  Insteon scanning occurs each time that you do a set_trigger.  I had
implemented logic to avoid doing so for normal reloads, but to allow the
scan on full restarts.  If this is not clear, then set debug=insteon and
watch the log when you do a set_trigger.  If scanning is always
occurring, then you might try disabling it via
Insteon_PLM_scan_at_startup=0.  I don't personally have a problem with
scanning causing lockups and from the responses that you've already
seen, apparently neither do other users of fairly large deployments.
But, it won't hurt to rule it out for your case.

It is quite unlikely that the restart itself is causing a lock-up, but
rather the possibility of user code tied to a restart creating traffic
that eventually leads to a lockup.

> These lockups are coming much more frequently here.  I have been using insteon for about a year
> now.  I never had a lockup until I put a KeypadLinc into service.  I'm considering deactivating
> the KeypadLinc, or at least the reverse surrogates, to see if that might have something to
> do with what has changed in my installation.  Could the KeypadLinc be an issue causing the
> PLM to get wedged?

As others have mentioned, it is unlikely that the presence of a KPL is
the culprit.  The only time that I ever get lockups is when a flurry of
activity is occurring and usually including at least one multi-target
scene. I'm pretty optimistic that whatever is occurring that the PLM
can't recover from will be significantly avoided/curtailed once I change
the queuing logic.  Unfortunately, I've just not made any progress on it
over the spring/summer and am hoping for lots of crummy weather soon to
force me inside.

Gregg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

[Jim Duda]

On 10/14/2009 02:31 PM, Gregg Liming wrote:

> Hi Jim,
>
> Jim Duda wrote:
>> This post is somewhat related to my last post.
>>
>> I've been getting Insteon PLM lockups on a much more regular basis the past couple of weeks.
>> When the PLM "locks up", all of my insteon activity halts.  I find that the PLM activity light
>> is a rock solid blue.  I have to power cycles the insteon PLM to get back.
>>
>> I've now noticed a consistent occurrence related to set_trigger operations.  With the new
>> tv shows the past two weeks, we've been using tv_grid to schedule pvr recordings.  Each
>> recording results in a set_trigger.  I've noticed quite a few times that when these triggers
>> come active, it appear to coincide with an Insteon lockup.  Its seems now to be more than
>> just a coincidence.  It's happened too many times.
>>
>> Could the insteon lockups be somehow related to a misterhouse restart condition?
>
> First, I can't remember--does a set_trigger result in a reload or a
> restart?  This is perhaps pertinent only in whether or not the automatic

I think its a reload

>    Insteon scanning occurs each time that you do a set_trigger.  I had
> implemented logic to avoid doing so for normal reloads, but to allow the
> scan on full restarts.  If this is not clear, then set debug=insteon and
> watch the log when you do a set_trigger.  If scanning is always
> occurring, then you might try disabling it via
> Insteon_PLM_scan_at_startup=0.  I don't personally have a problem with
> scanning causing lockups and from the responses that you've already
> seen, apparently neither do other users of fairly large deployments.
> But, it won't hurt to rule it out for your case.

Yes, I have this disabled.

Insteon_PLM_scan_at_startup=0
Insteon_PLM_max_queue_time=5
Insteon_PLM_disable_throttling=0
Insteon_PLM_xmit_delay=0.25
 
I get a fair amount of these warnings.

10/15/09 07:31:28 AM [Insteon_PLM] WARN: No acknowledgement from PLM to last command requires forced abort of current command. This may reflect a problem with your environment.
10/15/09 10:54:44 AM [Insteon_PLM] WARN: No acknowledgement from PLM to last command requires forced abort of current command. This may reflect a problem with your environment.
10/15/09 03:07:22 PM [Insteon_PLM] WARN: No acknowledgement from PLM to last command requires forced abort of current command. This may reflect a problem with your environment.

When the PLM locks up, I get a rather solid blue indicator light.

Is this indicitive of a problem with the Serial Link (RS232) or Insteon Channel?

>
> It is quite unlikely that the restart itself is causing a lock-up, but
> rather the possibility of user code tied to a restart creating traffic
> that eventually leads to a lockup.

This is an interesting avenue I can pursue, thanks.

>
> As others have mentioned, it is unlikely that the presence of a KPL is
> the culprit.  The only time that I ever get lockups is when a flurry of
> activity is occurring and usually including at least one multi-target
> scene. I'm pretty optimistic that whatever is occurring that the PLM
> can't recover from will be significantly avoided/curtailed once I change
> the queuing logic.  Unfortunately, I've just not made any progress on it
> over the spring/summer and am hoping for lots of crummy weather soon to
> force me inside.

Makes sense.

Thanks,

Jim




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

[Jim Duda]

Thanks for the feedback everyone.

I'm going to focus on maybe I have a bad PLM.

I moved the PLM to a different serial port and different A/C outlet for a while.

Jim


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

[Gregg Liming]

Jim Duda wrote:

> I get a fair amount of these warnings.
>
> 10/15/09 07:31:28 AM [Insteon_PLM] WARN: No acknowledgement from PLM to last command requires forced abort of current command. This may reflect a problem with your environment.
> 10/15/09 10:54:44 AM [Insteon_PLM] WARN: No acknowledgement from PLM to last command requires forced abort of current command. This may reflect a problem with your environment.
> 10/15/09 03:07:22 PM [Insteon_PLM] WARN: No acknowledgement from PLM to last command requires forced abort of current command. This may reflect a problem with your environment.
>
> When the PLM locks up, I get a rather solid blue indicator light.
>
> Is this indicitive of a problem with the Serial Link (RS232) or Insteon Channel?

It's indicative of a flaw in the PLM.  Apparently, there is some set of
conditions (or perhaps more than one set) that cause the PLM to lock up.
   The only thing that is known is that it can happen from time to time
(about one every several months for me) and w/o any obvious cause.  I'm
speculating that it is some form of timing issue that it somehow doesn't
like.  And, once I change the queing logic, there will no longer be
concurrency of commands permitted; rather they will be serialized.  That
might help alleviate some things.  It will definitely reduce the
probability of collisions and aborted scenes (due to traffic while
cleanup is occurring).

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365