mwester

A "status" change requires some sort of event to trigger the change -- and clearly the failed or unplugged device can't send a signal to trigger the change. So, instead, you'll need to arrange for the ISY to periodically query the devices, so that it forces a status update, or changes the status to "not responding" if the device is missing or failed. The ISY does this once per day at around 3AM usually -- probably not good enough for your purposes. So, simply create your own program that queries the devices in question several times an hour or so. Edited to add: You can't query a battery-powered device, so I hope your thermostat is powered!

Hmm... I can see a node-server-based integration with v5.0 firmware adding a lot of ease-of-use here! I don't have the exact devices you describe here, but perhaps a little shopping is called for

It will have either no impact, or what little impact it does will be positive. Java plugins in a browser were, and are pure evil. (opinion) This will ensure that people consciously go through the proper process to "install" a java-based application rather than having a full application "foisted" on them in the guise of a web page - that's a huge security fix. And the reason it won't impact the ISY application is because it's an application (a fact that UDI goes out of their way to disclose), and UDI have been and are encouraging folks to install the Admin Console application as an application in the first place! (And along with the Java browser plugin, may the Flash plugin also die!)

Awesome news! I was skeptical about the echo -- I could imagine the comments: "another toy for mwester!" -- but the family-acceptance-factor for this integration has far exceeded anything else I've installed. Hat's off to everyone for making this possible!

I have 35' from my ISY to my Linear garage door controller -- the two have two interior walls, an interior floor/ceiling, and an exterior wall separating them. I did link the Linear securely about 10' from the ISY before i installed it, but it works fine where it is. (I did get the Aeotech siren as a repeater, but it was installed long before I got around to the garage door opener, and ended up being very useful on the other side of the house, where it remains today!)

Ok, y'all have convinced me. My PLM is about two years old - given the pain of replacing a PLM as described in this thread (and others), I'm just going to proactively replace the capacitors. This failure rate is so unbearably awful, it just is beyond my comprehension how SmartHome/SmartLabs/Insteon haven't addressed this in some better fashion. For example, just making it possible to modify the address of a PLM so that the replacement simply requires a "restore" would be a minimum "mea culpa" on the part of the manufacturer. Yet we all put up with this... why?

In the Admin Console, start by creating a scene to be controlled by the controlling button on the KPL - make sure you add that button as a *controller*, not just responder. Then drag the button that is the responder into the same scene. Done.

And if, for some reason, they decide NOT to help you out, just put the bad on on eBay (for parts or repair, of course) -- there's a bunch of folks who fix 'em.

Nope - the non-toggle off is the best the hardware/firmware inside the KPL offers.

There's a thread for the beta connected home integration - it works very very well, and doesn't require the skill.

Nope - there's no easy or practical integration with the Nest and the ISY controllers. The licensing agreements that Google has for the Nest make it impractical for UDI to do an integration (since UDI is also in the ADR market).

If you have an elk, there's probably an elk-based solution for you... but, I don't have an elk, so I opted to go the z-wave route. I use the Linear GD00Z zwave garage door opener. It's a secure device, has the alert-before-operating feature, and if your door currently works with the IOLinc's relay you just connect the two wires you currently have on the IOLinc to the Linear device and you're done with the wiring! (The door open/close sensor is a wireless tilt sensor, and just attaches to the top door panel with tape or screws, real easy.)

ROTFL!

It works very nicely with 5.0.2 ISY firmware

Done - I removed everything from the portal and added in one scene and one device with simple spoken names. Then ran discover from the echo.amazon.com web page -- it found the two new items and added them to the existing 18 items I have defined using the Hue emulator. The two new items work exactly as expected. (Edited to add: neither spoken word will work with the skill - but work just fine with the connected home integration!) Very nice. Now off to try some more interesting things - some programs to manage timed things, like engine block heaters (it's COLD here!), and add my "good night" program...

You're clearly frustrated - you expected "reliable" to equate to "noise-tolerant"; that's simply not the way it is. It's rather like comparing a HAM radio operator sending Morse Code with the Internet. Morse Code has no error detection, and no error correction, is limited in terms of what it can send, but oh wow -- the ability to pull a signal out of the noise with a simple on/off Morse Code signal is unbelievable; in fact there's just nothing better ever invented in the presence of weak signals or noise. And so it is with X-10 -- whatever type of problem (noise, or weak signal) you have, the X-10 signal is punching through. And, as far as you know, it's always gotten through correctly (but there's the rub - how do you know? Just like the old telegrams, how do you really KNOW that when the message says "Dick fell off the haywagon" that it wasn't Rick or Nick?? You didn't back then, and you don't with X-10 either - it's just that apparently if it was ever wrong you didn't notice, or perhaps you just didn't care...) If the X-10 stuff works, and you're unwilling to find the noise or signal sucker, that's fine - go with what works for you! Using another analogy, farms with the new-fangled tractors co-existed with farms using the time-tested, reliable, trouble-free, works-great-with-nothing-but-hay-and-water horses...

