mwester

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.

Except that novels tend to be more readable, and a lot shorter! SSL is more like "Finnegans Wake", IMO.

I can't tell you what anyone else would expect - but my 'stat also has "AUTO" mode, and what I expect (and what it does) is that when in AUTO it maintains the temperature within a pair of setpoints, turning on the heat or A/C as appropriate to do so. I think the key here is the setpoints -- WHICH one are you asking Alexa to change when you tell it you want the temp to be set to 75 -- are you adjusting the LOWER setpoint upwards (which would turn on the heat!) or adjusting the UPPER setpoint upwards? Methinks that the vocabulary for Alexa is going to have to be adjusted so as to make that clear - and Alexa needs to refuse to act unless the intent is, in fact, completely unambiguous and clear. But that's just an opinion -- and as a matter of principle, I don't let my HA adjust my thermostats, because the amount of damage possible if something goes wrong with that is just way out of proportion to the benefit, at least at this latitude in the winter.

(Re: Original Topic) I wonder if there's a developer or debug feature that can be enabled to let one listen to exactly what it is that the Echo is hearing from its microphone array? That might offer some insight into the original problem described here (and might make the cardboard/foam workarounds described here less of a trial-and-error thing to set up) -- it might be worth an email to Amazon's echo support folks to find out (and while you're at it, perhaps they already know of this problem?)

Yes, one has to be selective to ensure one gets the feature -- but the cost isn't necessarily higher than Insteon. And when faced with a 3-way switch setup, the z-wave solution for that is far cheaper (although it must be noted that z-wave doesn't have such a solution for 4-way switches!).

Use both. Just remember that crossing between the two (z-wave and Insteon) requires the ISY to do the work to bridge the two, so there will always be a delay of some sort. Right now that delay is just too long for lighting (guests will actually start flipping the switch back and forth a few times before the ISY finally schedules the program and executes the command to turn on the light - not acceptable). I use z-wave for all sensors and the main garage door, and for second floor lighting. Insteon is used for first-floor lighting where the Keypadlincs play a huge part in the spousal-acceptance-factor. I also use Insteon in the out-buildings (shop and shed) because it's a tad too far for z-wave and I don't feel like putting a z-wave repeater on my yard light pole. Both have their place - and both have their frustrations. But to be honest about it, I've had ten times more trouble with signal issues on my Insteon stuff than I've had with the z-wave. Once someone comes up with a proper z-wave replacement for the keypadlinc, I'll be looking at re-doing my first floor with z-wave as well -- and getting rid of numerous filterlincs clogging up outlets all over the place!

No, this is not normal behavior -- this usually indicates communication problems between the ISY's PLM and the device in question. The REST API call cannot cause this -- HOW the "On" or "off" event is triggered is immaterial to the on-the-electrical-wire signal. However, if you really only ever see this with the REST calls, it could indicate that perhaps your REST call is doing something different from what you're doing when you turn that device on or off from the Admin console -- for example, perhaps you're addressing the device from the Admin console, but turning on or off a *scene*, and perhaps that scene references some non-existent device, thus triggering the error. Or perhaps (and this is a stretch) your computer from which you generate the rest call is creating electrical noise on the powerline, and its just a coincidence that the program you're running creates exactly right sort of load on the computer to create the right sort of noise so that interference is generated when you issue the REST call... (I said it was a stretch! You're better off investigating a common ordinary generic interference issue instead!)

There's a power supply in the fan itself -- the big advantage (at least the big one for me) of a DC fan motor is that it's completely quiet at low speeds - no audible hum at all. I understand they're also more energy efficient, but I confess that given how little it actually runs I can't see that being a feature that justifies the extra cost). Mine too has the proprietary RF remote, which just sucks because everything else in this room is automated. The only remaining solution that I'm planning to try, as soon as I find a low-cost used remote for that fan on eBay, is to solder a few wires to the remote and connect them to the relay on an IOLinc. I can accept one speed on/off, so that'll work for me.

Let's step back just a bit. Repeat your test sequence - this time watch the device status in the ISY Admin console. Does the console status update when you manually turn off the device? If not, then you have a communication problem if the device is Insteon, or a zwave device with "instant status".

There's the problem - I can't know that. The application is to add a "heart beat" to Polyglot, so that one can be assured that the connection between the Polyglot node server and the ISY is functional -- I have no idea what specific sensors or devices might be handled by that specific instance of the Polyglot service so I don't know how critical it might be. Thanks for the comments on battery life - for some reason I'd never connected the loooong 24-hr heartbeat interval with battery life, but it's obvious now! Since this wouldn't be battery powered, that would imply a much shorter heartbeat. How often is too often, though? (Note: this is ONLY between Polyglot and the ISY -- this won't add a heartbeat to sensors served by Polyglot if the end device doesn't have a heartbeat to begin with! So this is just to ensure that your Raspberry Pi, for example, hasn't crashed overnight...)