A deeper understanding of Scenes (Groups), and Diagnostics

[Illusion]

I am having the classic problem I have read about on this forum with scenes where some devices will not respond some of the time. In troubleshooting this issue, which is not yet resolved I have come up with many questions and a few ideas I would like to share.

 

The scenario: I have a 6 button KPL being the originator of my request, 1 ApplianceLinc and 3 LampLincs as the responders. The main on button of the KPL triggers a scene via a program in the ISY (v2.7.4 at the time of this writing) and the off button triggers a different scene via a program in the ISY. Sometimes some of the devices will not respond to the on scene, and other times some devices will not respond to the off scene. Interestingly, all the devices I am trying to control are on the same non-surge suppressing power strip. Further, this set-up worked with 100% reliability for a year. I added a couple of additional Insteon devices elsewhere and now I am at 75%.

 

Rather than just fix this issue I am having, I am trying to gain a greater understanding to facilitate greater skills for problem solving in the future.

 

I know the defacto answer is communication issues, but I am having a difficult time wrapping my head around that as each device that is supposed to respond are within inches of each other electrically on the same circuit on the same power strip.

 

Questions I have come up with after reading the forum posts on this issue for hours and hours.... and hours:

 

1. If I have a single Insteon device (controller) talking to a single Insteon device (responder) and no ISY in the system, the controller would send a direct message to the responder and look for a response, pending none it would retry up to five times. Is this a correct understanding?

 

2. If that is a correct understanding as I believe it is, if we add an additional Insteon device (responder) that we also want to have come on, now the controller switches to group broadcast mode with individual clean-ups and does not send a direct command except in the clean-up. Is that correct?

 

3. If that is correct as I believe it is, then even with a single Insteon device (controller) and a single Insteon device (responder) and the ISY in the system, all commands are going to be sent as group broadcasts with clean-ups as the ISY itself is a member of every scene in order to keep track of things, Is this correct? I do not think I understand this well as I just unplugged my PLM and triggered a scene from a controller and would expect to see the flashing error in transmission signal on the controller, as the PLM cannot respond, and did not.

 

4. How can this intermittent failure of devices to respond be so prevalent in the Insteon protocol? As I understand the protocol, after a group broadcast, which is not acknowledged, a device specific clean-up command is sent to each device in the scene (Group). So in my case I press the KPL on or off button, and that signal always makes it to the ISY/PLM. Then the ISYs program triggers a scene via a group command. Should not this group command be followed up with individual device specific direct messages? Do the clean-up commands not get repeated, do they have lower hop counts? Do the clean-up commands not look for an ACK and if it is not received for an individual device it retries it up to 5 times? Obviously I am confused on this issue as even with communication problems some of the devices respond, and other times different devices respond. I never see a device come on a second later having been picked up in the clean-up. If the command were retried up to 5 times with a 3 max hop count I would always see all the devices respond eventually, just as when I press the respective button on the KPL a second time the delinquent devices almost always respond. Five tries is never necessary.

 

5. How can there be a NAK? If the device gets the signal, how can it send a Not Acknowledged reply. Why not just execute the command and send an ACK? A touch off the topic at hand but it ties in with trying to understand the failures.

 

6. Trying to understand the event viewer for this problem brings up many of the aforementioned questions. Here is the level three for a failed execution:

 

2009/06/06 18:31:57 : [iNST-SRX ] 02 50 0A.DA.93 00.00.01 CB 13 00 LTOFFRR(00)

 

2009/06/06 18:31:57 : [standard-Group][0A.DA.93-->Group=1] Max Hops=3, Hops Left=2

 

2009/06/06 18:31:57 : [ A DA 93 1] DOF 0

 

2009/06/06 18:31:57 : [iNST-SRX ] 02 50 0A.DA.93 0C.A6.33 41 13 01 LTOFFRR(01)

 

2009/06/06 18:31:57 : [standard-Cleanup][0A.DA.93-->ISY/PLM Group=1] Max Hops=1, Hops Left=0

 

2009/06/06 18:31:58 : [ A DA 93 1] ST 0

 

2009/06/06 18:31:58 : [iNST-ACK ] 02 62 00.00.23 CF 13 00 06 LTOFFRR(00)

 

2009/06/06 18:31:58 : [ E 7C 0 1] ST 0

 

2009/06/06 18:31:58 : [ A DA 93 3] ST 0

 

2009/06/06 18:31:58 : [ A DA 93 4] ST 0

 

2009/06/06 18:31:58 : [ A DA 93 5] ST 0

 

2009/06/06 18:31:58 : [ E 7C 21 1] ST 0

 

2009/06/06 18:31:58 : [ D 53 C7 1] ST 0

 

 

