Another ALL ON Event

[marvel]

I read through this thread and don't see a solid resolution. Can anyone confirm whether a new PLM with the latest hardware & firmware resolves this? Also, what about the UDI PLM, is that available now?

 

I'm having the same problem here. It seems to be happening around 10pm, three times now in the past several weeks. I have one event that runs at 10pm, setting a scene to dim my exterior lights if certain conditions are met (attached). It's a pretty basic scene and has worked well for years. I don't see anything in it that could be causing this.

 

Here's a snapshot of my logs from the event last night:

Scene:Exterior / Exterior lights dim On 255 Wed 2015/08/26 10:00:00 PM Program Log
Interior / Upstairs / LaundryCenter KP:E Garage 2 Status 100% Wed 2015/08/26 10:00:01 PM System Log
Exterior / Garage / Garage 2-Sensor Status 100% Wed 2015/08/26 10:00:01 PM System Log
Interior / Upstairs / LaundryCenter KP:A GarageLts On   Wed 2015/08/26 10:00:01 PM Program Log
Interior / Upstairs / LaundryCenter KP:G Garage 3 Status 100% Wed 2015/08/26 10:00:01 PM System Log
Exterior / Garage / Garage 3-Sensor Status 100% Wed 2015/08/26 10:00:01 PM System Log
Interior / Upstairs / LaundryCenter KP:C Garage 1 Status 100% Wed 2015/08/26 10:00:01 PM System Log
Exterior / Garage / Garage 1-Sensor Status 100% Wed 2015/08/26 10:00:01 PM System Log
Interior / Upstairs / LaundryCenter KP:A GarageLts Status 100% Wed 2015/08/26 10:00:04 PM System Log

When the "Exterior Lights Dim" scene executed, every device in the house turned on. Most of the lights didn't come to full brightness like the last two times this happened; they were all at very low dim levels. As you can see, the IO Lincs on the garage doors all triggered as well. The rest of the log entries begin 23 seconds later and are me running around turning things off. 

 

Ideas?

 

[Michel Kohanim]

Hi marvel,

 

The new PLMs (version 2c and above) should help.

 

In the meantime, please review this post for some remedies:

http://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events 

 

With kind regards,

Michel

[EricK]

Hi EricK,

 

Please checkout this article:

http://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events

 

With kind regards,

Michel

Thanks, I am going to reconfigure my MS set up. Eric

[dstanley]

Things had been going well for me lately. I moved the MS away from my foyer that led to my garage. Almost all my All Ons were related to opening one of the garage doors manually and some conflict with the sensor.

So I moved this MS to my dining room for the last month or so. It needs to be noted that there are NO links or scenes with this MS ... just the PLM link when it was added to my system.

 

So today my wife was in the dining room vacuuming when I arrived home and opened one of the garage doors ... I knew I was in trouble when I saw both doors opening. Another ALL ON for me.

 

I also only have two MS in my system  An old one (2420M-SP) is in the kitchen and it has never caused a problem. My ALL ON started with the addition of this one MS (2842-222) to my system.

 

Since I never used this sensor for anything in my system yet I am going to remove it and never use it again.

 

Also ... I am still using the 'test plm' courteously supplied by Michel of UDI when Smarthome made some firmware changes. I have experienced at least two ALL ONs with this firmware.

 

I want to replace this PLM but good lord - I wish Smarthome would do something.

 

Dwight

[Teken]

Things had been going well for me lately. I moved the MS away from my foyer that led to my garage. Almost all my All Ons were related to opening one of the garage doors manually and some conflict with the sensor.

So I moved this MS to my dining room for the last month or so. It needs to be noted that there are NO links or scenes with this MS ... just the PLM link when it was added to my system.

 

So today my wife was in the dining room vacuuming when I arrived home and opened one of the garage doors ... I knew I was in trouble when I saw both doors opening. Another ALL ON for me.

 

I also only have two MS in my system An old one (2420M-SP) is in the kitchen and it has never caused a problem. My ALL ON started with the addition of this one MS (2842-222) to my system.

 

Since I never used this sensor for anything in my system yet I am going to remove it and never use it again.

 

Also ... I am still using the 'test plm' courteously supplied by Michel of UDI when Smarthome made some firmware changes. I have experienced at least two ALL ONs with this firmware.

 

