mwester

If you have an elk, there's probably an elk-based solution for you... but, I don't have an elk, so I opted to go the z-wave route. I use the Linear GD00Z zwave garage door opener. It's a secure device, has the alert-before-operating feature, and if your door currently works with the IOLinc's relay you just connect the two wires you currently have on the IOLinc to the Linear device and you're done with the wiring! (The door open/close sensor is a wireless tilt sensor, and just attaches to the top door panel with tape or screws, real easy.)

ROTFL!

It works very nicely with 5.0.2 ISY firmware

Done - I removed everything from the portal and added in one scene and one device with simple spoken names. Then ran discover from the echo.amazon.com web page -- it found the two new items and added them to the existing 18 items I have defined using the Hue emulator. The two new items work exactly as expected. (Edited to add: neither spoken word will work with the skill - but work just fine with the connected home integration!) Very nice. Now off to try some more interesting things - some programs to manage timed things, like engine block heaters (it's COLD here!), and add my "good night" program...

You're clearly frustrated - you expected "reliable" to equate to "noise-tolerant"; that's simply not the way it is. It's rather like comparing a HAM radio operator sending Morse Code with the Internet. Morse Code has no error detection, and no error correction, is limited in terms of what it can send, but oh wow -- the ability to pull a signal out of the noise with a simple on/off Morse Code signal is unbelievable; in fact there's just nothing better ever invented in the presence of weak signals or noise. And so it is with X-10 -- whatever type of problem (noise, or weak signal) you have, the X-10 signal is punching through. And, as far as you know, it's always gotten through correctly (but there's the rub - how do you know? Just like the old telegrams, how do you really KNOW that when the message says "Dick fell off the haywagon" that it wasn't Rick or Nick?? You didn't back then, and you don't with X-10 either - it's just that apparently if it was ever wrong you didn't notice, or perhaps you just didn't care...) If the X-10 stuff works, and you're unwilling to find the noise or signal sucker, that's fine - go with what works for you! Using another analogy, farms with the new-fangled tractors co-existed with farms using the time-tested, reliable, trouble-free, works-great-with-nothing-but-hay-and-water horses...

Nothing changed when I installed the network module. Some new features were available on the Admin console UI, but aside from that, there was no impact to any scenes, devices, and certainly not to any programs. So I would suggest that either your troubles are due to the upgrade, or they may stem from PLM problems (which may have only become apparent after the PLM was power-cycled a few times during the upgrade process, perhaps?) If you can provide some additional information, perhaps we can help debug this a bit. Start with confirming your UI version, and the firmware version on the ISY, then paste the source code for one of the failing programs along with the event log covering the time frame from the event that should have triggered the program through the execution of the program.

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