Krusty66

Since ISY994 are sunsetting, I'm considering migrating to EISY. One thing I can't find info on is...does a migration bring everything that was on the 994 over to the EISY? I have many hundreds of lines of "If/then" code that I don't want to have to replicate. It only makes sense that it would transfer in a migration, but I just don't see confirmation of that anywhere.

Since some time has passed and more testing has been done...I stuck an X10 filter on each blade at the box to combat the noise that was coming from outside the house. It appears to be working as I haven't really noticed any flickering. But tough to tell. The outside noise seemed to happen mostly in the day time and the room where all these insteon switches are is still incomplete. Until the room is finished and we spend time in it, I won't know for sure. That all said, I'm not sure there's much of a solution other than what I've already done.

One thing I can say with certainty is that every time the Air Conditioning kicks on, the lights in the entire house sag a little momentarily. It's been doing that for the 17 years we've lived here. I can try some of those other tests.

Just to close out my saga (unsuccessfully, I'm afraid): After thinking the FilterLincs would solve the problem, I spent a few days observing things for many, many hours. It seems the problem is not only coming from devices inside the house, but its clearly also coming from outside the house (the power supply from the street). Simple experiment to prove that: turned off every breaker in the house except one. That one is new construction where there is nothing on the circuit except two Insteon dimmer paddles and two banks of lights that they control. Absolutely nothing else in play. Sure enough, the flicker happens. Sometimes pretty intense, other times not so much. But its there and its way too frequent and annoying to live with. This suggestion was made earlier: "As an experiment you could try adding a temporary piece of NMD 14/2 cable onto the end of the circuit (hanging in the air or on the floor) to see if you can change the tuning of this circuit. Alternatively plug in a heavy load on a receptacle in the same circuit and see if you can change the whole dynamic." Since it's not any particular circuit, I'm not sure there's anything left to try - other than another brand of dimmer.

My E.E. is obviously a complete bozo as evidenced by his nonsense response about stamps, or whatever the hell he's talking about. What you're suggesting here in terms of testing for a tuned circuit is exactly what I was looking for. The problem has gone away using the filterlincs, but there's obviously something different with those of us that have this issue and those that don't. Your explanation may be the answer, or at least part of it.

I originally thought FilterLincs were the Leonard Cohen of Insteon products. In that they were ridiculously over-rated one-trick-ponies. But I was wrong. And I think on that note we wrap up this thread.

Drum roll please...Two FilterLinc devices arrived here an hour ago and I've been testing with them since then. They will indeed solve this problem. I put my entire A/V system on one and my entire Telecom closet on the other. Then killed the known culprit in the kitchen (the 24v supply for LED lighting), and absolutely no flickering at all. So there's the answer. Much thanks to everyone that chimed in. I hope this helps future users.

Yes, it could be something other than wall warts, or any other device and perhaps a wiring issue. That was point exactly. I was looking for the possibility that there is something specific to my wiring or electrical service and if that was the case, what could be done about that at a macro, rather than micro, level. If there is something about the wiring and the electrical service at the 3 houses that had no issues, vs. my house, I'd sure like to know what it is.

Unfortunately, its not just a matter of finding one culprit. I can see there are at least 5 different culprits. And there might be more, and every time I bring a new device into the house I have look out for that, too. I can filter the heck out of everything and hopefully it'll work. It seems that this issue should be present in the vast majority of applications. My house is 2000 sf with just two adults. I don't have kids (with their dozens of devices) or a large house (which would equal more potential culprits). It would seem that virtually everyone should have this problem. Who doesn't have a million wall wart adapters and power supplies all over their house these days? So I can't help but wonder why my E.E. friend has done massive Insteon installations in 3 different houses now, has never had this issue. He doesn't have filterlincs all over the place and he has many, many paddle dimmers. It sounds like there is some other variable in play, but I don't know what it could be.

Great info from everyone. I can't just switch to z wave at this point, but I will try the filters this week. It is more than a bit disappointing that Insteon has a formula for a circuit that is not susceptible to this problem (in the lamplinc and togglelinc units), but hasn't bothered to fix the issue in the keypad and paddle dimmers. Making it all the more annoying is that those latter units are more expensive and more difficult to install (than the lamplinc). You make a much bigger commitment to them (in money, and more importantly, time), just to find out they're inferior. I'm also a bit surprised this issue isn't documented or mentioned anywhere. Look it up on this forum or in any product reviews and you won't find it anywhere (until now).

Replace all what noisemakers? My TV? My refrigerator? Everything with a power supply or transformer? What, in your experience, are the noise makers?

I'll start by saying that I have a lot of experience with Insteon products and have been running them via ISY in my house for several years. The issue I'm now having has been observed by an electrician and an Electrical Engineer. The E.E. also uses an ISY/Insteon setup in his house and has hundreds of insteon devices, including the ones I'll mention, in use. Nobody has any explanation other than what I'll put forward - First, my system uses the ISY 994i with the PLM and I have dozens of insteon devices and some pretty simple programs running (turn on lights at dusk, turn on a light if Motion sensor is tripped, etc.). I use many of the insteon Plug In Lamp Dimmers (2457), Plug-in On/off (2634, 2635), many of the mini-remotes (2432), a few motion sensors, some of the bulbs (2672), a couple Toggle Dimmers (2466). I have never had any sort of issue like what I will describe here: I installed a 2334-222 Keypad Dimmer switch in my bedroom. It controls nothing but a single incandescent bulb overhead. Shortly after installing, I noticed that the bulb in question had some flicker going on. In short, it was a randomly timed, quick duration flicker and it appears that its not just an attenuation of the power. It's as though there is a surge sometimes (making the light brighter than normal) along with a trough (making light dimmer), then a return to normal. Sometimes just a trough, sometimes just a surge, sometimes both. Always in a split second and always returning the light back to normal. It could happen a few times in 10 seconds, or it could go a minute without happening. But rest assured, over a 5 minute period, it would happen several, or many, times. Went thru all the normal procedures to address such a problem and the flicker would not stop. Eventually yanked the switch and went back to the passive cheapo switch that was in there before. Flicker went away, just like it had been for the 17 years I've lived here. Chalked it up to a bad insteon switch. New part of the house - installed a 2477D Paddle Dimmer for my back patio (4 bulbs). Again with the flicker. Much testing, much observation, no solution. Could not stop the flicker. Now the biggie - doing a massive renovation on the basement and already had purchased several paddle dimmers (2477) to control 4 separate banks of ceiling lights. This is brand new wiring, direct from the breaker box 6 feet away. My house is old (1949), but this is all brand new equipment (can lights, wiring, circuit breakers, etc.). Long story short - exact same flicker problem as seen in bedroom and patio. Like I said, my electrician and E.E. were both stumped. I, too, was stumped. So here's what I did to analyze it, and bear in mind this took many, many hours and I am still in process. I've got at least 10 to 12 hours in this so far...I turned off every breaker in the box except one in the basement with a bank of lights and a 2477 dimmer paddle controlling them. There is nothing else on the circuit. In this state, no flickering. That is, the circuit by itself, with nothing else in the house powered up, does not produce the flicker. I then brought up other circuits in the house one at a time then watched for flicker. Brought up the bedroom circuit, sat and watched for the basement lights to start flickering...nothing. All clear, so bring up another circuit. Turned on the dining room circuit, sat and watched for flickering...nothing. And on and on until I bring up a circuit and observe the return of the flicker. And sure enough, the kitchen (by itself) and the living room (by itself) being on at the breaker will cause the flickering on my circuit in the basement. Let me re-iterate to be clear - I can take down every single breaker in the house except the one with my basement lights and there will be no flicker on those basement lights. If I then turn on my kitchen breaker, the basement light flicker happens. Ditto the living room breaker. When those two are shut down, I can turn on every other breaker in the house and the flicker still does not happen. So clearly we have a situation where (at least) one device in each of the two offending circuits (kitchen and Living room) is causing some kind of havoc with the electricity in the entire house. And whatever that havoc is, insteon paddle and keypad dimmers are sensitive to it and cause a flicker to happen on the bulbs to which they are carrying power. The flicker can even be seen on the dimmers themselves (the LED lights and lit buttons will flicker in unison with the lights). That said, the other devices (plug in dimmers and toggle dimmers) are not sensitive to this issue. Again, I have been using those latter devices for years and have never seen any kind of flicker. The paddle and keypad dimmers take one minute of observation and the flicker is clearly there and enough to drive one insane. Continuing my process, I've observed that when I remove certain devices from the offending circuits, the problems decrease. The first one was a 24 volt power supply for some LED light strips in the kitchen. Just to be clear again, took down the entire house except basement lights and kitchen, observed flicker happening, removed 24v power supply, flicker stops. Now, I wish I could say that its just that device, but we already know there are more in the living room. That, of course, contains A/V equipment, telecom stuff, fish tanks, UPS battery backup devices, you name it. Surely many of these devices are part of this problem. And it is clear that there is a cumulative effect. That is, when the whole house is up and running, the flicker is more frequent and more violent. As I remove devices, things get better. But as of now, until I remove almost every damn thing in that living room, the problem is intolerable. My E.E. tells me that it certainly sounds like I've tracked down the problem and it seems reasonable that cheap Chinese devices like these could be causing the havoc. What I'd like to know from the forum is - 1) has anyone observed this problem?, 2) why do only the keypad and paddle dimmers do this?. They are obviously using some different (and inferior) circuitry to the plug in modules, and 3) is there a solution? My E.E. suggests using some FilterLinc devices, which I have ordered and will try.

The lengthy "system busy" only happens when I execute code with the "adjust scene" function in it. And it does it over and over again every time I do anything with "adjust scene". I've just bailed out on trying to use it. I'll created separate scenes with their own dim levels, or I'll just write code to control the dim level (at different times) for each light. Whatever "adjust scene" is doing, it isn't worth the problems that come with it. Thanks for the help.

Forgive my lack of knowledge, but I'm not quite following that. The remotes are already part of the scene. That is, ButtonA on Remote1 controls SceneA (left side of button turns SceneA off, right side turns it on 100%, or hold either button to dim up/down). When you say "if you won't be using the mini remotes after I adjust the scene...", well, I will. I need them to be able to turn the lights (scene) on/off/up/down as desired. In other words, the program kicks on at 8pm turning the scene on (80% Light1, 50% Light2). At 11pm it turns them down to 60% and 40%. If I decide between 8pm and 11pm that I want some different levels, I use the remote to change them.

OK, I added a line to turn on the scene and it works - sort of. The code does execute (the lights change to 80% and 50% as written). But it still goes into this long painful (like 2 minute) system busy mode. Apparently its trying to write to the two mini-remotes that are part of the scene. I can see that by looking at the Main page. Then, if I have another subsequent program (lets say at 11pm I now want the lights at 60% and 40%), it fails. I have tried it with and without the new code you suggested (turning the scene on before specifying each item in the scene). The scene is already turned on (from the previous program at 8pm) so it would not seem necessary to turn it on again. But either way (turn the scene on again, or don't), this new program fails. BTW, If I write separate programs to set each light where I want them, instead of using "adjust scene", the :"system busy" does not happen. Is the "adjust scene" just a bad way of doing this? If so, why does it exist?

Example: I have SceneA with Light1 and Light2 in it. I write code such that I use the "Adjust Scene" function to turn on Light1 to 80% and Light2 to 50% at X time of day: If time is 8pm then in scene "SceneA", Light1 80% (on level) in scene "SceneA", Light2 50% (on level) That code comes from using (in the Actions box), Adjust Scene, In Scene, Set. This worked fine when I first test it and set it up. Then after a couple days its gone dead. As soon as its time to execute (by time, or by me manually triggering the Then), I get the "system busy" warning box. It starts counting slowly upward toward 100%, but never gets there and never executes the Then. Why did it work briefly and why won't it work now?

OK, 3AM was randomly selected by me in my example but has nothing to do with the coincidental 3AM module query. Much as Paul Simon (Wednesday Morning, 3AM) and Matchbox 20 (3AM and it Must Be Raining) made the same random time selection. There is no connection. Teken, I was excited that the tech document might lead me to a fix. So the capability is there, but there is no way to do it from here as an end-user? I use an ISY-994i.

Gary and Larry, I'm not sure what your comments mean about "Funny it happened at 3am" and "Microwave was blinking". There's either a joke there I'm not getting or your not following what I'm saying. I live in a place where power goes out frequently. It doesn't go out for hours at a time. We just get a lot of "brownouts" or quick blips. Most often its during the night and early morning. Old neighborhood, power on poles (not underground), lots of lightning. Usually you wouldn't know it happened, but the telltale sign is always the clock on the VCR or whatever blinking "12:00". The quick power outage reset the clock. My Insteon bulbs are not on sockets with a switch. But you can test my observation by doing that. Set one up properly (with continuous power to it), then cut power (via switch or lamp toggle or circuit breaker), then put power back on. The light will them come back in the ON position. 100% ON. Like blinding, eye burning, Close Encounters of the Third Kind bright light in your face while you're trying to sleep. Thanks for the comments from others about the Insteon Bulbs having options for changing the setting in this power outage situation. I will attempt to use the software to make it happen.

I've got a few of the Insteon LED light bulbs. I've discovered what I believe is a fatal flaw in them that renders them useless. Maybe there's a workaround, but here's what happens: The bulbs are to be placed where power is constant to them. So don't put them in a socket controlled by a switch, for instance. OK, not a problem. So I've got them in various locations in the house including the bedroom, where its pretty nice to have lights that can be dimmed to a real low level or brightened to extremely high levels - all with the control of a mini-remote. Or so I thought until 3am one night when we had a momentary power blip. You know - the kind that happens so fast you'd' never even notice it, but in the morning you find your microwave clock blinking? Well, that 3am incident was a great time for me to discover that Insteon bulbs, regardless of what their current on/off/dim status is, will set themselves to 100%-full-bright-On when power to them is interrupted like this. How nice it was to have the equivalent of 100 watts blaring in my face at 3am. Ditto that in 3 other locations in and around the house. So I pose the question - is there a way to make it revert to its former state (before the power outage)? Or better yet, just set itself to Off rather than On? I live in an old neighborhood and in a place where lightning is common year round and in the middle of the night. I don't need the threat of 100 watts waking me up every time there's a storm or somebody crashes into a utility pole.

I added the remotes to a "scene" and sure enough that works. I must say, though, that I cannot find any practical reason that the dimmer should not relay the message that it has been turned on by the remote. It does so when turned on by human finger, yet does not when using a remote. In the real world, the point of a remote is to keep us humans from having to get up and physically walk over to a device. The remote was to do exactly what the now seated human formerly had to get up and do by hand. It is clearly not intuitive, and illogical as well, to think that the Insteon remote does not perform the same function that a human finger would. But clearly it was designed this way. I understand that this product is for gearheads and will never be usable by the masses. But this kind of logic, or lack thereof, is even frustrating someone like me that has gotten deep into this type of product many times before. I have a few other beefs that I will post under appropriate headings. Let's see if you all can explain those away too. Thanks for the help in solving the problem. It is greatly appreciated since no amount of reasoning would have ever lead me there myself. My next topic - Insteon Light Bulbs, why do they turn on by themselves?

I'll try the scene suggestions here, but I still have to say that its really strange that this is necessary. Think about this - if I reach over with my hand and click the up button on my dimmer, the light on the dimmer turns green and its recognized immediately as being "on" in the Admin Console. If I click on my remote to accomplish same, the light on the dimmer turns green, but the Console recognizes nothing. I have a fair knowledge of electronics and all I can say is, if the green light comes on the dimmer, regardless of how I made it turn green, the downstream results should be the same. The dimmer knows to tell the Console it has been flipped on when I use my finger. But it doesn't do same when I use the remote. That's a design flaw.

I guess I'm confused because I don't really use scenes for anything. So I'm not sure why I need them for this. I control everything with programs. Simple example - I program LightA to come on every night at 7pm and turn off at 11pm. I only use the remote if I want the light to turn on or off at different times, or if I want to change the dim level. I know how scenes work and are constructed, but I don't need them for anything. And I'm not clear on how I would use them in my simple example. I know I could set up a scene where LightA is on, and another scene where LightA is off, and I could make the remote the mechanism for toggling between those two scenes. But then I lose my ability to use the remote as a dimmer. The whole use of scenes seems like overkill for what I'm doing. If the Console can recognize that the remote has been toggled on or off, why can't it recognize that the dimmer unit itself has also been toggled? Again, I can query and get the right answer, but the Console won't query on its own apparently.

The remote is manually connected to the dimmer via the brief instructions in the manual for the dimmer and the remote. That is, you click a button on the dimmer, then click a button on the remote, then hold down the other button on the remote, then push the set button on the dimmer, etc. Whatever that process is. But it is all done outside of the Admin console.

In response to Techman, the remote is linked and does indeed show the current status of it's buttons in the Admin Console. It's crazy - it shows the buttons turning on and off, but it won't show the lights (dimmer units) turning on and off. As to putting everything into a scene, I'm not sure I understand that. I understand having lights in a scene and making the scene control what they do. But I don't understand how a remote would be part of a scene.

Its not Windows or anything to do with refresh. It just plain does not react to anything that happens as a result of using a remote. I just shut down my Console session and restarted. It is still confused about the status of the lights in question - even after the restart. It thinks some are on that are actually off and vice versa. Again, only lights that were switched on or off using the mini remote. I can also prove that it doesn't know that status because I've written code to see if it will react correctly. It won't. It treats the status (for purposes of the program or code) as whatever it shows in the console. It does not know the real status of the devices. That's how I discovered the problem in the first place.