I want to replace this PLM but good lord - I wish Smarthome would do something.

 

Dwight

Well that isn't very good hear. . I was really hoping this whole ALL ON - ALL OFF issue was put to bed and behind those impacted by this.

 

 

Ideals are peaceful - History is violent

[stusviews]

SH has done something. They removed the All On/Off command from all shipping devices some months ago. Albeit, it doesn't help those with earlier devices. I'm not sure what else they can do that wouldn't wreak havoc on their finances.

[dstanley]

Well from my understanding it is a malformed instruction asking the PLM to turn everything on. Who would ever want that to happen!? Why not program or prevent the PLM from ever doing that in the firmware of that device as well? That way one replacement PLM and the issue is gone. I think that is what they attempted to do with this trial PLM but missed the mark on this version!

I also think it has something to do with the latest MS and not the older ones for some reason.

Now I have this newer MS out of my system and I am willing to bet money that an ALL ON will not happen again because it is removed.

 

Dwight

[Teken]

Well from my understanding it is a malformed instruction asking the PLM to turn everything on. Who would ever want that to happen!? Why not program or prevent the PLM from ever doing that in the firmware of that device as well? That way one replacement PLM and the issue is gone. I think that is what they attempted to do with this trial PLM but missed the mark on this version!

I also think it has something to do with the latest MS and not the older ones for some reason.

Now I have this newer MS out of my system and I am willing to bet money that an ALL ON will not happen again because it is removed.

 

Dwight

 

Hello Dwight,

 

Can you provide a little more clarity to your comments above. Was this *New MS* in place during the trial HUB PLM period. Is it fair to say while in place for quite awhile no ALL ON's have been seen with it in place.

 

Now say a few months later you experience another ALL ON event with all the same Insteon devices in place. I am hard pressed to understand how if all the same elements are in place. Save the new addition of the HUB PLM and things were calm and fine for an extended period of time.

 

Now this problem reappears??

 

1. Has this new MS always been in place during the HUB PLM trial? Or has it just been added to the Insteon network?

2. Have you made the program changes outlined by Michel where wait (seconds) are included to help off set this issue?

3. Have you ever removed the the HUB PLM & ISY Controller from the network and seen this issue?

[MWareman]

SH has done something. They removed the All On/Off command from all shipping devices some months ago. Albeit, it doesn't help those with earlier devices. I'm not sure what else they can do that wouldn't wreak havoc on their finances.

They could sell us the ability to reflash the devices.....

[stusviews]

They could sell us the ability to reflash the devices.....

 

Unfortunately, it's not that easy. Even at SH they don't/can't flash the devices over the powerline. If you remove a paddle, you'll see six points of contact at the top, left (three rows of two/two columns of three). Those contacts need to be accessed in order to flash an existing device. Access to KPL contacts is at the top, center under the frame.

 

At the SH HQ, that part of the paddle is cut out in order to flash installed SwitchLincs without removing them.

[MWareman]

They could, if they wanted to, sell a device to allow us to reprogram via these pins. Then we could flash all of our devices to a version without the ALL-ON. A pain, sure. I for one want to be able to do this though.

[Brian H]

Well the normal user could kill themselves. Not something the lawyers at Smartlabs would want to address.

The 5 volt logic supply in some of the Insteon modules is the Power Line AC 120 volts above ground.

That is also the 5 volt logic supply on the programming pins.

Modules like ApplianceLincs and LampLincs would have to be disassembled to program them. Again real near the pass through outlet AC pins and 5 volt logic supply sitting 120 volts above ground.

 

Dual Bands also have an RF Controller chip set of programming pins and I believe that aye not available from the outside.

 

Smartlabs has always been extremely protective of their firmware and not providing to to any outside sources.

Well at least so far. Lets hope UDI can eventually get the PLM firmware so they can proceed with their own PLM. Though my experiences with the Developer Groups showed lots of stalling and excuses why the chips where not available.

[MWareman]

 

 

Well the normal user could kill themselves. Not something the lawyers at Smartlabs would want to address.

If that was their concern, they wouldn't be selling the devices for consumer installation in places like Walmart, Home Depot and Menard's.

[dstanley]

Tekken,

I am not using a HUB PLM but a modified PLM provided by Michel as mentioned earlier in this thread. (Not home right now to get details).

