Partial List I2CS Modules.

[Brian H]

This is not a complete list of I2CS modules but the release notes for HousLinc show adding support for some of the I2CS devices.

Kind of a roundabout way to find out some of the known I2CS modules.

As Smartlabs isn't posting anything. Even to the Developers Group members.

http://wiki.smarthome.com/index.php?title=HouseLinc

[LeeG]

Nice idea Brian. To that add

 

Motion Sensor (2420M)

FanLinc (2475F)

SwitchLinc (2476S)

LampLinc (2457D2)

ApplianceLinc (2456S3) Rev 4.6 Firmware v.42

OutLetLinc Relay (2473S) Rev4.7 Firmware v.42

ToggleLinc Relay (2466S) Firmware v.41

I/O Linc (2450)

240V N/O Load Controller (2477SA1)

InLineLinc Relay w/sense (2475S2)

Thermostat (2491T7E)

Thermostat (2441TH)

 

ToggleLinc Dimmer (2466D) this is the first dimmer reported to have I2CS

KeypadLinc Dimmer (2486D) v.41 firmware

 

as known I2CS devices requiring 3.2.x beta.

[ELA]

I just ordered a replacement ApplianceLinc. I asked if I would be getting an I2CS version.

The tech asked what I2CS was....

After a moment ... he then said that units are reflashed before shipment with the most current code and thus my new module is likely to be I2CS.

[Brian H]

Very good chance it will be I2CS.

[Teken]

I just ordered a replacement ApplianceLinc. I asked if I would be getting an I2CS version.

The tech asked what I2CS was....

After a moment ... he then said that units are reflashed before shipment with the most current code and thus my new module is likely to be I2CS.

 

 

This begs to question why this company would not take advantage of those willing to have their equipment upgraded to the latest and greatest!

 

All the while they make some extra cash, and the end user is happy with the latest improvements that are available from the new firmware!

 

SmartHome . . . Lets, get smart, and offer this service for those willing to remove, send in, and pay hard earned money in having their investments reap the benefits of the new firmware!

 

Teken . . .

[LeeG]

The I2CS capability may not be all individual device firmware. The FanLinc and Motion Sensor that have I2CS also have new versions of hardware as well. Could be coincidence, could reflect the need for the hardware to assist in the additional validations required for I2CS, such as a later PLM. That is where I would put most of the logic. Why make every device implement the same additional logic when a new PLM variant could do it at a common point. Nothing more than speculation from an old programmer at this point. Eventually all this will leak out over time.

[Teken]

The I2CS capability may not be all individual device firmware. The FanLinc and Motion Sensor that have I2CS also have new versions of hardware as well. Could be coincidence, could reflect the need for the hardware to assist in the additional validations required for I2CS, such as a later PLM. That is where I would put most of the logic. Why make every device implement the same additional logic when a new PLM variant could do it at a common point. Nothing more than speculation from an old programmer at this point. Eventually all this will leak out over time.

 

At the end of the day a few things need to be addressed. One, its great that the company continues to improve on existing offerings. But, would it really kill them to keep the people such as those in the developers forum aware and up to date as to what is going on??

 

These people paid hard earned money for more insight, and support. That is the area where this company continues to fail on a epic proportion.

 

Teken . . .

[LeeG]

Unfortunately they don't always do that and if they did folks could not tell use because of the NDA they must sign.

[Brian H]

We where given an I2CS Developers Guide.

 

Not all I2CS features are in all the models.

So some may give 100% different answers than other ones. From a message that is not I2CS blessed. As LeeG and Michel have eluded to.

 

I can't comment on the Insteon Support large active manufacturers like UDI has.

I do know if I want to consult with an Insteon Support Engineer. I have to pay a fee for their valuable time.

[Teken]

I do know if I want to consult with an Insteon Support Engineer. I have to pay a fee for their valuable time.

 

You guys have to pay just to get into their portal. Which nobody is ever there or supplies any useful information. If, and when you need to ask a direct question you have to pay them for their solution(s)?

 

What an epic fail . . .

 

Teken . . .

[ELA]

Installed a new Switchlinc hardware R5.6 Firmware V40.

Did not appear to be an I2CS as the ISY query engine returned an "01" for i2 engine.

I was hoping it would be an I2CS since I just received it in the past two weeks. It came in an order along with an Appliancelinc ( R4.6 , V42) that was I2CS.

 

I want to express my disfavor over how Smartlabs has released the I2CS versions without notice and apparently in a hodge-podge fashion.

[LeeG]

Is that SwitchLinc a Dimmer or Relay? Not sure anyone has confirmed the latest Dimmer version being shipped is I2CS. I do agree that having some indication with the device that it is I2CS would be very useful.

[ELA]

Sorry ... my last installed device was a switchlinc dimmer.

 

I would think there would be an expectation to provice notice of such changes to avoid confusion from end users.