The second line up from the bottom E.7C.21 did not in fact turn off as it should. Of course the ISY thinks it did. This event log is identical to a successful execution of the same command. It sure would be nice to have the device names instead of just the addresses in this event viewer. It would make troubleshooting quicker. I guess that is a feature request.

 

7. In this case, why did the PLM not retry to send to E.7C.21? This is the entire event log for that failed execution. It sure does not look to me like the PLM is sending individual clean-up commands and awaited ACKs and attempting retries. Is this the way group commands work in the Insteon protocol? Is this identical to the execution I would see if the scene were just held in a KPL and executed from there?

 

On the subject of fixing this specific issue I am now having:

I have 6 access points in 2400 square feet. I have one piggybacked on the PLM that is on an outlet next to the service panel. I tried putting an access point on the very power strip that the failing devices are on and that actually seemed to reduce my reliability. I was doing better when I had 4 APs than I am now that I have 6. That was when this scene was 100% responsive, but I added some motion sensors some time ago, and without the extra APs some of the motion detectors are not reliable. I have filters on almost all electonics, I have an active X-10 bridge, but none of this changed from when the system was 100%

 

Again, I am more interested in understanding the concepts at play here than fixing this specific issue. I really would like to also understand what I am looking at in the event viewer.

[bpwwer]

That's quite a write up!

 

I don't know if I have time to try and respond to everything but I'll hit at least a couple of things.

 

1. If I have a single Insteon device (controller) talking to a single Insteon device (responder) and no ISY in the system, the controller would send a direct message to the responder and look for a response, pending none it would retry up to five times. Is this a correct understanding?

 

No, this isn't correct. About the only type of device that can send a direct command to another device is a PLM (or PLC). When something like a SwitchLinc or your KeypadLinc sends a command, it's always sending a group broadcast message. In fact, the sending device doesn't even need to know what devices are configured to respond to it's broadcast.

 

2. If that is a correct understanding as I believe it is, if we add an additional Insteon device (responder) that we also want to have come on, now the controller switches to group broadcast mode with individual clean-ups and does not send a direct command except in the clean-up. Is that correct?

 

Group broadcasts are the primary way messages are sent.

 

Cleanup messages are only sent to the devices the controller thinks are suppose to get it's broadcasts. For example, when you press the ON button of your KeypadLinc, it sends a group message (). Any device that has a responder record in it's database that says respond to will then perform the requested command (assuming it got it). For each device that the KPL has in it's database, it will send a cleanup message.

 

Now for PLM/PLC devices, this is a little different. They don't send cleanup messages by default, the controlling software has to do it. I'm not sure if the ISY does this or not, based on your log, it looks like not.

 

4. How can this intermittent failure of devices to respond be so prevalent in the Insteon protocol? As I understand the protocol, after a group broadcast, which is not acknowledged, a device specific clean-up command is sent to each device in the scene (Group). So in my case I press the KPL on or off button, and that signal always makes it to the ISY/PLM.

 

The KPL has the ISY's PLM in it's database, so it always sends a cleanup message to the PLM.

 

Then the ISYs program triggers a scene via a group command. Should not this group command be followed up with individual device specific direct messages?

 

UDI will have to respond to clarify if they are doing cleanups. They may not be since it can slow things down considerably. If they do, they have complete control over how many re-tries and how many hops will be allowed.

 

5. How can there be a NAK? If the device gets the signal, how can it send a Not Acknowledged reply. Why not just execute the command and send an ACK? A touch off the topic at hand but it ties in with trying to understand the failures.

 

A NAK usually means that the device saw a message but the message checksum failed so it was somehow corrupt.

 

6. Trying to understand the event viewer for this problem brings up many of the aforementioned questions. Here is the level three for a failed execution:

 

2009/06/06 18:31:57 : [iNST-SRX ] 02 50 0A.DA.93 00.00.01 CB 13 00 LTOFFRR(00)

 

2009/06/06 18:31:57 : [standard-Group][0A.DA.93-->Group=1] Max Hops=3, Hops Left=2

 

2009/06/06 18:31:57 : [ A DA 93 1] DOF 0

This is the ISY seeing the KPL sending the group broadcast message for an OFF.

 

2009/06/06 18:31:57 : [iNST-SRX ] 02 50 0A.DA.93 0C.A6.33 41 13 01 LTOFFRR(01)

 

2009/06/06 18:31:57 : [standard-Cleanup][0A.DA.93-->ISY/PLM Group=1] Max Hops=1, Hops Left=0

 

2009/06/06 18:31:58 : [ A DA 93 1] ST 0

 

This is the ISY seeing the cleanup message from the KPL (I think).

 

2009/06/06 18:31:58 : [iNST-ACK ] 02 62 00.00.23 CF 13 00 06 LTOFFRR(00)

