mwester

Me too -- I'd really prefer "Hey You!" as the wake word! Of course, that's politically-incorrect in today's day and age. I feel the preferred way might be: "Oh worthy one, I humbly beseech thee..."

Use the former method. The IOLinc is unlikely to be able to handle the current on the low-voltage side.

Sigh. I do appreciate the need to protect children who persist in trying to stick pointy metal things into outlets. So I do make a point to always have one or two commercial-grade TR outlets as spares in my electrical repair parts box. The problem is that the blasted things fail - the little leaves or shutters or whatever jam up and then you can't use the outlet for anything anymore. Grr. And then there are those arc-fault breakers... again, I appreciate the problem they solve, so I've been sure to have the installed even in a few rooms where code doesn't require it. But in this three-year-old house, I've already replaced one, and I've a second one that insists on leaving me in the dark for no reason at all randomly for the past couple days. Those things are EXPENSIVE! And that's just for the AFCI breaker -- I can't imagine what an electrician would cost to swap that out on top of that. My point -- until we figure out how to make this new "safety" stuff also reliable, people are going to reject it, and find ways to disable the malfunctioning safety bits or go back to the old tried-and-true "un-safe" devices. (We're really getting off topic here, and I'm contributing to that - sorry!)

I've heard about you Canadians and hydroponics... it's not lettuce that y'all grow up there, I know that!

Nobody can tell you if the RF connection will be adequate. That's a function of too many factors unique in your environment. IF your building has no other sources of RF, particularly around the 900 MHz band, and the fixtures into which you'll mount the Insteon dimmer units is not metal, and you have line-of-sight between each Insteon dimmer and the PLM, then it's reasonable to expect that it will work. However, all it takes is for some industrial machine operating in the 900MHz unlicensed range to power up, or for someone to take some other 900MHz device (baby monitor? Walkie-talkie? Who knows what?) and put it in exactly the wrong place (and nobody can tell you where that might be either), and suddenly you'll loose the connection. It's largely trial and error, so you'll just have to try it, find the issues, move things or add a few range extenders, etc, until ti works. I'm also a little concerned about the LED lighting power supplies -- they're undoubtedly switching supplies, which generate so much noise that they tend to render the Insteon power-line communications useless. That means that your mesh may have to rely entirely on RF, rather than the ideal case where the PLM need only have comms to one of the dimmers, and it would relay over the powerlines to the others. Or even worse (and again, you have to try it, nobody can tell if this will happen), if the noise at the zero-crossing point of the AC power is bad enough, Insteon devices cannot process the RF signal either -- so basically, if you have bad power, the RF may also become useless. Buy a couple units, make sure you can return them, and test the comms before you go any further with this project.

Or, of course, you could search around (eBay? "Coffee Shop" area of this forum?) to see if anyone has a KPL that has the same part number and about the same version as the failed one. Don't worry about the color; it's really easy to swap the entire faceplate with the buttons.

I left Ontario to attend college in the US -- a bunch of us had one of our new friends (from down south) convinced that when we went home for Christmas break, we would park at the border and rent a dog-sled for the rest of the trip... But the truth be told, as one of my roommates put it, there was no good way to distinguish the Canadians from the Americans at school, except to note that fact to a Canadian and observe the reaction.

I'm betting they noticed you're in Canada, and they're stuck trying to find a carrier that delivers by dog-sled.

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.