ApplianceLink Comm Error in ISY GUI

[vbPhil]

I have an ApplicanceLink in what must be a partial dead zone because it happens with a couple that I've tried. I'm getting the "Failed Communicating With" dialog in the Administrative Console when I try to turn the AplianceLinc On or Off. A query command always works without displaying the error message. Also, the device does turn on or off even though I get the error. If after clearing the error dialog I do a query the correct state of the device is shown.

 

When I exercise the device using Homeseer I don't see any error messages and the device status is correctly updated in Homeseer.

 

Below are the system components I'm using. I'm also using other ApplicanceLink devices throughout the house that don't get these error messages, I'm wondering if the ISY is too quick to report the error. The error dialog does pop up right away so it doesn't seem like it's doing any retries. I've tried the event viewer but I'm not sure what it's showing me, see below.

 

I am using a couple Access Points that link the 2 phases and I have a couple Dual Band swithlincs in the area so I don't understand why this spot would be weak in the first place.

 

Any ideas, especially about the ISY being too quick to complain?

 

Thanks, -phil

 

 

ApplianceLink 2456S3 v.28

Homeseer 2.5.0.20

ISY 99i 3.1.2

PLM, Smarthome PowerLinc Serial Dual Band, 2413S v1.0 (v92)

ISY Insteon Homeseer Plugin HSPI_ISYInsteon.dll

 

 

14.35.2D is the ApplianceLink

13.20.35 is the ISY PLM

 

 

Fri 05/27/2011 08:34:57 AM : [iNST-SRX ] 02 50 14.35.2D 00.00.01 C7 13 01 LTOFFRR(01)

Fri 05/27/2011 08:34:57 AM : [ 14 35 2D 1] DOF 1

Fri 05/27/2011 08:34:57 AM : [ 14 35 2D 1] ST 0

Fri 05/27/2011 08:34:57 AM : [iNST-SRX ] 02 50 14.35.2D 00.00.01 C7 13 01 LTOFFRR(01)

Fri 05/27/2011 08:34:57 AM : [iNST-SRX ] 02 50 14.35.2D 00.00.01 C7 13 01 LTOFFRR(01): Process Message: failed

Fri 05/27/2011 08:34:57 AM : [iNST-SRX ] 02 50 14.35.2D 13.20.35 41 13 01 LTOFFRR(01)

Fri 05/27/2011 08:35:04 AM : [iNST-SRX ] 02 50 14.35.2D 00.00.01 C3 11 01 LTONRR (01)

Fri 05/27/2011 08:35:04 AM : [ 14 35 2D 1] DON 1

Fri 05/27/2011 08:35:04 AM : [ 14 35 2D 1] ST 255

Fri 05/27/2011 08:35:04 AM : [iNST-SRX ] 02 50 14.35.2D 00.00.01 C7 11 01 LTONRR (01)

Fri 05/27/2011 08:35:04 AM : [iNST-SRX ] 02 50 14.35.2D 00.00.01 C7 11 01 LTONRR (01): Process Message: failed

Fri 05/27/2011 08:35:04 AM : [iNST-SRX ] 02 50 14.35.2D 13.20.35 41 11 01 LTONRR (01)

[LeeG]

From the messages in the Event Viewer it looks more like a LampLinc load being turned On/Off manually rather than an ApplianceLinc.

 

EDIT: there are no commands in the event viewer trace showing any outbound commands from the ISY PLM to the device.

[vbPhil]

Sorry, wrong file.

I created a new one.

From a cleared event viewer I querried the ApplicanceLinc, 04.D8.D0. It showed up as On so I sent an Off and then got the error dialog. I cleared the dialog and then did another query.

 

 

 

Sat 05/28/2011 02:18:27 PM : [iNST-ACK ] 02 62 04.D8.D0 0F 19 00 06 LTSREQ (LIGHT)

Sat 05/28/2011 02:18:27 PM : [iNST-SRX ] 02 50 04.D8.D0 13.20.35 2B 00 FF (FF)

