Quantcast

Insteon PLM errors

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

Insteon PLM errors

Jeff Siddall
My PLM has gone AWOL a few times in recent weeks.  It seems to start
with errors like this:

11/09/16 06:04:59 PM [Insteon_PLM] ERROR: Received data did not start
with a valid prefix.  Trimming to:

which repeats many times.  Then nothing works after that:

11/09/16 06:14:38 PM [Insteon::BaseMessage] WARN: now resending
obj=$Basement_LED; command=off; extra=00 after 1 attempts.
11/09/16 06:14:40 PM [Insteon::BaseMessage] WARN: now resending
obj=$Basement_LED; command=off; extra=00 after 2 attempts.
11/09/16 06:14:42 PM [Insteon::BaseMessage] WARN: now resending
obj=$Basement_LED; command=off; extra=00 after 3 attempts.
11/09/16 06:14:44 PM [Insteon::BaseInterface] WARN: number of retries
(4) for obj=$Basement_LED; command=off; extra=00 exceeds limit.  Now
moving on...

Restarting MH alone does not seem to solve it:

11/10/16 08:34:43 AM [Insteon_PLM] 2412[US] using serial,
serial_port=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6028NMC-if00-port0
11/10/16 08:34:43 AM [Insteon_PLM] setting default xmit delay to: .25
11/10/16 08:34:43 AM [Insteon_PLM] setting x10 xmit delay to:
0.5[Insteon::BaseMessage] WARN: now resending obj=$PLM; interface_data=
after 1 attempts
11/10/16 08:34:51 AM [Insteon::BaseMessage] WARN: now resending
obj=$PLM; interface_data= after 2 attempts.
11/10/16 08:34:52 AM [Insteon::BaseMessage] WARN: now resending
obj=$PLM; interface_data= after 3 attempts.
11/10/16 08:34:53 AM [Insteon::BaseInterface] WARN: number of retries
(4) for obj=$PLM; interface_data= exceeds limit.  Now moving on...


But if I unplug AC power from the PLM for a few seconds, then plug it
back in, then restart MH it seems to start working again.

Is this a sign my PLM is failing or some other issue?

Thanks,

Jeff

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Insteon PLM errors

Jeff Siddall
On 11/10/2016 08:42 AM, Jeff Siddall wrote:
> My PLM has gone AWOL a few times in recent weeks.  It seems to start
> with errors like this:
>
> 11/09/16 06:04:59 PM [Insteon_PLM] ERROR: Received data did not start
> with a valid prefix.  Trimming to:
>
> which repeats many times.  Then nothing works after that:

Update: after a number of those PLM errors in a row in the logs
yesterday MH finally crashed and since then no combination of unplugs
and MH restarts would get it do do anything.  I don't know if the crash
was related to something in the latest master I installed a few days ago
but in case it means anything here is the console errors:

Can't call method "plm_receipt" on an undefined value at
/usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187.
  at /usr/local/mh/bin/mh line 31.
         main::__ANON__("Can't call method \"plm_receipt\" on an
undefined value at /usr"...) called at
/usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187
         Insteon_PLM::_parse_data(Insteon_PLM=HASH(0x5a4b100),
"0257a2043229bd000000") called at
/usr/local/mh/bin/../lib/Insteon_PLM.pm line 301
         Insteon_PLM::check_for_data(Insteon_PLM=HASH(0x5a4b100)) called
at /usr/local/mh/bin/../lib/Insteon/BaseInterface.pm line 33
         Insteon::BaseInterface::check_for_data() called at
/usr/local/mh/bin/mh line 1701

Anyway, I pulled apart the PLM and replaced C7 & C13 with 10 uF 35 V
Nichicon caps I had on hand.  Put it back together and it seems to be
working fine again.  Hopefully that was all it took to put an end to the
Insteon flakiness and to keep it working for another 2 years.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Insteon PLM errors

H Plato
It looks like my PLM also died over the holidays. LED light on the side is dim and flickery. Unplugging it for a few minutes brought it back to life, but now it's dead again.

I’m going to order a new PLM, however I’d like to try repairing my old one so I have a backup. I’ve done a bit of soldering, but not much. Are there any guides or advice anyone might have on how to replace capacitors?  I saw Denny’s email about the thread on universal devices and will order those capacitors.

Also, for those of you that have replaced a PLM, is there a simple method to replace it, by just updating the PLM’s address in the items.mht? Do all the insteon devices need to be relinked as controllers and responders?


> On Dec 6, 2016, at 2:32 PM, Jeff Siddall <[hidden email]> wrote:
>
> On 11/10/2016 08:42 AM, Jeff Siddall wrote:
>> My PLM has gone AWOL a few times in recent weeks.  It seems to start
>> with errors like this:
>>
>> 11/09/16 06:04:59 PM [Insteon_PLM] ERROR: Received data did not start
>> with a valid prefix.  Trimming to:
>>
>> which repeats many times.  Then nothing works after that:
>
> Update: after a number of those PLM errors in a row in the logs
> yesterday MH finally crashed and since then no combination of unplugs
> and MH restarts would get it do do anything.  I don't know if the crash
> was related to something in the latest master I installed a few days ago
> but in case it means anything here is the console errors:
>
> Can't call method "plm_receipt" on an undefined value at
> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187.
>  at /usr/local/mh/bin/mh line 31.
>         main::__ANON__("Can't call method \"plm_receipt\" on an
> undefined value at /usr"...) called at
> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187
>         Insteon_PLM::_parse_data(Insteon_PLM=HASH(0x5a4b100),
> "0257a2043229bd000000") called at
> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 301
>         Insteon_PLM::check_for_data(Insteon_PLM=HASH(0x5a4b100)) called
> at /usr/local/mh/bin/../lib/Insteon/BaseInterface.pm line 33
>         Insteon::BaseInterface::check_for_data() called at
> /usr/local/mh/bin/mh line 1701
>
> Anyway, I pulled apart the PLM and replaced C7 & C13 with 10 uF 35 V
> Nichicon caps I had on hand.  Put it back together and it seems to be
> working fine again.  Hopefully that was all it took to put an end to the
> Insteon flakiness and to keep it working for another 2 years.
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ________________________________________________________
> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>


------------------------------------------------------------------------------
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Insteon PLM errors

Lieven Hollevoet
Administrator
Hello Howard,

are the capacitors through-hole devices or are they surface-mount? Can you share any pics of the hardware? That info might help in providing you some tips/tricks.

Best regards,
 Lieven.

> Op 30 dec. 2016, om 16:02 heeft H Plato <[hidden email]> het volgende geschreven:
>
> It looks like my PLM also died over the holidays. LED light on the side is dim and flickery. Unplugging it for a few minutes brought it back to life, but now it's dead again.
>
> I’m going to order a new PLM, however I’d like to try repairing my old one so I have a backup. I’ve done a bit of soldering, but not much. Are there any guides or advice anyone might have on how to replace capacitors?  I saw Denny’s email about the thread on universal devices and will order those capacitors.
>
> Also, for those of you that have replaced a PLM, is there a simple method to replace it, by just updating the PLM’s address in the items.mht? Do all the insteon devices need to be relinked as controllers and responders?
>
>
>> On Dec 6, 2016, at 2:32 PM, Jeff Siddall <[hidden email]> wrote:
>>
>> On 11/10/2016 08:42 AM, Jeff Siddall wrote:
>>> My PLM has gone AWOL a few times in recent weeks.  It seems to start
>>> with errors like this:
>>>
>>> 11/09/16 06:04:59 PM [Insteon_PLM] ERROR: Received data did not start
>>> with a valid prefix.  Trimming to:
>>>
>>> which repeats many times.  Then nothing works after that:
>>
>> Update: after a number of those PLM errors in a row in the logs
>> yesterday MH finally crashed and since then no combination of unplugs
>> and MH restarts would get it do do anything.  I don't know if the crash
>> was related to something in the latest master I installed a few days ago
>> but in case it means anything here is the console errors:
>>
>> Can't call method "plm_receipt" on an undefined value at
>> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187.
>> at /usr/local/mh/bin/mh line 31.
>>        main::__ANON__("Can't call method \"plm_receipt\" on an
>> undefined value at /usr"...) called at
>> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187
>>        Insteon_PLM::_parse_data(Insteon_PLM=HASH(0x5a4b100),
>> "0257a2043229bd000000") called at
>> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 301
>>        Insteon_PLM::check_for_data(Insteon_PLM=HASH(0x5a4b100)) called
>> at /usr/local/mh/bin/../lib/Insteon/BaseInterface.pm line 33
>>        Insteon::BaseInterface::check_for_data() called at
>> /usr/local/mh/bin/mh line 1701
>>
>> Anyway, I pulled apart the PLM and replaced C7 & C13 with 10 uF 35 V
>> Nichicon caps I had on hand.  Put it back together and it seems to be
>> working fine again.  Hopefully that was all it took to put an end to the
>> Insteon flakiness and to keep it working for another 2 years.
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ________________________________________________________
>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>
>
> ------------------------------------------------------------------------------
> 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
>


------------------------------------------------------------------------------
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Insteon PLM errors

H Plato
I believe through-hole


On Jan 1, 2017, at 1:46 PM, Lieven Hollevoet <[hidden email]> wrote:

Hello Howard,

are the capacitors through-hole devices or are they surface-mount? Can you share any pics of the hardware? That info might help in providing you some tips/tricks.

Best regards,
Lieven.

Op 30 dec. 2016, om 16:02 heeft H Plato <[hidden email]> het volgende geschreven:

It looks like my PLM also died over the holidays. LED light on the side is dim and flickery. Unplugging it for a few minutes brought it back to life, but now it's dead again.

I’m going to order a new PLM, however I’d like to try repairing my old one so I have a backup. I’ve done a bit of soldering, but not much. Are there any guides or advice anyone might have on how to replace capacitors?  I saw Denny’s email about the thread on universal devices and will order those capacitors.

Also, for those of you that have replaced a PLM, is there a simple method to replace it, by just updating the PLM’s address in the items.mht? Do all the insteon devices need to be relinked as controllers and responders?


On Dec 6, 2016, at 2:32 PM, Jeff Siddall <[hidden email]> wrote:

On 11/10/2016 08:42 AM, Jeff Siddall wrote:
My PLM has gone AWOL a few times in recent weeks.  It seems to start
with errors like this:

11/09/16 06:04:59 PM [Insteon_PLM] ERROR: Received data did not start
with a valid prefix.  Trimming to:

which repeats many times.  Then nothing works after that:

Update: after a number of those PLM errors in a row in the logs
yesterday MH finally crashed and since then no combination of unplugs
and MH restarts would get it do do anything.  I don't know if the crash
was related to something in the latest master I installed a few days ago
but in case it means anything here is the console errors:

Can't call method "plm_receipt" on an undefined value at
/usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187.
at /usr/local/mh/bin/mh line 31.
      main::__ANON__("Can't call method \"plm_receipt\" on an
undefined value at /usr"...) called at
/usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187
      Insteon_PLM::_parse_data(Insteon_PLM=HASH(0x5a4b100),
"0257a2043229bd000000") called at
/usr/local/mh/bin/../lib/Insteon_PLM.pm line 301
      Insteon_PLM::check_for_data(Insteon_PLM=HASH(0x5a4b100)) called
at /usr/local/mh/bin/../lib/Insteon/BaseInterface.pm line 33
      Insteon::BaseInterface::check_for_data() called at
/usr/local/mh/bin/mh line 1701

Anyway, I pulled apart the PLM and replaced C7 & C13 with 10 uF 35 V
Nichicon caps I had on hand.  Put it back together and it seems to be
working fine again.  Hopefully that was all it took to put an end to the
Insteon flakiness and to keep it working for another 2 years.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users



------------------------------------------------------------------------------
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




------------------------------------------------------------------------------
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Insteon PLM errors

Jeff Siddall
On 01/01/2017 07:07 PM, H Plato wrote:
> I believe through-hole

Yes,

Definitely through-hole.  Nothing complicated.

Jeff

------------------------------------------------------------------------------
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Insteon PLM errors

H Plato
In reply to this post by H Plato
So just an update on this; my replacement PLM arrived (t’s a v2.1 and my old one was a v1), so I decided to replace the PLM while I try and figure out how to repair the old one.

The replacement process was a bit painful.

Looking at the list, I thought I needed to do was to ‘sync all links’, then delete orphans, and I was up and running. This was not the case. Trying to sync all links gave me an warning that I hadn’t linked the device to the interface.

OK, so I did that, went through each insteon device and did a link to interface, after that was done, I scanned the link table, then sync links.

That was a bit time consuming, but now MH could turn on and off insteon devices, so that was great.

However, I ran into another problem, turning on the device locally did not update MH status. So then I went to each physical device, and linked that device as both a controller and responder for the PLM. Now local changes are reflected in MH.

My IOLincs didn’t report back when the sensor closed, but I figure that’s due to the IOLinc not being a controller for the PLM.  Unfortunately I have to get a ladder to climb up to where the garage door openers are, so I’ll do that this weekend.

For about 30 devices, the PLM replacement took about 3 hours.

I didn’t ‘delete orphan links’ for two reasons;

- I thought having the old PLM as a record in all the devices would be useful once it is fixed. In theory if this PLM was to die, I should be able to take the old one and just plug it in.
- I have a few scenes that have peer-to-peer controller/responder links. I have a micro switch, and then three SwitchLinc relays to give me a pseudo 4 way switch. This works great, but if I delete orphan links they will all be deleted. MH controls the set as a scene:

INSTEON_ICONTROLLER, 15, garage_scene, All_Scenes
SCENE_MEMBER, garage_light, garage_light_inside, 100%, 0.1s
SCENE_MEMBER, garage_light, garage_scene, 100%, 0.1s
SCENE_MEMBER, garage_light, garage_light_bench, 100%, 0.1s
SCENE_MEMBER, garage_light, garage_light_outside, 100%, 0.1s
SCENE_MEMBER, garage_light_inside, garage_light, 100%, 0.1s
SCENE_MEMBER, garage_light_inside, garage_scene, 100%, 0.1s
SCENE_MEMBER, garage_light_inside, garage_light_bench, 100%, 0.1s
SCENE_MEMBER, garage_light_inside, garage_light_outside, 100%, 0.1s
SCENE_MEMBER, garage_light_bench, garage_scene, 100%,  0.1s
SCENE_MEMBER, garage_light_bench, garage_light, 100%, 0.1s
SCENE_MEMBER, garage_light_bench, garage_light_inside, 100%, 0.1s
SCENE_MEMBER, garage_light_bench, garage_light_outside, 100%, 0.1s
SCENE_MEMBER, garage_light_outside, garage_light, 100%, 0.1s
SCENE_MEMBER, garage_light_outside, garage_scene, 100%, 0.1s
SCENE_MEMBER, garage_light_outside, garage_light_bench, 100%, 0.1s
SCENE_MEMBER, garage_light_outside, garage_light_inside, 100%, 0.1s

Having gone through this, I have two questions that I’m wondering if people might have some ideas on;

- Am I doing something wrong on the linking? Should ‘link to interface’ make the device both a controller (to send updates) and a responder (to take changes from the PLM)?
- How does MH store peer-to-peer links? I also have a keypadlinc that is linked to an outdoor module to control some christmas lights. How should something like that be configured?

> On Dec 30, 2016, at 8:02 AM, H Plato <[hidden email]> wrote:
>
> It looks like my PLM also died over the holidays. LED light on the side is dim and flickery. Unplugging it for a few minutes brought it back to life, but now it's dead again.
>
> I’m going to order a new PLM, however I’d like to try repairing my old one so I have a backup. I’ve done a bit of soldering, but not much. Are there any guides or advice anyone might have on how to replace capacitors?  I saw Denny’s email about the thread on universal devices and will order those capacitors.
>
> Also, for those of you that have replaced a PLM, is there a simple method to replace it, by just updating the PLM’s address in the items.mht? Do all the insteon devices need to be relinked as controllers and responders?
>
>
>> On Dec 6, 2016, at 2:32 PM, Jeff Siddall <[hidden email]> wrote:
>>
>> On 11/10/2016 08:42 AM, Jeff Siddall wrote:
>>> My PLM has gone AWOL a few times in recent weeks.  It seems to start
>>> with errors like this:
>>>
>>> 11/09/16 06:04:59 PM [Insteon_PLM] ERROR: Received data did not start
>>> with a valid prefix.  Trimming to:
>>>
>>> which repeats many times.  Then nothing works after that:
>>
>> Update: after a number of those PLM errors in a row in the logs
>> yesterday MH finally crashed and since then no combination of unplugs
>> and MH restarts would get it do do anything.  I don't know if the crash
>> was related to something in the latest master I installed a few days ago
>> but in case it means anything here is the console errors:
>>
>> Can't call method "plm_receipt" on an undefined value at
>> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187.
>> at /usr/local/mh/bin/mh line 31.
>>        main::__ANON__("Can't call method \"plm_receipt\" on an
>> undefined value at /usr"...) called at
>> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187
>>        Insteon_PLM::_parse_data(Insteon_PLM=HASH(0x5a4b100),
>> "0257a2043229bd000000") called at
>> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 301
>>        Insteon_PLM::check_for_data(Insteon_PLM=HASH(0x5a4b100)) called
>> at /usr/local/mh/bin/../lib/Insteon/BaseInterface.pm line 33
>>        Insteon::BaseInterface::check_for_data() called at
>> /usr/local/mh/bin/mh line 1701
>>
>> Anyway, I pulled apart the PLM and replaced C7 & C13 with 10 uF 35 V
>> Nichicon caps I had on hand.  Put it back together and it seems to be
>> working fine again.  Hopefully that was all it took to put an end to the
>> Insteon flakiness and to keep it working for another 2 years.
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ________________________________________________________
>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>


------------------------------------------------------------------------------
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Insteon PLM errors

Eloy Paris
Hi Howard,

Sorry to hear about the pain you went through while replacing your PLM.
I think I've heard of similar stories from others in the past, and I
dread having to go through the same experience when mine dies.

A couple of comments:

> - I thought having the old PLM as a record in all the devices would be
> useful once it is fixed. In theory if this PLM was to die, I should be
> able to take the old one and just plug it in.

But if all devices still are sending updates to the old, non-present
PLM, would that not generate unneeded traffic? Basically, each device
would try to update the old PLM and because the PLM is not present then
there would be re-transmissions. That might cause network problems, I
think, plus, if you have battery-powered devices (like motion sensors)
then that would affect battery life.

> - Am I doing something wrong on the linking? Should ‘link to
> interface’ make the device both a controller (to send updates) and a
> responder (to take changes from the PLM)?

Yes, that's my understanding as well so I think you are doing the
linking properly.

I just skimmed through
https://github.com/hollie/misterhouse/wiki/Insteon-Link-to-Interface and
didn't see anything suspicious in terms of the process.

Do note the following comment in that page:

"Due to the nature of i2cs the link to interface procedure needs to be
done *before* anything else"

Perhaps that was the reason you received a warning when you tried to
sync all links before linking your devices to the PLM?

> - How does MH store peer-to-peer links? I also have a keypadlinc that
> is linked to an outdoor module to control some christmas lights. How
> should something like that be configured?

Not sure I follow but the inter-device links do not involve the PLM, do
they? In other words, I think the following statements:

SCENE_MEMBER, garage_light, garage_light_inside, 100%, 0.1s
[...]
SCENE_MEMBER, garage_light_inside, garage_light, 100%, 0.1s

create reciprocal links on those two devices (garage_light and
garage_light_inside) but these should be (I think) unrelated to links
involving the PLM.

Finally, just in case, I thought I'd mention that the "audit" commands
for removing orphaned links and sync'ing links is very handy, and allows
one to see what MH would do without actually doing anything. Very useful
to make sure that one does not create a problem when manipulating
devices' link tables.

Cheers,

Eloy Paris.-

On Fri, Jan 06, 2017 at 03:11:19PM -0700, H Plato wrote:

> So just an update on this; my replacement PLM arrived (t’s a v2.1 and my old one was a v1), so I decided to replace the PLM while I try and figure out how to repair the old one.
>
> The replacement process was a bit painful.
>
> Looking at the list, I thought I needed to do was to ‘sync all links’, then delete orphans, and I was up and running. This was not the case. Trying to sync all links gave me an warning that I hadn’t linked the device to the interface.
>
> OK, so I did that, went through each insteon device and did a link to interface, after that was done, I scanned the link table, then sync links.
>
> That was a bit time consuming, but now MH could turn on and off insteon devices, so that was great.
>
> However, I ran into another problem, turning on the device locally did not update MH status. So then I went to each physical device, and linked that device as both a controller and responder for the PLM. Now local changes are reflected in MH.
>
> My IOLincs didn’t report back when the sensor closed, but I figure that’s due to the IOLinc not being a controller for the PLM.  Unfortunately I have to get a ladder to climb up to where the garage door openers are, so I’ll do that this weekend.
>
> For about 30 devices, the PLM replacement took about 3 hours.
>
> I didn’t ‘delete orphan links’ for two reasons;
>
> - I thought having the old PLM as a record in all the devices would be useful once it is fixed. In theory if this PLM was to die, I should be able to take the old one and just plug it in.
> - I have a few scenes that have peer-to-peer controller/responder links. I have a micro switch, and then three SwitchLinc relays to give me a pseudo 4 way switch. This works great, but if I delete orphan links they will all be deleted. MH controls the set as a scene:
>
> INSTEON_ICONTROLLER, 15, garage_scene, All_Scenes
> SCENE_MEMBER, garage_light, garage_light_inside, 100%, 0.1s
> SCENE_MEMBER, garage_light, garage_scene, 100%, 0.1s
> SCENE_MEMBER, garage_light, garage_light_bench, 100%, 0.1s
> SCENE_MEMBER, garage_light, garage_light_outside, 100%, 0.1s
> SCENE_MEMBER, garage_light_inside, garage_light, 100%, 0.1s
> SCENE_MEMBER, garage_light_inside, garage_scene, 100%, 0.1s
> SCENE_MEMBER, garage_light_inside, garage_light_bench, 100%, 0.1s
> SCENE_MEMBER, garage_light_inside, garage_light_outside, 100%, 0.1s
> SCENE_MEMBER, garage_light_bench, garage_scene, 100%,  0.1s
> SCENE_MEMBER, garage_light_bench, garage_light, 100%, 0.1s
> SCENE_MEMBER, garage_light_bench, garage_light_inside, 100%, 0.1s
> SCENE_MEMBER, garage_light_bench, garage_light_outside, 100%, 0.1s
> SCENE_MEMBER, garage_light_outside, garage_light, 100%, 0.1s
> SCENE_MEMBER, garage_light_outside, garage_scene, 100%, 0.1s
> SCENE_MEMBER, garage_light_outside, garage_light_bench, 100%, 0.1s
> SCENE_MEMBER, garage_light_outside, garage_light_inside, 100%, 0.1s
>
> Having gone through this, I have two questions that I’m wondering if people might have some ideas on;
>
> - Am I doing something wrong on the linking? Should ‘link to interface’ make the device both a controller (to send updates) and a responder (to take changes from the PLM)?
> - How does MH store peer-to-peer links? I also have a keypadlinc that is linked to an outdoor module to control some christmas lights. How should something like that be configured?
>
> > On Dec 30, 2016, at 8:02 AM, H Plato <[hidden email]> wrote:
> >
> > It looks like my PLM also died over the holidays. LED light on the side is dim and flickery. Unplugging it for a few minutes brought it back to life, but now it's dead again.
> >
> > I’m going to order a new PLM, however I’d like to try repairing my old one so I have a backup. I’ve done a bit of soldering, but not much. Are there any guides or advice anyone might have on how to replace capacitors?  I saw Denny’s email about the thread on universal devices and will order those capacitors.
> >
> > Also, for those of you that have replaced a PLM, is there a simple method to replace it, by just updating the PLM’s address in the items.mht? Do all the insteon devices need to be relinked as controllers and responders?
> >
> >
> >> On Dec 6, 2016, at 2:32 PM, Jeff Siddall <[hidden email]> wrote:
> >>
> >> On 11/10/2016 08:42 AM, Jeff Siddall wrote:
> >>> My PLM has gone AWOL a few times in recent weeks.  It seems to start
> >>> with errors like this:
> >>>
> >>> 11/09/16 06:04:59 PM [Insteon_PLM] ERROR: Received data did not start
> >>> with a valid prefix.  Trimming to:
> >>>
> >>> which repeats many times.  Then nothing works after that:
> >>
> >> Update: after a number of those PLM errors in a row in the logs
> >> yesterday MH finally crashed and since then no combination of unplugs
> >> and MH restarts would get it do do anything.  I don't know if the crash
> >> was related to something in the latest master I installed a few days ago
> >> but in case it means anything here is the console errors:
> >>
> >> Can't call method "plm_receipt" on an undefined value at
> >> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187.
> >> at /usr/local/mh/bin/mh line 31.
> >>        main::__ANON__("Can't call method \"plm_receipt\" on an
> >> undefined value at /usr"...) called at
> >> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 1187
> >>        Insteon_PLM::_parse_data(Insteon_PLM=HASH(0x5a4b100),
> >> "0257a2043229bd000000") called at
> >> /usr/local/mh/bin/../lib/Insteon_PLM.pm line 301
> >>        Insteon_PLM::check_for_data(Insteon_PLM=HASH(0x5a4b100)) called
> >> at /usr/local/mh/bin/../lib/Insteon/BaseInterface.pm line 33
> >>        Insteon::BaseInterface::check_for_data() called at
> >> /usr/local/mh/bin/mh line 1701
> >>
> >> Anyway, I pulled apart the PLM and replaced C7 & C13 with 10 uF 35 V
> >> Nichicon caps I had on hand.  Put it back together and it seems to be
> >> working fine again.  Hopefully that was all it took to put an end to the
> >> Insteon flakiness and to keep it working for another 2 years.
> >>

------------------------------------------------------------------------------
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...