mwester

Ok, back on topic -- Any details anywhere on how the Echo determines which is closest? Is it simply volume, or signal-to-noise ratio, or is it something more complex (such as quality of the voice matching or suchlike)? I ask because given the placement of my two devices, I'm not sure that volume will do the right thing, but understandability of the voice certainly will improve that (specifically, you lose the high-frequency components but not the volume when sound travels through a glass door...)

Sorry, I don't speak "Minion". Can you try again, in Java or Python?

With the rise of Internet "journalism" comes the precipitous plummeting of the quality of same.

Regrettably, new-in-the-box doesn't mean anything with regard to Insteon settings; it's commonly reported that new Insteon devices show up with all manner of odd (and in some cases impossible-to-reproduce) settings and devices configured. So the general advice is to factory-reset each device before initial setup. Based on what you've said, I doubt that this is your problem, but a factory reset and a restore of that device certainly wouldn't hurt. (FWIW, I'm in that group of users who've switched to more reliable controls for the GDO -- I use a z-wave door controller instead of the IOLinc.)

Alas, because the protocol Smart Home designed into the PLM doesn't permit doing that in any reliable manner. The ISY can request the links from the PLM, but the PLM will abort transmitting the list as soon as it has any other traffic. So on a large installation, where you'll have lots of links, and lots of devices that are reporting back and forth, it's pretty much impossible to get the full and correct list of PLM links back. This is a known issue, and its one thing when a human is looking at the results, but it completely kills any possibility of an automated "integrity" task. It sure would be nice, and not just to detect failing PLMs.

i agree completely -- consolidation is clearly being forced by the Echo. The fragmentation of the Home Automation marketplace has been a huge problem for everyone, and I'm really surprised that it's Amazon, and the Echo, that has proved to be such a catalyst to at least some form of high-level consolidation. And I'd have preferred that it didn't happen in the "cloud". But it's better than nothing. The fog in my crystal ball is clearing slightly -- the shadows imply that we'll see a consolidation for the smaller players, most likely in the form of a standard API layer that would sit between services like Amazon's Echo and the proprietary device/service. While the vendors would do this to reduce the cost of implementing, testing, and certifying with Amazon each time they make a change or introduce a device, we might benefit from such a (hypothetical) API if we could coerce the ISY or a node server into integrating with that (hypothetical) API. Of course, that would imply cooperation... and now the fog has filled my crystal ball completely again. Sigh.

Don't they allow Chrome to be installed on WIndows systems up there in Canada???

Below is a screenshot of a Hue bulb, as it appears in 5.0.2 using the current Polyglot/Hue node server. The ONLY other way to integrate Hue is via network resources. In other words: there is no software-only solution that does not require an outboard processor for the ISY -- basically because it is not possible to write software add-ons that run on the ISY itself. Thus the Polyglot solution - UDI adds a means to make it possible to "proxy" nodes to an outboard computer, and software developers and hobbyists can safely write all the code they want on that outboard computer without compromising the ISY itself. It's a beautiful thing. Now I understand from our earlier conversation on this that some folks don't want to have to set up an outboard computer. I get that. Hence my suggestion that somebody (UDI? mwester-devices-r-us.com?) package up the outboard computer, complete with cables and instructions to tell you to plug this there and that here, point your browser at this url, fill in these fields, and presto! Now you can download apps from the UDI Polyglot App Store. We're just not there yet.

Those pins are designed to be soldered - specifically to a circuit board. For reliable operations, you'll want to solder wires to those pins, especially if the circuit could be exposed to humidity (indoors or outside) where corrosion might make a crimped connection unreliable very quickly. An alternative means might be the use of crimping pliers and the crimp connectors (commonly sold for use with automotive wiring) -- but I'm always a bit concerned about those because one has to use a LOT of force, and that has a tendency to pull pins out of the device itself if one isn't careful. A crimp connector differs from a simple "twist" connection of wires even if the twisting is done by pliers; a crimp actually results in deformation of the metal and areas of metal-to-metal contact where oxygen cannot get in between -- and that requires a lot of mechanical force relative to the size of the wire.