I had at least one ALL ON in my system with this newer MS in my foyer. I believe that the MS was firing data while my garage door was opened using a non-insteon button. I do have an IO-Linc hooked up to the doors and use the data to turn on an overhead light. I had added the seconds delay early on in my testing.

Since I had that all on I moved this MS out of my foyer and placed it in my dining room. This MS had no scenes and no programs associated with it - just the PLM link form the initial linking process. I had planned on using it but never got around to it.

Since it was moved I had not had an all on until the other day. The house is only occupied by my wife and I so there has not been many instances where the MS was triggered while the garage door was opened. It obviously doesn't happen every time there is a collision but once in a while it does. Moving the MS just made the incidents far, far apart.

I have now removed this MS from my system completely.

I have never run my system without my isy994 - I do use a few programs every day with the system.

Not sure if I have answered all,of your questions but hope I have helped somewhat!?

 

Dwight

[dstanley]

Tekken,

Just to add to this I have not added anything new to my system in a long time. I refer to this as a new MS simply because it is a different model number than my original MS in my kitchen. I have had it for quite a while in my system but not used by the ISY.

I can say with almost certainty that the combination of this MS firing and the IO-Linc activating causes some kind of event totally unknown to the ISY but seen at the PLM as an ALL ON command. Even after the event has happened the ISY has no idea that things have changed and needs a query all to 'right' the status of the devices.

I think that almost all of these all one involve a motion sensor and now I am curious if it is just the later issued model that it has happened with!?

 

Dwight

[Teken]

I guess what troubles me the most is the fact none of this is repeatable. This thread has extended past six pages and there is a consistent theme in all of this.

 

Which is no one at an engineering level is able to reproduce this odd behavior. I have no doubt this particular issue is on the radar for Smartlabs but it would be very helpful if someone would offer some kind of diagnostic tool. As others have mentioned its quite impossible that these COM's are not available for capture and viewing.

 

As I have indicated in this thread and elsewhere perhaps the easiest (short term) solution is to implement a system wide shut down of the ALL ON - ALL OFF capability with in the ISY Series Controller.

 

I've been asked and pressed on this issue many times in hundreds of installs to date. Some of the feed back and questions in my mind are hard to ignore or explain away.

 

To the point:

 

1. As far as we are aware the latest 2413S PLM hardware no longer has the ability to issue a ALL ON - ALL OFF command.

 

2. As of this writing any newly produced Insteon devices no longer support the ALL ON  - ALL OFF command.

 

3. Given there are still people who have number (1) PLM's in place which do not have such commands. Yet continue to see such random events to occur its highly unlikely its the PLM.

 

4. This begs to ask the question what else in the system is capable of issuing ALL ON - ALL OFF commands?

 

Perhaps I am over simplifying the issue at hand. Or have over looked other factors which we already know contributes to some instances of ALL ON - ALL OFF. Some people have seen less instances by incorporating wait times, while others have changed programs to correct flaws in logic (tight loops, repeats, over lapping time intervals) etc.

 

While others have removed any sort of association where more than one device is a controller to a scene etc.

 

5. Bench Mark Testing: Moving forward this is something I have thought about for quite sometime. Given (1) & (2) if Smartlabs was to exchange just one house that is impacted by this issue on a consistent basis. With new products that do not have any ability to issue a ALL ON - ALL OFF command.

 

If the issue is not present we have 50% of the validation.

 

Should the (Test) home using said hardware experience even one ALL ON - ALL OFF condition in (4) this is the area where resources need to be focused upon.

 

In my mind taking one known test home to help validate ideas, thoughts, and hardware is the most practical and next logical step in this process. As its clear to me this issue is not going away and the biggest problem is not a soul is able to repro the steps???

 

I have over 389 Insteon sites at the moment and 65% of them are using the ISY Series Controller. Not a single site has been impacted by this odd behavior and truly hope I never do! Some of the sites have extremely complex programs and scenes in place.

 

Again, not one site has ever seen such odd behavior and the hardware spans at least six years of hardware releases. The bulk of these clients are very aware of this situation and many have asked me repeatedly where this issue stands.

 

My personal thoughts are this issue needed to be solved yesterday. People at the highest level need to engage one or more customers in this thread and do a *Test Site*. I don't care what people think about the time, effort, or cost.

 

