mwester

Two of mine are approaching that limit, that'd be disappointing indeed. I guess I'll find out...

Yes, all powered devices act as repeaters, but that doesn't mean that the routing selected by the "heal" will necessarily use them -- what I was referring to was that the routing the ISY determined started using that GE in-wall unit, as opposed to the far-closer Aeon Siren that it's always used previously (and I put there specifically to act as a repeater for the ISY -- the Aeon Siren is known to perform very well in that role, and does something useful in addition to being a repeater!). In order to view the routing information I use the diagnostic console and the "zwave->show information in event viewer->all" menu for each z-wave device. It's quite tedious. But I save the diagnostic output to a file, and parse it with a perl script, to select only the bits of info I'm after. Some day I might try to find the API to trigger this operation, and set up something to magically fetch all this data, and graph it -- kinda like the way one can display the routing graphically in HAAS.

The units send a single-tap and a double-tap -- but I'm referring to is the trick with Insteon where you can set up the local on-level, so that a single-tap on the Insteon device ramps it up to the specified on-level (e.g. 30%). And on Insteon, a double-tap is a "fast-on" with the side-effect that it also goes immediately to 100% on. I've found no z-wave devices that support a local on-level; they all go to 100% when they ramp up. Regarding healing the network, the only issue I've had has been with the new card in the ISY (the z-wave plus) -- it's range is far less than the old non-plus card. I finally made sure the ISY was within about 10 feet of a z-wave plus device to act as the first repeater. Oddly enough, now that I've done that, and run a few heals, most of the z-wave devices in the house have a direct path to the ISY! No idea what's going on - but it seems unique to the ISY's z-wave card, and seems to all work find as long as one has a close-by device to act as that critical first repeater.

Quality is good -- love the screw terminals as opposed to the wire leads that most switches have. Downside is that they're big - hard to fit in multigang boxes if you have a bunch of them side-by-side. Color changing is inexpensive -- they provide white, and light almond in the package (thought they used to include ivory - I'll have to check my parts box - but the web site says only white and light almond now. Works for me, but that's a consideration!) Feel isn't bad -- not quite as "clicky" as the Insteon switches (and way less "clicky" than the mechanical counterparts, of course). The GE Z-Wave Plus units are far, far better than the lower-cost z-wave units (like the Enerwave unit, which is so dreadful I tossed one in the trash rather than re-purposing it, after I replaced it with a GE unit). The LED is kinda lonely, if you're accustomed to the multi-color, multi-LED units like the SwitchLinc Dimmer, or the HomeSeer multi-color multi-led device (which is only in white, so I can't use them, alas ). There's also not a lot of customization you can set -- I have a bunch of Insteon devices where one press brings them up to 30% brightness for normal lighting, and a double-press brings them up to their whopping great full brilliance (for tasks like cleaning, etc). Can't do that with the Z-Wave stuff. However, the GE unit DOES support associations and will notify the ISY when the button is pushed - so programs, and ISY-based scenes, all work with the unit. For whatever reason, one of the basement GE units (the GE Z-Wave switch w/occupancy sensing) just popped up as a preferred repeater for a number of my z-wave devices, after I moved some plugin devices around post-christmas-cleanup. So it clearly works as a repeater, even though being embedded in a wall isn't the ideal location for a repeater. Bottom line: All future z-wave switches will be the GE units for me (at least until HomeSeer comes up with light almond faceplates).

Ok, whatever. Go ahead and ignore the capacitor issue, all you Insteon apologists! My opinion is that there's far too much evidence that this is a real issue, and one that needs to be considered when equipping someone else's house with an ISY... But I stand corrected: as long as the OP handles the PLM with care, ensures that it has nice clean power, and ensures that the new house is "a good fit", then there'll be no problem, I'm sure.

I'm laughing myself silly, larrylix! Seriously, you're trying now to tell us that everyone who suffers from the PLM failure problem has been throwing their PLMs against the wall, dropping them in pails of water, putting them in freezers and ovens, and/or has unusual electrical noise on their power lines? I think we can safely rule out all of those issues, with the only possible point-of-argument being what one would consider to be "unusual" electrical noise. I'd maintain that if the problem is the quality of power (which I don't believe for an instant - see below), then given the number of folks experiencing the issue, it's far more likely that those who do NOT have a failure are the ones with "unusual" power. Now the issue is, as has been CLEARLY identified by others and documented in the lengthy PLM repair thread, that Insteon has used the wrong type of capacitors in the PLM (and in the hub, for that matter) -- the capacitors used are not designed for high-frequency switching power-supply use, and fail as one would expect them to fail when used in an application for which they were not designed. So, I respectfully reject both your and lilyoyo1's theories that it's about water, temperature, noise, surges, or just plain "fit" (whatever that means)! The problem is simply that they use (present tense) the WRONG components. BTW, I have a whole-house surge suppressor -- multiple actually (one on each panel). Solves a lot of issues, and highly recommended -- but it doesn't solve this problem.

