Quantcast

Insteon

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Insteon

mtmigs
I am having a problem with an INSTEON_MICROSWITCHRELAY. I currently have
it linked with a keypadlinc in a 3-way synchronized configuration. I can
turn the light on or off from either the keypadlinc or the micro on off
module and the key pad indicator goes on and off with the light no
matter where it is turned on or off. It works great. The micro on off
module is on a pole outside and there is a switchlinc in a shed about 30
ft farther down the same power wire. Both operate without any delay in
turning on or off.

When I tried adding PLM control as a 4-way synchronized configuration I
ran into problems. Misterhouse reported problems when I tried plm global
- scan changed device link tables. It reported this problem:

03/12/2016 20:35:12  [Scan all link tables] Now scanning: $Post_Floods
(6 of 6)
03/12/2016 20:35:12  [Insteon::AllLinkDatabase] WARN The link table for
$Post_Floods has changed.
03/12/2016 20:35:12  [Insteon::ALDB_i2] $Post_Floods reading ALDB at
location: 0x0000
03/12/2016 20:35:15  [Insteon::BaseMessage] WARN: now resending
obj=$Post_Floods; command=read_write_aldb;
extra=000000000001000000000000000000 after 1 attempts.
03/12/2016 20:35:18  [Insteon::BaseMessage] WARN: now resending
obj=$Post_Floods; command=read_write_aldb;
extra=000000000001000000000000000000 after 2 attempts.
03/12/2016 20:35:21  [Insteon::BaseMessage] WARN: now resending
obj=$Post_Floods; command=read_write_aldb;
extra=000000000001000000000000000000 after 3 attempts.
03/12/2016 20:35:25  [Insteon::BaseMessage] WARN: now resending
obj=$Post_Floods; command=read_write_aldb;
extra=000000000001000000000000000000 after 4 attempts.
03/12/2016 20:35:28  [Insteon::BaseInterface] WARN: number of retries
(5) for obj=$Post_Floods; command=read_write_aldb;
extra=000000000001000000000000000000 exceeds limit.  Now moving on...
03/12/2016 20:35:28  [Insteon::BaseInterface] WARN: Message Timeout:
Now calling callback: &Insteon::_get_next_linkscan_failure(1)
03/12/2016 20:35:28  [Scan all link tables] WARN: failure occurred when
scanning $Post_Floods.  Moving on...

None of the other devices had a problem. Next I tried post floods run
ping test. It again had a problem which seemed to after a while lock up
misterhouse and I had to hard (-9) kill the process. Here is part of the
print.log file:

03/12/2016 20:13:03  [Insteon::BaseDevice] Sending ping request to
$Post_Floods 3 more ping requests queued.
03/12/2016 20:13:06  [Insteon::BaseMessage] WARN: now resending
obj=$Post_Floods; command=ping; extra=030000000000000000000000000000
after 1 attempts.
03/12/2016 20:13:10  [Insteon::BaseMessage] WARN: now resending
obj=$Post_Floods; command=ping; extra=030000000000000000000000000000
after 2 attempts.
03/12/2016 20:13:13  [Insteon::BaseMessage] WARN: now resending
obj=$Post_Floods; command=ping; extra=030000000000000000000000000000
after 3 attempts.
03/12/2016 20:13:16  [Insteon::BaseMessage] WARN: now resending
obj=$Post_Floods; command=ping; extra=030000000000000000000000000000
after 4 attempts.
03/12/2016 20:13:17  [Insteon::BaseObject] received ping acknowledgement
from $Post_Floods
03/12/2016 20:13:17  [Insteon::BaseDevice] Sending ping request to
$Post_Floods 2 more ping requests queued.

It there possibly a difference between what the micro on off switch is
sending and what misterhouse is expecting?


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Loading...