Partial List I2CS Modules.

[ELA]

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.

 

Thank you jdale,

I have been attempting to work with the i2CS protocol in attempts to understand its impacts and the two comments above were of particular interest to me. Do you have any further details you can share?

How do you configure the number of direct cleanups msgs?

 

With the two i2CS modules I have tested I am seeing cases where they are sending what were unexpected messages ( based on my limited understanding). The first case was a message send after the reply to a "0x09" begin linking command. I detailed that in the Getting Serious thread so I will not address that one here.

 

Now that I have received a second module I am also seeing an extra message sent after the valid response to the "0x10" Device ID command. ( PLM is linked to APL so that I get a valid response).

I send the "0x10" command and get a valid acknowledgement as shown below:

2 62 1c ee 2b f 10 0 6
             Hops, Max : Remaining   3 : 3 
2 50 1c ee 2b 18 d4 d4 2b 10 0
             Hops, Max : Remaining   3 : 2 
2 50 1c ee 2b 2 9 42 8b 1 0
             Hops, Max : Remaining   3 : 2 

 

After the acknowledge the APL sends another message that is not recognized by the PLM (needed to use the O'Scope to see it). Thus the APL attempts 4 retries after the initial send. Since the response message is a Device ID broadcast message I wonder if this fits what you have said above? However this is not like a group broadcast command(that is intended to control) it is only a broadcast ID. I did not think it would require a response.

 

So why does the APL attempt retries and who is it trying to get a response from and why?

What used to take 0.5 seconds to accomplish now takes 2.0 seconds (due to retries)!

 

This concerns me because I see these very same messages being sent by the ISY and I can see where the ISY has to send messages more than once (via the comm log). Is this because the i2CS device is busy retrying!

 

THIS MAKES ME WONDER??? IS ADDING i2CS DEVICES TO AN EXISTING NETWORK ACTUALLY SLOWING IT DOWN?

 

I see a similar message when you manually hold the set button. I guess I am lost without a new "details" manual

[Teken]

I would like to know if anyone has taken the time to read the user manual for the new Insteon diagnostic tool.

 

There are details in that user manual which don't make any sense, or makes me take pause. If someone can please read it and tell me if there was something you saw stand out that made you look twice.

 

Please do chime in . . .

 

Teken . . .

[LeeG]

It would make more sense to describe the circumstances that are confusing/conflicting, etc

[Teken]

It would make more sense to describe the circumstances that are confusing/conflicting, etc

 

If you take a few moments to read the document with respect to the *Unlinking* portion. Please do let me know if there are conflicts in this process. I don't want to bias anyone from my interpretations vs what is being stated in the users document.

 

For reference: Five engineers read the document and all them had the same look I had and simply scratched their head.

 

Teken . . .

[LeeG]

Is this what you are referring to?

 

Unlinking is important when testing is complete on any device.

1) Tap UNLINK button to remove link from unit under test.

[jdale]

ELA: I don't have any additional details, this is just putting together the meager gleanings from other posts. Hopefully we can figure out the details!

 

The diagnostic keypad manual says "*The success report feature was released in devices shipped after March 2012.

A small number of INSTEON devices do not support this feature." It's clear that a message is sent after a scene is activated. And that linking is not necessary to see this message. It makes sense that this is a broadcast message. Based on the message you report seeing (flags = 8b is a broadcast, command1=1, command2=0) it could look like a Set Button Pressed message, except with command2=0. Probably command2 would take a different value if the message failed. Should be easy to force this situation to occur (just link something and then disconnect it).

 

As for the diagnostic keypad...

 

In the Diagnostic Keypad manual, the instructions for Distance seem weird. You have to link the device. But then you may need to unlink it before actually doing the test. I wonder if this only removes the link from the responder device link database, not from the diagnostic keypad database (which will be overwritten the next time you link it anyway, since it only supports 1 link). That's my guess about what is really going on here.

 

I don't understand the point of the Lock/Unlock feature, given that you can't lock a device and unlock it later if you used the diagnostic keypad for anything else. Maybe for professional installers who don't want their customers to be able to fix things at all? Seems problematic.

 

The manual also doesn't say anything about how to link it to other devices... odd omission.

[Brian H]

I believe the new modules have the ability to have their local settings locked by the test keypad, but still be able to be unlocked remotely.

Why is another question.

[Teken]