Your implication is that all those who've been suffering from the "two-years-and-dead" PLM problem should believe that the issue IS THAT THEIR HOME IS NOT A GOOD FIT for Insteon??!! And you base this on the fact that you, one individual, haven't experienced this problem??? I've re-read your post several times, but I just can't parse that sentence any other way. Perhaps you can clarify what you really mean?

One would presume that it's because the motion sensor is not repeatedly sending the "on" signal when people are moving about -- rather, it simply does not send the "off" signal until it determines that motion has ceased. Check the diagnostic log, at level 3, to see what's being sent by the motion sensor as you test the scenario. I would guess that you might get the results you're looking for if you implemented the following logic: a) When the motion sensor sends an "On" signal, turn on the lights and stop the timer, if it's running. b) When the motion sensor status switches to "Off", start the timer. c) When the timer expires, turn off the lights.

If you do choose Insteon, don't forget to set up a Subscription on Amazon for them to replace that PLM every two years. Detailed instructions for the process will be required.

I understand that it was designed, and perhaps even a few beta units were sent out (but perhaps that's just rumor). In any case, the brilliant, forward-looking geniuses at Not-So-SmartHome failed to deliver the chips and/or firmware necessary, so the product didn't make it to market. (I suspect Not-So-SmartHome decided to take the short-term revenue from ISY users replacing their PLMs every two years, rather than take the long-term view of owning a bigger market by making partners, and thus customers, successful.)

One of the features I'd *REALLY* like to see, and one I think would help UDI as well, would be the addition of an "Association Editor" for advanced usage. Hide this behind a "we're not responsible for what you do with this" Advanced dialog, if necessary. Such a tool would be used to allow us to create/edit/delete associations in all or any of the groups, or all or any of the Z-Wave devices. Closely related would be the ability to enable a program to be triggered on ANY message from a z-wave device -- perhaps allowing the use to specify some simple form of regular expression matching to limit the messages of interest. This doesn't have to be fancy, or even efficient -- just enough for experimenters to take actions for devices or messages that are otherwise not-yet-supported. The point would be to allow experimenters to see how best to set up and use Z-Wave devices -- once we establish mechanisms that work well, UDI could add those to the core support.

Actually, the hub has the same capacitor problem that the PLM suffers from -- I replaced the caps on my daughter's hub, and it came right back to life. I'm not sure I'd rate the ISY/PLM combination any better in that regard, since we still don't know that Not-So-Smarthome has *really* fixed the problem in the PLM yet.

Even if there's nothing connected to the red "load" wire on the KPL, the on/off buttons continue to send their "on/off" signals -- so you can happily use those on/off buttons in a scene to control something else. I do this in my kitchen, where due to a strange layout and a somewhat odd interpretation of what constitute a "hallway" (and thus requires three-way switches), I have far more KPLs on the wall than I have actual loads to control. It works out really well.

It's not a matter of the technology being replaced. It's a matter of Insteon being single-sourced and proprietary, and then failing to keep up with the rest of the world. IMO, if a company wants to be closed and proprietary, that's up to them -- but to be successful, that demands that they take the sole burden of ensuring that their devices work as the technology around them changes (e.g. LED lighting, switching power supplies, etc). In other words, if my Sony BlueRay player sucks, I can go buy another brand that works better in my home. I can do that with Z-Wave. But, if my Insteon PLM dies every two years, for example, I'm stuck with buying a new one, 'cause they don't care, and I have no other source to go to. So, yeah, if all you want is seven-year-old technology, that works with seven-year-old lighting, then the seven-year-old Insteon technology is great! Except for the PLM, which you'll have replaced at least three times in that seven years...

As for why, well, it's because it's my belief that Insteon has no long-term future as a company or as a technology -- the current owners show no interest in new market areas nor in cooperating with partners, and the current technology remains tied to the zero-crossing point of the AC waveform, accurate detection of which is becoming extraordinarily difficult given modern high-efficiency power supplies and lighting. I use an older version of the GoControl/Linear GD00Z-4 garage door controller. It's a proper garage door controller, unlike the Insteon solution, and offers a secure comms connection as well as the recommended audible and visual alert signal before closing the door. The GD00Z unit uses a tilt sensor on the door itself to detect when the door is open -- there are other companies (such as Enerwave) who offer just the tilt-sensor as a z-wave device if you don't need to open/close the garage door.

I'll be different. Avoid Insteon-based solutions -- instead consider the use of a z-wave tilt sensor, or for a complete solution, a z-wave garage door opener device.

Try replacing the power supply.

In general, LED loads are incompatible with any neutral-less dimmer. The issue is more than the load; it's the nature of the load that can also cause problems. I'll skip the details, but in general, any neutral-less dimming device needs to be able to satisfy its required minimum load with a non-reactive load (i.e. resistor-type load or incandescent lamp load -- not LEDs, CFLs, and certainly not things like fan motors).

Yes, that does -- it implies that the device may be working just fine, but the problem is one of the other things noted earlier -- noise on the electrical line, or a failing PLM.

Yep -- it's quite possible to work locally but not communicate with the ISY. Before you replace it, try power-cycling the device itself -- pull out the little tab at the bottom of the switch paddle (you don't even need to remove the faceplate for that). Push it in. See if that gets it working. If not, try (as paulbates suggests) a factory reset -- usually this is done by pulling out that same tab, then pushing it ALL the way in, and holding it in until the switchlinc unit beeps, and letting go after that beep stops. Go to the ISY and see if you can do a "restore" operation on the switch (factory reset like this will erase its links table, so you need to restore the links from the ISY before you can do anything. If that doesn't work, then try to remove the light bulbs that the device is controlling -- sometimes an LED or CFL bulb will fail in such a way that it causes the Insteon switchlinc to "go deaf". This is unlikely, but it's easier and cheaper to try than replacing the switchlinc! After removing the loads (lights), try to restore the device again from the ISY. If nothing has worked, stop, and let it go for a while... and think about what sorts of Christmas gifts or other things have arrived recently that may have been plugged in somewhere. Could be anything -- I had serious comms issues in my kitchen, and it took me forever before I finally tried unplugging a tiny little cell phone charger from one of the kitchen outlets. Believe it -- a tiny cheap knock-off Chinese cell phone charger was able to kill the Insteon comms for all the devices in my kitchen, just by virtue of being plugged in. So look around, unplug, and keep trying... it's cheaper and easier than pulling out a switchlinc and replacing it! Finally, if all else fails, it's time to find a replacement. When you do, use the ISY "replace" mechanism to update all the links table for the PLM, and other devices with the unique address of the new device -- much easier than manually adding the device to all the scenes, etc.

It means that the ISY cannot communicate with the switch. It could be that the switch has failed -- or it could mean that the switch has no power (e.g. the circuit breaker tripped), or that there's too much noise on the power line and the ISY comms aren't working, or that the PLM has failed, etc, etc.

In general, the ISY will display a blank status when it doesn't know the status of the device. This happens at power-up of the ISY, of course -- and it quickly fixes that by running a query to find out the status of the devices (unless one has disabled that query-on-power-up option), so for most devices you will always see a status. Battery-powered devices such as the motion sensors are different - they go to sleep, and won't respond to the ISY's query attempts (so the ISY won't even try to query them usually). So for battery-powered devices, the status fields will often be blank, and will only be filled in when the device itself wakes up and informs the ISY about its status. So, for the Dusk/Dawn sensor, you should be seeing that have a value within 24 hours of an ISY restart. At least mine does. For the battery devices, that'll be blank until the battery report comes in, again about 24 hours. Are your motion sensors not behaving in this fashion, then?

