A message from Steve at Smarthome.

[apostolakisl]

I keep reading about the bad micro switch batch of insteon products. I have about 70 or 80 insteon switches and would like to know if any of them were part of the "bad batch". Is there a way to know by looking at the switch if I have any of them? So far I have not had any failed switches. Some are several years old and some are months old.

 

[BLH]

Smarthome emailed many of the customers with possible problem switches. Where earlier ones and I got the email.
I only have one Switchlinc in use. The first ones tact switches got flaky. Its twin from the same purchase has been 100% for years now.

 

[Xpendable]

I've written code for both the PLC and PLM. The PLM is a real pain to write for.

I thought the PLM was supposed to be easy to write code for? I heard people complaining about the pain of writing for and using the PLC for years (such as HomeSeer).

The PLM can be very easy, and there are as many people that developed to the PLC the didn't have the problems as those that have. Based on what you are trying to do with it could be challenging. For other applications it is straight forward. Because HomeSeer had problems with there plug-in does not mean that an applicvation could not be written for it. Some were better with it that others. Was it perfect, No. Were people sucessful with it yes.

SteveL

Who told you that? The PLM is most definitely harder to write for than the PLC. (Assuming we are not talking about SALAD, which pretty much nobody uses anyway). The SDM (which was a buggy piece of crap, by the way) was an API that was extremely easy to program against, at least if you were using Windows. That's the only thing it had going for it. Simple method calls existed for doing most of what you needed to do. The SDM API did have some key functinality missing and broken, though (like no working methods to handle deleting links). The PLM, on the other hand, has no API. You have to essentially build your own API and write your own low-level asynchronous serial communictions for the PLM. That's not for the faint of heart. It can take a lot of time to get that working right, and there is a HUGE potential for getting stuff wrong. And the PLM's host computer protocol could have been better to make this job easier. I've programmed low-level serial communications to a pin-debit/credit card machine (Ingenico's i6780 device with 320x234 color screen) that was easier to program for than the PLM. I'm just saying I have a lot of experience in low-level serial communications programming. I'd say programming a complete API for the PLM is pretty difficult and challenging. The folks that are able to do this are your strong programmers.

 

[SteveL]

I've written code for both the PLC and PLM. The PLM is a real pain to write for.

I thought the PLM was supposed to be easy to write code for? I heard people complaining about the pain of writing for and using the PLC for years (such as HomeSeer).

The PLM can be very easy, and there are as many people that developed to the PLC the didn't have the problems as those that have. Based on what you are trying to do with it could be challenging. For other applications it is straight forward. Because HomeSeer had problems with there plug-in does not mean that an applicvation could not be written for it. Some were better with it that others. Was it perfect, No. Were people sucessful with it yes.

SteveL

Who told you that? The PLM is most definitely harder to write for than the PLC. (Assuming we are not talking about SALAD, which pretty much nobody uses anyway). The SDM (which was a buggy piece of crap, by the way) was an API that was extremely easy to program against, at least if you were using Windows. That's the only thing it had going for it. Simple method calls existed for doing most of what you needed to do. The SDM API did have some key functinality missing and broken, though (like no working methods to handle deleting links). The PLM, on the other hand, has no API. You have to essentially build your own API and write your own low-level asynchronous serial communictions for the PLM. That's not for the faint of heart. It can take a lot of time to get that working right, and there is a HUGE potential for getting stuff wrong. And the PLM's host computer protocol could have been better to make this job easier. I've programmed low-level serial communications to a pin-debit/credit card machine (Ingenico's i6780 device with 320x234 color screen) that was easier to program for than the PLM. I'm just saying I have a lot of experience in low-level serial communications programming. I'd say programming a complete API for the PLM is pretty difficult and challenging. The folks that are able to do this are your strong programmers.

I agree with you for programming a link management application, you have to know what you are doing. But writing a simple program that can fire some serial commands to devices is alot easier. ELK writing an interface to the PLM is not the same thing as someone writing a full application for link managemant like the ISY...that takes a strong programmer.

SteveL

 

[xlurkr]

The developer side of the conversation should be held on the developer forum.

I'm glad it's taking place here. I'm not a developer, so I don't have access to those forums. I do rely on the programs and utilities these small developers write, so I'm very interested in hearing about their frustrations and SH's solutions, if any, for them. I'm an end user, but one who wishes to have a healthy "ecosystem" for the platforms I buy into, to coin an iphrase. I don't think I'm alone. I hope SH understands this.

-Tom

 

[jhdale]

Many of the people who are on the developers' forum have a financial interest in not having other people figure things out. I have yet to hear anyone say they got all the information they needed from the forum. Instead I see everyone reinventing the wheel. If there's an SDK why are people writing low-level serial code at all? Because no one who has gone through the trouble has been willing to share their work and give a boost to potential competitors. (Or, of course, Smarthome could have just written a DLL and saved everyone the trouble. They've already done the work themselves for Houselinc 2.)

I'm very interested in getting a community of programmers working together but I think it has to happen outside the closed world that is currently strangling any attempt at sharing.


As for relative ease, there are lots of design choices that would have made the PLM easier to code for. For example, the messages sent by the PLM to the computer are of variable length and have no consistent terminator. That means you can't parse them into meaningful chunks without going to the trouble of interpreting them. But with reception and use of the data happening in different threads in VB.Net, that's inefficient at best.

I don't really know about link management, since it's been irrelevant to my design goals, but my impression so far is that the main difficulty there is the quality of the documentation, more than any real difficulty in the task itself.

 

[Mr Spock]

I called SM today. It seems the 7 year warranty is only valid on SOME switches!

Mine were purchased in 2004, they are x10 only predating the ICON and Insteon support. They are NOT covered under the extended warranty. If the microswitches fail (as mine are starting to do) you are screwed. Obviously I'm really pissed off right now. I installed these 2384W switches throughout my house (~25). Three have failed and a couple more are starting to fail.

I'm going to complain on every message board I can find. They have lost a customer for life.

Does anyone know where to find replacement microswitch parts?

 

[Digger]

I called SM today. It seems the 7 year warranty is only valid on SOME switches!

Mine were purchased in 2004, they are x10 only predating the ICON and Insteon support. They are NOT covered under the extended warranty. If the microswitches fail (as mine are starting to do) you are screwed. Obviously I'm really pissed off right now. I installed these 2384W switches throughout my house (~25). Three have failed and a couple more are starting to fail.

I'm going to complain on every message board I can find. They have lost a customer for life.

Does anyone know where to find replacement microswitch parts?

I have the ones that fit the Insteon switches. Not sure if they are the same. I dumped Insteon so I dont need them anymore. If you PM me your address I will mail you a bunch. No charge (I know how it feels to be screwed by SH). If they work in the older switches great. If they don't try some other forums if nobody here knows the exact switch.

 

[Mr Spock]

Thanks Digger I sent you a PM, yet it does not show up in my PM sent items list...

Let me take of my switches apart and see what kind of micro switch is in there. I'll get back to you on your generous offer. I'll pay shipping.

 

[Digger]

Thanks Digger I sent you a PM, yet it does not show up in my PM sent items list...

Let me take of my switches apart and see what kind of micro switch is in there. I'll get back to you on your generous offer. I'll pay shipping.

I got the PM. Dont worry about the shipping. I ship stuff all of the time for my business and this will cost practically nothing. Just hate to see you suffer what I went through. If SH refuses to do the right thing for you I will try. Obviously the tact switch problem is wider than SH cares to admit even though it was documented in the X-10 devices before the Insteon devices if I remember correctly from when I first researched it in regards to Insteon. I was amazed how they kept denying it existence for almost a year when I pointed out it was even in their X-10 devices (they denied that to).

SH will never learn.

 

[jhdale]

Going back to earlier topics in this thread, personally my only i1 device is a ControlLinc, but it's worth noting that it shipped from SmartHome sometime between October and December of 2008. Oh, and the PLC of course, I assume those are still i1 since they haven't been updated. I don't know if any other i1 devices are still being sold.

If you can send Insteon commands to your devices, it's easy to determine whether a device is i1 or i2. Send a "Get INSTEON Engine Version" command (command1 = 0x0D, command2 = 0x00). The response will be in command2 of the ACK message. 0x00 = i1, 0x01 = i2.