mwester

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!

Well, yes. In general. There are a lot of other considerations for a delay this long (many of which we can safely skip over when dealing with short delays) which make this more complex than the usual "wait" operations. So, in no particular order, here's a list of questions that might impact the answer: Is the goal just to turn the button itself off, or is it do stop operation of the programs that the button started as well? What is the impact (in terms of cost, inconvenience, possible property damage, etc) if the button is NOT turned off? Same, but if the button is turned off early? What's the acceptable delta for the delay (i.e. must it be plus or minus one day, one hour, one minute, or one second)? What bad things happen if the delta is outside the acceptable range? What external factors might affect the 10 day delay (e.g. power failure to the building, human operating a power switch elsewhere, etc)? What should be the correct behavior in the face of the various external factors (e.g. should the timer be restarted when the ISY reboots after a power failure, or should the timer be reset on the assumption that the button is also off and all programs are reset, or does some other action need to happen to alert someone that a "short cycle" may have happened)? This may sound excessive, but as an example of why this is important, I have a timer for my ice-melting cables on the roof, and a set of timers that monitor my septic lift pump. The former is a really simple timer program 'cause the downside is trivial -- the latter, however, has some very real consequences if it goes wrong, so that is actually a set of programs (and a bunch of relays and other hardware to act as a final backstop if the logic or ISY or Insteon fails)...

Re: use of the Rasberry Pi for Industrial Control: https://info.opto22.com/raspberry-pi-io Of course, you pay for it -- at $120 list price for JUST the power supply, it had better be good! (I've got a few of the opto 22 mounting racks, and a whole bunch of the opt 22 I/O modules, so I'll be buying the Raspberry Pi adapter ("Carrier" they call it)... but I think I'll use one of my existing power supplies, thank you! )

I'd suggest you get a spare on-hand, my experience is that once they start to misbehave, even if you can get them back working, they're on the way to failing so it's just a matter of time. That said, there is one possibility that's worth trying -- if you can pull out all the bulbs (I'm assuming that it's controlling lighting, right?) that it controls directly (i.e. with the "A" button), then try a factory reset. I've had a couple of cases now where LED bulbs or other funky loads were able to generate enough electrical "racket" that the device just goes berserk. It's a long shot, but should be pretty easy to try. Adding/removing the device from the ISY won't really help. What you want to do is follow the procedure to factory reset the device, then on the ISY, do a "restore" of just that device. If that won't work, then try that again with the bulbs (load) disconnected or removed, as suggested above -- and if it still won't work, then chances are it's a goner.

You want to expose the scene (which contains both the switch and the light) to the Echo rather than exposing just an individual device.

Given all the troubles folks seem to have with thermostats and Insteon/Z-Wave, I have to suggest that the following may be a more reliable way to resolve your problem! https://www.homedepot.com/p/Honeywell-Thermostat-Guard-CG511A/202024249 Originally, I thought I wanted an HA-enabled thermostat as well -- based on the unending litany of troubles folks keep reporting, I am so, so very glad I never did that. I know that may not be what you wanted to hear, though.

The Insteon powerline/RF portion of the protocol is unaware of the link database -- so it will make no difference if the hub is "discovered" or not. Any Insteon device will "relay" for any other, even if that other device is linked to nothing at all.

https://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface