Insteon Extended Messaging

[Paul_PDX]

Without extended messaging Linking, Link scanning, and polling is definitely not as fast as it could be, but it still can be accomplished.

This slows down computerized set up and it slows down computer software when it first starts up if it wants to determine the initial state of swicthes. But for normal use it really doesn't slow things down once you are started up and running.

I link all my devices back to the PLC so the PLC receives a notice of every change as they happen and I set up groups in my PLC for any mass changes I need to do with my devices. I do not use manual linking anymore.

Using powerhome it takes about 15-20 minutes to do a full scan of all of my links with about 60 devices installed. I only do this when I have been doing major relinking. The status scan of all of my devices seems to take about 6 minutes before powerhome correctly knows the initial state when it is first powered up (which lately is one or two times a week as I am still tinkering).

If you have a continuously running system it should be able to stay up to date in close to real time. If you don't use automation software this doesn't affect Insteon owners at all.

My only worry about not having these commands is the same as upstatemike -- If new devices come out using these will future software stop supporting our early devices. It definitely is easier as a programmer to use the extended commands (if they worked) so I would imagine alot of developers would skip implementing code for the non-extended commands. Hopefully this won't happen as the hard part has already been done by most of the major players at this point, but this could still become an issue down the line.

 

[upstatemike]

I have 3 times as many Insteon devices as you so the total scan time is a lot more of an issue for me. I think I would feel better with devices where the full protocol is implemented so I'm going to start unistalling stuff right now and getting it ready to exchange.

Can anybody confirm that the extended messaging devices have started shipping? Anybody know the revision/version numbers?

 

[Paul_PDX]

As far as they have told us on the developers forum the 2.12 PLCs and newer are the only devices with working extended peek and poke commands.

The SignaLincs don't support the commands at all (so they can't bridge powerline phases or be repeated by a SignaLinc).

AFIK other devices all have some bug that sometimes corrupts part of the buffer or crc of the extended message so it appears invalid.

 

[Digger]

Before we start ripping them out is the fix implemented and are they actually going to exchange them?

If they dont I think they will kill their reputation but who knows maybe not enogh people know about it yet.

I feel like we are all beta testers and dont even know it.

 

[KenM]

Hi all,

As a very tired, mostly x-Insteon amateur software author and device user, I can make the following observations and comments,

I am not aware of any immediate plans by SH/SL to address this issue.

The Rev 2.12 PLC firmware (that I have) does not appear to work with extended peek/poke operations.

I understand that the KPLs support extended messages, there is no way to verify that just yet as no other device seems to support it.


My own opinion;

I would dearly love for SH/SL to publish a public list of know (past/present) problems and fixed or estimated fix dates and rev levels on the fixed items. I can see this reaching a point where people are just plain afraid to buy this stuff because it seems, is up to the end user, and not the retailer, or manufacturer, to verify that the hardware is current and or is even safe before it is sold.

For a geek type like me, it just gives me something to do. Average Jane or Joe consumer may not be so happy with the status quo.

My first V2 ApplianceLinc that smoked was in Dec of 05. I very much appreciate that a problem with that module was finally posted. The seven(ish) month delay from problem start to the final outcome of a safety issue?

Ken

 

[wuench]

I have posted this many other times, but it is a race in my opinion. SH needs to fix these issues or UPB needs to fix the doubletap delay. The first to market with the fix will probably get the market share and become the next lighting standard.

I have seen posts that UPB manufacturers are working to make the delay an option.

The clock is ticking Smarthome...

 

[dhoward]

Some additional info...

SmartHome has just released an Insteon conformance specification. There appears to be some conflicting dates but it looks like extended messaging will be required in future devices. A new "required" Insteon command is "Product Data Request" which is required after 09/01/06. This command is standard length but the return data is an extended message. Another section of the document states that all devices manufactured after 02/01/07 must support the "Product Data Request" command.

Having said that, the document also states that the current method of peeking and poking link data (as well as any direct EEPROM writes such as X10 addresses, KPL XOR buttons, etc.) is deprecated and should no longer be used. This will be accomplished in the future using a modified extended data poke.

My understanding is that all PLC's with firmware 2.12 and above have the extended messaging fixed. We just don't have any other devices with the extended CRC bug corrected yet.

Dave.

 

[Madcodger]

Before we start ripping them out is the fix implemented and are they actually going to exchange them?

If they dont I think they will kill their reputation but who knows maybe not enogh people know about it yet.

I feel like we are all beta testers and dont even know it.

I have to agree that we have been beta testers, and that we were not informed of the "beta" stage of the product when we purchased it. Then again, maybe even SH wasn't fully aware of all the problems until they started to unfold over time. One can only hope that was the case. It doesn't relieve them of their responsibilities, but it does have ethical implications so I'm giving them the benefit of the doubt on that one.