ELA: I don't have any additional details, this is just putting together the meager gleanings from other posts. Hopefully we can figure out the details!

 

The diagnostic keypad manual says "*The success report feature was released in devices shipped after March 2012.

A small number of INSTEON devices do not support this feature." It's clear that a message is sent after a scene is activated. And that linking is not necessary to see this message. It makes sense that this is a broadcast message. Based on the message you report seeing (flags = 8b is a broadcast, command1=1, command2=0) it could look like a Set Button Pressed message, except with command2=0. Probably command2 would take a different value if the message failed. Should be easy to force this situation to occur (just link something and then disconnect it).

 

As for the diagnostic keypad...

 

In the Diagnostic Keypad manual, the instructions for Distance seem weird. You have to link the device. But then you may need to unlink it before actually doing the test. I wonder if this only removes the link from the responder device link database, not from the diagnostic keypad database (which will be overwritten the next time you link it anyway, since it only supports 1 link). That's my guess about what is really going on here.

 

I don't understand the point of the Lock/Unlock feature, given that you can't lock a device and unlock it later if you used the diagnostic keypad for anything else. Maybe for professional installers who don't want their customers to be able to fix things at all? Seems problematic.

 

The manual also doesn't say anything about how to link it to other devices... odd omission.

 

That is just one odd thing. If you look at the manual it states the *Unlink* can only work with devices produced after March 2012. How are you supposed to *Unlink* a device prior to that shipping date?? It is absolutely stated that the device under test must be *Unlinked* otherwise the half links will remain.

 

If at that point, you realized your mistake. The device under test will need to be factory reset and all programing will need to be restored. Not so much of a problem with a HL2, or ISY. But, if you have done all of this manually that will be a huge undertaking in a large install.

 

Teken . . .

[Brian H]

Sounds like they are only thinking of I2CS modules as they where released in March 2012.

Sometimes I get the impression. Smartlabs Engineers can't think in the past. Like my 2005 modules must be trash.

 

I am periodically helping older SwitchLinc Relay owners in Factory Resetting them. The old manuals with the before Air Gap Switch procedure are no where to be found in their Manuals Area. Same for the older ApplianceLincs and LampLincs Local Control being tied to an X10 Address information.

[Teken]

Sounds like they are only thinking of I2CS modules as they where released in March 2012.

Sometimes I get the impression. Smartlabs Engineers can't think in the past. Like my 2005 modules must be trash.

 

I am periodically helping older SwitchLinc Relay owners in Factory Resetting them. The old manuals with the before Air Gap Switch procedure are no where to be found in their Manuals Area. Same for the older ApplianceLincs and LampLincs Local Control being tied to an X10 Address information.

 

Exactly, my point . . . How is a person supposed to *Unlink* a device with the 4 other buttons, which clearly states CAN be used with Insteon devices made before March 2012?? I will give SH the benefit of the doubt on this that there is a clerical error.

 

Or, there are steps not yet published in the original user manual.

 

One can not be expected to enroll / link a device using the On/Off, Beep, Distance modes, and than in the same breath not be able to *Unlink* that same device. Per the users manual this will leave a half link in the device.

 

Five engineers all read the manual and all of them with in ten seconds had the same questions I had . . .

 

I thought I was retarded for a moment!

 

Teken . . .

[Brian H]

Well it will not be me being the early adopter this time.

I have learned my lesson with early production release Insteon Modules.

[LeeG]

Folks have been linking/unlinking devices with buttons/paddles/Set buttons since the beginning of Insteon. Long before I2CS was a dream in some engineer’s eye. Those 5 engineers that read the document, do they meet the presumption "user has a moderate to expert understanding of INSTEON and INSTEON products". Without that level of knowledge and understanding of Insteon I am not surprised they do not understand.

[Teken]

Folks have been linking/unlinking devices with buttons/paddles/Set buttons since the beginning of Insteon. Long before I2CS was a dream in some engineer’s eye. Those 5 engineers that read the document, do they meet the presumption "user has a moderate to expert understanding of INSTEON and INSTEON products". Without that level of knowledge and understanding of Insteon I am not surprised they do not understand.

 

Alright I'll bite. Given what is stated in the users manual, and seeing as there is only one *Unlink* button. How does one unlink a pre made March 2012 Insteon device with out the aid of the Unlink button on this device?

 

