mwester

Oddly enough "Open the Garage Door" should work, but you might have to say "Close the Garage Door light" or "Turn off the Garage Door" to do the opposite. "Opening" and "closing" lights is an idiom used by some (I've heard that most often used by those for whom English is a second language).

(from the XKCD comics at https://xkcd.com/ )

Michel, is the portal still in beta, or is it available for anyone to purchase right now?

Which Java JRE are you all running with the Hue emulator on the Raspberry PI?

It's not too late for that... This thread is way confusing, and this device (Echo) seems to warrant something better organized. If I knew how to get a sub-forum created, I'd do so -- perhaps some of the more senior members here know how and can do it.

I'm not sure what that is -- but I had similar behavior (although it didn't happen all the time). I manually changed the trigger settings; I think it was the hold-off time that did the trick. It's set to 10 seconds now, and all is well.

As stusviews says, load sensing is not a solution -- you need the Syncrolinc to sense current draw by the pump. I have a similar situation, except the other end of the water chain -- it's a septic pump. When the filter on the pump outlet gets plugged up, the pump runs way too long. If it's completely plugged up, then the pump will run forever (which won't damage it, but at 12+ amps of current draw, that gets really expensive!). My solution is a syncrolinc, into which I've plugged a new-style appliancelinc, into which the line to the septic pump is plugged. The ISY has a series of programs that manage this. The most important set of which is the set that is triggered when the syncrolinc detects current draw and counts seconds while the pump is running. If the pump shuts off within 10 minutes, all is well, and it sends me an email with the duration of the run. If the pump fails to shut off, the ISY triggers a z-wave siren for 30 seconds, illuminates a red "Alarm" button on a keypadlinc in the kitchen, and turns the appliancelinc off to power down the pump. After a few hours, it re-powers the appliancelinc -- and the cycle will continue. (The reason for this is that the clogged filter will often partially-clear with the back-flow from the pipe going up the hill to the septic field, so it makes sense to keep trying; it usually will pump the level down so that the system keeps working.) The duration of the run is currently managed manually, because the code to handle this elegantly in the ISY escapes me -- I've observed that the pump run time is a very good indicator of the filter's condition, if one smooths the curve to remove the outliers. A sudden increase in the running average of pump run-times would probably suffice, but managing lists is not easy in the ISY... Another to-do on my list is an indicator of "not-running" -- I'm thinking that correlating manually-initiated events (light switches, etc) with pump run events would handle this; I'd be looking for signs of human presence without the pump running, which would signal a tripped breaker or failed float switch. Setting the syncrolinc was the hardest part of this -- it seems the ISY cannot set the full range of current draw in the UI for the device, so I had to go through a fair amount of pain to catch the pump in a "run" state to do the push-button gymnastics to get the threshold set on the device itself. Unfortunate bug, and one that seems to have been with the ISY for a rather long time. (Edited to add: I turned off load-sensing -- I do not want the the appliancelinc to turn the septic pump on just because the float switch triggered! That could be a Very Very Bad Thing -- since the tank (and filter) is a long ways from the panel and breaker to shut off the pump while I'm cleaning the filter, I use MobileLink to turn off the Appliancelinc while I'm cleaning it -- just imagine what would happen if the float switch tripped while I had the cover off and the cleanout open, and load-sensing happily turned the pump on... No, I DO NOT want that to happen!!)

I avoid surge outlets, and prefer outboard surge-protectors. I've had two lightning "events" -- one struck a tree about 15 feet from the house, the other (according to a neighbor) struck my ham-radio antenna on the garage roof. In both cases, surge protectors performed wonderfully - sacrificing themselves for the good of my computer and radio equipment. Because they were plug-in modules, replacement of the smoked surge protectors was trivial, which is not the case had they been wired-in. Since then I've added Insteon to the mix, and prefer to ensure that all my surge protectors are on the other side of FilterLincs - again, something you can't do if they're wired-in. (Edited to add: my PLM is plugged into the unprotected line -- but on the second floor, diagonally opposite the panel, in hopes that noise and sharp spikes on the line will be somewhat attenuated by sheer length of cable...)

If you are able to set up your own port forwarding, then by all means do NOT do UPnP! UPNP is a (poor) mechanism to enable a device to negotiate port forwarding with a router - if you can do it yourself, it'll be more reliable, plus you'll find troubleshooting to be easier IMO.

"If the Hub Pro goes offline, can I still use Siri to send out commands? If the Hub Pro goes offline, you will still be able to state commands, however the Hub Pro will not be able to process them." I laughed out loud when I read that gem. What a great way to say "No!" without actually saying "No". That sort of marketing drivel makes a used car salesman look like a paragon of virtue by comparison. On a serious note, I just cannot, having worked in the technology world all my career, entrust my home automation to an internet connection and some company's server, no matter what marking deodorant they spray over that (can anyone say "cloud"??). Siri, Echo, Hub, they're all the same -- a malfunction/leak/hack/latency/frustration just waiting to happen.

I cannot imagine being happy with the hub, after using an ISY994i. My biggest concern with a vacation property is that the hub is dependent upon Smarthome's servers, and thus requires an always-on Internet connection for all its features to work.

Can't speak for the original poster, but I use all z-wave for my door sensors because of the nasty All-ON bug that seems to be triggered by, among other things, Insteon motion and open-close sensors. I'm using several of the Aeon multi-sensors - they work very nicely on a power supply (I opted to avoid batteries on these because I could, and because with an external PSU they act as repeaters, and can update more frequently. I have the Aeon on-the-door sensor as well; nice unit, well-constructed, works as advertised. Compared to a couple of others, the Aeon units are better made (tamper switch is far more sturdy, etc), and another big plus is that the Aeon unit takes a standard battery. You'll need to make sure that you have coverage - I added the Aeon siren to my collection in part to satisfy that need, but also because Insteon doesn't have such a unit, so it was a very nice addition to the system. In general -- I've no ALL-ON events, I get a broader selection of devices to choose from, and with the ISY and programs, I can make the z-wave devices and the Insteon devices play well together. (The only downside is that there's a noticeable delay in an Insteon light turning on when triggered by a z-wave device, as compared to an Insteon scene doing the same thing).

Yes, others will follow the lead of Firefox - but there will always be an option, because there really are a lot of devices out there that cannot be upgraded. You may have to do some clicking to get rid of some ominous warning dialogs and such, though.

I've had significant troubles with my remote linc 2440 -- almost all of which have been resolved by replacing the batteries, and in the one case (the last time I had troubles) I had to clean the contacts for the batteries with a smidgen of sandpaper. I hypothesize that the 2440 is a current hog when transmitting. This would explain all symptoms: generally short battery life, inability to link when previously button presses worked fine (due to the longer "conversations" required when linking being affected by the characteristics of a low battery), and the malfunction when the contacts were slightly corroded (similar to the higher internal impedance of a low battery). Give it a try -- fresh, high-quality batteries, and brush the contacts and tips of the springs in the battery compartment with a little fine sandpaper or emery cloth, followed by a swabbing of same with a little 90% (or better) rubbing alcohol wipe-down. (And if my hypothesis is correct, then the most suitable batteries for the 2440 would be those advertised as ideal for motorized tools and toys -- which is the "consumer way" of the manufacturer saying that the cell has a very low internal impedance.)

MobilLinc is probably what you want for mobile. I find it quite usable on Android, I hear it's far better if you have one of those cult, er, I mean Apple phones!

I'm eager to see what someone (not necessarily UDI) might come up with as an alternative. Like shannong, I too hate Java. Not the language -- as a programming language it beats C++ hands down. Rather, I find the culture around Java applications to be very "hate-able" -- the assumption that memory is unlimited is pervasive with Java applications, and the general culture of "throw in every possible library that might be remotely applicable" make the apps a long, tedious download on anything other than those fortunate urbanites with FIOS. Combine that with a new release of the entire (huge) java run-time environment, each one claiming to be "critical" due to "security fixes", every month or so, and you can find that you're spending more time downloading and installing java and java apps than you actually spend running same. However, if you restrict the use of your ISY Java app to in-home only, then the security issues are less of a concern, so you skip a lot of the Java updates. And the UDI guys seem to have done a pretty reasonable job with the app (I've only had an out-of-memory crash once in a year now). So it's not so bad. Plus I limit ISY access to one machine (an older laptop), so I only have one Java install to deal with. Priority-wise, while I despise Java, and I'd love to see UDI dump it, I'd much rather see UDI offer bi-directional network operations in an upcoming release for the ISY.

I vaguely seem to recall that the LED is wired into the sense circuitry, not controlled by the micro in the I/OLinc -- which means that it is possible it may illuminate even though the micro in the device didn't sense the change. So, you cannot reliably use the LED's status as an indication of what the device actually reads. In other words, what I'm trying to say is that it's very possible that the LED is being lit by the voltage from the motion sensor, instead of lighting up because the input is seeing what the micro needs to see. Remove the motion sensor, and use a jumper wire on the inputs to the I/OLinc -- if you can see the jumper wire changes to state on the ISY, then clearly the problem is that your motion sensor is not providing what the I/OLinc requires -- as Lee G stated above.

If Insteon isn't dead, they're almost dead. They have a handful of products that everyone needs, and generally work pretty well -- switchlincs, keypadlincs, and perhaps the appliancelinc. And some of us on this forum have spend literally a thousands dollars or more on these devices. But lately they seem to be investing enormous effort and dollars in what seem to be "flash in the pan" or "grown-up toys" -- and while I too find it "neat" to be able to turn on lights from a cell phone, once someone gets over that novelty, it's hardly compelling anymore. The concept of the "hub" is a disaster waiting to happen - I just cannot understand how people think that placing control over their homes on some unknown third-party server in an unknown datacenter with no terms-of-service published anywhere would be a good idea! From a marketing point of view, I just don't see that those who would purchase these recent "toy" starter kits are going to be the ones that will spend upwards of 4 figures with Insteon. I think it's a good idea to expand into that market, but Insteon seems to be doing so at the cost of losing a lot of business from those who are willing to spend a lot more dollars with them -- that includes everyone on this forum, who ended up buying a device from UDI to manage their Insteon devices! Someone at Insteon needs to understand that almost every ISY sold represents money that Insteon *didn't* get. I'm reminded of the attitudes in Detroit when the Japanese automobiles started to eat into their sales -- and look how that ended for those Detroit automakers. Their abandonment of HouseLinc software is telling -- that bit of software should be a vital tool for everyone who owns Insteon gear, but they don't even support a device they introduced over a year ago! The only valid explanation for that is that they lack the staff and capital to update it. Finally, note the sales end of things -- the junk that Smarthome sells. All of this paints a picture that says that Insteon is going to be taking a huge fall relatively soon. I personally think the core technology is good enough that someone will buy the patents and designs and we'll see Insteon-compatible products in the future. So I'm delighted to see the focus on Z-Wave stuff -- it's future-proofed my home-automation to a great degree, by offering me an alternate to Insteon.

There's definitely a bug with the way the ISY handles keypadlincs - and I suspect the frustration felt by some of the posters on this thread is rooted in whatever this bug might be. Here's how you can tell if this is at the root of the problem -- select the keypadlinc in question, then in the diagnostics section, display the device links table. When that dialog box is completely populated (it will take a while), there's a compare button at the bottom -- click that. You've tripped this bug if the result of that comparison shows that there are differences between what the ISY thinks the links are, and what the device really has. If that happens, the only reliable way to fix it, and to restore your sanity, is to use the "restore" option to rewrite the entire link database to the keypadlinc. Then repeat the comparison above to confirm that this time the keypadlinc was updated completely and correctly. (And to those who would tell me I have "bad communications", you might be right - although I find that the numerous test scenarios I've used, which include a benchtop setup, make that unlikely. But even if it is "bad communications" the ISY should report that error and not leave a keypadlinc incompletely updated!) Try it - see if that is the root cause. I now compare each and every device affected when I make any changes to anything with the ISY - and my life has become a bit more tedious but a lot less frustrating as a result.

Pertinent topic Diesel tractors are particularly hard to start when the engine is frozen (diesel fuel actually turns into a gel below zero) -- I've a KPL button that turns on/off the tractor block heater, but I also have a weather station and it just never occurred to me to have that turn on/off automagically.

I agree - fix the problem, not the symptom! Try a filterlinc on the door opener(s).

Isn't that similar to what they said before Apple entered the cell phone market? Hmm... so I'd have to repaint my walls, because Apple will only be shipping devices in white?? And if they failed to turn on reliably, the fault would be mine for not "holding" my Apple switch correctly??