mwester

Probably before you add the lock (they seem temperamental devices), it'd be best to install your other z-wave devices first, in order to establish the mesh you'll need for the lock to work reliably. When adding a device, it's best to attempt to "exclude" it first -- often that doesn't appear to do anything, but it helps to ensure the device isn't already added to some testing system they used at the factory, etc, etc. When you get two or three non-battery z-wave devices added (battery-powered devices don't act as repeaters, and therefore aren't really part of the mesh), then add the lock -- use the same process (attempt an exclude first, then an include), but make sure that the z-wave option to include *securely* is set (so that the lock and the ISY exchange security keys at time of inclusion, which is required for the lock to function with the ISY).

Oh yes, LED bulbs can indeed be noisy -- they have the same switching power supplies that other electronic devices have (and size of the device is NOT an indicator of the noise introduced, rather it's dependent on design, and usually correlates with quality...) I use the Philips Warm Glow LED bulbs, they are pretty well behaved. I've had mixed results with others. They also fail in odd ways -- my Insteon switch for the outdoor lights on either side of the garage door suddenly wouldn't turn off anymore -- went deaf, but only when it was turned on -- turned out that one of the 25-w LED bulbs had failed in such a way that while it still delivered all the light that it should, when it was on it generated enough noise to render the switch controlling it completely unusable. Switching to a better LED bulb fixed that.

Reasonably stable -- there's a handful of relatively minor bugs, and I suspect the real reason it's still not released is based on some features yet to be added, not based on lack of quality. Read the thread carefully, especially the part about your passwords being reset, and go for it.

Insteon as we knew it is dead. The new Smarthome, with new leadership, doesn't know who UDI is, what an ISY is, and they don't care either. The new MS (and any other Insteon device they might happen to release) won't ever have it's API released to UDI, because that's just not in the business plan for the new Smarthome. The above is not really my opinion -- I know that there are those who vehemently disagree (they'll be posting shortly on this thread) -- but I think putting the above on a post-it note on your computer monitor is wise, just so you can make absolutely certain that you really want to do this when you click "Buy Now" on that order for more Insteon MS devices... (My real opinion FWIW: the new Smarthome is still thoroughly confused by what they bought when they acquired Insteon, the PLM, and all the users that come along with it -- somebody thought they were just getting into the way cool, awesome IoT market, and discovered that there's more too it than little boxes and cloud servers, and that it's those little details like capacitors and noise and FCC approvals and UL certification and, etc, etc. that matter. So, not really a matter of kicking UDI and all of us to the curb as unwanted customers, but in the end, the effect is the same -- make sure, absolutely sure, you really want to invest further, especially with devices that aren't supported now, and may never be... (and I'd love to be proven wrong on that point, let's see if 2018 will bring an API document to UDI...)

Time lag, excessive Insteon traffic, and general uncertainty (is the door open, or closed, or should you wait a few more minutes and check again -- and if you can't rely on it, why automate it in the first place???)

No, the "10110" icon indicates that the ISY has queued up updates (such as a parameter change or a link-table update) for the device, but for some reason or other, it has not yet been able to do the update of the device. This is often associated with "link mode", but the ISY does not require a device to be in linking mode for the update -- it's just that when in link mode, a battery-powered device stays awake, making this update easier to perform.

And, if you think about this carefully, this seems almost tailor-made for malware... if you can somehow sneak a simple trojan into someone's home, it needs only the most rudimentary code to exercise this same uPnP code to ask your router to open up a port for some hacker to use, and then take the IP address so graciously offered by the router after it flings the doors wide-open, so-to-speak, and present that IP like the keys to the castle gates to said hacker for his/her enjoyment. For that reason, you should ALWAYS disable uPnP on your router!

If you are using the portal, there's nothing at all that needs to know your public IP address -- the ISY makes an *outbound* connection to UDI's portal servers, which obviates any need for anything to know your public IP.

There's another thread here where I've described my solution in detail -- the syncrolinc failed miserably because it's fused, and caused a failure. In a nutshell, what you want is to search eBay or Amazon for a "current-operated switch" -- these are squarish plastic-encased devices with a hollow center through which you run an insulated conductor (either the hot or the neutral, doesn't usually matter) for the line you wish to monitor. It has a couple of screw terminals on the top, which are connected to an internal solid-state switch that turns on or off (depending on model) when the current exceeds a preset threshold, usually adjustable via a screw and set of jumpers. Connect those screw terminals in the correct fashion to an IOLinc, and you have a far better solution for current sensing than the Syncrolinc ever was.

People seem to think in terms of "things" -- and as long as the conditions and actions associated with "things" are relatively simple, the "thing" approach offered by the ISY's programming language works just fine. If you have non-simple things -- lots of other conditions, or where the "then" or "else" clause has waits embedded in them, etc, then you quickly find that ISY's programming language just makes your head explode. In those cases, programming in terms of "events" is almost always easier, and almost always results in fewer "surprises" (aka bugs). At least in my experience -- I suspect this varies based on how one learned logic and coding, and may even vary depending on how individual brains are wired...

Been tinkering off and on with the 3D printer to see if I can make a replacement for the KPL buttons (which has worked pretty well). I can see if I can dig up the STL files for those, if you're interested. The issue is the finish on the face of the button -- it'll need to be filled, sanded smooth, and painted or laquered in all likelihood. (I've also been working (again, off and on) with making a replacement for the entire KPL faceplate -- with custom-sized buttons. The external geometry is done, and works great - now I need to work on the buttons themselves and how they link to the frame geometry. That project isn't ready yet, I'm afraid...) (Edited: found the source code for the KPL button generator -- and attached it. It's written in SCAD, so very easy to edit to tweak for your printer and filament characteristics. By default it generates three individual buttons (aka "chicklets") -- one double-wide standard, one small standard, and one double-wide that straddles two small buttons (i.e. a double-wide button that covers the "C" and "D" buttons on a KPL). If you prefer not to mess with SCAD, I've attached the default generated STL, which works great for me on a Lulzbot Mini, with ABS filament.) KPL_chicklet._new.scad KPL_chicklets.stl

Yep. I've replaced a couple with this issue -- one switchlinc that wasn't too painful, as it truly was ancient, but I also had a bad KPL and that hurt (much more $$ + it was just out of warranty period...)

You'll get lots of divergent opinions. I'll start: avoid Insteon, even if it means compromising on the multi-button devices. In a nutshell, at this point in time there's been no public announcements of direction from the new owners of the company, and based on the past year's product announcements, as well as announcements at CES there's simply no evidence of any new products or any new product development -- something sorely needed since Insteon's technology (as well as the protocol, both on the power line and over-the-air) is lagging far, far behind the others in this field.

A thing of beauty it is not... but immensely practical. And a lot safer than a tangle of wires on a workbench, waiting for a short circuit to happen!

Load sense. Various Insteon modules will send a very small trickle of current downstream after the relay, so that they can sense when the load is turned on or off (or plugged in or out, in the case of xmas lights). This allows them to turn on when a user (for example) turns on the floor lamp with its switch - a nice feature. It can then send a signal to other nodes in a scene informing them as well -- another really nice feature. Alas, to make this work, it is necessary to run that trickle of power. And it turns out that up to a few years ago nobody would ever notice that, and then we all installed those highly-efficient low-current-draw LEDs, and suddenly that teeny trickle of power is enough to make the lights actually stay on! There's no setting to change - you can turn off the load control feature in the settings menu, but that just changes the logic - it does not (and cannot) remove that trickle of power you're seeing. Sorry.

If you are wondering if its possible for a new Insteon device to be designed so that it doesn't need to be manually awakened, the answer is "Yes" -- newer Z-Wave devices do this with a feature called "beaming" (a very poor name, as it implies the wrong thing, but be that as it may). However devices need to be designed to work with this sort of technology, both the sending (powered) device and the sleeping (battery) device. For current Insteon products, there is a way to run a program when the device triggers, and force any updates to be applied. I'm not sure, however, that this technique will work for the heartbeat, or if it requires the actual triggering of the device (which would be a lot harder to do for a leak sensor than a door sensor, for example). And, of course, this will only work if the device is still linked correctly to the PLM -- so things like PLM replacements will never work with this. I've used this technique with an Insteon motion sensor, so my experience is limited -- perhaps someone knows if this works with the heartbeat from devices like leak sensors, etc.

It's not just a matter of supplying DC power -- the Insteon devices also require access to the AC signal as well in order to receive/inject the power-line communications signal, and for the RF side to coordinate its transmission. So, power-supply repair is required; replacement with an external source is not a solution.

My current network uses a single flat subnet -- so everything on the LAN can talk directly to each other, without involving any firewall or anything that can monitor that traffic. I was only interested in monitoring and controlling what various devices did with inbound/outbound internet traffic. That was 2017 -- my resolution for 2018, based on the increasing volume of IoT-based security vulnerabilities, is to actually segment my LAN into different spaces that cannot communicate except through firewall rules (as suggested by Scottmichaelj, above). This will certainly complicate my experimentation, but I too am worried that someone may gain access to more critical and valuable data on my LAN by using a compromised IoT device. (And I guess, as I think about this, that I should lump all my audio/video devices into that same controlled/restricted category -- I suspect that the FireTV stick, the Sonos units, etc, are also likely to be hacked...) (Thinking about this even more, it almost seems as if I need to do the opposite: segment the few devices that hold truly valuable data into a secured subnet, rather than try to lock out the IoT, Audio/Video, and guest access... but with Windows 10 calling back to Microsoft every few hours with all your personal information, is there really a device in your own home that you can trust???)

I have all my IoT devices on specific IP address ranges, and have my pfsense firewall configured very carefully. To oversimplify, basically the ISY is the ONLY IoT device that is allowed to make unlimited outbound connections. The Amazon Echo isn't in that address range -- I considered it an "audio/video" device when I installed it originally, so it's in that address range instead. I should probably reconsider that, and start watching/logging exactly what it's sending to whom... Thanks for the heads-up on this.

Insteon is just as "fractured"... I1 -- and I2 -- and I2CS -- and no good way to determine which protocol is used by which device, and sometimes it even changed with the version of the firmware in the device. And then there's the RF -- some devices have it, others don't, and again, no good way to know which ones are RF, and which are not other than the advertising glossies (or tearing the device apart). Some devices support peek and poke commands, others don't - and sometimes the version of the firmware matters when determining if peek and poke work. The difference is that (recent history aside), UDI and the ISY *know* about all the quirks and capabilities and even bugs in each device. We'll need to develop that for the fractured Z-Wave space, that's all (other controllers are already doing that, so it's something that's possible -- which doesn't seem to be the case with recent Insteon devices, alas.)

I've found that recording the state of the light in a variable, state or otherwise, is unreliable (old programming maxim: if you have multiple copies of something, it's correct in at MOST one place...). So, my solution is to dim the light to slightly different levels based on how it was turned on, and then it's easy to have a program determine if it should turn it off or not. As a simplified example, every evening my mudroom light turns on at 41% for a few hours (so the dogs can see their dinner while they eat...). There's a door sensor as well -- and it triggers a program. If the "door-opening" program observes that the light is at 41%, then it sets the light to 91%. If it observes the light being "off", it sets it to 99%. If the light was at 100%, then it leaves it at 100%. Then it arranges for a "light off" program to run after a short delay. The "lights off" program checks the light's level: if 91%, it sets it back to 41%. If 99%, it turns it off. If 100%, it was originally turned on manually, and it leaves it as-is. It's actually a bit more complicated, since there's also a motion sensor, and the dog's lighting is dependent on sunset, etc. But you probably get the idea - use programs, and set the light level itself to record the state it should be returned to.