The manual states explicitly that this task must be done using this sole button. So, if this button only works for devices after March 2012, how then do you unlink a pre March 2012 Insteon device with out using the unlink key, and avoid the half link?? One doesn't need to be an Engineer to have common sense or understanding. I am taking this document and instructions literally. Unless this document is incorrectly stated and it really doesn't matter, and the tool will unlink the device regardless of the production date.

 

Then, no harm no fowl. But, this simple fact needs to be clearly made to all users. Assuming it will work doesn't cut it in the field, that only leads to extended down time and frustrations for all.

 

Teken . . .

[jdale]

I believe the new modules have the ability to have their local settings locked by the test keypad, but still be able to be unlocked remotely.

Why is another question.

 

I don't think it's actually new. Documented at least back to 2007 for some devices. Standard message, command1=0x20 (set operating flags), command2=00 for lock and 01 for unlock.

 

I assume the issue here is that the diagnostic keypad will send these commands only to the device it is linked to. But if you lock a device with it, then link it to something else, there is no way to link it to that first device again (because it's locked). So functionally you cannot use the diagnostic keypad to unlink it. You can still do so from software. This makes sense, I just don't get what is the point of including the function in the diagnostic keypad. I do get the point of being able to lock a device, to avoid people from accidentally messing up the settings by playing around too much.

[ELA]

Teken,

I superficially read the the diagnostics tool manual but do not pretend to understand it.

 

As far as the link/unlink this is something I have been attempting to add to my ELAM.

I recognized the need since the i2CS modules will not react to (direct)commands such as on/off if they do not have a link record to the device commanding them.

So the tester (diagnostic tool) must temporarily install a responder link into the i2CS device in order to perform its on/off, beeper etc. diagnostic commands. Once the testing is done you would then want to remove that temporary link.

This would not need to be applied to earlier non-i2CS modules since they will respond to (direct) commands without a link installed.

 

jdale,

What I am addressing is a command that cannot be seen in the event viewer. Not the broadcast ID that you do see in the viewer. There is another command sent that is "hidden". You only see it with an O'scope. It happens immediately after the broadcast ID msg. It may be a set button pressed command that is not passed up to the application?

 

Due to this I have needed to purposely delay an additional 1.5 seconds after sending some commands such as the "0x09 and 0x10", otherwise you get collisions.

 

I would like to know what these commands are and why they are there. They were not present prior to i2CS in the 0x10 command. Since they are not passed up to the application level I may never know without signing an NDA

For now I am electing to add delays and ignore them.

[LeeG]

My point exactly. A moderate to expert Insteon user would not ask how to unlink a device. If you do not know how to unlink a device, how did you get the device linked to begin with? Once you know how to link the device you will know how to unlink it. The procedure for linking and unlinking pre March device is described in every KeypadLinc User Guide.

[Teken]

My point exactly. A moderate to expert Insteon user would not ask how to unlink a device. If you do not know how to unlink a device, how did you get the device linked to begin with? Once you know how to link the device you will know how to unlink it. The procedure for linking and unlinking pre March device is described in every KeypadLinc User Guide.

 

Hello LeeG,

 

I would like you to answer how you will perform this unlinking task, for a pre-march 2012 via this diagnostic tool using the unlinking button.

 

Teken . . .

[jdale]

So, does anyone have any hints as to how the checksum is calculated? That seems the main sticking point for normal communication with i2cs devices.

[Brian H]

Confirmed. The 2476S Hardware 6.0 and above. X10 support is now NA.

6.0+ manual.

http://www.smarthome.com/manuals/2476s.pdf

 

The sales page for the 2476D also is now showing X10 NA. Guess the I2CS code took up too much room or was conflicting with I2CS.

[Teken]

Confirmed. The 2476S Hardware 6.0 and above. X10 support is now NA.

6.0+ manual.

http://www.smarthome.com/manuals/2476s.pdf

 

The sales page for the 2476D also is now showing X10 NA. Guess the I2CS code took up too much room or was conflicting with I2CS.

 

You will also notice that they actually stated the standby power consumption as 0.67 watts. Opposed to the <1.00 Watts.

 

Teken . . .

[xlurkr]

The sales page for the 2476D also is now showing X10 NA. Guess the I2CS code took up too much room or was conflicting with I2CS.

 

My guess is that it has more to do with upping the security, like the other change I don't like, eliminating direct control by address without a link.

 

It sure would be great if someone from SH would chime in and tell us the strategy, and workarounds for those affected. Is SteveL still here?

 

-Tom

[Brian H]

It is like pulling teeth to even get any information on anything Insteon from Smartlabs.

Even the data we get in the Developers Group is old and incomplete many times.

[Teken]

It is like pulling teeth to even get any information on anything Insteon from Smartlabs.

Even the data we get in the Developers Group is old and incomplete many times.

 

To this day that really boggles my mind . . . What is the purpose of having a developers forum when NO ONE IS AROUND TO HELP YOU??

 

WHAT IS THE PURPOSE OF CHARGING SOMEONE WHO JUST SPENT HARD EARNED MONEY IN THE HOPES OF SUPPORTING YOUR PRODUCT??? That has to be one of the most aszz backwards mentality I have ever seen, or read about.

 

Based on some of the older threads I know SH / Smartlabs got put into a hard place when they stated something and, IT, just dragged on with no ETA, or hope in sight.

 

Better to say nothing until you're good and ready to launch and have your ducks in a row. But, what they fail to understand and see is that its the power of the people (clients) who bring forth ideas, advancements, and trouble shooting to the HA tech.

 

What they (Smarthome / Smartlabs) need to really be aware of is that they are a sole vendor with almost no support from ANY major supplier vendor.

 

You have the likes of Cooper, Leviton, and the list goes on and on supporting Z wave, Zigbee, etc. Insteon doesn't have one major player supporting and making their wares. The only one that comes to mind and they aren't even big compared to the two listed names is Skylink which is the maker of the PIR sensor.

 

The only saving grace for this company is that someone has been tasked to review some of the major threads and forums around the world. There were several key suggestions I know I made along with many others which were implemented not too long afterwards.

 

This is what makes a great company, and a successful product line. You get your defect rates down to bare minimum, you get your price point where you can make a decent profit, and ensure proper support and warranty on said item.

 

That my friends is a recipe for success . . . If anyone should read this thread from SH / Smartlabs.

 

1. Make the Insteon devices firmware upgradeable in the field. The worst case have the service available for those interested in getting the latest fix / enhancements.

 

2. Bring back the 7 year extended warranty. I am one of the last people to ever purchase an extended warranty on most items. Having said this, when you have thousands of dollars on mini computers in your home controlling all manner of critical systems in your home. Having an extended warranty to protect your investments is not only wise, its required.

 

3. Value: You guys need to bring back the Icon line or at the very least give those who purchase multiple of the same items a break. Or have a loyal customer discount for these things. This shows appreciation to the long time customer, and fosters on going sales.

 

4. Have a consistent PR campaign to let all the customers know of new products and how they have been improved. Hiding random facts is not helpful. Launching I2CS with out any form of information in the wild is not idiotic, but plain stupid.

 

If it wasn't for this forum and the others many would have not figured out why XXX product didn't work as expected. This directly affects sales, and the perception of a bad product!

 

5. Lastly, stop with the stupid so called sales . . . If you have a sale don't take off $1.00 and call it a sale. You're wasting my time and energy trying to wade through all the crap. Last, but not least get rid of all the crap on that web site which has no reason to exist in this world.

 

I have to shake my head when I see some of th wares / items SH is trying to sell and push off to the customers. In the same breath you're trying to sell that same crap at 99999999999 times than can be had at the dollar store.

 

Bottom line carry reasonable priced items, stop selling all of that dollar store crap and try to pawn it off as high tech.

 

Teken . . .

[Brian H]

I wish I had archived the big list of manufacturers going to support Insteon released by Smartlabs/Smarthome. Around late 2005 or early 2006.

Except for a few like UDI; Simplehomenet {there are a few others}. The majority faded into sunset.

Faded memory kind of remembers a few of the manufactures you mentioned dropping out of Insteon support.

 

I too can understand not announcing a product well before it should have been.

My favorite is the 2454D SocketLinc Dimmer. It was very late and then had a few problems. Heat related so only vertical mounting with bulb above it and always went to 100% On when the power fluctuated. Even if it was Off.

http://www.smarthome.com/2454D/SocketLi ... 54D/p.aspx

[jdale]

All the old press releases are still up on the Insteon.net site if you really want to find it.

 

 

I dug up some info on how the iMeter Solo computes checksums, but it's incomplete (does not say how to reduce a 4 byte unsigned integer into a single checksum byte) and I'm not sure it's the same in any case... Anyone else turn up any hints for the checksum computation?