Without dedicated members like LeeG, BLH and many others to answer seemingly endless user questions the frustration level would be much elevated.

Such inaction's are not encouraging movement towards getting Insteon out of the hobbyist realm.

 

I would really like to know at what point integrating I2CS into my system will reap rewards or benefit? One ,two ... or when all devices are I2CS? In a particular how important is an I2CS PLM (ISY companion).

 

Why would anyone want Smarthome to send them one I2CS device along with one non-I2CS device?

I apologize for the rant but at this point I can only view this I2CS release as a gigantic failure in customer relations on Smarthome's part.

[LeeG]

ELA

 

I understand the frustration, I shared it. The CheckSum aspects of I2CS will insure a higher level of reliability. The longer Extended messages carry a CheckSum byte which gives Extended messages an additional level of validation. The benefit of this feature is specific to the I2CS device and immediate.

 

The other aspect of I2CS which allows an I2CS device to differentiate a known PLM from an unknown PLM would only be guess work as to why SmartLabs felt this necessary. It certainly adds an additional level of security against someone trying to hack into an Insteon installation. Perhaps this had its genesis in the commercial world.

[Brian H]

I don't believe the PLM has to be updated. It can send and receive the Extended Messages now. Some of the information in the messages have to be modified by the firmware to add the Check Sum Bits.

 

What makes it tougher is not all of the I2CS features are incorporated in every module.

 

Also there are other features; that eventually will improve communications even more. I have not seenn implemented yet.

[ELA]

According to the old Insteon Details doc out there there is a CRC byte in both standard and extended messages (prior toI2CS).

 

This is exactly why I question the value of I2CS unless all modules are utilizing it. I know people may not know for sure, or not be free to release details.

We are then left to speculation but I suspect the new I2checksum will most likely not be of any benefit unless each end of the communications exchange is utilizing it.

 

Maybe they have included an additional byte or bytes to the checksum to provide a more thorough check.

[LeeG]

BLH

 

I agree completely. There should be no need to make any PLM change. I added an I2CS device to the current Houseline using a very old 2412SH PLM from years ago that came with the original HouseLinc Desktop software. That PLM worked fine. There are no special I2CS PLM commands.

 

The comment regarding recognizing the PLM, that related to whether the PLM had been registered with the device or not, not whether the PLM was incompatible. I'd say there are no incompatible PLMs as far as I2CS is concerned

[LeeG]

ELA

 

Device to device communication (not involving a PLM) does not use Extended commands. I'm guessing the CRC character does not catch all the conditions of concern, thus the added CheckSum. If the PLM sends an Extended message to an I2CS device with the CheckSum missing or invalid the command is rejected. That would be the equivalent of the Extended message being damaged due to powerline issues. I have always assumed the CRC would pick that up but there would be no need for this new CheckSum if that was the case. As far as the why it is all guess work. The need for a valid CheckSum is not guess work. I had to update the SHN Utility Suite to get it to work with I2CS devices.

 

As a side note I just received the I2CS ApplianceLinc. I had no problems getting the ApplianceLinc to answer the PLM request for information. I added the ApplianceLinc again without a Factory Reset and also added after a Factory Reset. Cannot explain the lack of a PLM response you have traced.

 

The ApplianceLinc is Rev 4.6, firmware v.42.

[Brian H]

Well it could be worse.

I played around with Indigo on an old Mac and still get their update newsletters.

I2CS required the latest revision 5.1 and many 4.? users where told all new modules would not work. As well as the user with the 2414U PLC that doesn't do Extended Messages correctly.

[ELA]

LeeG,

 

In this discussion I was assuming extended communications (unless the new protocol applies to standard messages as well?)

 

When a person has a ISY-99 based system they are heavily reliant on PLM communications to each module in the network. Seems to me that if the PLM firmware is not updated to I2CS then it would not be able to take advantage of the new checksum.

(We know it can take advantage of other features such as using extended msg link records, like Brian previously mentioned in another post, getting rid of peek and poke)

 

I was not questioning backward compatibility. Sure the existing PLMs had better be able to communicate without update, but then how can they be taking full advantage of the new protocol?

 

Thanks for your testing on the appliancelinc. My current module is installed in the home network. I have another one the way as a backup (test module). I will try to add that one to the ISY as a 2nd test when I get it.

 

Other than the one off problem I encountered when linking in the ISY, I am still a little curious about how I got a Flag byte with the NAK bit set, whereas I did not see that in the ISY linking? ( from the other post exchange we had on the appliancelinc).

 

You mentioned that the ISY detected the Cmd2 "0xFF" as an indication of a failed response. I wonder why in one instance the Flag NAK bit is set and in another it is not.

[LeeG]

I do not know who is responsible for verifying an inbound Extended message with I2CS CheckSum value. The checksum byte is in a previously unused location inside the Extended message so the PLM does not have to know. If it is the job of the PLM to verify the inbound checksum then we will need to know at what PLM firmware supports CheckSum validation. If it is the applications responsibility then the PLM level makes no difference.

 