GE Z-Wave dimmers have been working well for me. I have a few Hue bulbs, but I've found I can only use those effectively in floor lamps and table lamps -- they require power all the time, and I'm not willing to bypass the wall switches to direct wire all the ceiling fixtures. Also I'm not a fan of the Hue tap things....

"...wear out faster..." That's a curious way to describe the failure of a non-mechanical part. There's nothing to wear out, there are no wear surfaces (other than the micro switches on the paddle, which have nothing to do with the load, and are the same on a dimmer or a switchlinc device). The closest failure mode that matches with "wear" might possibly be operating the device near its thermal limits, which might accelerate age-related failures. I cannot imagine why LEDs in general would cause more heat than an incandescent load. I suppose specific LED bulbs with very poorly-designed power supplies might cause intense current spikes on the power line, but that would impact all dimmers, not just Insteon. In short, that phrase simply does not compute. As Paul stated above, the electrician needs to provide more detailed technical information on the nature of the problem (if one assumes that said electrician is merely guilty of "oversimplification" of the problem, rather than being guilty of passing on misinformation).

Not sure where you live -- but I feel compelled to comment that if your HVAC system is doing more than just "comfort" you should consider your thermostat first and foremost for reliability, not automation. As noted above, that would put Honeywell and the like up at the top of the list, not the Insteon nor the any of the numerous "fancy feature" thermostats from startups. Up here in the frozen north, if my HVAC system fails, my house freezes -- and that would result in a multi-thousand-dollar event if I were at home, and 10x that if I were out of town when the house froze. I integrate automation with the system, but only to "nudge" the existing controls -- there is no way that my automation can result in a failure that would prevent the unit from heating. Search the forum and read the posts -- you'll find almost nothing positive about "Automation-enabled" thermostats, especially the Insteon ones. Stay away... don't go there would be my advice!