This is the ISY acknowledging the clean up message (again, I think)

 

2009/06/06 18:31:58 : [ E 7C 0 1] ST 0

 

2009/06/06 18:31:58 : [ A DA 93 3] ST 0

 

2009/06/06 18:31:58 : [ A DA 93 4] ST 0

 

2009/06/06 18:31:58 : [ A DA 93 5] ST 0

 

2009/06/06 18:31:58 : [ E 7C 21 1] ST 0

 

2009/06/06 18:31:58 : [ D 53 C7 1] ST 0

 

I'm guessing here, but I think this is just the ISY setting all the device's in your scene to 0 based on the program. UDI would have to describe the logic the ISY is using here.

 

7. In this case, why did the PLM not retry to send to E.7C.21? This is the entire event log for that failed execution. It sure does not look to me like the PLM is sending individual clean-up commands and awaited ACKs and attempting retries. Is this the way group commands work in the Insteon protocol? Is this identical to the execution I would see if the scene were just held in a KPL and executed from there?

 

The PLM does not send cleanup messages. The ISY could, but it looks like it doesn't. If this was all properly linked to a KPL, it would send the cleanup messages.

 

I don't know that I can help with your specific problem. 6 AP's in a 2400sqf house seems excessive to me. I have 1 AP and 2 old signalincs. The AP is piggybacked on the PLM (and a signalinc). I do have problems with that AP, it seems to stop working after a while and needs to be unplugged to reset it. Since it's there for the motion detectors and thermostat, I know it's not working when the ISY stops getting status from those devices.

 

Have you tried different AP's on the power strip? Maybe one of the new AP's is bad and corrupting messages?

[Michel Kohanim]

Hi Bob, thanks so very much for the answers.

 

Illusion, I think Bob has answered most of your questions. So, I am only going to clarify some:

 

1. We do send group commands but we use the direct command interface of the PLM (we simply change the multicast bit). In this way, the PLM does not do any retries but it still processes all the cleanups. That's why you see NAKs or device communication errors. You can even test this using the Scene Test menu Item in the Diagnostics

 

2. If you have recently added new devices to your network, and especially if they are SWL versions 35 and above, I would remove them to see if the comm problems go away

 

3. As Bob suggested, having too many APs would not help and in most cases would cause interference

 

With kind regards,

Michel

[Sub-Routine]

I can chip in a bit as well. All very good advice from Bob.

 

As Michel suggested if you have added new devices and then began seeing comm failures you will have to test each new device. If they are wired you should not have to un-wire them, pulling the set button should take them out of the equation. If plug-in simply unplug them. If your system goes back to 100% then add back one new device at a time to see if you can point the failure to a specific device.

 

Going back to ground zero and testing should allow you to isolate a problem device. I would first suspect any KPLs as they are the most complicated devices and thus most prone to failure.

 

If a device does appear to be a problem then you can try a factory reset and then an ISY Restore.

 

A LampLinc or SwitchLinc Dimmer will send a NAK; first as Bob suggests, a malformed checksum, but also if there is no load on the device. A burned out bulb or a lamp switched off or unplugged will cause the device to send a NAK. When you see a NAK the device is responding to the request, there is not a communication failure.

 

Cleanups sent from the ISY are quick and will quit when any other Insteon command is seen. This is to prevent interference with normal Insteon operations. So if the ISY sends a command and someone presses a switch the ISY cleanup will abort to allow the local controller to process it's messages.

 

I would also suggest removing all of your SignaLincs and adding them back one at a time. Although the Event Viewer should show you if they are sending extraneous commands sometimes the level may be so low the PLM may never see the noise while it is interfering with local devices. Usually the LED on the SL will flicker when this occurs.

 

Rand

[Illusion]

Thanks all for the quick replies as always.

 

Bob, yea, 6 APs is a bit much, but they are spread over 10,000 square feet of property. The 2400 square feet includes my neighbor's house that is on my ISY. We are on the same transformer and I treat her house as an extension of mine. I definitely needed one more AP to pick up the RF from a Motion Detector on the far corner of the outside of my house, and I just decided to pick up a refurb two pack for cost efficiency. The other two are on opposing phases at my significant neighbor's house.

 

Hi Bob, thanks so very much for the answers.

 

Illusion, I think Bob has answered most of your questions. So, I am only going to clarify some:

 

1. We do send group commands but we use the direct command interface of the PLM (we simply change the multicast bit). In this way, the PLM does not do any retries but it still processes all the cleanups. That's why you see NAKs or device communication errors. You can even test this using the Scene Test menu Item in the Diagnostics

 