As for exchanges, I think that's their opportunity to redeem themselves. I won't be happy if I have to replace my 60 + devices in a few months (and I don't even like to think about upstatemike, with his 180 or so) but I would still recommend SH and Insteon in the future if they agree to replace all my devices without charge once the product line is stable. If they don't agree to do this, via a direct cross shipment program of at least 30 days, one can only imagine how mad people will be and how badly their reputation will suffer. So... you have to think / hope they are smarter than that.

Also, they need to replace these devices directly regardless of WHERE they were purchased. SH is both a retailer AND a manufacturer, which some members of their organization seem to forget from time to time. Personally, I buy from Martin at AO because of their service and advice. But unless SH is willing to enable dealers to cross ship replacements without suffering financially for it, dealers will be forced to charge us for replacement devices before they can ship them, and then - hopefully and depending on SH's policies - credit us back once the defective units are returned. I don't mind that for one or two devices, but beyond that it's the manufacturer's responsibility to either handle these things directly or enable their dealers to do so.

I have converted almost my entire house to Insteon (everything that I need to automate, anyway) and really, really WANT to believe in this product line. But I think we all need to believe the manufacturer has both their own AND OUR best interests at heart over the next few months. It seems time and actions will tell...

 

[upstatemike]

Having said that, the document also states that the current method of peeking and poking link data (as well as any direct EEPROM writes such as X10 addresses, KPL XOR buttons, etc.) is deprecated and should no longer be used. This will be accomplished in the future using a modified extended data poke.

So they are ending support for the current version by the end of the year and want everybody to move to the new method of doing things that is based on different technology. After you start using the new stuff you may find you have to replace some or all of your plugin modules to ones that have been updated to work with the new data structure.

Why does this whole scenario sound so familiar?

 

[Digger]

I am soooooooooooooo sorry I wasted my money on Insteon. I knew it in my gut and I was stupid and bought it anyway and then bought more. Tomorrow I will all them and try and RMA everything not installed. If they dont do that then I know that they have no intention of exchanging these once they fix the problems.

I will post the outcome of my phone call.

 

[upstatemike]

Problem is all the other alternatives have problems too... just different ones. UPB has the double tap delay and rip-off pricing. Z-Wave has local control status reporting issues tied to a big patent battle plus a super confusing standards policy that makes it very hard to determine what features are supported by which manufacturers (and even in which models).

I suggest you concentrate on making your X-10 environment as solid as possible and leave it at that. At least then if SH won't let you return your switches you can use them in X-10 mode.

Of course there has been enough discussion on this now that I'm sure somebody from SH would have said something if they were not going to swap the units that don't support extended messaging. The challenge is just finding out when extended messaging will be available for each device type.

 

[ver0776]

Even without extended messaging, I feel Insteon is still faster and more reliable than X10. So if they never fixed it, I would still consider the Insteon products.

I read that the big impact is with discovery and spidering, but will the extended messaging actually help in the simple response times in sending a command to turn a light on, etc? What about the PLC USB controller, I hear it is a major part of slowness? Is the extended messaging supposed to help that?

I know X10 motion detectors and my own software tuning are to blame for alot of the delays I experience in turning lights on and off, but I would like to make sure I am addressing EVERY speed issue I can. Although my home is somewhat crappy, it is the pilot home for my software and 1 second in a string of events to get a light turned on is Major...

I trust in the house so I will charge into a dark room knowing the lights will come on, but for visitors, they don't know and have time to hit the switch and just confuse things. I really want the response times fast enough that the light is on before they can touch the switch.

I have been resorting to pressure mats outside of doors and on steps to get the extra second I need, but that is just too much to expect anyone else to do...

Thanks,
Vaughn

 

[upstatemike]

I read that the big impact is with discovery and spidering, but will the extended messaging actually help in the simple response times in sending a command to turn a light on, etc? What about the PLC USB controller, I hear it is a major part of slowness? Is the extended messaging supposed to help that?

I think the major advantage of extended messaging will be in polling devices for status. Right now polling is not practical because the response from the devices takes so long to transmit that even a moderate installation cannot be polled in a reasonable amount of time. If devices can respond using extended messaging then my understanding is that the entire process becomes practical again.

The speed advantage for creating and managing links would just be a bonus.

I do not think the extended messaging fix will improve the latency in the PLC which as I understand it is due to slow communications through between the PLC and the computer. I'm not sure if this is a firmware or hardware problem so I don't know what the fix will be.

 

[upstatemike]

Even without extended messaging, I feel Insteon is still faster and more reliable than X10. So if they never fixed it, I would still consider the Insteon products.

Also if you shop the sales Insteon is quite a bit cheaper than high end X-10 switches.

 

[jeffx]

If they don't agree to do this, via a direct cross shipment program of at least 30 days, one can only imagine how mad people will be and how badly their reputation will suffer. So... you have to think / hope they are smarter than that.

I think they would be prime candidates for a Class Action Law Suit if they refuse to replace these devices. Even if they do, a Class Action might be a possibility because of all the time/labor to replace switches multiple times. We'll have to wait and see how this unfolds.