Sat 05/28/2011 02:18:27 PM : [standard-Direct Ack][04.D8.D0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Sat 05/28/2011 02:18:27 PM : [ 4 D8 D0 1] ST 255

Sat 05/28/2011 02:18:27 PM : [ 4 D8 D0 1] OL 255

Sat 05/28/2011 02:18:27 PM : [ 4 D8 D0 1] RR 31

Sat 05/28/2011 02:18:36 PM : [iNST-ACK ] 02 62 04.D8.D0 0F 13 00 06 LTOFFRR(00)

Sat 05/28/2011 02:18:36 PM : [iNST-SRX ] 02 50 04.D8.D0 13.20.35 AB 13 FE LTOFFRR(FE)

Sat 05/28/2011 02:18:36 PM : [standard-Direct Nack][04.D8.D0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Sat 05/28/2011 02:18:45 PM : [iNST-ACK ] 02 62 04.D8.D0 0F 19 00 06 LTSREQ (LIGHT)

Sat 05/28/2011 02:18:46 PM : [iNST-SRX ] 02 50 04.D8.D0 13.20.35 2B 00 00 (00)

Sat 05/28/2011 02:18:46 PM : [standard-Direct Ack][04.D8.D0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Sat 05/28/2011 02:18:46 PM : [ 4 D8 D0 1] ST 0

Sat 05/28/2011 02:18:46 PM : [ 4 D8 D0 1] OL 255

Sat 05/28/2011 02:18:46 PM : [ 4 D8 D0 1] RR 31

[LeeG]

Thanks. That is a better looking trace.

 

The device sent a NAK (negative acknowledgment) in response to the Off command. The Ax in the Red highlighted area is the NAK flag and the ISY annotation after the NAK message also indicates NAck. This can happen when there is no load attached to an ApplianceLinc or the load is causing a problem or the ApplianceLinc is defective.

 

This is not a powerline communication problem. The device received the command, found something wrong at the device and NAKed the command.

 

 

Sat 05/28/2011 02:18:36 PM : [iNST-SRX ] 02 50 04.D8.D0 13.20.35 AB 13 FE LTOFFRR(FE)

Sat 05/28/2011 02:18:36 PM : [Standard-Direct Nack][04.D8.D0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

[vbPhil]

LeeG you're pretty good. Can you write a manual for us on how to read the event viewer? I wasn't giving you a test but you scored an A. I have no load plugged into the ApplicanLinc. I will eventually have a water fountain on it but it isn't ready yet. I did a test with a load plugged into it and I didn't get the error message. I guess I'm thinking now that the ISY shouldn't have reported a communication error since it was communicating OK. That is confusing.

 

 

Sat 05/28/2011 03:52:01 PM : [iNST-ACK ] 02 62 04.D8.D0 0F 19 00 06 LTSREQ (LIGHT)

Sat 05/28/2011 03:52:01 PM : [iNST-SRX ] 02 50 04.D8.D0 13.20.35 2B 00 00 (00)

Sat 05/28/2011 03:52:01 PM : [standard-Direct Ack][04.D8.D0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Sat 05/28/2011 03:52:01 PM : [ 4 D8 D0 1] ST 0

Sat 05/28/2011 03:52:01 PM : [ 4 D8 D0 1] OL 255

Sat 05/28/2011 03:52:01 PM : [ 4 D8 D0 1] RR 31

Sat 05/28/2011 03:52:11 PM : [iNST-ACK ] 02 62 04.D8.D0 0F 11 FF 06 LTONRR (FF)

Sat 05/28/2011 03:52:11 PM : [iNST-SRX ] 02 50 04.D8.D0 13.20.35 2B 11 FF LTONRR (FF)

Sat 05/28/2011 03:52:11 PM : [standard-Direct Ack][04.D8.D0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Sat 05/28/2011 03:52:11 PM : [ 4 D8 D0 1] ST 255

Sat 05/28/2011 03:52:18 PM : [iNST-ACK ] 02 62 04.D8.D0 0F 13 00 06 LTOFFRR(00)

Sat 05/28/2011 03:52:18 PM : [iNST-SRX ] 02 50 04.D8.D0 13.20.35 2B 13 00 LTOFFRR(00)

Sat 05/28/2011 03:52:18 PM : [standard-Direct Ack][04.D8.D0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Sat 05/28/2011 03:52:18 PM : [ 4 D8 D0 1] ST 0

[LeeG]

Thanks. Glad the answer was found. If I was a writer I would. We had an entire department dedicated to producing our external publications. Not all for sure but most developers (we will never admit this) make poor technical writers. That is why we have technical writers.

 

There is an insteondetails.pdf document on the Insteon.net web site. Page 18 has a chart of the Flag byte field. This is the best explanation I’ve seen of the various bit patterns that can be returned in the Flag byte.

 

The ISY needs to make that NAK visible as the device reported what amounts to a failure (not necessarily an ApplianceLinc failure). If everything had been connected it could indicate a relay failure in the ApplianceLinc or some issue with the load being controlled. In this case the situation is benign and caused by not having a load attached during initial setup. However, it could be indicating an actual device failure or appliance connection issue which should not be ignored.

 

Unfortunately a NAK could have been an actual communications problem. The timing of Insteon messages would have been different but that is a difficult area for the ISY to analyze on the fly. Perhaps the message could say a NAK was received but without analyzing the event trace that piece of information by itself would not be definitive. This is what makes Insteon so much fun to play with!

[ELA]

 

The ISY needs to make that NAK visible as the device reported what amounts to a failure (not necessarily an ApplianceLinc failure). If everything had been connected it could indicate a relay failure in the ApplianceLinc or some issue with the load being controlled. In this case the situation is benign and caused by not having a load attached during initial setup. However, it could be indicating an actual device failure or appliance connection issue which should not be ignored.

 

Unfortunately a NAK could have been an actual communications problem. The timing of Insteon messages would have been different but that is a difficult area for the ISY to analyze on the fly. Perhaps the message could say a NAK was received but without analyzing the event trace that piece of information by itself would not be definitive. This is what makes Insteon so much fun to play with!

 

Thanks for the great explanation LeeG,

 

I find it Unfortunate that Insteon uses a "NAK" to indicate either a communications protocol failure OR a command failure at the hardware level. If I understand your comments correctly?

This surprised me.

 

I am more familiar with the use of a NAK meaning only a communications protocol level failure. Another message type reports the other control and/or hardware errors or failures.

 

I took a quick look at the Details doc as well as the 2412S developers guide and saw only what you have described.

 

Does Insteon not support separate error message types? In the future perhaps with extended messages?

If not has there been an explanation as to why not? .

[LeeG]

I am not aware of message types as far as the NAK indication in an inbound message. A PLM can NAK a serial command but that is indicated in a different manor. The NAK cmd2 field contains a 0xFE which may indicate a load issue for an ApplianceLinc. That level of device specific detail is not available to the general public. Folks with a developer subscription may have access but from what I read on other public forums the subscription information does not have all the answers.

 

Usually a powerline problem can be discerned by the timing of the messages as retries slow the response. Also hop counts may be useful. With other Insteon traffic that could be flowing at the time the event trace has to be viewed and analyzed in the context of all that is happening. This NAK was quick and consistent making it a little easier to evaluate.

 

It would be helpful if SmartLabs adopted an open approach to technical details. That has always been considered proprietary and confidential information. Doubt that will change anytime soon.

[ELA]

Once again great information and thank you LeeG,

 

I reviewed the Developers guide again and see the cmd2 byte you mention. This then referenced the "NAK error codes" in the details doc.

 

I did not see a list of the NAK errors codes there?

 

So the more readily available, and older, 2412 developers guide appears not to contain some more recent and relevant info that you have to pay more for ?

I think I understand now.

 

I agree that it would be nice if they would share more

[ahwman]

I'm having the exact same issue with my ApplianceLinc. I can turn it on/off from my ISY without fail and if I query the device, it reports the correct state, however I'm getting an error message suggesting a communication problem along with an exclamation point next to the device... I'm running the latest ISY firmware - 3.3.10.

[LeeG]

ahwman

 

The problem the original OP had was there was no load connected to the ApplianceLinc.

 

Do you have a load plugged into the ApplianceLinc and if so is the load turned On?

 

Run Tools | Diagnostics | Event Viewer at LEVEL 3. Turn the ApplianceLinc On and Off a few times. Post the event trace.