mwester

Same problems noted above. I observed that I'm not very original in my naming -- and theorized that perhaps Echo is getting confuzzled with all the similar names for devices and scenes. So, I picked a test device and gave it a spoken name that can't conflict with any scenes, devices, or programs (I used "fungus" for the spoken name). Still no luck - it correctly understood "fungus" but couldn't find it. Some of the responses just made no sense contextually -- it was refreshing devices, and asking me if I wanted to wait, to which I would answer "Yes" -- and out of the blue it started offering help on devices (!??). Then later on, as it was prompting for the device name, it claims to have heard the word "yes". Which doesn't sound anything at all like "fungus", which is why it seems strange. It's as if it's a multithreaded app that's gotten threads confused somewhere...

i've converted several using this trick (after stusviews mentioned this in an earlier thread) -- very nice, and more intuitive to use. I use the bottom double button as an "all off", and control the main lighting for the area in question from the top double button. Definite improvement in the WAF.

I'm not suggesting that Insteon REMOVE the ability to do multi-way switching they way they do now -- that's a very useful feature for all the reasons stated. I'm suggesting that for those of us who already have the wiring in place for a multi-way switch that it would be very nice if Insteon would provide a lower-cost alternative that USES that extra wire, instead of leaving it abandoned in the wall!

Perhaps I'm missing something here... SmartHome/Insteon makes the device, but they don't know how it works? (I wonder if their hubs also don't support this thing... that'll make a lot of annoyed purchasers!!) Edited: Sorry, I didn't read carefully enough -- they're not saying that they don't know the API, they're saying that they don't know when they'll be able to share the API with UDI. I'm not sure that's better -- but at least it absolves SmartHome of gross ignorance!

Which is, actually, rather sad when you think about it. There's no real reason why they couldn't have implemented a companion-slave mechanism with an Insteon device; it would vastly reduce the cost of a three-way/four-way circuit! I suspect that the real reason, since it can't be a technical reason, is that a companion-slave switch would have reduced their net profits, and at the time Insteon was so far ahead of X10 that they felt no competitive pressure to do so. Now that Zwave, which DOES implement the companion-slave switch, is making inroads, perhaps Insteon will rethink this, and provide us with a lower-cost multi-way switching mechanism. I know I have a bunch of multi-way lights (one has four switch locations, the others are three locations) that I'm not intending to convert to Insteon simply because of the cost of multiple switches/dimmers -- I'm willing to spring for one switch plus some amount, but not 3x or 4x the cost! That's money Insteon/SmartHome is leaving on the table.

The ISY is event-based; it will not "busy-wait". Basically, the upon encountering the "wait one minute" it will schedule that program to wake up in one minute, and go do something else, and if there's nothing else to do, it will go watch "Judge Judy" on TV or whatever it is that the ISY CPU does when it's idle...

I've been surprised by mid-model unannounced changes in functionality with some of the older devices that I purchased used - I found the following reference pages to be very helpful in determining if a specific device model with a specific firmware has any "gotchas". I just skimmed it for the models you described above, and found no listing of them, but I may have overlooked it. http://www.madreporite.com/insteon/Insteon_device_list.htm As you can tell from the notes in the list, and indeed from the fact that a third-party list such as this needs to be created and maintained by the community, SmartHome does a dreadful job with release notes, and in my opinion, they do a poor to at best passable job with firmware quality in almost every regard. It certainly is a shame that they do not support firmware updates; it would certainly boost customer satisfaction!

I'm just next door (well, sort of -- a state away). I've been using the older ApplianceLinc's in a pole barn to turn on/off block heaters, turn on/off the ice-melting cable on the roof, and the same building has a bunch of ancient Insteon switches, a newer keypadlinc, and (oddly enough) one of the Insteon LED bulbs. Not a one of these has had any trouble attributable to either summer heat or winter cold. (They have trouble communicating when the welder's running, but that's not unexpected!)

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.