Troublesome: APL/Circuit/I2CS Extended messages

[ELA]

Upgraded to 4.0.5 in the ISY.

As I said I was hesitant because for some unknown reason I always seem to have difficulties upgrading. I have done a few painless upgrades but this one was painful once again. Ended up having to upgrade Java and then there may have been an unrelated issue with the computer, not sure, but finally got er done.

 

When I select the new i2CS APL I get the advanced option with PLM communications ( says device does not support).

 

When I tried a get engine command ( standard length) on the APL it gets a fast response and reports as "02" or i2CS. Then the ISY issues the "2F" request ( extended length) "calibrating engine" and this takes a few retries but ultimately completes.

 

I think for this module i2CS may stand for i2 Corrupt Stuff

 

Just joking...

 

I will search out and find what the issue on this circuit may be eventually. Only thing I can say for sure is that standard length commands work much better than the extended on this circuit and this device.

[LeeG]

The PLM Communication retries sets a value in the Controller link On Level field. With the ApplianceLinc being a Responder Only device it will not have Controller link records, thus the not supported message.

[ELA]

I have now tested the heck out of this APL and confirmed it is indeed a craplinc.

Took a hard long look at resonance or other possible issues with the circuit and found only the APL to blame. The circuit is near the service so any device placed there does "see" a fairly large load but nothing all my other devices do not seem to handle.

 

This is a very disturbing trend with these APLs.

 

The final straw was when this APL then began failing in an isolated network with only a test PLM and one other device.

It clearly does not like having to work very hard. Use of extended commands does work the transmitter harder and thus the flaw shows up faster when using extended commands.

 

It is so disturbing seeing 3,4,5 return commands due to this new i2CS implementation ( when a unit is marginally communicating , or just a craplinc?). My guess is that they thought it could be faster for the responder device to retry rather than for the controller to have to re-request the information multiple times

 

After 3 flawed units I am going to give up on APLs. A Lamplinc and an older outdoor APL ran in the very same position just fine so I may try one of the new dual band outdoor units to replace this APL.

 

I updated an earlier post on the strange behavior I saw using a 131Khz burst to test phase relationships.

The responses I saw had to have been due to my implementation/configuration error. I have been unable to reproduce that response in the final code.

Use of the 131Khz burst is interesting to view the phase relationships at any one location.

 

The first trace is from the problematic APL location with the APL removed and a PLM driving the line:

 

This second is the same setup but a 50ft extension cord with a 0.1uf surge strip at its end is plugged in nearby.

 

 

Quite the change in phase relationship.

[Brian H]

"Craplinc"?

This is not the first time that reference was made about Insteon products.

It was either Sloop or Digger that coined that name during the early Insteon days.

[TJF1960]

nor will it be the last I'm sure

[Xathros]

ELA-

 

I have one of the outdoor I2CS appliancelincs at the far end of a 300+' run out to my barn along with 2 Togglinc relay switches. The OAPL is rock solid 100% reliable while one togglelink is about 90% reliable and the other about 20% reliable. Comm tests to the OAPL show consistent 3/2. I don't think these are related in anyway to the indoor APL's. One of these days I'll get to swapping out the older TLR and move it up to the garage where it will likely work just fine.

 

-Xathros

[ELA]

Yes I was hesitant to plagiarize that term it just seemed so appropriate.

 

Here is a log of a very short test of this APL in an isolated network with a PLM sending and a Switchlinc as a third ( repeater) device.

In this test it did not run long enough for any outright failures. Success rate was 100%.

( no retries were with respect to the PLM sender)

However, note how out of only 30 messages sent; 30 good ones were received; and 31 spares just decided to come along for the ride!

[Brian H]

I had a seven month old 2456S3, hardware 4.9, date code 1246 fail dead last week.

Wounder if it was a common problem. Gold Line Support said power supply problem and gave me a prepaid FedEx return label and FedEx picked it up at my house.

 

Expect a replacement in a few weeks.

Will post what hardware and firmware are in it. When it arrives.

[ELA]

Sorry for your troubles Brian,

Did Gold Line say there is a "known power supply problem in all those APL revs" or that they suspect the power supply in your unit only?

 

You said it was dead?

Any chance you did some signal strength tests on it before you sent it back, or was it just plain dead?

 

I have no doubt the APLs have issues. Not sure if it is the power supply or something in the transmitter/receiver circuit but all of mine lost signal strength/quality over time.

 

Best of luck with your new one. Is the circuit where your APL is located in an area that you might expect to be a very good communications scenario or possibly a little marginal?

I will be curious to hear how well the new unit links using extended commands, if the location is at all marginal.

[Brian H]

They didn't say anything like a known problem. My thoughts are they where fast in generating all the needed RMA and Labels. Like maybe they have seen this before.

 

Completely dead. Unplugged it on the chance it was locked up. After a few minutes. Reconnected it. No LED or Set Button toggling the relay on and off. ISY994i said can't communicate with it.

 

It was an I2cs, v.42 firmware as reported in My Lighting.

Will be interesting what hardware and firmware revisions I get on the new one.

 

Communications in my setup are strange. Most of my modules are early {2005-2006} I1 devices. Most of my communications show a hops left of 2. Occasionally a 1. Now every once and a while. The whole system goes almost dead. 3 or 4 modules do not respond to a query of My Lighting but then query each one individually and hops left are again 2. Even the 3:00 AM query will fail maybe one time in a month.

 

I have a strange feeling it maybe I have X10 primary Addressee in all of them. As I did find a very obscure bug when using both a Primary and Scene X10 address.

[Brian H]

Got my replacement 2456S3 the other day.

ISY reports the same v.42 firmware.

Hardware sticker 4.A with a Date Code sticker 1310.