So looking at my log of this event, are the first 7 lines the dialog between my KPL and the PLM/ISY and the last 6 lines are the PLM/ISY trying to set the devices to the desired levels of the scene? You say that the PLM processes the cleanups, but do you mean cleanups from other devices? It does not appear that the PLM sent any cleanups for this event. Am I reading that correctly? By that same token, if the first 7 lines are the dialog between the KPL and the PLM, the last six lines are direct commands that are not looking for ACK and will not be retried and are not a Group Broadcast type. Am I understanding this correctly? Do they carry a Hop count?

 

Cleanups sent from the ISY are quick and will quit when any other Insteon command is seen. This is to prevent interference with normal Insteon operations. So if the ISY sends a command and someone presses a switch the ISY cleanup will abort to allow the local controller to process it's messages.

Where are the cleanups sent from the ISY in this event? No other traffic stopped this process as evident in the log. Each device listed in the log is a device that was being addressed specifically for the scene in question.

 

That's quite a write up!

 

I don't know if I have time to try and respond to everything but I'll hit at least a couple of things.

 

1. If I have a single Insteon device (controller) talking to a single Insteon device (responder) and no ISY in the system, the controller would send a direct message to the responder and look for a response, pending none it would retry up to five times. Is this a correct understanding?

 

No, this isn't correct. About the only type of device that can send a direct command to another device is a PLM (or PLC). When something like a SwitchLinc or your KeypadLinc sends a command, it's always sending a group broadcast message. In fact, the sending device doesn't even need to know what devices are configured to respond to it's broadcast.

 

Bob, I spent a good portion of yesterday and the day before reading up on this trying to understand it. I had read the Insteon Details White Paper and that is where I came to the belief about direct commands.

 

2. If that is a correct understanding as I believe it is, if we add an additional Insteon device (responder) that we also want to have come on, now the controller switches to group broadcast mode with individual clean-ups and does not send a direct command except in the clean-up. Is that correct?

 

Group broadcasts are the primary way messages are sent.

I believe you, but this is directly contrary to what I understood from said White Paper by SmartLabs. Thanks for taking the time to write up such a complete response!

[Illusion]

3. If that is correct as I believe it is, then even with a single Insteon device (controller) and a single Insteon device (responder) and the ISY in the system, all commands are going to be sent as group broadcasts with clean-ups as the ISY itself is a member of every scene in order to keep track of things, Is this correct? I do not think I understand this well as I just unplugged my PLM and triggered a scene from a controller and would expect to see the flashing error in transmission signal on the controller, as the PLM cannot respond, and did not.

 

So is the PLM/ISY a member of every group? So I add a SWL and link it to nothing. It should have the PLM/ISY in its link table right? And if I unplug the PLM the SWL should flash the error status LED when turned on because one device did not respond... the PLM right?

[Michel Kohanim]

Hi Illusion,

 

Yes, the PLM is the member of each and every scene that a device belongs to. I urge you to try the Scene Test.

 

Please NOTE: ISY does NOT do any cleanups/retries above and beyond what the PLM does automatically. Furthermore, we have disabled PLM cleanups since they interfere with almost everything else including group dim/brighten, activating devices/scenes in programs without adding a delay of 500m.s x the number of devices in a scene, AND any other INSTEON activity destined for the PLM stops the cleanup process anyway and causes unexplained behavior.

 

So, again, I urge you to use the scene test to isolate the communication issues. I am almost certain (99.9%) that even with cleanups and retries you will continue having the same exact issues. And, if you have any new SWLs version .35, I would suspect them as culprits.

 

With kind regards,

Michel

[Illusion]

Thanks for the quick reply, Michel. Yes I have used the scene test, with 100% positive results, never a failure. I am actually not focused greatly at the moment on fixing this issue. I have been a member of the X-10 world for several decades and I am confident that I will eventually find the culprit. Right now I am trying to become a little more educated on the communications to better understand what I am viewing in the event viewer. I think this will serve me greatly in the future troubleshooting I am sure to need. I do not have any SWL .35 but I do have several Icon Relays .35. I have had those for almost 7 months.

 

So we are not doing cleanups/retries with the PLM/ISY. Is there a hop count? Will other devices retransmit a command from the PLM/ISY? If the commands do not have a hop count, would not the system become less reliable as more devices are added instead of more reliable? In my event log what appears to be the commands from the ISY to the devices does not seem to include a max hop count.

 

Also, I find it interesting that on my controllers such as KPLs and Controlincs I get the error flashing LED of a missing linked device when I pull the PLM as I would expect if it is a member of every group. But then when I fire a scene connected to another button on the Controlinc that of course the PLM should be part of, the error light does not flash even though the PLM is disconnected. This is not the behavior I was expecting. I clearly still am not understanding the communications protocol as well as I thought I did.

[bpwwer]

