mwester

Nice. The Dot just replaced the Echo in the kitchen. Looks nicer there (less obtrusive), and now the Echo can go to my office, where it was always supposed to go (I made the error of setting it up in the kitchen, and once we started using it there, well, it just wasn't going to leave...) The spoken audio quality of the Dot is noticeably less than the Echo - not objectionable, but I guess we just got spoiled by the better speakers in the bigger unit. The appearance, however, is far nicer - the Dot doesn't "vanish" on a table by any means, but it's not at all "in your face" like the Echo tended to be.

Basically, the API between a node server and the ISY is limited to integer data, and pre-defined text values such as "0 = off", "1 = on". Thus one cannot provide the user with any of the identifying information about a Sonos Zone, because one (the name) is an arbitrary text string that cannot be pre-defined in the node server app (I can't possibly know your room names!), and the other (the id) is a hexadecimal string which cannot be represented as a simple integer. The result is that one would need to create a separate, out-board web-based "configuration" tool that could provide that user-defined mapping as part of a setup or configuration exercise. And from a practical point of view, if you're going to write that, then it just doesn't make much sense to write an entire node server -- a few network resources as we can do today are dead simple by comparison.

@barrygordon - no, Sonos does not do bluetooth control. It uses a very complex SOAP-based API for communications and control. @bsnively - I think you'll find that what you're proposing is rather easily done, and I suspect others are doing it now. Search the threads for Sonos. In a nutshell, you'll need to create network resources to control your various Sonos devices - on resource per action (so if you want, for example, on and off, select playlist a, b, c and d, for each of 3 rooms, that's (2 + 4) * 3 total resources... it gets painful to keep editing all those, but it works. Then create programs to do the work, and assign the programs as "spoken" in the portal. Remember that "Alexa tell izzy to turn Kitchen Sonos on" runs the "then" part of the program, and the "off" command runs the "else" -- so tie the appropriate network resources into the appropriate parts of the programs. Done. Enjoy! (Now, if you're looking for something a lot easier to set up on the backend -- there are folks working on that, but it ain't easy. I'm stalled on my project right now (a node server integration of the Sonos) because without a richer set of controls in the ISY screens, you just can't create a node status that makes sense -- I can show you that Sonos 7 is playing source 43, but you probably prefer to know that Sonos "Master Suite" is playing "Classical Rock Redux" instead!). (And, if you're looking for something on the front end, where you can tell Alexa to "play Classical Rock Redux in the Master Suite", well, that's something that a lot of Sonos users would like to see, but IMO are unlikely to ever get -- the amazon folks want music playback to happen from Alexa, not Sonos, where the data is streamed from their data center servers instead of your choice... and since they own Alexa, the echo hardware, they're not likely to give that up!)

I suspect we're on the bleeding edge of automation - like the early days of any new technology, everyone wants an exclusive lock-in on it. I'm going to be optimistic and state that my crystal ball indicates a high probability of a standardized HA interface for devices such as these -- on the low end, perhaps just dry contacts on a few key items, on the high end perhaps a serial port of some sort. Your HA "z-wave interface box" or "Insteon interface box" or "cell phone NFC interface box" would just plug in, and of course hobbyists could create their own interfaces. The reason I think this is that once this sort of instrumentation becomes a common consumer expectation, most of the appliance manufacturers will realize that there's no margin in creating their own custom interface. Many will start by OEM'ing and re-branding common "black boxes" provided by other companies, and end up not wanting to even do tech support for those, hence they'll just provide a connector -- and you go to Best Buy or Walmart and pick up your favorite brand of appliance interface box. Now, anyone wanna bet if Insteon will end up in that race, or if they'll have fallen on their faces in the mud by then??!

I too thought I'd invested way too much effort with HouseLinc and my devices to start all over again with the ISY. I was wrong. It proved to be a nightmare in terms of management to try to preserve the links. After pulling out my hair (something I can ill-afford since I have so little left), I gave up -- factory-reset all devices, the PLM, the ISY, and started afresh. It was the best choice I could have made, and proved to be far less work in the long run. I'd advise you to do the same - reset everything, start fresh with the ISY, and use it for all link management. Much easier. Heck, I'm betting the effort you invested thus far as documented in this thread is more than you would have spent if you reset and started over to begin with!

I blame you all for my OCD on wall plate screws. Until someone on this forum mentioned, I didn't used to care... now all of them are properly vertical, and there's a little screwdriver in the kitchen junk drawer just in case I come across one that isn't "just right"...

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).