mwester

But, at the risk of side-tracking the conversation, this does bring up an important and interesting issue regarding home automation in general: liability. In particular, we've had a lot of threads involving controlling heating equipment - perhaps because I live where it gets really cold in the winter I'm particularly sensitive to the risks. Not to mention that I live in a rather litigious nation. We've had a number of threads that have discussed using ApplianceLincs and other On/Off relay devices to control pumps, blowers, and the like... I just wonder when Joe Average follows instructions on some post to do this, and comes home to burst pipes and a frozen house, will he sue UDI? SmartHome? Or hire a lawyer to try to track down the posters on this board and sue them? Other idle speculation... I wonder when someone will sue Google (they have buckets of money) because Grandpa ended up hospitalized with hypothermia, because the Nest thermostat, being unable to detect a lot of motion from Gramps who's bedridden, turned the heat down to 60 degrees... Or when Charles Chef-Wannabe sues because he cut his thumb off while chopping onions when his ISY/PLM combination issued the dreaded "All ON" command and blinded him with the kitchen floodlights on at max power... Or when Mike Misguided finds out his insurance company isn't paying out in full, because they determined that his Insteon-based "so-called-security-system" isn't really a security system at all... Final bit of speculation here, perhaps some on this forum may have an answer to this one -- do installers of this stuff carry the equivalent of "malpractice" insurance, in addition to the normal insurance contractors carry? Just wondering about the legal aspects of all this...

Get a Raspberry Pi, a cell phone charger, and a roll of electrical tape -- tape the Pi to the back of the cell phone charger, plug it into the wall, plug an ethernet cable into the Pi, and think of it as a vastly-superior version of the Insteon Not-So-SmartLinc device!

Recent Insteon devices have removed the "All-ON" and "All-OFF" capabilities -- it's far better to expressly declare what is to be turned on, and what is to be turned off, rather than blindly issuing network-wide commands to turn on or turn off. Simply create a scene named "all-lights" or something, add all appropriate devices to that scene, and use that scene instead. [edited to add: I'd also suggest the use of some ISY programs to help out those older devices -- you can create a program that checks on a variable that is set on ISY boot to a specific value, and upon finding that value it can assume a power-fail may have occured, issue the appropriate off commands, and change that value to mark that it's done so. You could also have some watch-dog programs that can monitor how long those 8000 watts have been running, send alerts, and finally just turn them off...]

Suggestion: (based on what worked for me when I switched from Houselinc to the ISY) Take the opportunity to reconsider what should be linked and not -- factory reset all the devices, and leave them that way for a day or so. Periodically during the day note the most annoying things that don't work -- and if you don't live alone, have other do that as well. Collect all input, and you might be surprised at how may "critical" functions really aren't so critical. I know I was! (As a specific example: I ended up with only 4 scenes for the kitchen, replacing the 8 scenes that I originally set up. It turns out, for example, that nobody thought it was a good idea to have the over-sink light controlled by a button on a KPL in addition to the switch by the sink. The KPL button that turned on the island lights ended up swapped for the paddle switch that controlled the hallway - turns out nobody but me ever turns on the hallway light from there, but they always want the island light on. The net result of this simplification was a huge improvement in the WAF (or more politically-correctly, Spousal Approval Factor))

This past year hasn't seen any big purchases from me, and this most recent sale was no exception - I'm expanding with z-wave, primarily, and picking up switchlincs and similar items at the local Menards store (I also grabbed some Insteon on/off switches and LED bulbs for a real bargain when the local Walmart clearanced them off). The only item on my list from Insteon is a spare PLM - but I'm putting off that purchase as long as I possibly can in hopes that someday someone will find that elusive "All On" bug and fix it (if it happens that fixing it requires a new PLM, I'd rather not be stuck with an old spare -- oh if only Insteon devices could take firmware updates!)