Hi Illusion,

 

1. If I have a single Insteon device (controller) talking to a single Insteon device (responder) and no ISY in the system, the controller would send a direct message to the responder and look for a response, pending none it would retry up to five times. Is this a correct understanding?

 

No, this isn't correct. About the only type of device that can send a direct command to another device is a PLM (or PLC). When something like a SwitchLinc or your KeypadLinc sends a command, it's always sending a group broadcast message. In fact, the sending device doesn't even need to know what devices are configured to respond to it's broadcast.

 

Bob, I spent a good portion of yesterday and the day before reading up on this trying to understand it. I had read the Insteon Details White Paper and that is where I came to the belief about direct commands.

 

The white paper is describing the Insteon protocol, not necessarily the way the current devices implement that protocol. The protocol allows for a number of things that were left out of the devices, probably for cost savings. I think that white paper has done more to confuse people about Insteon than to educate them

 

Going by just the white paper, you'd think all devices do dual-mesh (power line and RF), but that's not true either. Only a couple of devices can do that.

 

I spent a lot time working on link management software for the PLC. So I had to develop a pretty good understanding of how the original devices worked. I'm more fuzzy on the newer devices. The way Smarthome was changing the devices is one of the reasons I stopped working on that software. The other is the ISY, Michel and Co. has done such a good job that I just don't need to develop my own software for link management.

[IndyMike]

Hello Illusion,

 

In reference to your questions -

 

So we are not doing cleanups/retries with the PLM/ISY. Is there a hop count? Will other devices retransmit a command from the PLM/ISY? If the commands do not have a hop count, would not the system become less reliable as more devices are added instead of more reliable? In my event log what appears to be the commands from the ISY to the devices does not seem to include a max hop count.

 

Also, I find it interesting that on my controllers such as KPLs and Controlincs I get the error flashing LED of a missing linked device when I pull the PLM as I would expect if it is a member of every group. But then when I fire a scene connected to another button on the Controlinc that of course the PLM should be part of, the error light does not flash even though the PLM is disconnected. This is not the behavior I was expecting. I clearly still am not understanding the communications protocol as well as I thought I did.

 

The PLM/ISY do use a hop count - from previous discussions with Michel this is set at a Max Hop of 3. For outgoing transmissions, the ISY event viewer does not "tag" the communication with the "MAX HOPS/HOPS Remaining" the way that it does for incoming transmissions.

 

From your previous post, the following transmission was a group broadcast message from the PLM to Group 23 (00.00.23). The 6th byte (CF) identifies the message as a group broadcast ("C") with a Max Hops/Hops left of 3 ("F"). See page 21 of the "Insteon the Details" paper.

 

2009/06/06 18:31:58 : [iNST-ACK ] 02 62 00.00.23 CF 13 00 06 LTOFFRR(00)

 

The lack of a flashing error indication on your controlinc (PLM disconnected) is not normal. It should be linked to the PLM and it should flash it's little heart out when it can't communicate. Try scanning the device link table and using the compare function of the ISY. It sounds as if the PLM or Controlinc has a missing link.

[Illusion]

IndyMike,

 

Thanks for taking the time to reply. I looked at page 21 of the "Insteon the Details" paper again but could not see how "CF" is a three hop count unless it a Hexadecimal thing which I do not know anything about. If I have to learn about Hex to have my lights turn on, I am out on this automation deal. While I want a deeper understanding of the communications issues, that might be going a little far for me, so for the purposes of this thread I will just assume you are 100% correct and the CF is a group broadcast with a 3 hop count max.

 

But this begs the question: If the message is sent with a three hop count, then each receiver of the message is going to repeat it until the hop count is reduced to 0 correct? How can 3 items on a power strip not all get the message? If device A get the group broadcast, as I understand it, in the next time slot it is going to repeat said message. As device B and C are right there, how can they not get this command? In my case it is random which device/s fail to respond.

 

In my event Log for this thread the last 6 lines address each device in the scene. As I am understanding from this thread all of these lines are not commands at all. The ISY is not sending these signals to the PLM. This is the ISY internally setting the status of the devices. Is this a correct understanding?

 

And now on to the failure of the flashing error indication on my ControLinc (PLM disconnected)

 

So it is very interesting indeed. Buttons 1,4,5 on said ControLinc are not linked to any devices or scenes in the ISY. They are just monitored for signals to execute simple programs to control X-10 devices. I originally had the channels in the ControLinc set up to just send the desired X-10 commands but then it was not a Insteon button. I remember having difficulties in relation to the ISY but I do not remember specifically what they were. After much hassle I just factory reset the ControLinc and use programs in the ISY. It is a short term solution as those X-10 devices are sure to be replaced with Insteon in the future. Operations have worked nearly flawlessly for the past year set up this way. Pressing one of these buttons on the ControLinc while the PLM is disconnected will indeed cause the ControLinc to flash its little heart out as I would expect.

 