Because the reality is, this issue is all over the Internet and is hurting both companies and the Home Automation industry as a whole! The over all impact and cost over the long run to both companies can not be understated.

 

America is the most litigious country in the free world bar none. It only takes one person to file a suite and win indicating some kind of harm, loss, damage was seen due to the above issue(s).

 

The ISY Series Controller has been the cornerstone of my home automation and thousands of others around the world. Insteon too has been the cornerstone of my home and millions of others around the globe.

 

I have no doubt UDI takes this issue very seriously as does Smartlabs.

 

But my suggestion posted above is the next logical step in identifying root cause and deploying a fix where ever it may be. Speaking for myself and thousands of others across the globe seeing the UDI name tarnished in any small way is not acceptable on any level, none.

 

UDI has lead the way in not only direct communications but also possible fix's to this issue. They have continued to help and facilitate PLM exhanges in hopes of resolving this issue. The next logical step is for Smartlabs to work in concert with UDI in setting up a test site.

 

This in my mind will speed up this extended process that simply won't go away. I hope these writings are read and understood by those empowered to do so.

 

Regards . . . 

[Michel Kohanim]

Hello everyone,

 

I just want to reiterate what we think causes the issue:

Simultaneous command from an INSTEON device (mostly RF because they repeat the same command twice) while ISY is sending a command to the PLM for a scene and/or a scene for which the same device may be a controller. Although adding delays may work alas they just reduce the likelihood of collision. At some point, they will happen. So, the best way to address this issue is to make sure you don't have any devices that are both controllers in a scene AND that they are used in an ISY program to cause another INSTEON action.

 

With kind regards,
Michel

[EricK]

I guess what troubles me the most is the fact none of this is repeatable. This thread has extended past six pages and there is a consistent theme in all of this.

 

Which is no one at an engineering level is able to reproduce this odd behavior. I have no doubt this particular issue is on the radar for Smartlabs but it would be very helpful if someone would offer some kind of diagnostic tool. As others have mentioned its quite impossible that these COM's are not available for capture and viewing.

 

As I have indicated in this thread and elsewhere perhaps the easiest (short term) solution is to implement a system wide shut down of the ALL ON - ALL OFF capability with in the ISY Series Controller.

 

I've been asked and pressed on this issue many times in hundreds of installs to date. Some of the feed back and questions in my mind are hard to ignore or explain away.

 

To the point:

 

1. As far as we are aware the latest 2413S PLM hardware no longer has the ability to issue a ALL ON - ALL OFF command.

 

2. As of this writing any newly produced Insteon devices no longer support the ALL ON - ALL OFF command.

 

3. Given there are still people who have number (1) PLM's in place which do not have such commands. Yet continue to see such random events to occur its highly unlikely its the PLM.

 

4. This begs to ask the question what else in the system is capable of issuing ALL ON - ALL OFF commands?

 

Perhaps I am over simplifying the issue at hand. Or have over looked other factors which we already know contributes to some instances of ALL ON - ALL OFF. Some people have seen less instances by incorporating wait times, while others have changed programs to correct flaws in logic (tight loops, repeats, over lapping time intervals) etc.

 

While others have removed any sort of association where more than one device is a controller to a scene etc.

 

5. Bench Mark Testing: Moving forward this is something I have thought about for quite sometime. Given (1) & (2) if Smartlabs was to exchange just one house that is impacted by this issue on a consistent basis. With new products that do not have any ability to issue a ALL ON - ALL OFF command.

 

If the issue is not present we have 50% of the validation.

 

Should the (Test) home using said hardware experience even one ALL ON - ALL OFF condition in (4) this is the area where resources need to be focused upon.

 

In my mind taking one known test home to help validate ideas, thoughts, and hardware is the most practical and next logical step in this process. As its clear to me this issue is not going away and the biggest problem is not a soul is able to repro the steps???

 

I have over 389 Insteon sites at the moment and 65% of them are using the ISY Series Controller. Not a single site has been impacted by this odd behavior and truly hope I never do! Some of the sites have extremely complex programs and scenes in place.

 

Again, not one site has ever seen such odd behavior and the hardware spans at least six years of hardware releases. The bulk of these clients are very aware of this situation and many have asked me repeatedly where this issue stands.

 

My personal thoughts are this issue needed to be solved yesterday. People at the highest level need to engage one or more customers in this thread and do a *Test Site*. I don't care what people think about the time, effort, or cost.

 

