mwester

I started with the hue emulator, and was very happy with the way it worked. When the portal came out, I added a few new scenes to the portal, and was happy with those working, too. Then, well, "life happened" for a while and up until last evening, that's how it all was left. Nobody in the house noticed the difference between the devices/scenes on the emulator vs those on the portal, and even I forgot which were where. The point being that I guess the worry I had that the portal would be slower or less reliable or whatever was an unfounded fear. Last evening I felt the need to "fix" one of the scenes that was on the hue emulator -- and found that I could no longer get Alexa to find my emulator. I fought with that for several hours, to no avail, and then just turned off the emulator and added those devices/scenes to the portal. Working great, and again, nobody noticed the change this morning. Net of it all -- the portal is easier to set up, and multiple names are a huge benefit, but in terms of day-to-day voice response the two are identical. But it should be noted that the most recent versions of Alexa don't seem to play nice with the hue emulator any more, at least not for me.

That's exactly what mine looked like as well - and it's relatively new (purchased last fall). The fuse replacement was easy (it's a 15 Amp, slow-blow fuse - T15AL250V) as long as one is comfortable doing some soldering. The pump draws about 12 - 13 amps, with the startup current being well above that, of course. It was only a matter of time before that fuse blew.

I blew the fuse in a synchrolinc that was monitoring a lift pump (startup current eventually proved too much for the fuse). So I replaced it with an IOLinc and a current sensor instead. I used a surplus (old)j Neilsen-Kuljian D150-1A for the job -- it does not have "dry contacts", but the semiconductor they use triggers the IOLinc very reliably (as long as you wire it the right way around to the IOLinc -- polarity matters!). The lift pump has a filter on the output side, and initially the ISY's job was to monitor run time and report via text message -- if the run time increased about 25% over the baseline, the filter needed cleaning. At this point in time, the setup logs all run times to an external device, which has a web page that allows me to track run times historically. The ISY program has been extended so that if the run time is double the baseline, it powers off the pump for 30 minutes, then re-applies power -- thus cycling the pump, which in addition to ensuring the pump cools, often seems to disturb the filter enough that after a few cycles it shuts down normally, buying me some time (very helpful when I'm out of town). Another watchdog program on the ISY checks to make sure that the power to the pump is not shut off for more than an hour at a time -- thus avoiding any malformed logic or GUI clicking mistakes to effectively disable the pump altogether. As for the pump power, that used to be an On/Off unit (the new ones; the old ApplianceLinc can't handle the current), but it was replaced with a Functional Devices high-current relay controlled by the IOLinc -- it's set up so that the normally-closed side is wired to the pump so that the IOLinc has to be enabled to power off the pump. Finally, I distrust all extra devices -- and my paranoia was justified when the Syncrolinc fuse blew. That problem was easily detected because I wired a bright blue LED panel indicator into the junction box downstream from all the relays and sensors. When the tank high-level alarm (independent of all ISY/Insteon stuff!) sounded, a quick check in the basement showed the LED was off -- checking the panel, the breaker was on -- unplugging the line to the pump from the Syncrolinc to a normal outlet resolved the problem in about 15 seconds, without any need for the person doing this to know anything at all about my Home Automation. That's really important; never ever assume that you'll be around, armed with a functioning computer and the ISY password, when something goes wrong! I picked up a box of the current sensors on eBay -- this summer they'll go on various lines inside my Geo unit, on both primary and backup well pumps, and on the water heater. Cheap, reliable, and they don't introduce a fuse or anything else into the wiring... I'm sold on these devices. Oh yeah - I'll also dump my Syncrolincs on eBay... when I replaced the fuse, I became VERY unimpressed with the design. Non-critical, low-power loads ONLY...

Just tell Alexa to wash the dishes... she stole my line!

Yes, do not let the keying concern keep you from a Schlage. I have a lot of doors, interior and exterior on the house and buildings -- some are Schlage, some are Marvin, and a few Anderson. I purchased a Schlage re-keying kit (from eBay), and with a bit of effort I was able to rekey each and every lock to use the same key. The Schlage and Anderson locks were easy (the Anderson used a Schalge cylinder), and with some trial and error I managed to find a set of pins that worked with the Marvin locks so that they too would accept the same key. Unfortunately, I purchased the (expensive) Schlage combo locks and keyed deadbolts before the z-wave units were available, so I have to wait for one of those to fail before I can play with that. I suspect I'll be waiting a looooong time...

still shaking my head, sadly. Nothing on this thread so far has convinced me that ISY programs are a solution. The OP has repeated - several times - that he does not wish his house to freeze (and provided a link to emphasize his point). Yet, we all persist in ignoring the real problem -- which is that the high-falutin' fancy really-expensive whizz-bang electronic computer-ized thermostats FAIL! If the brakes on my car have failed, I don't care to pursue a solution that involves an ISY, lots of fancy programming to repeatedly query the car's engine computer to see if the braking system reports that it's alive, etc, etc etc. Instead, I'll have the car towed to the nearest service station, and have the brakes fixed before I'll rely upon that vehicle again. Similarly, the solution for the OP's problem is to replace the existing FAILED thermostats with reliable ones. If he desires, keep the fancy failing ones, and wire them into the system such that the new (low-tech) WORKING ones act as a failsafe to keep the house from freezing. Then use the fancy expensive unreliable ones to "tweak" the temperatures (at least when they're working, that is). What have I missed here?

It gets that cold here one state over... and I am very concerned that I not do anything with my Insteon or other projects that would result in the heat failing. For any reason. If your thermostats may fail to come back with a reasonable set point, then I respectfully submit that the solution is not to depend on an overly-complex solution such as the ISY. Oh sure, do have the ISY program - but don't depend on it, because it too can fail! Instead, I'd suggest that you wire in an old mechanical-type thermostat in parallel with the high-tech one that fails so badly - and set the junky mechanical one (that you can rely on!) to a setting that will keep the house from freezing. Fly-by-wire is great, but when it doesn't work reliably, any sane person will want to ensure they have a mechanical linkage as a fallback instead of depending on yet another fly-by-wire system as a fallback.

Unless you are an expert in networking and have configured both routers "just so", your network is fundamentally broken. It may seem that all you need to do is fix the ISY connectivity, but given what you've described, there's a lot of other stuff that just isn't going to work - things that aren't going to be reachable from other things. Replace Router 2 with a network switch. That may not fix your ISY problem, but at least it will ensure that your network is a single logical network, with every device able to see every other device, with every DHCP device able to get an address in the same range from the same authoritative source and with no conflicts.

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.