Buttons 2 and 3 trigger scenes. Neither of these trigger the flashing error indication when executed while the PLM is unplugged.

 

Edited to include: Yes, I did do a links comparison and that all looks good with no records mismatch.

[IndyMike]

Illusion,

 

I apologize if I in any way implied that you learn Hex/binary code to be able to operate your automation system. Fortunately the ISY people have developed a sophisticated device that removes this as a requirement. It's something that old Anal farts like myself mess with to keep ourselves occupied.

 

Some 35 years ago I helped a young college girl though a programming class in college (Hex/Binary/Octal conversion). I must have ticked her off in a major way - a number of years later she married me to get even. She's now a Math professor at the local university (still can't do Hex/Binary conversions for beans). I've learned my lesson.

 

Thanks for taking the time to reply. I looked at page 21 of the "Insteon the Details" paper again but could not see how "CF" is a three hop count unless it a Hexadecimal thing which I do not know anything about. If I have to learn about Hex to have my lights turn on, I am out on this automation deal. While I want a deeper understanding of the communications issues, that might be going a little far for me, so for the purposes of this thread I will just assume you are 100% correct and the CF is a group broadcast with a 3 hop count max.

 

But this begs the question: If the message is sent with a three hop count, then each receiver of the message is going to repeat it until the hop count is reduced to 0 correct? How can 3 items on a power strip not all get the message? If device A get the group broadcast, as I understand it, in the next time slot it is going to repeat said message. As device B and C are right there, how can they not get this command? In my case it is random which device/s fail to respond.

 

Things get a bit complicated here. Per the which paper, neither the transmitter nor responder to a communication will repeat a transmission.

 

From the paper : "Also, a device that is the intended recipient of a

message will not retransmit the message, no matter what the Hops Left value is." and "Note that the Sender will not retransmit its own

message..

 

Pretty straight forward. The problem is, I've seen some transmitters and some receivers repeat messages. I wouldn't consider this a hard rule. Older units may in fact abide by this. In other words, if your units plugged into the strip abide by the white paper, they will not repeat the command as recipients.

 

Having written the above, I just read your post on the scene test results. If these same units pass the scene test I'm at a loss to explain how they can not activate properly during a scene command.

 

In my event Log for this thread the last 6 lines address each device in the scene. As I am understanding from this thread all of these lines are not commands at all. The ISY is not sending these signals to the PLM. This is the ISY internally setting the status of the devices. Is this a correct understanding?

 

That is my understanding as well. The ISY is simply reporting the scene status for the command it just sent.

 

And now on to the failure of the flashing error indication on my ControLinc (PLM disconnected)

 

So it is very interesting indeed. Buttons 1,4,5 on said ControLinc are not linked to any devices or scenes in the ISY. They are just monitored for signals to execute simple programs to control X-10 devices. I originally had the channels in the ControLinc set up to just send the desired X-10 commands but then it was not a Insteon button. I remember having difficulties in relation to the ISY but I do not remember specifically what they were. After much hassle I just factory reset the ControLinc and use programs in the ISY. It is a short term solution as those X-10 devices are sure to be replaced with Insteon in the future. Operations have worked nearly flawlessly for the past year set up this way. Pressing one of these buttons on the ControLinc while the PLM is disconnected will indeed cause the ControLinc to flash its little heart out as I would expect.

 

Buttons 2 and 3 trigger scenes. Neither of these trigger the flashing error indication when executed while the PLM is unplugged.

 

Edited to include: Yes, I did do a links comparison and that all looks good with no records mismatch.

 

Once again I'm at a loss. I would have expected the link table compare to show missing PLM links for buttons 2 and 3. It sounds as if the Controlinc is not issuing a group cleanup to the PLM.

 

All I can say is that I have a very similar setup on my controlinc (mixed scenes and program triggers) and every button registers errors when the PLM is off line.

 

Sorry, I think I need to drop back and let Michel and the ISY team handle this...

 

IM

[Illusion]

IndyMike, thanks again for jumping in here. This has been tremendously helpful with my understanding. It did not occur to me that a device would not repeat a group command because it is an intended target of that group.. That certainly helps me understand how this could be happening at all. Of course, it is right there in the white paper, I just had not processed that piece of info.

 

Your funny answer to my Hex question is good stuff. I did not even know I was right, I was just taking a shot with the Hex statement. That is how little I know about it.

 

Yea, the scene test working 100% of the time is kinda a bummer for troubleshooting. While I have done link comparisons for all devices in question I have not gone the route of reset and restore as I wanted to preserve the situation to gain this deeper understanding of the use of diagnostics. I am not of the belief that that is going to help anyway based on symptoms. But this thread has certainly been helpful to my general understanding.

 