Because the reality is, this issue is all over the Internet and is hurting both companies and the Home Automation industry as a whole! The over all impact and cost over the long run to both companies can not be understated.

 

America is the most litigious country in the free world bar none. It only takes one person to file a suite and win indicating some kind of harm, loss, damage was seen due to the above issue(s).

 

The ISY Series Controller has been the cornerstone of my home automation and thousands of others around the world. Insteon too has been the cornerstone of my home and millions of others around the globe.

 

I have no doubt UDI takes this issue very seriously as does Smartlabs.

 

But my suggestion posted above is the next logical step in identifying root cause and deploying a fix where ever it may be. Speaking for myself and thousands of others across the globe seeing the UDI name tarnished in any small way is not acceptable on any level, none.

 

UDI has lead the way in not only direct communications but also possible fix's to this issue. They have continued to help and facilitate PLM exhanges in hopes of resolving this issue. The next logical step is for Smartlabs to work in concert with UDI in setting up a test site.

 

This in my mind will speed up this extended process that simply won't go away. I hope these writings are read and understood by those empowered to do so.

 

Regards . . .

Hello everyone,

 

I just want to reiterate what we think causes the issue:

Simultaneous command from an INSTEON device (mostly RF because they repeat the same command twice) while ISY is sending a command to the PLM for a scene and/or a scene for which the same device may be a controller. Although adding delays may work alas they just reduce the likelihood of collision. At some point, they will happen. So, the best way to address this issue is to make sure you don't have any devices that are both controllers in a scene AND that they are used in an ISY program to cause another INSTEON action.

 

With kind regards,

Michel

Hello everyone, I just want to reiterate what we think causes the issue:Simultaneous command from an INSTEON device (mostly RF because they repeat the same command twice) while ISY is sending a command to the PLM for a scene and/or a scene for which the same device may be a controller. Although adding delays may work alas they just reduce the likelihood of collision. At some point, they will happen. So, the best way to address this issue is to make sure you don't have any devices that are both controllers in a scene AND that they are used in an ISY program to cause another INSTEON action. With kind regards,Michel

My wife came home this evening and every insteon device in the house was on. I no longer have motion sensors controlling a scene and triggering a program, which seems to be a trigger for my last all on. I checked the logs and there appeared to be some scene feedback from what was probably the all on. This occurred more than a few after a timer program turned some lights on. Again, no one was home.

What is also interesting is that Kpl secondary buttons turn on.

In addition, last night some scenes or devices just turned off including the kitchen lights, outside landscape and front lights, lights up the stairs.

My plm is just under two years old so I emailed smarthome to try to set up,an exchange. I have away buttons by some doors that essentially turn everything off in the house. I may need to have an all on recovery button that turns everything off, then runs my timer programs to turn on devices that should be on. Like a huge box of band aids.

[Michel Kohanim]

Hi EricK,

 

I am so very sorry to hear. Do we know the approximate time of any of these events? i.e. if you have can see ON or OFF status in the logs for your devices, then it's really not an All On/Off but a program. Do you see on/off events in the logs?

 

With kind regards,

Michel

[EricK]

Michel, can you check this log for me.  I see a program ran at 741.  Then at 748 there are multiple system logs.  However, the GR door sensor went 100% at 7:48:12,  So i think the 748 activity is a result of my wife coming home and pressing buttons/switches, not from the all on.  She probably came in and went right for the GR door to let the dog out.

Thank you,

Eric

Scene:Hall and Foyer, Office / Hall and Foyer, Office Scenes / Hallway Stairs 90%	On	 	Fri 2015/09/11 06:51:42 PM	Program	Log	

Master Bedroom / Master Bedroom Devices / Master Shades-Relay	Off	0	Fri 2015/09/11 07:41:42 PM	Program	Log	

Great Room / Great Room Devices / GR Sink KPL - A Cabinet / GR Sink KPL - E Family	Status	0%	Fri 2015/09/11 07:48:00 PM	System	Log	

Great Room / Great Room Devices / GR Sink KPL - A Cabinet / GR Sink KPL - F Spots	Status	0%	Fri 2015/09/11 07:48:00 PM	System	Log	

