I'm impressed with the concept and, so far, with the execution but am still leery because SmartHome has such a poor track record. I also do not have problems with X-10 but do understand that others would probably prefer something that is more reliable (in their view) and easier to install so I hope that Insteon will succeed. The prices are attractive.
It now looks like they are well on their way to turning a silk purse into just another sow's ear.
There are numerous complaints that center on two issues. One is with units that flicker on and off, in some cases shortening bulb life. The only explanation I've seen doesn't appear to address the various reported scenarios (although it may be that some reports are related to user inexperience or ineptitude).
The second major complaint is that there is little to no useful software available. I think this is directly related to their inane license restrictions (as well as to the underlying SALad language).
While I've only recommended that those who are new to HA should investigate Insteon, I now feel I have to recommend waiting until these issues are resolved.
You might want to review this long thread on Smarthome's Insteon forum...
I just read through the thread and it's pretty amazing. SmartLabs must know what the problem is - they stopped asked for samples of modules that exhibit the problem at the end of May.
It's pretty hard to reconcile the reports, including those that claim that Insteon even makes hard-wired Lutron dimmers flicker. When someone says "The issue I have is that when I hit one Insteon switch, the lights on another Insteon switch flicker for a brief moment" you have to wonder whether it's one or two faulty switches or whether all of them are bad. It won't bode well for Insteon if they have to keep replacing equipment wholesale. I wonder how much of a recall they can absorb without endangering their corporate viability?
And finally: "the issue does appear to be one when one particular SwitchLinc unit sends out a dim command. The light it control dims correctly, but a totally different SwitchLinc unit that was not a target of the dim command flickers" which seems to indicate that the problem is not just with the defective(?) switches. It seems to point to a defect that apparently can propagate through the system as well. Ouch.
The thread makes it clear that you're not the only one losing confidence in Insteon. A number of folks who've sunk a lot of money into Insteon have indicated their unhappiness. One poster said that it was no better, in the long run, than with the X-10 he had in his house to start with.
While SmartLabs is encouraging people to buy the current (and one assumes uncorrected) switches, another Dave (Walters) added this succinct comment towards the end of the thread:
"If we buy now, will you come to our homes and re-install the new (working) replacements in the future?"
As for trying to reconcile the reports, that's what I was alluding to when I said some reports may be due to user inexperience or ineptitude. However, there have been reports from someone who is neither inexperienced nor inept that some X-10 dimmers are flickering during Insteon events. I think the most likely culprit is excessive triac noise getting to the mains from the Insteon dimmers. That could also explain the Lutron dimmer report.
It really seems improbable that Insteon, X-10 & Lutron devices would all flicker in some reaction to the low level Insteon control signals.
Since Insteon starts sending data BEFORE the actual zero crossing, I suspect that dimmers using the zero crossing as a time reference may be confused by the Insteon signal. That would cause the triac phase to be modulated by how early that erroneous zero crossing is detected. At full intensity, the triac should be triggered right after the real zero crossing. If the Insteon signal causes the triac to be turned on early, it would switch off at the real zero crossing, and miss conduction for the next half cycle. Similarly, dimmed lights would change intensity in response to any shifting trigger phase delay.
Since X10 sends its data after the zero crossing, dimmers that use zero crossing as a time reference would be unaffected by X10 data.
There are reports of dimmers made by other manufacturers being effected, so this may be a nasty problem to resolve.
There are a few points that really confuse the issue.
Some have reported flickering while others have indicated the lights flash full on/off, even wiping out bulbs.
Some have reported experiencing it only when some Insteon device is at a certain level.
Some Insteon devices (in the same installation) are affected while others are not. Similarly, some X-10 devices (in the same installation) are affected while others are not.
Triac noise should be present during each half cycle (You can see it on a scope from all of the X-10 dimmers that are active.) but this phenomena seems to occur only when Insteon control signals are being sent.
Insteon control signals have about the same amplitude as X-10 control signals. They are at 131.65kHz. If they were the cause, I would think that all X-10 lamp modules and switches would have been affected from Day 1. The problem is also affecting some Insteon units which should not be confused by any early phantom zero crossing (even if set for X-10).
There are chokes in all X-10 dimmers that attenuate the triac noise. It appears there are similar chokes in Insteon dimmers (at least in the one LampLinc V2 that I opened).
Perhaps there's a path being opened during the Insteon signal transmission that allows triac noise onto the mains.
The transmitters in controllers that send the Insteon signals have no triacs but all of the Insteon units are two way and both repeat Insteon control messages as well as send acknowledgements.
I would really like to see oscilloscope screenshots of the mains in a system where this is occuring.
Smarthome says it's due to a faulty comp>Since Insteon starts sending data BEFORE the actual zero crossing, I suspect
I think they're being truthful, if only because they suddenly lost interest in examining any more defective units that customers offered to send in. I have a feeling that their fix is going to fix some, but not all, of the reported problems because, as you pointed out, the symptoms vary so wildly from installation to installation.
As you also pointed out we're limited in what we can deduce without more details. It will be interesting to see how they handle this. I'd like to know what percent of their user base is affected. I would hazard a guess that they are also being truthful in stating this is not a common problem, or else it would have likely shown up during the beta test.
Also, how can a defective switch "blow" a normal bulb? Sounds a little "off" to me. Bulbs should only do that if presented with a voltage way over their rating. I suspect miswiring, perhaps bad enough to feed 240 into a
120VAC device, at least in the blown bulb reports.
The reports of flickering go back at least a year. At that time someone with Smarthome said it was caused by defective triacs. Now, someone from Smarthome is saying it is caused by a choke.
To kick Jeff's idea around a bit. The Insteon signal starts 800µS before ZC which is approximately 10% of the time it takes for 1/2 cycle. I'm not sure of the maximum amplitude of the Insteon signal. The specs give a minimum figure (3.16Vpp). On my scope it appears to be about 3Vpp (but that may be distorted by the ACT ScopeTest-2 I was using). If it's symmetrical about 0V this means the negative peak is about 1.5V. I haven't done the trig but the point where the line voltage drops below 1.5V is awfully close to ZC. While the Insteon signal might cause a premature turn-off, I really doubt that anyone would perceive a flicker. It would just increase the off time slightly. The lamp would turn on again at the point past the ZC called for by the dim setting. I don't know how the Insteon electronics detect ZC but doubt whether a 1.5V amplitude would be detected.
If non-Insteon devices are being affected by such a low amplitude signal so near ZC (I've seen reports of Lutrom dimmers and Leviton X-10 dimmers flickering when Insteon signals are being sent) it would seem they would also react to triac noise from other dimmers which is much higher in amplitude. Even if their triacs are turning off in reaction to a false ZC, they would (by Jeff's reasoning) turn on either at the normal point or turn on and off at twice the Insteon 131.65kHz rate.
I th>Since Insteon starts sending data BEFORE the actual zero crossing, I suspect
Dave, what I was trying to describe was a scenario that could cause the triac to be off for the entire next half cycle, or 8.3 mS. We know that at full intensity the triac is triggered just after the zero crossing, and it continues to conduct until the end of that half cycle. If the Insteon signal causes the trigger circuitry to think the zero crossing has just passed, it might trigger the triac before the actual zero crossing. In that case the triac would immediately turn off, and miss conduction for the entire next half cycle.
While I am not saying this is the case, it is certainly a possibility to consider. If I could obtain one of the dimmers susceptible to this phenomena, I may be able to simulate it here running a triggered 130KHz burst from a Wavetek through the XTB.
I understood what you were describing. I just don't think that would happen. Normally, I would expect that the earliest the triac is triggered (full bright) would be just after the Insteon control signal ends at ZC+1023µS.
If it were switched off early, the electronics should still detect ZC (and maybe detect 232 of them caused by the control signal before true ZC). I think it likely the triac will be triggered on at the normal point after the true ZC.
Do you think that it's flickering the same, small amount when brighter but that it's less noticeable as the lamp brightens?
In filmmaking, the human flicker fusion threshold seems to be around 16 hertz (Hz) although most movies are recorded at 24 frames per second, and TV with PAL and NTSC even faster. Motion seems continuous at 25 or 30 fps but brightness deltas may still be noticeable. People can reliably detect much faster flicker rates indirectly by various stroboscopic effects like the ghost image of a airplane propeller slowly moving superimposed over the blur of the rotating blades or wagon wheels seeming to rotate slowly backwards.
Anyway, the point of all that was to posit that the Insteon lights are likely to be flickering at < 25 time per second to be detectable by the human eye.
In one of the threads you cited previously, a "dbaustin" said: "For me, the problem is only on loads over 240 watts, which is about 8 out of 80 devices. However, it is a problem for 100% of my house since these 8 loads provide the primary lighting and they all blink if dimmed with every bit of Insteon traffic."
It sounds very much like the Insteon signal itself is being rendered "visible" almost the way the battery LED on a boombox dims as very loud bass passages play. I recall having a CRT that would flutter in time to loud bass played using a receiver on the same circuit as the CRT.
"Dbaustin" reported something that others have reported as well: that this problem appears to be related to running the switches at full load.
When an "We have found a field fix that is simple to apply to a problematic dimmer that has "mild" flickering. There are some varying opinions as to whether we should offer this kit. I believe SmartLabsMike would like to hear some thoughts from the community."
formatting link
I just hope someone takes some photos of the modules before Insteon swaps the troublesome units so we can know for sure what's been changed.
I've had bad runs of bulbs that have blown switches when they popped. Some detached from the screw base completely. Do you still have the LM14A? Did you inspect it internally for blown components? I just had a bad batch of bulbs (4 to be exact - from a four pack). Not only did they blow, but they killed the local (but oddly enough not the remote) control of the wall switch twice in a row before I realized it was the bulbs.
Getting back to blowing bulbs, I thought a triac only "chops" the existing waveform? So, how does it burn it out? The dimming flash? I can flick a manual light switch on and off all day without cashiering a bulb. Is there something different about the way a lamp module switches that presents a different inrush current scenario than a mechanical click switch?
I was just wondering whether you got part of the same bad batch of bulbs that I did and they partially blew your LM14A. Then, the rest of the bad bulbs burned out prematurely (or spectacularly, as mine did) and threw "suspicion" on the LM14A. My security system flashes the house lights from full on to full off and those bulbs don't explode or seem to burn out very much faster than bulbs that aren't on the flash circuit. I'll bet I could rig a test with either an appliance or lamp module and count the number of cycles until failure pretty simply.
I'm not doubting that you lost a string of light bulbs, I'd just like to understand how that's electrically possible without there being a huge surge on the whole house line or some overvoltage getting to the filament.
Again, not trying to be a prick, just trying to understand *how* an X-10 switch can blow a light bulb. It's always been the other way around for me - a bulb "pops" and takes the *switch* with it. As far as I know (and that's not very far!) filaments fail due to fatigue from the constant thermal cycling causing plastic deformation of the hot filament each cycle. I seem to recall that's normally hundreds of cycles if not thousands, although I've yet to find a specific claim as to number of cycles. I did find this, however, from a list of light bulb tips:
Light bulbs Sometimes Get Brighter When Something Else is Turned On and also Burn Out at an Excessive Rate:
a) This usually means that you have a broken or poor neutral connection, usually in the main panel, or sometimes in a sub-panel if you have any sub-panels. Be sure that screws holding down wires in your fuse boxes / breaker boxes / panels are adequately tight. If you are not up to this fix or it fails to correct this situation, call an electrician. This is a dangerous condition that must be fixed urgently.
formatting link
While I obviously don't think this is the case with your LM14A, I can easily see it being the problem Insteon's facing, at least with some of the lamp failure problems. We've seen, time and time again right here in CHA, that when faced with a lack of a neutral at the switch, people become incredibly creative in finding ways to get a neutral to that location. Lots of times, it's via some very, very dubious wiring practices. If you pulled a neutral to an Insteon switch that wasn't properly bonded at the panel, it might cause some serious issues. I suspect that it's the cause of at least *some* of the trouble reports.
The TRIAC snubber circuitry typically consists in an resistor-capacitor (RC) network but is sometimes an inductor ("choke"). Most dimmers using these semiconductors do have output chokes to reduce the noise. Architectural grade dimmers often have chokes 100 times larger than residential dimmers.
All three models of INSTEON wall dimmers I have looked at have output inductors. In general, series inductors decrease the rate of voltage change (dv/dt) but _increase_ the magnitude and time duration of line transients caused by TRIAC or back-to-back SCR's.
Choke inductance and saturation current depend on the geometry and composition of the core as well as wire gauge and number of turns. The size and number of turns is easy to inspect/verify, but the inductor core composition is not. So if an off-spec core was used by a fabricator, it might not be detected until the dimmers started to cause problems in marginal situations.
FWIW, I've encountered no noise or flicker problems with INSTEON (n = ~16), but my large loads are controlled by a dimmer panel in the basement with donut-sized filters/inductors. One of the several benefits of switching from X10 WS467 to INSTEON ICON dimmers has been to eliminate the buzz in my main audio system caused by a nearby X10 dimmer.
I don't think it is a "small" flicker. Some people are losing bulbs.
I was taking the humanoid perception threshold into consideration when I wrote that I thought it would require rather large anomolies to cause perceptible flicker.
You need to read that Insteon forum carefully (and maybe also read the AccessHA thread some have referenced). I think the "SmarthomeJohn" comment is from the other thread and is a year old.
The load caused by the modules repeat>> the flicker occurs. This would put the triac switch-on point well past the >> ZC.
One of the sites I looked at mentioned that brightness changes are much more detectable than motion changes, ostensibly because of the larger number of receptors involved. It would be nice to have more information about the nature of the flicker because it's so subjective an issue and the reports range from mild flickering to full blown flashing. There's not enough detail in the reports to form an accurate conclusion as to actual intensity of at least the low level flickering. At least not that I can see.
I read it over pretty carefully as I've been discussing it off-line with another CHA'er. There seem to be at least two problems people are describing and it's not clear whether they are intimately related to each other. I think the people with the big flashes are experiencing a problem perhaps only marginally related to the flicker issue. I still suspect those folks are experiencing issues related to bad neutrals. It will become apparent if I am right or wrong if those flashing reports persist after the fix but the flickering reports fade.
Respectfully disagree, sir! I recall I had to look hard for a date on the messages and at first only saw the word "Today" without reference to a year. It seems that the board's designers believe that the day a poster joined was the most important number to place on the message header. Look again. It's easy to be confused by how they do things in their HTML but with a straight text copy it shows clearly that SmarthomeJohn's post had a message date of May 20, 2006 but a join date featured more prominently that says July 2005:
formatting link
*********************************************************
05-20-2006, 07:17 PM SmarthomeJohn Registered User Join Date: Jul 2005 Location: Anaheim, CA Posts: 72
The component is the choke coil. We found that the repeated Insteon signals generated by the dimmer was getting into the traic and causing the flicker. Basically, we are upping the value to attenuate the Insteon signals that go into the triac.
We are using this new part on the ToggleLinc Dimmers now in production and it should appear in SL V2 Dimmers and ICON models by probably this July (no promises!).
We looked for an easy field fix for this, but couldn't find anything that worked well or didn't mess with common electrical codes.
Disclaimer: don't use this information to figure out a fix for yourself. Things could catch fire or kill you and that is a bad thing.
In fact the last post their was registered a few days ago:
06-22-2006, 08:05 PM Redoubt Registered User Join Date: Jan 2006 Posts: 37
Its been a month since the last update. Are the replacement dimmers still on track for july?
I have several I still need to replace!
************************************************
I realize the large delta, but when the system's strained, it could be that there's some effect that goes unnoticed normally, but might be caused by all transmitters becoming active at once. Where is the noise that the chokes apparently are choking on coming from? SmarthomeJohn says "We found that the *repeated* Insteon signals generated by the dimmer was getting into the traic and causing the flicker." That seems to implicate the repeating circuitry in the unit.
It's easy for me to believe, at least, that their desire to make the switch as small as they could led to the selection of some undersized components that a more conservative (and very likely much larger design) would have avoided. Is it possible that the choke heats up too much inside the small switch body under large loads and fails to perform properly?
It's all speculation, though. The nice part is that eventually, the truth will be known!
The person who first referenced it said it was a "year old thread". When I looked, I saw a year old date and so took it to be older than it is. The actual date of a post doesn't jump right out.
However, in one post "SmarthomeJohn" says they found it was the triac while in another he says they found it was the choke. I would reserve judgement.
Anyways, I got my latest roZetta boards so I'll be busy with that and will not have time for much else.
Nor am I unless it is the choke and high amplitude triac switching transients are getting to the powerline. I think Lutron dimmers are susceptible to this - it may be why Lutron sells inline chokes for it. The report about Leviton made X-10 dimmers flickering came from a reliable source who posts here frequently while I think some of those reporting in the other forums qualify as "usual suspects". ;)
I wonder whether anyone with both Insteon and UPB has seen a problem when sending UPB which deliberately puts high amplitude transients on the line?
Yes, the actual date of the post seems to be a secondary data item (although not to me!) and I really believe that when I went there the first time the only date showing *was* the poster's "join date." Maybe if someone enters the thread from a URL cite and not from the top of the forum some date var doesn't init properly.
Ah, yes, his credibility gap. :-) To be precise, he blamed the "traic" and made some other comments that led me to believe he was *not* a part of either the design team or the debugging team. Perhaps prepending "Smart" to someone's name doesn't necessarily make it so! I'm assuming, based on flimsy data to be sure, that he meant "noise is leaking into the "traic" because of a bad choke."
My vote is for bad choke because that's an explanation consistent with enough garbage on the powerline to effect other manufacturer's dmmers. The potential for HA gear to interfere with old-style dimmers has been noticed, on occasion, with X-10, specifically with the CM11A. I don't recall if a probable cause was determined, though, other than "noise on the line."
The differences in the behaviors reported (flickering, blinking and flashing) for the SwitchLinc V2's might have to do with whether the choke has failed completely.
Yes. Get back to that grindstone and grind!
"Keep thinking Butch, that's what you're good at!" :-)
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.