As to the ControLinc, yep, I am lost as well. There is no way it is a coincidence that the buttons with scenes do not trigger error flashing but the others all do. There is no operational problem here for me as everything works the way I want it to, but it does make me question my understanding of what is going on a little.

[Illusion]

Interesting data points after a few hours of additional testing:

 

One of the LampLincs is not a responder to the on scene, so in theory it should act as a repeater of any commands it hears, but I have just as many problems with the on scene as the off scene.

 

I unplugged all 6 APs, the X-10 active coupler/amplifier, turned off all 220v breakers in both my house and the next house in line to the transformer (I am two houses away from said transformer), verified that the ISY/PLM was on a different leg (Phase) than the troublesome powerstrip and commenced testing. The Scene test still resulted in 100% success each time I tried it. I did a Query on the entire system and only 1 device had comm issues and that was a switch at my neighbors house. When the scene was called by the KPL plugged into that same power strip I still saw about a 20% failure rate even as the scene test was returning a 100% success rate. Remember that the scenes are called from the ISY in my case no matter what as the KPL does not talk to these scenes directly. The KPL shoots out the call and the ISY either runs the on scene or a different off scene.

 

I clearly have great phase coupling and a low noise environment as proven by my query testing with no phase coupling intentionally supplied.

 

I think I am getting ready to factory reset these devices unless anyone has any other test or ideas that I could try to better understand what is going on here.

[Illusion]

This is not related to the previous issues, which I still have not successfully resolved, but is related to understanding diagnostics, so I figured this would be a good thread to plug it in.

 

I have a program that monitors a motion detector, and when tripped sounds a chime (X-10 I9) and turns on the front porch light if it is after sunset and not already on.

 

Last night at 9.58pm the chime sounded, but the light did not come on. I went the ISY to see what was up, and it showed the porch light was off, even though the program was running properly.

 

I looked at the log:

 

Bathroom KeypadLinc Status 0% Sat 07/11/2009 09:57:40 PM System Log

Bathroom Track Lights Status 0% Sat 07/11/2009 09:57:40 PM System Log

Bathroom Vanity Status 0% Sat 07/11/2009 09:57:40 PM System Log

Bathroom Shower Light Status 0% Sat 07/11/2009 09:57:40 PM System Log

Laura's Flood - Back Off 0 Sat 07/11/2009 09:57:53 PM Program Log

Laura's Flood - Back Status 0% Sat 07/11/2009 09:57:53 PM System Log

X10 I9 Sat 07/11/2009 09:58:01 PM Program Log

X10 I9 On (3) Sat 07/11/2009 09:58:01 PM Program Log

Front Porch On 255 Sat 07/11/2009 09:58:02 PM Program Log

Laura's Flood - Back Status 0% Sat 07/11/2009 09:58:03 PM Program Log

Laura's Flood - Back Status 0% Sat 07/11/2009 09:58:03 PM Program Log

Office Keypadlinc.A Status 100% Sat 07/11/2009 09:58:25 PM System Log

 

Where is the System Log line that says Front Porch Status 100%? I would have expected to see a group of lines like this from earlier in the evening:

 

X10 I9 Sat 07/11/2009 08:35:31 PM Program Log

X10 I9 On (3) Sat 07/11/2009 08:35:31 PM Program Log

Front Porch On 255 Sat 07/11/2009 08:35:31 PM Program Log

Front Porch Status 100% Sat 07/11/2009 08:35:32 PM System Log

 

What happened here? How do I interpret what I am looking at? Why did the light not come on? The ISY knows the light did not come on, but it looks like it knows it should have turned the light on. What does Program Log and System Log mean?

[Michel Kohanim]

Hi Illusion,

 

I think the best thing to do do resolve the other problem is to schedule a call with our tech support so that we can resolve it more expeditiously.

 

As far as the log, it seems that ISY is showing:

Front Porch On 255 Sat 07/11/2009 09:58:02 PM Program Log

 

If this light is part of a scene, I strongly recommend using the Scene Test (under Tools | Diagnostics) at around the same time to see if this device responds properly. If it doesn't, then we have to figure out the cause of the noise/signal issue.

 

With kind regards,

Michel

[Illusion]

After a lengthy trouble-shooting session with Michel, I have many more long term test to perform. But as I have stated several times, the purpose of this post was not so much to try to solve my problems, but to gain a deeper understanding of how things work and how to better understand diagnostics.

 

