mwester

For those of us in cold places, we'd like to turn on the "block heater" and the "de-icer" or "de-icing cable"...

+1 ! Reviewing all the feedback, playing with my own installation at length, and reading up on the Amazon documentation on developing skills, I would agree that the "everything and anything" approach is just not compatible with the way Amazon has designed Echo/Alexa skills. Even if it worked perfectly -- actually, *especially* if it worked perfectly -- I'm not comfortable with having *all* my nodes available. There are a small few that would be very problematic for me if they were easily able to be turned off (in fact, I have watch-dog programs running that ensure that the "off" times for these devices is limited). So I for one would be very happy with a solution that exposes only a set of nodes to Echo/Alexa. Ideally, it would be excellent if the "spoken" field was the trigger for exposing a node (which would require that the "spoken" field be added to programs, etc). In the future, it would be wonderful if we could "annotate" a spoken field with metacharacters that could limit/control the values -- for example, a trailing exclamation point might indicate that despite the device in question being a dimmer, the only permissible values are "on" and "off". Something like "Counter%25" might indicate that the device is dimmable but only in steps of 25%. And "Basement Stat *2" might indicate that the thermostat named requires the value to be multiplied by 2 (i.e. the thermostat takes settings in 1/2 degree increments). My examples are sloppy and not consistent, but the point of this, when extended carefully, would be to move special cases out of the skill and into the control of the ISY user instead. That's all "blue sky" -- for an initial release, I'd be perfectly happy if this was done by some external means to the ISY itself (so that we don't require modifying any ISY code). Perhaps creating a mapping on the Portal would be easy. Another suggestion, although horribly "hacky" might be to read the "spoken" field where it exists on devices, and look for a specially formatted comment in a program to find the "spoken" value for a program, at least until such time as the "spoken" field is added to programs. Finally, if the skill's "learning" about device names is community-wide, rather than per-user, then it seems that we, as a community of users, should probably try to stick to some common names where practical. Perhaps we start with the list of examples provided by Benoit earlier in this thread, and add to it common other names? As a simple example, perhaps we would all get better results if we agreed upon "foyer floods" instead of a mish-mash of "foyer", "foyer spots", "foyer accent", "front foyer lights", etc, etc, etc.?

(Opinion Alert!) You're several years too early, based on what you describe. The device/control nirvana you want is just not available yet. Dada is doing a good "sales job" -- the reality is that there's just no "plug it in and it all works" solution. For example, Sonos remains a closed ecosystem, mainly due to the fact that they do not publish their API -- with the result being that hobbyists have to reverse-engineer the messages on the network and hope that Sonos doesn't change it. The ISY is a hobbyist's dream. Universal Devices is unusually open with their user community; it's a joy to work with the device and with the company that manufactures it (quite the reverse is true of the SmartHome/Insteon hubs). However, you'll not find the ISY to be a "plug something in and it magically works" sort of device. We'll see where the market goes. Apple has decided, in typical Apple fashion, that everyone else is stupid and wrong, and therefore they will design some custom hardware and strongarm the entire marketplace into doing home automation their way. Microsoft has jumped into the fray - and in typical Microsoft fashion, nothing much interesting seems to be happening. Google is getting in the game with Nest, but it's unclear if we'll see "Google outlets" and "Google lightswitches" any time soon. As for the hub vendors (smartthings, hue, etc) - in my opinion, the end-game for these companies is not to become the gorilla in the space, but to see if they can get enough market share to be purchased by one of the big boys -- they don't seem to be after the "big picture" but rather all seem to be focused on making your light switches and toaster controllable from your iPhone. That's not home automation - that's just remote control (moving the light switch from your wall to your phone). UDI, with the ISY, is positioned to be the one central control point for all these disparate "little things". But, alas, you need to be the brains that are going to decide what and how to automate. In summary - if coming up with creative ideas and implementing them is fun for you, you'll enjoy the ISY. If, on the other hand, you want things to "just work", you're several years too early yet. If, on the third hand you just want to play with light switches on your iPhone - go for the Insteon hub.

Hmmm.... So, finally success -- I got one (and only one) of my devices to work, for the first time ever, this morning. I managed this by picking a spoken name from the list of sample devices -- and lo and behold, doing so finally got something to work! It may indeed be that a device spoken name outside the provided list DOES work, but apparently there are limits to this. I am trying to imagine what Echo does with the sample devices -- perhaps it analyzes the list to find similarities of some sort in order to see if the device it THINKS it heard might be correct. If so, this would explain why spoken names that are completely correctly recognized (e.g. "fungus") do not do anything, just get the prompt "what device?" over and over. I presume then, that "fungus" -- even though that's what I put in the spoken name field -- is not considered valid based on some sort of parsing and matching on the example device list? Can anyone more familiar with how Alexa/Echo works comment on this presumption? Because it this is true, then it means that users have quite a chore ahead of them to find spoken names for all programs, scenes, and devices that meet this magical, mystical Alexa criteria! I'll continue playing to try to find out more on my own, but for now I'll just pick names from the sample list to get things working -- the WAF for this skill is bouncing around zero right now, so I need to demonstrate some success soon!

It'll probably work, but it sounds awfully "rube goldberg"-ish. Why not just use a power strip with at least three outlets, and plug two on/off modules and the always-on device into that instead - cleaner, more obvious as to function, and less likely to get into a bad state. Plus it's cheaper - the outlet on/off devices are pretty expensive.

First - a big thank you to the UDI folks for letting us all play with this so early -- it takes a lot of corporate courage to take a brand new relatively-untested bit of technology and let the world find all the bugs and problems with it! I've learned a lot about not just Amazon's echo but also about the challenges of dealing with spoken language. And then, for what it might be worth, a data point that I found interesting... I'm one of those who, thus far, have not had Alexa do *anything* right with the skill. In exasperation, a short while ago, I instructed Alexa to "tell izzy to go jump in the lake". Now I don't expect the skill to understand that statement, but I was certainly surprised when Alexa responded by asking me "get status for which device?" Something is seriously awry with Amazon's speech processing if it interprets "jump in the lake" as a status request! (And yes, I checked the echo.amazon.com page to confirm that it correctly heard me.)

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