EDIT: let me repeat, I do not know. It could be difficult for the PLM to do the check because the PLM does not know whether the inbound message is coming from an I2CS device or not. The application does know. If the PLM checks the previously unused byte for a valid checksum of a non-I2CS device it could reject a message from a device that did not insert a checksum at all. I mentioned in a previous post the logical place for the CheckSum validation would be the PLM. However, with more thought this topic has generated the PLM may not be able to do that check.

[LeeG]

I've updated my initial post on page 1 of this topic with two additional I2CS devices, the ApplianceLinc and the OutletLinc Relay. The OutletLinc Dimmer received today is not an I2CS device. Seems like the dimmer variants are running a little later than the relay variants.

[ELA]

I do not know who is responsible for verifying an inbound Extended message with I2CS CheckSum value. The checksum byte is in a previously unused location inside the Extended message so the PLM does not have to know. If it is the job of the PLM to verify the inbound checksum then we will need to know at what PLM firmware supports CheckSum validation. If it is the applications responsibility then the PLM level makes no difference.

 

EDIT: let me repeat, I do not know. It could be difficult for the PLM to do the check because the PLM does not know whether the inbound message is coming from an I2CS device or not. The application does know. If the PLM checks the previously unused byte for a valid checksum of a non-I2CS device it could reject a message from a device that did not insert a checksum at all. I mentioned in a previous post the logical place for the CheckSum validation would be the PLM. However, with more thought this topic has generated the PLM may not be able to do that check.

 

LeeG,

This makes me wonder if SmartLabs is then departing from their original standard where they stated this from the details doc:

Firmware in the INSTEON Engine handles the CRC byte automatically, appending it

to messages that it sends, and comparing it within messages that it receives.

Applications post messages to and receive messages from the INSTEON Engine

without the CRC byte being appended.

 

That would be pretty strange.

 

Do you know for a fact that they use a previously unused byte within the extended msg body? That would also be strange to me. I would expect an additional checksum byte to be appended to the end of the msg if required by I2CS.

 

 

I did some more testing on my original I2CS Appliancelinc module since the new one may take some time to arrive, being a replacement -not cross shipped.

 

I see now why I was getting the "0xA1" ... NAK bit set along with the "0xFF" for cmd2 when the device was not in the I2CS devices link record.

This I2CS device is only setting the NAK bit when 1 hop is requested. If you request 2 or 3 hops it does not NAK it. Once the sender is put into the link record it will no longer NAK a 1 hop request.

 

Any speculation as to the purpose of this?

 

I guess I do not understand the "Insteon" purpose of the NAK bit. I can send a direct msg to command the Applianclinc ON or OFF (when senders address is not in its link record) and as long as it is commanded with more than 1 hop it is not NaKed. ( even though the device does not physically respond).

This I2CS device does return a "0xFF" in the CMd2 .... but isn't that also a valid response when commanding an "ON".

 

This seems a strange usage of the NAK bit vs. the CMD2 byte?

[LeeG]

“Do you know for a fact that they use a previously unused byte within the extended msg body?â€

 

As sure as I can be. The SHN Utility Suite changes I made allow the Utility to work with I2CS device link database with extended commands. The checksum is in D14 which has been unused up till now. Look at the event trace from 3.2.x versus anything earlier where extended commands are used in either direction.

 

Anything about why NAK under some conditions versus no NAK, why the FF when it could be valid would be more speculation. Everything I have noted in posts has been based on observations working with I2CS devices. How much applies to every I2CS device type is unknown and so is the why. It took years before someone slipped about the difference between the 2412S and the 2412SH PLM.

[jdale]

I updated the device list at http://www.madreporite.com/insteon/Inst ... e_list.htm (it's now also split into several tabs across the bottom of the table). Not much more info than is already posted here though.

 

For the sake of summing everything up, here is what I have gathered about i2cs so far:

 

CS in the name refers to "checksum". All extended messages place a checksum byte in D14. How this is computed or checked... uncertain.

 

Wired i2cs devices must specifically be linked as a responder before they will accept commands. It is no longer possible to send direct commands to unlinked devices. (Uncertain whether this refers to all i2cs devices or only some.)

 

After an i2cs device sends a broadcast message, it will send a report of how many devices didn't respond with a cleanup message.

 

It is possible to set how many times cleanup direct messages are set after a group broadcast. Also, previously any other Insteon traffic would cancel these messages. It is now possible to turn on a message that forces a device to finish cleanup.

 

x10 is removed from some devices

 

The Get Insteon Engine Version command will return a value of 0xFF and a NAK if the i2cs device is not linked to the PLM. If it is linked, it will return a 0x02 which is the i2cs indicator.

 

i2cs devices mostly do not support Peek/Poke.

 

As with other aspects of the protocol, not every device supports every command.