We do this all the time here along the upper Mississippi. I see strings of truck trailers, back-to-back, racing upwards of 70 MPH in both directions between Minneapolis and points south. The only difference between these and your scenario is that the one guy at the desk is sitting in a locomotive at the front of the moving string of vehicles... Now, to be serious about it -- doesn't it seem easier to just implement some variation on a train-like system, where one operator takes care of 10s or 100s of vehicles that travel the same route? I'd feel better about mechanically-coupled vehicles with a trained operator than I would about 100 independent vehicles, all with different software, with untrained operators who are distracted at the least and abusing the machine at worst.

Polyglot Guide For Dummies -- that's less a guide as it is a product. As noted by DualBandAid above, there's a lot assumed in the current docs - but the problem is that what is assumed has nothing to with Polyglot, and everything to do with installing an operating system on a computer, setting up networking, etc, etc. And there's not just one short guide already published for that, there are shelves full of that sort of documentation already. My point is that for that group of users, what's needed is not Yet Another guide to follow (and frustrate). Rather, what's needed is an appliance. Someone needs to step up, and provide a "NodeServer CoProcessor for the ISY" (NoSCoPISY -- sounds like a medical procedure on your nose -- so we also need a better acronym). Such a thing might be nothing more than a Raspberry Pi in a case, with a power supply and an ethernet card, prepackaged with a Raspbian operating system and Polyglot preloaded, with some startup scripts installed that prompt the user for some Polyglot/ISY setup information. Now we just need someone to step up to create that package and market it...

I use a mixture of network resources and Polyglot. Response time is usually sub-second. Polyglot makes each Hue bulb appear in the ISY -- it's level and color (in XY coordinates) can be read. You can write programs to trigger on those levels, etc. Just the same way you can do that with the Insteon LED builb, for example. I doubt that the usability factor with the 2477D will be good. There's an expectation when using that dimmer of "instant" response, and even a small delay will result in overshoot, etc. But it's worth a try. I have my Hue bulbs in pot lights in the family room -- and there's no direct control for them. Instead, they are controlled indirectly by other scenes controlled by Insteon switches and a few timers. For example, at 7:30AM, they come on set to a pleasant color and brilliance -- makes it easier for me to have my first cup of coffee. If I turn on the "evening" scene switch, the ceiling accent lights come on, the Insteon-controlled floods behind my chair go to 50%, and the Hue lights shift color and brilliance to fill the rest of the room. And so on. Regarding the network resources, the Hue bulbs have a neat "alert" feature where they flash (rapidly dim and brighten). A number of programs monitor various things like z-wave door sensors, and the appropriate Hue bulb with start to alert depending on which door was left open for too long. Until the alert feature gets added to Polyglot, I use network resources to implement that feature.

These are the days when the BBQ grill becomes very useful, especially the side-burner. Those little LP tanks aren't cheap, but when you figure that I have to pay TWICE for the electricity used to cook something (once to heat the stove/oven, and then again to remove that heat with the A/C unit), well, it's quite palatable.

Yes, but oddly enough the track that gets played over and over again makes a pretty reasonable point; one that most homeowners should be aware of before they make whatever decision they choose to make.

Yes, you are exactly right -- you won't know about the absence of the device until the 3AM query unless you arrange to query on your own. So you'll need to query and then test the responding status separately in order for this to work.

In theory, you could do that. In the real world, there isn't enough storage or memory in a router to support an application written in python. If you are capable of installing DD-WRT and setting up Apache/PHP, etc, then you can also set up a Raspberry PI -- just do that, it'll be far, far easier.

Stuff happens. Alas, it's the weekend -- but no worries, if you send an email to UDI's support team, they'll fix it when they get back.

Perhaps it's as simple as the device can hear the controller (and thus act on the commands), but the controller cannot hear the device (thus marks it as having comms errors). I think that device is based on the nefarious Insteon PLM -- which is known to have odd communications issues just before it fails, right after the 2-year mark -- that may be another explanation.

