bcdavis75

So has anyone successfully added this to V4.62? I'm trying it now and it shows up as a node but I'm not see it show and status and no change when motion detected.

I'm curious. A few of you have mentioned that the Insteon dual band protocol is a flawed concept becasue line noise compromises both "bands". I don't want to get too far off my own topic but is that known fact or a strong suspicion? For me, I'm not contemplating a rip and replace. I have no experience with Zwave devices and I'm generally happy with Insteon despite the occasional failure and/or communication problem. However, I don't want to be caught flatfooted if Insteon starts to disappear or keep buying their stuff if the writing is on the wall and I've just been missing it. Thanks for all of you views on this. It's an interesting discussion. I should mention that more then anything, I hope UDI keeps chugging along! Even as a novice DIY'er, I find the ISY an amazing device compared to all the other nonsense out there.

As one of the first owners of the Commodore Amiga... I know what you mean Anyway... is fair to sum up you opinion by saying there's a lack of clear options at the moment and therefore, sticking with Insteon is not an inherently more risky option? @paulbates The HUB was the other thing I forgot to mention. Obviously that causes a long-term misalignment.

Oh no disagreement there. I think what I was trying to get at is is there a valid concern that UDI and Insteon's interest may diverge and/or that Insteon will simply not be able to compete other ubiquitous platforms that, for whatever reason, have more name recognition and acceptance. My preference (I think) would be to stick with Insteon products for exactly the reason you mentioned.

Apologies if this topic has been hashed out elsewhere. I'd love to get some opinions (or pointed to other relevant discussions) regarding peoples thoughts on Insteon v. converting to zwave devices on the ISY. The impetus for me is two-fold. First, I have a lot of old dimmers/keypads 8-10years--some of these are beginning to fail. It's not the failure itself that concerns me. It's more the question of whether or not I should just replace them with Insteon dimmers or reconsider the options. The second impetus was a discussion I stumbled onto in this forum regarding the new version of the Insteon Motion detector. The discussion alarmed me becasue it dispelled some pre-conceived notions I've had about the relationship between Insteon/UDI/Smarthome. The truth is, I've never fully understood the relationship but I'd assumed it was one of mutual proactive co-operation at the very least--maybe that's still the case. But That particular topic didn't make it seem that way. Also, I haven't spent a lot of time in the V5 forum but I gather that a lot of the upgrades have to do with more fully implementing Zwave? So it's entirely possible that these accumulated impressions causing me to question if I should be gradually, moving away from Insteon are totally misplaced. I'm not nearly as informed as most of the folks in this forum. So let me know your thoughts. They are appreciated.

Ah. Got. Thanks!

Hi all. Hoping to get some help on a program issue. The purpose of the program is to use the network resource module to announce a warning through my sonos system when motion is detected in my basement. However, despite the fact that I have a wait command after triggering the network resource, each time motion is detected, the announcement gets interrupted and starts over again. Screen shot of the program is attached. Thanks in advance for your help.

Hey stu. Well that's part of what's happening but the program flow has a lot of other elements. What I found way back when I first tried to set this up was that my LED controller Scene was also affecting my lighting scenes if the ose Lighting scenes were linked directly to the KPL buttons. Thus I unlinked them and used programs to initiate the lighting scenes creating that annoying lag. Perhaps there was something else going on but by limiting my LED controller Scenes to 1 button and 1 KPL, everything is working much better (lighting scenes are now directly linked to those KPL buttons.).

STU! Don't take this wrong way but I may be deeply in love with you. That did it! I realize what I was doing wrong in past attempts. The Scene I used to control the LED had more then 1 Keypad Link link button in it. I was trying to use 1 scene to control the LED on/state of the buttons on Both KPLs in the room that had the same function. I'm curious... how did you know that? Is there something fundamental that changes in a scene if it only has 1 member? Anyway... thanks to everyone who responded. I greatly appreciate it.