I don't recall the firmware version on my similarly-behaving kpls -- but I definitely have a pair of them where the LED indication does NOT always follow the always-on or always-off mode. I fought with these for days, resetting and changing the mode with the buttons lit and not-lit, until finally I got them to the state where my LED would be always lit (which is what I wanted). Then, one day I noticed that one of them had reverted. So, I repeated the entire painful process several times until I got it back to behaving. Weeks later, it reverted again - LED off, would blink on press, and return to off, which is exactly opposite of what I wanted. I actually left it that way for months until a sudden flash of inspiration led to a solution: a) set the KPL button to the correct mode (always-on, or always-off), ignoring the state of the LED. b ) create a scene that to be used for nothing but resetting the state of the involved devices - it should include all the KPL buttons that need their backlight state adjusted as responders, with the level set correctly. c) turn on the scene from the ISY admin console (which is the only way to do it, since it has not controllers listed). If you're struggling with the same problem I've had, then this process will preserve your button "always-on" or "always-off" configuration while allowing you to control the LED light status independently. Note that once in a while you may have to repeat step c above to reset the LED -- for me this seems to be associated with a comm error or something like that (the KPL will beep when I press a button, and the load won't change state, and the LED will end up in the wrong state again... I hope I've not interpreted your problem incorrectly - if so, just ignore this post entirely. Edited to add: 2334-2 with v43 firmware on both of my odd-ball KPLs...

'Tis true that the component cost is minimal. However, what I've learned from my customers who have product manufactured in China is that there are huge problems in oversight of the manufacturers. More specifically, I've been told that you can specify certain critical components, but ensuring that your manufacturer doesn't substitute cheaper components (and pocket the difference) is a huge problem. I suspect that at least part of the problem is that Smartlabs/Smarthome/Smartwhatever doesn't have what it takes to keep their manufacturer honest.

They're giving away their hubs, practically -- so they have to keep prices high on the rest of the stuff so that they cover the losses. That said, they have a problem - three way circuits are so common now in homes (some of them convenience but many mandated by code), and the Insteon solution for three-way circuits is identically-priced switches at each location. The z-wave folks have created, instead, a solution where there's a very low cost "slave" switch and a single master. Technically, there's nothing preventing the creation of a master and slave switchlinc set, where only one has electronics (the other being nothing but a dumb switch) -- other than the fact that they're busy spending all their money and time on multiple hubs and "cloud" stuff. Another example: consider garage door monitoring -- Insteon is still selling the rather hacky solution based on the IOLinc and to top it off they ship the wrong sensor, while Linear is selling a proper garage door system, using a secured device and including the required 10-second delay and visual flashing light notification. And the Linear solution is really only slightly more expensive than the Insteon hack. Z-Wave and Zigbee pretty much own the creative wiz-bang stuff (Hue bulbs, LED strip lights, multi-function sensors, even useless things like electronic egg containers for your fridge!). I think the thermostat battle is over too - and Insteon didn't win that. Insteon never even really put a horse in the race for door locks (the most common vendors, Schlage and Kwikset, are both Z-wave). I guess if you consider the Morningstar thing to fit the door lock need, then maybe they did try to get into that market - but once again, the price was outlandish compared to the entire Kwikset solution. So, when you look at it like that, it just makes all the sense in the world to get the ISY Z-wave module, and start investing there. Cheaper, and in many cases, better. (Hopefully, when SmartLabs/Smarthome/whatever goes bankrupt, the buyer of the Insteon technology will see the wisdom of opening up the protocol to other vendors so that we can have, like Z-wave, X10, Zigbee, etc, multiple vendors working on the devices. Competition is healthy for everyone; it may result in having to share the pie, but the pie inevitably ends up much larger!)

All very good points above! It surprises me that so many people pamper, for example, their automobiles by parking them in a garage and by letting them idle for a while to "warm up" before hitting the road on a frigid winter day, etc -- but they abuse their homes by putting a massive set-back on the thermostat and putting a huge temperature stress on their biggest investment. False economy - not only is that not really saving any energy, it's also (as noted above) potentially damaging to the house itself. We should be using home automation to monitor and maintain a constant, consistent in-home environment instead.

As I understand it, in order to add your own custom command structure (i.e. something that does not fit into the existing phrases and commands that Alexa understands), you need to write your own "skill" - which is a significant programming effort (Java coding), and requires that you have a server up and running to run the skill software code. So, the answer is that yes, indeed with enough effort you could make alexa understand any custom commands -- but in reality, there are very few Echo owners that are capable and even fewer who will be willing to do so!

Yep - agreed! Suggestions are great, but this is try #3 to get this integration into the Echo skills list -- at this point I think the priority needs to remain on getting this through Amazon's process so we can start using it, and thus provide more pertinent feedback for a future release. (I've been checking the Echo skills list daily for weeks now, waiting for Amazon to get this done...)

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