As for the relay, the easiest way to handle that is to use a pre-packaged device. I prefer the Functional Devices "RIB" line -- you find any number of these, in various voltages and current ratings and configurations on eBay for very little $. Here's a very common one -- the data sheet for it will tell you what size motor it can handle, very specifically. You'll notice from that data sheet that there are different current ratings for different purposes -- that's because devices behave differently particularly during startup. A motor is usually far harder on a small relay than a resistive load, for example -- the startup surge current can arc a lot, resulting in a lot more wear (pitting) on the contacts, eventually resulting in the contact melting open, or welding shut. I would recommend that you use a relay on BOTH low and high current sides -- the Insteon device is really, really small and it would be shame to have to toss out such an expensive device if it fails under load. Dirt-common low-current (and low-cost) RIB: http://www.functionaldevices.com/building-automation/display.php?model=RIBU1C I'm using one of the above relay's bigger brothers, controlled by an Insteon appliancelinc to control a 3/4 HP pump. As for wiring that - help us out a bit, what is your level of comfort with wiring, conduit, junction boxes, etc? What level of detail are you asking for folks to provide?

I agree with the posters above -- and I'll add that proper installation of the wires is NOT just due to "anal-retentive" or OCD people on this forum! Sloppy installations result in failures - which are bad - or outright short circuits - which are worse. And even though this is only 24VAC, that's enough power to result in an overheating situation. Starting from the right side, going left -- the installation looks very good, gradually decaying to horrifyingly awful at the left end. It needs to be cleaned up and fixed. As noted earlier, make sure NO bare copper is showing. Also, use the proper wire size -- the stranded wire on the far left is NOT the right size, and you can't just put that into those terminal strips -- you'll need to use wire nuts and a short length of solid copper wire to make the connection to that stranded cable. Sloppy == failure, if not immediately then at some point in time where Murphy's law dictates that said failure will result in maximum inconvenience or outright monetary damages.

Start tracking your error/retry rate (just examine the diagnostics level 3 info whilst doing a compare of the links table on something with a lot of links, like a KPL). You'll probably observe it going sky-high just before the unit croaks entirely... I've been wondering if it's at all practical to have a diagnostic program run every night and use the API to do that automagically, and chart the results -- it might be an early-warning system of sorts.

Yep, keep it safe, standing by for when your original PLM fails. That'll happen at about 2 years and 2 months of plugged-in time. So don't plug the new one in -- the clock will tick on its lifespan as long as it is plugged in. (The PLMs suffer from a dreadful problem that limits their lifetimes in this fashion; Smarthome claims to have improved the situation with the latest HW version, but based on the component-level investigation done by others on this forum, I'm skeptical -- I think it'll last a bit longer but ultimately suffer the same fate. So brace for the inevitable, and keep that unit!)

Was the cover plate too hot to touch? Or just hot, but you could keep your fingers on it as long as you wished? If the latter, that's normal -- you have two dimming devices which have to dissipate heat -- and the only place to do that is on the exposed metal (aluminum) front plate of the switch itself. That heat finds its way to the cover plate. You can help to manage that heat in several ways. First, if the electrician installed a metal box, that'll help a lot -- but if it's plastic, you can't change it. However, you can change the cover plate to a metal one. They're getting harder to find, but you can still get them, and in most cases the painted color will match the others well enough that few will notice. You can also separate the dimming devices -- put them on each end, with the switch in the middle. That will spread out the heat to opposite ends, and keep any one device from overheating. In fact, if you check the specs, you'll note that the safe load any of the dimmers can handle goes down if the dimmer is installed in a box next to another dimmer. Finally, the amount of heat is dependent on the load. Switch to dimmable LED bulbs, and you'll create less heat (and save energy).

My master plan to resolve this whole issue is well underway. I've claimed half the garage as a workshop -- leaving one of the two cars parked on the driveway. By early winter, I intend to have the other half claimed for the workshop... and that will resolve any issues relating to the garage door.

Is all this REALLY easier than just installing a polyglot instance on an RPI and using that to make each bulb appear as if were native?