Great Room / Great Room Devices / GR Sink KPL - A Cabinet / GR Sink KPL - H Dining	Status	100%	Fri 2015/09/11 07:48:00 PM	System	Log	
Master Bedroom / Master Bedroom Devices / Master Door KPL - A Lights / Master Door KPL - E Cabinets	Status	100%	Fri 2015/09/11 07:48:00 PM	System	Log	

Great Room / Great Room Devices / GR Family Room Lights	Status	0%	Fri 2015/09/11 07:48:00 PM	System	Log	

Great Room / Great Room Devices / GR Spots	Status	0%	Fri 2015/09/11 07:48:00 PM	System	Log	

Great Room / Great Room Devices / GR Spots KPL (DB) - A Spots	Status	0%	Fri 2015/09/11 07:48:00 PM	System	Log	

Great Room / Great Room Devices / GR Spots KPL (DB) - A Spots / GR Spots KPL (DB) - E Dining	Status	100%	Fri 2015/09/11 07:48:00 PM	System	Log	

Master Bedroom / Master Bedroom Devices / Master Door KPL - A Lights / Master Door KPL - F Kitchen	Status	100%	Fri 2015/09/11 07:48:00 PM	System	Log	

Great Room / Great Room Devices / GR Sink KPL - A Cabinet / GR Sink KPL - G Fan	Status	0%	Fri 2015/09/11 07:48:01 PM	System	Log	

Great Room / Great Room Devices / GR Fan	Status	0%	Fri 2015/09/11 07:48:01 PM	System	Log	

Scene:Great Room / Great Room Scenes / GR Night KPL	Off	0	Fri 2015/09/11 07:48:03 PM	Program	Log	

Scene:Great Room / Great Room Scenes / GR Night KPL	Off	0	Fri 2015/09/11 07:48:06 PM	Program	Log	

Scene:Great Room / Great Room Scenes / GR Dining Correction	Off	0	Fri 2015/09/11 07:48:07 PM	Program	Log	

GR Door Sensor-Opened	Status	100%	Fri 2015/09/11 07:48:12 PM	System	Log	

[marvel]

I just experienced another all on event with my new PLM. 2413S v2.1 1514. Definitely related to setting KPL backlights. Should I just stop doing that programatically or is there a workaround? I have 9 KPLs and I like them dimmed when I'm sleeping. 

[Techman]

I just experienced another all on event with my new PLM. 2413S v2.1 1514. Definitely related to setting KPL backlights. Should I just stop doing that programatically or is there a workaround? I have 9 KPLs and I like them dimmed when I'm sleeping. 

 

Are all the KPL backlights dimmed at the same time? If so try adding a 10 second wait between devices.

[stusviews]

All our media room KPLs (6) dim at the start of a movie and are restored at the end. All our BR KPLs (3) and SwitchLincs (7) do the same at bedtime and in the morning, respectively. We have experienced several All On events, none related to the device LED brightness.

 

Look at what else occurs at or about the same time. I inadvertently caused an All On when I had a program with a KPL button as both a trigger for and responder to (as a scene member) the same program and tapped the button a few times too rapidly.

 

Edit: This doesn't mean that your All On is not related the the KPL brightness. Every All On appears to be different. This is just my experience. The only commonality appears to be a signal collision.

[marvel]

Thank you for the replies. Yeah, all backlights are dimmed at the same time, although I've noticed it takes about half a minute to process through them. It doesn't happen instantly. I don't know if the ISY is waiting for each SET command to complete before moving on to the next, or if it's flooding the network with all of them at once and the KPLs are just responding sequentially, but I'd imagine the former is true. 

 

stusviews, this was very very helpful, thank you. Yes the very KPL button I'm pressing is triggering itself. This was done so I could activate the scene remotely and have the button light up. I will remove this and see if it helps. If not, I'll try putting time between the KPL backlight settings.

[Techman]

Thank you for the replies. Yeah, all backlights are dimmed at the same time, although I've noticed it takes about half a minute to process through them. It doesn't happen instantly. I don't know if the ISY is waiting for each SET command to complete before moving on to the next, or if it's flooding the network with all of them at once and the KPLs are just responding sequentially, but I'd imagine the former is true. 

 

Your should definitely try spacing out the dimming commands. There's probably too much data flowing back and forth at the same time which can cause issues in the PLM. Each dimming command takes more time than just an on or off command.