mwester

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

What I mean by fixed is that I determine when I build the device what the heartbeat interval is - and you can't change it, no way, no how. Variable is if you, as a user, have a control or setting to change the interval at which the heartbeat is sent - so if you want a heartbeat once per 24 hours, you can set that, or if you want it once every 8 seconds, you can set it to that... I'm going to take your question as a vote for "fixed".

Assume I'm implementing the heartbeat feature for a device to be managed by an ISY. How exactly should that heartbeat function? 1) I'm leaning toward a fixed heartbeat time period. The argument against a user-adjustable period is that it renders sharing of programs to monitor the heartbeat more difficult, invites confusion when different instances of the device in question end up with different heartbeat times, and it adds yet another step when performing a complete reset of a device (one has to update the heartbeat). Feel free to try to convince me why you need it to be adjustable. 2) Right now, I've implemented the heartbeat as a periodic sending of the DON command (i.e. the device was just switched on). The device will ALWAYS respond OFF when queried, and will never send the DOF command. 2a) Is this consistent with other devices that have heartbeats? 2b) Would it be better to send a DON, wait a few seconds, then send a DOF instead? 2c) Would it be better to implement something completely other than an On or Off? 2c1) perhaps an actual HEARTBEAT command? 2c2) perhaps an actual HEARTBEAT command with an incrementing value? Feedback requested.

Ah, so that's the REAL question -- how can one cause a program to run on the ISY from a phone? What phone? (Android or iPhone?)

??? Perhaps you can clarify what you mean by "Virtual Control"? I'd solve this by simply coding your program thusly: Turn on alert device wait 5 seconds Turn off alert device Close garage door

Exactly what is turned on first, and what fails to turn on? For a while (I've since redesigned my solution), I had a large pump on an applianceLinc, with a syncrolinc and an IOLinc -- I noticed that when my program turned on the applianceLinc, the pump would start, but the messages from the syncrolinc would be lost, and messages sent to the IOLinc would be missed unless I added a several-second delay. The problem is that the pump's startup either sucked down the voltage on the line or injected too much noise on the line, and until the pump motor's internal startup circuitry switched to normal mode, there were no Insteon messages that were making it through. Perhaps whatever you're starting when you switch on the first half of the outletlinc is causing the same sort of temporary startup noise that prevents the second message from being seen by the outletlinc.

Hold on a second here. I wonder if there are some assumptions being made incorrectly -- based on the original post, I suspect everyone is understanding that your keypads are not working, but assuming that all the other devices ARE working with the ISY. This last post makes it seem as if it's not just your keypads that aren't working but 40+ switches that are ALSO not working -- but are there other devices that ARE working with the ISY? I guess I'm now wondering if there's a much simpler explanation at hand -- if your ISY can't talk to ANY of 40+ devices, then it's pretty unlikely that 40+ devices all failed simultaneously. The simpler explanation would be that your PLM (the box through which the ISY talks to all the devices) has failed. Perhaps you can give a broader picture of exactly what is NOT working, and what IS working in your network - that would be really helpful right about now!

http://forum.universal-devices.com/topic/10516-random-all-on-event A 41-page thread (and not the only thread on the topic at all!) devoted to one such issue/concern with reliability. I have NO critical systems that can be impacted by such an event -- the one system that demands control by the ISY has been set up so that the normal (safe) state is with the IOLinc in the "on" position (I needed an external relay to do this, but that's a small price to pay for peace of mind). My garage door is controlled via z-wave now, which (if you read the forum) may have connectivity issues for some homes, but at least it doesn't suffer from the Insteon issues.

Upgrade to the latest 4.x version (make sure firmware and console version match) - you'll find that you'll be able to change the font size so you can read it on those ultra-high-res displays. And if you search other threads here, you'll note that UDI have stated that they're doing no further development on the Java IDE -- they too know that a Java-based IDE is not the way to go!