mwester

Not really - no news in this case merely means no news. What I've gathered from the various threads on the "All On" issue is that: - the new PLM firmware from SmartHome/SmartLabs does NOT necessarily fix the problem. - the new PLM hardware does NOT necessarily fix the "drop-dead-at-two-year-mark" problem. - UDI has still not been given access to a supply of PLM chips which which to build their PLM. The above has a measure of speculation, but it's enough to be quite distressing (and make me build out my z-wave devices rather than insteon devices)... Perhaps UDI can drop in on this thread and provide a definitive update?

Reality isn't sexy. Hence I don't pay too much attention to CES - it's all about "marketing sizzle" sorts of things, rather than a forum for practical, day-to-day-useful products. Expensive toys, mostly.

True enough, I expect I'll end up with some Insteon devices that are a bit back-rev. But unlike the PLM, I don't anticipate any significant, material modifications by SmartLabs/SmartHome. The issue with the PLM is the combination of the not-yet-solved "All-On" problem, the general distrust that the "dead-after-14-months" issue is really fixed, and the unreleased-but-discussed UDI PLM -- any one of those is significant, but together they make the purchase of a spare 2413S PLM just not something I can recommend. If mine fails -- and that'll happen soon, since I'm coming up on the 2 year mark -- I've got a set of capacitors handy, and I'm just going to be hopeful that I can get a replacement quickly.

I have more spare Insteon devices than I have spare light bulbs. But in this case, I'd NOT keep a spare PLM on hand, for the same reason that I don't keep spares of the 100W Cree LED bulbs -- I am in fear of a significant product update leaving me holding onto an unused device that I'd be tossing out...

I'd love to be a fly-on-the-wall in the SmartHome/SmartLabs conference rooms when the topic comes up -- I'd also love to know the gory details of the discussions with UDI regarding the PLM chips that they won't sell to UDI... I imagine the conflict must be significant - on the one hand, SmartHome is almost certainly looking at all the ISY's sold and realizing that all those customers are not "captive" (i.e. are not beholden to SmartHome for their servers to do their automation, and thus not potential revenue generators when SmartHome inevitably starts charging a monthly service fee for "premium" hub support). On the other hand, they must realize that they really don't have anything that competes with the ISY in any real fashion, and that they would lose those device sales. On yet a third hand they probably look at the addition of Z-Wave support in the ISY as a major threat to their device sales anyway... and there's probably a fourth hand that Iv'e not considered. No matter how you look at it, Joe has some tough decisions ahead. But after getting to know SmartHome/SmartLabs a bit better, I predict that the decision will be this: make no decision at all, just slog ahead with more half-baked ideas, hoping that the market will magically transform itself and SmartHome/SmartLabs will reap huge benefits simply by the luck of having made no *bad* decisions... rather than the hard way, like most other companies, which is to make the *hard* good decisions!

Why not just create the scene on the ISY, and set the ramp rate there? That'll not only be easier, but it avoids confusing the ISY (because it won't know about the links you've manually created).

This isn't a REST or even an ISY thing - this is an Insteon design thing. Basically, you cannot directly control the LED for a keypad (other than the main button that is wired to the load, that is). Instead what you need to do is create a scene, and assign that keypad button as a responder to that scene, and then send an "On" or "Off" to that scene instead. It is sufficient to have nothing but that one button as a scene member -- I do this for a number of buttons that I use as status and alarm indicators.

Try restarting the ISY. That's probably a bug, since I didn't find it documented anywhere, but when I re-added a deleted device (after a device replacement), it failed time and time again, until I reluctantly tried the "Microsoft Windows" Universal Fix -- rebooted the ISY.

Quick question: does the ISY use the TTL logic level serial port connections, or does it use the RS232 logic level connections? (I did search the wiki, and the forum, but if it's there I didn't use the right search terms to find it.)

