troublesome dimmer

[ergodic]

I have a chronic problem with one dimmer with which the ISY occasionally loses communication. It is a V.35 SL 2476D with h/w address 0F.2F.38.

 

When I login I see a "unable to communicate..." dialog. When try to query it from the ISY, it tries for a while and then gives up with a dialog again that it can't communicate. I then do a right-click... restore device, and all is fine with it -- for a a few days anyway. Then the whole thing happens again.

 

So I looked at the diag. trace of a query both before and after in an attempt to figure out what is different after it is restored, thinking I could work the problem backward. But I can't really puzzle it out. I've posted the trace below (sans the endless restore-device trace). What I can't really understand is before the restore the hops-left count on the initial ACK is 2, and after the restore it is 1. The "duplicate ignored" I don't get at all.

 

Do you have any insight into what could be happening? Is it possible this is an i1/i2 issue? (The INST-ERX in the after-trace makes me think it is possible, and this might also explain the smaller hops-left count.)

 

This is a fairly new remodel - all the dimmers are V.35, the KPLs are V.2D, and the PLM is a V72. There are an assortment of new APs sprinkled around including one on the PLM. (A phase coupler/AP pair is not yet in pending the install of the subpanel.) This dimmer is for exterior lighting - all incandescent and I believe it is the only thing on that particular circuit.

 

(query before restore)...

 

2009/05/09 03:21:30 : [iNST-ACK ] 02 62 0F.2F.38 0F 19 00 06 LTSREQ (LIGHT)

2009/05/09 03:21:30 : [iNST-SRX ] 02 50 0F 2F 38 0E DC 6D 2B

2009/05/09 03:21:30 : [standard-Direct Ack][0F.2F.38-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

2009/05/09 03:21:30 : [ F 2F 38 1] ST 255

2009/05/09 03:21:37 : [sET-BTN ] 02 54 02

2009/05/09 03:21:38 : [iNST-SRX ] 02 50 0F 2F 38 0E DC 6D 27

2009/05/09 03:21:38 : [standard-Direct Ack][0F.2F.38-->ISY/PLM Group=0] Max Hops=3, Hops Left=1

2009/05/09 03:21:38 : Duplicate: ignored

2009/05/09 03:21:38 : [iNST-SRX ] 02 50 0F 2F 38 0E DC 6D 27 : Process Message: failed

2009/05/09 03:21:38 : [standard-Direct Ack][0F.2F.38-->ISY/PLM Group=0] Max Hops=3, Hops Left=1

 

(restore device here - trace omitted)...

 

2009/05/09 03:22:41 : [iNST-ACK ] 02 62 0F.2F.38 0F 19 00 06 LTSREQ (LIGHT)

2009/05/09 03:22:41 : [iNST-SRX ] 02 50 0F.2F.38 0E.DC.6D 27 0D 54 (54)

2009/05/09 03:22:41 : [standard-Direct Ack][0F.2F.38-->ISY/PLM Group=0] Max Hops=3, Hops Left=1

2009/05/09 03:22:41 : [ F 2F 38 1] ST 84

2009/05/09 03:22:42 : [iNST-ACK ] 02 62 0F.2F.38 1F 2E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 06 (00)

2009/05/09 03:22:42 : [iNST-SRX ] 02 50 0F.2F.38 0E.DC.6D 27 2E 01 (01)

2009/05/09 03:22:42 : [standard-Direct Ack][0F.2F.38-->ISY/PLM Group=0] Max Hops=3, Hops Left=1

2009/05/09 03:22:42 : [iNST-ERX ] 02 51 0F 2F 38 0E DC 6D 11 2E 00 01 01 00 00 20 00 1D FE 00 00 00 2B D5 00

2009/05/09 03:22:42 : [Extended-Direct][0F.2F.38-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

2009/05/09 03:22:42 : [ F 2F 38 1] OL 255

2009/05/09 03:22:42 : [ F 2F 38 1] RR 29

[Sub-Routine]

I have a chronic problem with one dimmer with which the ISY occasionally loses communication. It is a V.35 SL 2476D with h/w address 0F.2F.38.

 

When I login I see a "unable to communicate..." dialog. When try to query it from the ISY, it tries for a while and then gives up with a dialog again that it can't communicate. I then do a right-click... restore device, and all is fine with it -- for a a few days anyway. Then the whole thing happens again.

 

So I looked at the diag. trace of a query both before and after in an attempt to figure out what is different after it is restored, thinking I could work the problem backward. But I can't really puzzle it out. I've posted the trace below (sans the endless restore-device trace). What I can't really understand is before the restore the hops-left count on the initial ACK is 2, and after the restore it is 1. The "duplicate ignored" I don't get at all.

 

Duplicate messages are generated when a message is not repeated quickly enough. It is a fail-safe in Insteon controllers. As long as you have any hops left proves the device is able to communicate.

 

Do you have any insight into what could be happening? Is it possible this is an i1/i2 issue? (The INST-ERX in the after-trace makes me think it is possible, and this might also explain the smaller hops-left count.)

 

If the restore functions correctly then it is not an i1/i2 issue. A Query is only i1, Restore may use i2.

 

This is a fairly new remodel - all the dimmers are V.35, the KPLs are V.2D, and the PLM is a V72. There are an assortment of new APs sprinkled around including one on the PLM. (A phase coupler/AP pair is not yet in pending the install of the subpanel.) This dimmer is for exterior lighting - all incandescent and I believe it is the only thing on that particular circuit.

 

If it is the only Insteon device on that circuit then that would explain the duplicate messages. Does the device respond correctly to other commands and is only faulty with the Query? If the device does not always function correctly I would suggest plugging another Insteon device (LampLinc, AL, AP) into the circuit and see if that helps. If not then I would have to suspect that the switch itself is bad.

 

I have heard many good reports on the 2406H coupler, installing that on your main panel would not be a bad idea.

 

Rand

[ergodic]

Yeah, I'm not going to worry much about it until the panel goes in. I'll post back if it is still an issue after that.

 

I was more curious as to what could be happening. Nothing I understand really could explain this behavior. (Of course odd behaviors with Insteon are the norm.) AFAIK the device has no problems other than this - it is in a 3-way with other controllers and seems to respond fine.

 

Basically I was wondering why is there an ERX response in the post-restore query but not in the pre-restore one? The two sequences look significantly different. If I put the ISY into i1-only mode just to test will there be a problem? I've never tried it because of the warning that pops up when I do that.[/code]

[Michel Kohanim]

ergodic,

 

Although I've been told not to talk in terms of i1/i2, but I have no choice just to shed some light on your question:

i1 Mode- everything is done in i1 small packet syntax

Device Reported - uses whatever the device reports as the mode of communications

Automatic:

-- Uses i1 mode for database management for all devices except motion sensors and triggerlinc

-- if the device has reported i2, and if ISY was successful in communicating with the device in i2 (query), then for some queries and command sequences ISY uses i2

 

So, your device has reported i2. Your mode is automatic. ISY is using i2 to query your device (which takes much less time than i1).

 

With kind regards,

Michel

 

Yeah, I'm not going to worry much about it until the panel goes in. I'll post back if it is still an issue after that.

 

I was more curious as to what could be happening. Nothing I understand really could explain this behavior. (Of course odd behaviors with Insteon are the norm.) AFAIK the device has no problems other than this - it is in a 3-way with other controllers and seems to respond fine.

 

Basically I was wondering why is there an ERX response in the post-restore query but not in the pre-restore one? The two sequences look significantly different. If I put the ISY into i1-only mode just to test will there be a problem? I've never tried it because of the warning that pops up when I do that.[/code]