No, with a common ordinary UPS used for computer sorts of devices, you will NOT get the PLM to communicate through it. And in fact, at least on the line-side of the UPS, it will put enough noise on the electrical lines that attempting to use it without a FilterLinc will result in degraded or no comms on the line side of the UPS as well. So, in summary, it is a true statement that common UPS devices are incompatible with the PLM's power-line communications.

yes, because 5.x is not yet released, you'll have to do a manual upgrade.

I'm not sure we actually want Leviton to "eliminate their Hail" -- it's the only thing possible to trigger on and without it, there's absolutely no hope that we can detect a switch on/off/dim event without polling! The problem, just to be clear, is that the concept of proactively sending a status update when a person turns the switch on/off is patented. That patent expired very recently, so the majority of the Z-Wave switches and dimmers out there still do not support a proactive status update message -- instead, many of them send a "Hail" message, which can be used by the controller as a signal that it should poll the switch/dimmer to find out what changed. If Leviton just turns off "Hail" because it's "obsolete", then we have nothing - nada - zip - zero! Regarding the last sentence, again, just to be clear and avoid mistaken assumptions for future readers -- one cannot get Hail added back, because it was never supported by the ISY in the first place. We need UDI to do what many (if not all) other z-wave hubs do when they get a Hail message (obsolete or not): it should simply poll the device that sent the Hail message. Should be very easy to do. And if that's not possible for some odd reason, then a next-best thing would be to expose a Hail message as a trigger (that's undesirable because it would then restrict most existing Z-Wave switches and dimmers to being useful only by programs -- which in the ISY add a 1 to 3 second delay (usually the latter)). Just to provide a data point: Running a Home Assistant software on an old Dell PC, with an Aeon z-wave stick, the total response time from depressing the paddle to turn on my office light to the time my desk lamp turns on is a fraction of a second -- the desk lamp is on before the main light has ramped to full-on. That's a z-wave paddle switch on the wall sending a Hail message, the Home Assistant software getting that message from the Aeon z-wave stick, polling the switch, running the "automation" (their equivalent of an ISY program), sending a "turn on light" message to the Philips Hue hub, which sends a zigbee message to the bulb in my desk lamp. Yes, that's a silly long sequence of events, but it was set up that way to test things -- and it works flawlessly andfincredibly fast with some open-source software on a surplus PC... that's the expectation users have, and if the ISY (IMO) is going to be taken seriously in the Z-Wave HA space, it needs to be in that same ballpark in terms of performance. High bar, indeed.