Hey guy. Perhaps I should have posted this first... but it wasn't really prepared with public consumption in mind. This link will show the program flow of what's happening in this room. https://docs.google.com/drawings/d/1e8B6I_0kkW5pUjdej1KJXiFBK2uG4YezmbCwz-ALHfU/edit?usp=sharing In essence. There are 2 KPLs that contral 2 main scenes; "All On" and "Dim". As several of you mentioned, the actual KPL buttons are controls their own scenes for that pupose alone--they don't control the lighting scenes directly. The program flow changes a variable as various conditions are met as a person switches between the 2 scenes. The only thing that makes it a little complex is that I have a "Day/Night" variable that, when changed to night, moves the room into the DIM scene--simultaneously turning off the "ALL ON" Buttons on both KPLs and on the "DIM" buttons. The program flow then also accounts for the scenario when my wife decides she doesn't want the room dimmer despite the fact it's dark outside.... SO if someone manually hits the ALL ON button again, it will stay there. What other details of the room would be helpful? Stu... that's very interesting that you have no lag... If I could simply solve that issue, I'd be set. Perhaps the issue is signal related as Lee alluded to, I'm going to try his test this evening.

Hey Erik. Oh don't worry. I intend to listen to everyone that responds... especially Lee. I've already been through the tutotial videos--at least all the ones I could find. Also, I'm doing exactly as you suggested creating a scene that just controls the KPL. In my original post, that the 'dummy' scene I'm referring to. But what you're saying more or less confirms what I thought... You can't turn off a KPL button that's directly linked to a scene without, in fact, turning off all the members of that scene. This is why I don't understand the advice on always directly linking... it becomes very limiting if you want to address scenarios like your Dining scene. So I'm assuming you have a very similar setup to me... Don't you experience a program lag activating that scene from the KPL?

Well that's erik's example... I was referencing that simply so that he could answer my question in the context of his own environment because it kind of gets to the heart of why I haven't been linking scenes directly to KPL buttons. Make sense?

Hey Lee. My legs are bridged. I will run that test... I was unaware it existed. But my more pressing question has to do with Erik's example... If you link a KPL button directly to a scene, is it possible to un-light that KPL button without turning off all the lights in that scene?

So Erik... oour example gets to the heart of the issue... So I'm clear, your Dining scene is linked directly to scene button on the KPL? It does not rely on a program? If so, my issue in the past was that--using your example--if I used a checker program to un-light that button if, as you say, a member of the scene was altered--then ALL the light in the scene would get shut off. If that's not happening in your case then I'm definitely doing something incorrectly... which is a good thing--i agree that linking the scene directly to the button is preferable.

Hi. After living with my setup for a few years, some persistent issues have cropped up and I'd love some input. My biggest issue has to do with how I manage scene's from My KeypadLinks. Without getting into a ton of detail (although I'm happy to if it helps); In my family room, I have 2 KPLs on either end of the room. The scene layouts more or less mirror either other on the KPL so you can initiate a scene from either end of the room etc. All of the Scenes are triggered by Programs on the ISY which are configured according to "Condition/State/condition/nextstate" how-to's wonderfully explained elsewhere on this site. I use 'dummy' scenes to control the On/Off state of the actual buttons on the KPLs and keep the 2 KPLs co-ordinated.... And herein lies the problem. As a result of not directly linking the KPL button to the scene, there is a 1 to 1.5 second delay before anything happens. It is shocking to me how much distress this seems to cause... but here I am posting about it. It simply fails the 'wife' test. And also the houseguest test. What seems to happen is they end up holding the button down (it's unclear to me what effect that has) or they start hitting the button again... or the button next to it... or the wall... or the dog.... To compound this... every great once in a while, the button actually fails to trigger the program. I mean like 1/100 times. However, it is a button that gets used every day sooooo--you can can probably fill in the how the resulting conversation goes. My question is this, do you guys use a different paradigm to control and co-ordinate multiple KPL's controlling multiple scenes in a room? Are there ways to mitigate the delay when using programs to trigger scenes? Do any of you have 'checker programs' that make sure everything that was supposed to happen did happen? Thanks in advance!

Sorry as I'm sure this has been cover elsewhere; but I can't find it. I have a simple scene with a few dimmers and lamplincs. I added a KPL button B as the controller. Then I went into the scene and tried to change some on levels. However, Pressing B seems to return to the previous on levels. If I remove and re-add B to the scene, it works. But is this really necessary? Is their some easier way to update the controller?