So what is unique about the "all on" command that makes it the ONLY one that EVER gets "auto-created" by RF message collisions? As Xathros says, what more can we (user community) do? Not much, I fear -- other than keep the involved vendors' collective feet to the fire. There is something unique about the ISY/PLM combination that does this, and I have to say that I'm disappointed in the response, which seems to be utter and total silence by SmartHome and "We don't know what else to do and we think it's SmartHome's problem" from UDI. There IS lots more that can be done. I've said it before - here it is again -- start with something simple, a cheap device (arduino based) that functions as a data logger on the serial port between the ISY and the PLM, logging every character it sees coming and going with timestamps and sequence numbers. A simple I/O Linc device will serve to detect the "All On", which the logging device should treat as the signal to write the last 10 minutes (or whatever) of data logged in memory to an SD card. I'm suggesting this because it's cheaper to send a bunch of these out to those plagued by "All On" events than it is to send a full-fledged logic analyzer with operator to each site. Once this data is collected, we can then use it to confirm some facts: a) Does the ISY, in fact, generate an "all on" message and send it on the serial port? Does the "all on" message occur only when certain other messages are sent (i.e. correlation)? c) Is there any message coming FROM the PLM that might alert the ISY that this event has happened (i.e. possibility for correction)? Another possibility is to change out the PLM from serial to USB -- perhaps this problem is avoided on SmartHome's USB PLMs. In order to test, again one can use a simple outboard device -- the device (perhaps a Raspberry Pi) needs to connect to the PLM (easy, just plug it in), and to the ISY (needs a USB->serial converter, but that's not too hard to find). A program simply copies the bits from one port to the other - really, really basic stuff. I suspect unless a firmware mod is made on the ISY, the program would have to fake out the identifier from the PLM if the USB PLM identifies itself differently than the serial one... again, can't be too hard. (hmmm.... I think my serial PLM is failing, I've some comms errors and it's at the 2 year mark... I have a USB PLM in a box, and I have a raspberry pi on the bench, and I have a USB/Serial adapter, and I have some connectors, wire, and a soldering iron... perhaps a New Years day project to see if I can make this work... )

Oh dear - don't do this! While it *seems* to be making life easier for yourself, the fact that it works as well as it does for you is due only to good fortune and luck -- neither ethernet nor the TCP/IP protocol is designed to handle this. And, as you've observed with the ISY, any devices that enforce uniqueness (which is usually associated with security) will have problems with this. The right way to have solved this is the use of DNS entries (aliases), so that the hostname (for example) "weatherstation" will resolve to a different IP address on each network. This is how most networks that permit "generic" names operate -- for example, for one of my previous employers, each field office could assume that "hp" was the local printer, but the IT admin knew that each printer had a unique IP address, which allowed him to easily connect to the printer that was in Detroit versus the printer that was in Chicago. I realize that you may not have plans to ever have your networks interconnected, but nevertheless if you have a computer that might live on both networks, it's still better to follow the de-facto standards for networking and use DNS names instead of duplicate IPs.

Yes, the Polyglot implementation is bi-directional (unlike the network resource technique, which has no way to obtain the current status of the hue bulbs). It polls the Hue Hub every second for status, so it actually feels very responsive.

The short answer: a Polyglot node server is a Raspberry Pi that is running UDI's Polyglot software. One of the challenges with ISY controller is that UDI, the creators of the controller, need to make an update to the firmware in order to support new devices and types of devices. It would be great if there were a way to do this without requiring UDI and firmware updates -- this would not only allow third-party companies to issue "drivers" for their products to add support in the ISY, but it would allow the community to contribute (or even possibly sell) drivers for devices. And even UDI might use this to add support for a new type of device without re-releasing an update for the entire firmware for the ISY. In order to make this happen, the ISY controller, with the 5.0 versions, uses the generic concept of a "node" to describe any device that it knows about, regardless of type of device (Insteon, Z-Wave, etc). The concept of a "node server" is to support nodes (devices) that the built-in firmware doesn't handle. A node server is an external network device or computer that communicates with the ISY using a very specific set of network commands - it could be a custom "black box", but it could equally well be a Window computer, a Linux computer, or even a mainframe if you had the right software and networking on it! The ISY, when faced with an action to be performed on a device that is not one of the built-in types, will look at the device record it has in memory in order to find out which node server manages that type of device, and then using those specific network commands, it will forward that action to the node server device or computer to be processed. Polyglot is a software package provided by UDI that runs on the Raspberry Pi computer and implements a set of node servers - the first one being a node server that knows how to talk to Hue Hubs. It's also extensible, so that developers can easily create their own custom types of devices. There are other node server implementations already being used, so the concept seems sound even though UDI's Polyglot package is still in "beta" and not generally available yet.

We have guests visiting -- international, and they've never had any direct exposure to Echo/Alexa before. In the chaos of arrival, I asked Alexa to turn off the porch light - the echo did so. A few minutes later, when one of the guests went out to the car and returned (with arms full of suitcases and packages), she simply asked Alexa to turn on the kitchen lights. Of course, the echo did so. She wasn't surprised at all, she just assumed, having seen it work with the porch lights, that it would work with the kitchen lights too. That's an approval factor for home automation that's just off the charts! The KPLs I've installed and set up are cool, and scenes do neat things, but I usually need to at least provide some guidance to guests (eg: "Yes, that's the light switch, among other things"). In contrast -- the integration with Alexa was just completely natural. No explanation necessary. I'm now completely convinced that voice control is not only possible and even practical, it's also a natural way to interface anymore. (Once the holidays are over, I'll be moving a bunch of switchlincs to other high-traffic areas of the house, and expanding the scope of my Echo/Hue Emulation implementation; it's clearly the right way to go!)

Works for me I'm actually using 5.0.2 and the new Polyglot node server with Hue support right now - and can change the color and intensity quite easily. However, the node server implementation does not yet support some of the "cool" features of the Hue that I use (I use the Hue's notification feature to blink one of bulbs when a door sensor indicates that an exterior door has been left open too long). So for that feature, I continue to use network resources. The two approaches co-exist nicely, which is great because each has some complementary features that the other lacks yet. The one big PITA is that the Hue bulbs do not return to their last-known state after a power failure - they turn on. I don't find this a big problem, since they're LEDs and neither generate enough heat to be a concern nor do they consume enough power to be worrisome for the few times this actually happens. I guess i could write an ISY program to turn them off when the ISY boots up, but it's just not a big enough deal for me to have ever gotten around to writing that simple bit of code

