Jump to content

PLM Replacement


Recommended Posts

Posted

I just replaced my approx. 10 year old serial PLM connected to my Eisy with a new serial PLM. I followed the wiki replacement instructions and everything is working fine now but it was an interesting journey. This will be my 3rd PLM. I started quite early with insteon. I have about 120 insteon devices with 4 or 5 being wireless RL2s, a dozen or so Zwave devices and 11 node servers. The only wireless devices other than the RL2s are some Yolink devices. 

The reason for the replacement was erratic behavior with my lights starting about 6 months ago. I had a "all lights off" event when one of the KPL button was pressed. Never had this happen before. The only lights impacted were about 15 or so of the older insteon switches that respond to the all off command. A few months went by with no problems but then I experienced a few "all lights on events" which I also never had before but only when an insteon switch (KPL I think) was activated but this did not always happen (but was sometimes repeatable). Then I just started occasionally having only a few of the older insteon lights coming on (but not all of them) but this was infrequent and random but very annoying (WAF!). 

The replacement process took about 3 hours. During the replacement process I had 55 popup messages saying "could not communicate with...". and 3 times there was a message saying that the system was restarted or rebooted and to create a new session which I did.

At the end of all this, everything including the programs were working as normal and I have had no random events for 3 or 4 weeks now.

Wondering what the significance was of the popup messages since everything works fine.

Gary

Posted

It's a guess;

I can't think of a busier time on the insteon network than during a plm replacement. A number of messages to each device to reconfigure them. Sometimes messages don't make it, in either direction, and then they are repeated.

My guess is that as iox stepped through each device to reconfigure it, collisions sometimes happened, but the iox code is also retrying what it couldn't finish until it was complete.....  and you got a message each time it happened.

 

  • Like 1
Posted

Is the “all on” command in the PLM or in devices? I’ve had many “all on” events over the years. I did everything prescribed to mitigate them but would occasionally get one. I noticed it only affected my older devices. After EISY and new PLM I haven’t had one in some time till last week. 2:00 am and everything (old and new devices) came on. Hard to explain to wife what was going on 🙄.  Very annoying

Posted
1 hour ago, drprm1 said:

Is the “all on” command in the PLM or in devices? I’ve had many “all on” events over the years. I did everything prescribed to mitigate them but would occasionally get one. I noticed it only affected my older devices. After EISY and new PLM I haven’t had one in some time till last week. 2:00 am and everything (old and new devices) came on. Hard to explain to wife what was going on 🙄.  Very annoying

I had a receptacle On/Off module go erratic and produced an Insteon Scene On command occasionally, when sent a simple On or Off. It happened about 7 or 8 times over a few years or more. Since I recognised the lighting pattern, I always thought it was just a bad program somewhere, but could never identify it's source.

Eventually, I was examining my Log and found some bad packets from this particular module instead of the ACK expected from it. The time coincided with the latest erratic Insteon scene occurrence. In a first ditch effort to nail it down further, I simply unplugged the on/off module and plugged it back in again. I could not ever figure out why power failures didn't do the same thing, but years after (as I type this), I just realised that the difference may have been the inductive motor load I had plugged into it. When I did it manually, there would have been no inductive load (humidifier) attached.

After power cycling the module, it never happened again for about the last 5 years.

I post this example because I believe ALL ONs are just another form of Insteon Scenes, that can be produced by any module in your system. Other Insteon modules could then see this, and repeat it into the closest valid Insteon signal code. Insteon has demonstrated that it really doesn't have any signal security, despite what has ever been proposed in white papers.

  • Like 1
Posted
On 7/9/2024 at 7:15 PM, larryllix said:

I had a receptacle On/Off module go erratic and produced an Insteon Scene On command occasionally, when sent a simple On or Off. It happened about 7 or 8 times over a few years or more. Since I recognised the lighting pattern, I always thought it was just a bad program somewhere, but could never identify it's source.

Eventually, I was examining my Log and found some bad packets from this particular module instead of the ACK expected from it. The time coincided with the latest erratic Insteon scene occurrence. In a first ditch effort to nail it down further, I simply unplugged the on/off module and plugged it back in again. I could not ever figure out why power failures didn't do the same thing, but years after (as I type this), I just realised that the difference may have been the inductive motor load I had plugged into it. When I did it manually, there would have been no inductive load (humidifier) attached.

After power cycling the module, it never happened again for about the last 5 years.

I post this example because I believe ALL ONs are just another form of Insteon Scenes, that can be produced by any module in your system. Other Insteon modules could then see this, and repeat it into the closest valid Insteon signal code. Insteon has demonstrated that it really doesn't have any signal security, despite what has ever been proposed in white papers.

I had a similar experience with a plugin dimmer module many years ago. I have a number of plugin modules that are primarily used to power various Christmas decorations. Wife plugged a fountain into a dimmer module once. The dimmer module did not play well with the pump motor and caused disruption on the network. Sometimes things went on when they should not and sometimes did not go on when they should 

Guest
This topic is now closed to further replies.

×
×
  • Create New...