xd40

nope--I was born AT NIGHT but I wasn't born LAST NIGHT. but I did replace OLD with NEW1 and when it didn't work replaced NEW1 with NEW2 which also didn't work right until I factory reset it. I keep forgetting that you have to factory reset every insteon device right out of the box.

After moving over to the 994 I was able to do a replace to the new device BUT it isn't really working right anymore. The ISY shows that the buttons are controllers for the old scenes, but they don't do anything when the buttons are pressed, so I guess I'll have to sit down and figure out how they used to work and completely reprogram the keypad again So the ultimate answer is "no", the replace doesn't work correctly--at least not for this particular circumstance.

OK--when I get the 994 later today I'll see if I can do the replace--I hope so because I sure don't want to have to reverse engineer all of the configuration for the keypad...

My 994 is on the FedEx truck for delivery today--I ordered it a while back but it was on back order at smart home and it takes a long time to get stuff from the left coast. So does this "upgrade option" include a discount on the hardware? If so, can I take advantage of that even though I already bought the hardware? If not, it's not really an "upgrade path" but more of a "replacement path"... and nobody is touching question #2, are they--sounds like UD hasn't figured out they need to have a device equivalence list to allow direct replacement when the part numbers are different, but the device is functionally similar enough to be a direct replacement.

BUMP! I have similar issue: Replacing another failed 2486D with a 2334-232 (the 2486D is no longer available) 1) KNOWN problem: ISY99 is on the newest firmware which can't be updated any further and the 99 doesn't know what the "2334-232" is. Is there any plan to provide updates that at least add new devices, or is there a work around to allow me to do a replace? 2) Suspected problem: I suspect after I get past this issue I may still have problems replacing the 2486D with the 2334-232 because the ISY will think the devices are different.

Jeff, If you have questions on this, just post to this thread--I'll keep watching it and help you out if I can. I have my configuration working fairly well now.

That's interesting. Nothing like making the outcome of a "function call" non-deterministic based on some external event that you've already tested against. I guess that makes sense in somebody's world--just not mine. I have a computer science degree over 25 years programming experience and I have to say that the home automation world has a very odd concept of what a programming language should look like. I should know by now that when your "programming" is constrained by a menu driven "program builder" that there are going to be significant limitations of that "language". i.e.: - abnormal program flow - no case statements - no arrays - no type conversion - no function calls - no math functions - oh, and no variables...??? Why don't you guys consider embedding a LUA interpreter so we can write some of the functionality we need for ourselves? I still have a 10 year old X10 controller running all of my lawn sprinkler programs because the programs are too complex to implement on the ISY...

Interesting, that has not been my experience. Maybe there was a bug in one of the beta versions I was recently using. I guess the next time I'm tweaking my programs I'll try this again.

O.K. I've finally got it. Wow, I could write this functionality in .NET in about 2 minutes--this took help from LeeG and several HOURS... Limitations: The ISY can't directly turn a KeypadLinc secondary button off, so: Added 2 Scenes: Scene-BTN-A Scene-BTN-B Added 2 programs (pseudo code): If Control Remote-BTN-A is switched On Then Set Scene Scene-BTN-B Off If Control Remote-BTN-B is switched On Then Set Scene Scene-BTN-A Off so this, plus the stuff from my first post makes all of this work (finally). thanks for sticking with me on this LeeG !

LeeG, Doing what you said will probably work, but then you are in the realm of needing the ISY to intervene to operate a scene. I have avoided that up to this point and only use the ISY for more complex scenes that are done with relationship to time or other status values (i.e. nobody home). I could have SWORN you used to be able to independently control a secondary button as a responder in a scene in an older version of ISY but you sure can't now.

pseudo code example: Program1 do thing x do thing y run program2 do thing z <-- this never runs Program2 do thing a do thing b

CORRECT--that is why you need to create the mutual exclusion using the SCENE, which you now CAN'T do.

Jeff, I'm trying to do the same thing right now. Hopefully we can put our heads together and make this work. Let us say we have 2 scenes that operate differently on the same loads and are thus mutually exclusive: Scene A & Scene B We use the ISY to create scene A & B We use the ISY to make buttons A & B Controllers for scene A & B We use the ISY option "Link Management/Add Button to IRLinc Receiver" to add remote control buttons A & B We use the ISY to make the remote control buttons A & B Controllers for the scene A & B Finally, we use the ISY to make the buttons mutually exclusive (even though the console warns us that their are issues with this) Now: when we go to the keypadlinc and press A, scene A activates and the light on Button A on the keypadlinc comes on. Next we press B and Scene B activates, the light on Button B comes on, and the light in button A goes out. However, here's the problem: we use the remote and press button A and scene A activates and the light on Button A goes on. Next we press B on the remote and Scene B activates, the light on Button B goes on, but the light on button A stays on. This is what you need to be able to do and I THOUGHT you could do it on older versions of the console: On Button A, Add Button B as a RESPONDER and set its On Level to 0%. On Button B, add Button A as a RESPONDER and set its On Level to 0%. You can no longer do this though because the BUTTONS do not show up in the section that allows you to set their on level (I swear they used to in the older version of the console -- I'm on 2.7.15 now and I just upgraded from some beta version that was after the version that they fixed the big keypadlinc problem).

you said "call", I suspect you meant "run" as that's the only option I see. But the distinction is that if I "run" the other program from a program, it DOES NOT return to the calling program. It originally took me hours to figure out why my code wasn't working until I understood that the execution does not return from a "run" (that was a year or so ago).

WOW! thanks I don't know if I ever saw that functionality in the console before. I'll give it a try