In our conversation I was able to understand one very very important key piece of info that I want to pass on here. If you look at my log entries from my previous post you will see that the status portion of the Front Porch (System Log) never showed up in the failed execution. This means that the ISY knows that the device did not turn on as it did not receive a response from the device! This only occurs on direct commands, not scene commands. This will help with troubleshooting immensely.

[Illusion]

Does the ISY use i2 in any way to communicate scene (group) commands to a know i2 device?

 

Is i2 exclusively used for programing, and in no was has anything to do with triggering devices, recognizing device triggers, or scene triggering?

[Michel Kohanim]

Hi Illusion,

 

I2 is used in:

1. Programming if and only if the mode is set to "Device Reported" under Advanced Options

2. There are some devices (motion sensor is one) that work ONLY in i2 mode and, therefore, i2 is used exclusively for these devices

3. And, there are certain commands that only work with i2 messages. In those cases and if the device supports i2, then i2 is used

 

With kind regards,

Michel

 

Does the ISY use i2 in any way to communicate scene (group) commands to a know i2 device?

 

Is i2 exclusively used for programing, and in no was has anything to do with triggering devices, recognizing device triggers, or scene triggering?

[Illusion]

 

The lack of a flashing error indication on your controlinc (PLM disconnected) is not normal. It should be linked to the PLM and it should flash it's little heart out when it can't communicate. Try scanning the device link table and using the compare function of the ISY. It sounds as if the PLM or Controlinc has a missing link.

 

Well here it is, coming up on a year later, and I have more very confusing data to add.

 

I have this Version 1.4 Controlinc. I have now added more Insteon devices to be controlled by it. Its reliability of controlling devices has gotten terrible. After much pain and testing I have discovered quite the anomaly:

 

I built a scene with an appliancelinc and Contolinc button 1 together in the ISY. Things work fine. If I remove the APL from the system though (via unplugging it), I do not get the flashing error light on the controlinc. If I build the link outside of the ISY and remove the APL, the controlinc will flash its little heart out trying to communicate with that missing module.

 

This explains much of the confusion earlier in this post. It also explains much of my poor response to commands sent from this Controlinc to my other devices.

 

I have tried to restore using i1 only, I have removed the controlinc and re-added it, and I have factory reset the controlinc at least 10 times. Any Ideas? I am on 2.7.13 beta at this time.

[IndyMike]

Hello Illusion,

 

I have to hand it too you, you do not give up easily.

 

Since I appear to be the one that provided the information on the Controlinc cleanup commands (flashing when an linked device doesn't respond) I decided to reaffirm what I knew to be true.

 

Since you were using a ApplianceLinc, I thought there might be a difference in how the ISY linked this device. ApplianceLincs and LL's can generate errors when their attached load is off.

 

Test 1 - KPL Linked to a LL

1) Manual Linking - Flashes when LL off-line (disconnected)

2) ISY Linking - Flashes when LL off-line.

 

So far so good - Confirms what I thought I knew.

 

I remembered that I had my controlinc button #3 linked to my whole house fan (ISY scene). The breaker on that fan (Icon Switch controlled) is off for the winter months.

 

I decided that, given your persistence, I could take a break from March Madness and plod up to the second floor to check things out.

 

Test 2 - Controlinc V1.0/Rev 1.2 Linked to Icon SW through ISY.

1) NO FLASHING LED even though the ICON is de-powered.

Crap!

 

Test 3 - Controlinc Linked to KPL dimmer through ISY

1) NO FLASHING LED with KPL air gapped.

Sh!$

 

It appears that I owe you an apology. I made a statement based on the Insteon protocol rather than getting off my FAT A$$ and testing the hardware.

[Illusion]

IM,

 

Thanks,

 

I am going to manually link my ControLinc to the responders. I need those cleanup commands. We will see what happens.

[Michel Kohanim]

Hi to both,

 

We'll have to go through the code and see what could be causing this. I cannot fathom why there would be a difference UNLESS there's no slave link in the CL for the unplugged device. Can you confirm that there's indeed a slave link for the device in the CL?

 

With kind regards,

Michel

[IndyMike]

Hi Michel,

 

I ran a compare on both my Controlinc and my KPL. No errors detected by the ISY. Manual inspection shows the Controlinc (button 1) with links to the KPL and the KPL with companion links to the Controlinc.

 

If you'd like, I can email the XML files.

 

IM

[Michel Kohanim]

Hi IM,

 

Thanks so very much. So, it's indeed odd that the CL does not blink when the responder is offline and when configured by ISY. I guess this is would be another question for SH.

 

Thanks again and with kind regards,

Michel

Hi Michel,

 

I ran a compare on both my Controlinc and my KPL. No errors detected by the ISY. Manual inspection shows the Controlinc (button 1) with links to the KPL and the KPL with companion links to the Controlinc.

 

If you'd like, I can email the XML files.

 

IM