Nothing changed when I installed the network module. Some new features were available on the Admin console UI, but aside from that, there was no impact to any scenes, devices, and certainly not to any programs. So I would suggest that either your troubles are due to the upgrade, or they may stem from PLM problems (which may have only become apparent after the PLM was power-cycled a few times during the upgrade process, perhaps?) If you can provide some additional information, perhaps we can help debug this a bit. Start with confirming your UI version, and the firmware version on the ISY, then paste the source code for one of the failing programs along with the event log covering the time frame from the event that should have triggered the program through the execution of the program.

Not really - no news in this case merely means no news. What I've gathered from the various threads on the "All On" issue is that: - the new PLM firmware from SmartHome/SmartLabs does NOT necessarily fix the problem. - the new PLM hardware does NOT necessarily fix the "drop-dead-at-two-year-mark" problem. - UDI has still not been given access to a supply of PLM chips which which to build their PLM. The above has a measure of speculation, but it's enough to be quite distressing (and make me build out my z-wave devices rather than insteon devices)... Perhaps UDI can drop in on this thread and provide a definitive update?

Reality isn't sexy. Hence I don't pay too much attention to CES - it's all about "marketing sizzle" sorts of things, rather than a forum for practical, day-to-day-useful products. Expensive toys, mostly.

True enough, I expect I'll end up with some Insteon devices that are a bit back-rev. But unlike the PLM, I don't anticipate any significant, material modifications by SmartLabs/SmartHome. The issue with the PLM is the combination of the not-yet-solved "All-On" problem, the general distrust that the "dead-after-14-months" issue is really fixed, and the unreleased-but-discussed UDI PLM -- any one of those is significant, but together they make the purchase of a spare 2413S PLM just not something I can recommend. If mine fails -- and that'll happen soon, since I'm coming up on the 2 year mark -- I've got a set of capacitors handy, and I'm just going to be hopeful that I can get a replacement quickly.

I have more spare Insteon devices than I have spare light bulbs. But in this case, I'd NOT keep a spare PLM on hand, for the same reason that I don't keep spares of the 100W Cree LED bulbs -- I am in fear of a significant product update leaving me holding onto an unused device that I'd be tossing out...

I'd love to be a fly-on-the-wall in the SmartHome/SmartLabs conference rooms when the topic comes up -- I'd also love to know the gory details of the discussions with UDI regarding the PLM chips that they won't sell to UDI... I imagine the conflict must be significant - on the one hand, SmartHome is almost certainly looking at all the ISY's sold and realizing that all those customers are not "captive" (i.e. are not beholden to SmartHome for their servers to do their automation, and thus not potential revenue generators when SmartHome inevitably starts charging a monthly service fee for "premium" hub support). On the other hand, they must realize that they really don't have anything that competes with the ISY in any real fashion, and that they would lose those device sales. On yet a third hand they probably look at the addition of Z-Wave support in the ISY as a major threat to their device sales anyway... and there's probably a fourth hand that Iv'e not considered. No matter how you look at it, Joe has some tough decisions ahead. But after getting to know SmartHome/SmartLabs a bit better, I predict that the decision will be this: make no decision at all, just slog ahead with more half-baked ideas, hoping that the market will magically transform itself and SmartHome/SmartLabs will reap huge benefits simply by the luck of having made no *bad* decisions... rather than the hard way, like most other companies, which is to make the *hard* good decisions!

Why not just create the scene on the ISY, and set the ramp rate there? That'll not only be easier, but it avoids confusing the ISY (because it won't know about the links you've manually created).

This isn't a REST or even an ISY thing - this is an Insteon design thing. Basically, you cannot directly control the LED for a keypad (other than the main button that is wired to the load, that is). Instead what you need to do is create a scene, and assign that keypad button as a responder to that scene, and then send an "On" or "Off" to that scene instead. It is sufficient to have nothing but that one button as a scene member -- I do this for a number of buttons that I use as status and alarm indicators.

Try restarting the ISY. That's probably a bug, since I didn't find it documented anywhere, but when I re-added a deleted device (after a device replacement), it failed time and time again, until I reluctantly tried the "Microsoft Windows" Universal Fix -- rebooted the ISY.