mwester

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?

I'd agree completely with your conclusion -- if it weren't for the fact that leak sensors are battery-powered, no? A battery-powered device isn't subject to power-line surges, so they shouldn't have been affected. On the other hand, the power-line-connected thing they all have in common is your PLM. So you need to pay close attention to that thing; perhaps it had some flash memory problems that lost the links to the three devices?

I'm reasonably sure that any of my vehicles will hang out over the beam. It's pretty low. I suppose I could add another beam, to catch my SUV's bumper (which is the most sticky-outest part). And another to catch the much-lower bumper on the wife's VW for when she parks in the garage. Perhaps another if the snow-blower handles (higher than both cars) stick out if I'm ever careless in putting it away. My point is that I don't think it's practical to have a beam cover the entire door plane, and most certainly none I've ever encountered does.

The U suffix indicates a USB interface -- that WON'T work with the ISY. You want the 2413S model.

Nope, not much else to try. I suppose you COULD check that the outlet has power -- but I suspect you've already checked that. Time to pony up, and pay SmartHome another $100 for the next two years of PLM service! But before you do that, you should check the date code on your PLM, or dig up your records on the unit -- perhaps it's still under warantee. Some users get lucky, and have theirs fail soon enough that SmartHome will replace it; most of us, though, end up replacing the units every two years like clockwork. If you're good with a soldering iron, there's a thread here that describes how to replace the capacitors on the circuit board, which usually fixes 'em (I'm one for two on that so far).

Your best bet is to use the sort-of-normal "seconds-since-epoch" for date-time stamps. That way simple math can easily be used to figure out time deltas - plus it's pretty much just the standard way it's done. Regarding the integer size -- I've had no difficulties storing an epoch-style value in a variable, so I think it's at least 32 bits -- but I'll defer to others who may have more definitive information on integer size on the ISY.

1) You ALWAYS need a hue hub to control the hue bulbs -- this is a requirement of Philips, not of the ISY. 2) No, the Raspberry Pi is not necessary. If you choose to use network resources to control the Hue bulbs, then you need no outboard computing device at all. And if you choose to use Polyglot, then you can use other Linux devices, or perhaps even a Windows host -- depending on how self-sufficient you are with Python and computer admin things. 3) Polyglot is not a necessary item -- with limitations, you may be able to use nothing but network resources to communicate directly from the ISY to the Hue hub. Here's the details: with a network resource you can send ONE command to the Hue hub with a pre-defined hard-coded network resource. You cannot receive information from the Hue hub (i.e. you cannot write a program that queries the state of the bulbs, for example). If you have a very few bulbs, and limited settings for them, this is practical. Consider my original setup -- I had three bulbs. I wished to turn the all on at once and turn individual ones on. That's four network resources. Of course, if you turn them on, you need to turn them off. That's four more. And in the evenings, dimming to 50% was nice. Four more resources. Some colors were cool -- we selected four colors that were nice, and wanted each color to work at 50% dimmed and full on -- that's (4 + 4) * 3 or 24 more resources... at about that time I stopped and said the heck with it. What polyglot and the node server offer is the ability to make each bulb appear as if they were Insteon devices. So things like on and off and dimming are built-in, and easy to do. Color is also built-in (although the XY color coordinates that the Hue uses are a real pain). 4) You need the network module regardless -- in order for the ISY to communicate (send data) with any external device, be it the Hue hub with network resources or the Polyglot service on a Raspberry Pi, it needs the network module. So yes, if someone doesn't have it, they'll need it. (Frankly, I think the network module needs to be rolled into the base ISY, with a price bump to the ISY base price if necessary, because most creative things require that module anyway - but that's my opinion, and I'm lousy at marketing things...) 5) The ISY Zigbee module communicates only with utility meters, I understand. Even so, I don't think reverse-engineering the Philips Hub-to-Bulb protocol is a worthwhile thing to do -- huge amount of labor, having to be re-done each time Philips introduces a new device or new version of a device. The Node Server concept and the Polyglot implementation was designed to avoid exactly that by simply making another vendor's hub device easy to subsume into the ISY's notion of devices.

The Hue is controlled over the network -- so you'll need at least the network module. BUT you also want to integrate the Amazon echo, which suggests that you really want the Portal module (which just happens to include the network module, which neatly solves both problems). You can set up "network resources" in the ISY to control the Hue devices, but that's sort of limited in terms of what it can do. If you have a Raspberry Pi (or another always-on computer), you can consider using Polyglot with the Hue node server to manage the Hue devices (and integrate other things, as well). That's a pretty reasonable place to start, methinks.

Yep, undo the trigger reverse -- change the sensor/switch so that you can do that. The trigger reverse option is perhaps the single worst option in the entire Insteon family of devices. I'm not sure if the issue is that it's implemented so poorly, or if it's designed poorly - but there's no doubt it's just plain wrong. Not even buggy - just wrong.