Awesome! This feature is significant for me -- it makes access to my home automation so much easier whilst traveling. Thanks!

Quick question, since we're on the topic -- Can I replace a KPL relay device with a KPL dimmer device using the ISY "replace"? If so, I'll do a quick swap this evening before the guests arrive, otherwise it'll be a mess of scenes and devices to update and I guess it'll have to wait until the new year... Thanks!

I expect Techman is correct -- I had similar issues with my two kitchen keypads, which were frustrating everyone here (obviously heavily used scenes!) There were two problems, first was that one of the KPLs was missing some links. This was revealed using the diagnostics/compare as Techman recommends. The other issue was a general comms problem on one of the kitchen lighting circuits - this was uncovered when I noticed that multiple diagnostic/compares of the same KPL, with no intervening changes at all, resulted in vastly different results! Bringing up the diagnostic window to view the traffic, and setting it to the max (to view all traffic) showed the hop count issues to all the devices on one circuit. A FilterLinc fixed the comms; a "restore device" fixed the link issue. All has been well since.

What type of host is the VM running on? Might it be possible to just run the Hue Emulator on the host instead? If you do need to run the emulator on the Windows VM, that should work as well - pretty easily. Far more challenging may be getting the necessary ports opened on the Windows firewall and ensuring that you have the correct type of networking set up for the VM so that it can fully participate on your home's network, which varies by the type of VM software you're using -- but most refer to it as "bridging".

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