Short answer: yes, you can make events on the ISY result in actions on HA. I try to avoid that, however. My strategy is to try to make everything work with the ISY, first. If doing that is not practical or possible, or if it's too expensive, then I'll consider using another automation controller. I also try to avoid crossing automation protocol boundaries in the same part of the house -- what I mean by that is best illustrated by example: the kitchen and dining rooms are all Insteon, and all controlled by scenes, so everything in that part of the house will work regardless of the state of the ISY or any other controllers. Most of the z-wave devices are also on that same ISY -- all the door sensors, the multi-sensors, and the garage door controller, as well as half a dozen plug-in appliance controllers and dimmers. Those devices are all managed by ISY programs, and none are automating things where the delay is objectionable (and in many cases, what they automate is not critical so a malfunction is not objectionable). That leaves a small handful of problematic z-wave devices -- and these all ended up on the second floor. As a result, these z-wave devices don't interact with the ISY-controlled things in any significant way. My current integration strategy between Home Assistant and the ISY is simplicity itself -- even if somewhat crude. I have a python web app running that creates files in a folder based on incoming REST calls. The ISY uses network resources to do this, and Home Assistant watches for these files -- in this way, a program (which might be triggered by a keypad button push) can cause an automation to run on Home Assistant. The other way around is done via ISY variables -- an automation event on Home Assistant can use a REST call to set a state variable on the ISY, which can trigger a program to run. Again, this is a bit "Rube Goldberg" in design, but it works for now. And I'm reluctant to spend a lot more time making a better integration, because it's my hope that some day, one day, perhaps, the ISY may be able to handle those z-wave devices as well... I'm not a fan of multiple automation controllers.