gweempose

I tried re-linking the skill to my Alexa account this morning, but it didn't work. I just tried again, and now it worked. Everything appears to be functioning properly for me again. Thanks for taking care of this so quickly, guys!

I had the same dilemma, and I ended up with the exact same solution as you. I literally just came here to check to see if there was a better way of doing it when I stumbled upon this thread. I have a scene called "All Kitchen Lights" that controls the kitchen lights, foyer lights, and island lights. The controller for the scene is a keypad button, and just like you, I only wanted the button to light up when all three sets of lights were on. The only way I could come up with for accomplishing this was to create a new scene with only the keypad button in it, and then trigger that scene from a program: All Kitchen Lights Button Monitor - [ID 000B][Parent 0001] If 'Main Floor / Kitchen Lights #1' Status is 100% And 'Main Floor / Foyer Lights #1' Status is 100% And 'Main Floor / Island Lights' Status is 100% Then Set 'Main Floor / All Kitchen Lights' On Else Set 'Main Floor / Keypad (B) Status Control' Off It works like a charm! I guess great minds think alike!

I ended up rewiring the switches and moving the load to one of the other dimmers. So now the keypad is 100% virtual. This works out better for me, since I prefer to control the "All Main Floor Lights" scene from the two large buttons on the keypad, and the status of those buttons is no longer affected by the other two switches. Thanks for the help, guys! Much appreciated!

Thanks! I figured this was probably the case. So it sounds like I basically have several options. The first option is to leave everything as is and simply live with the fact that the light on the keypad will occasionally not reflect the true status of the "All Main Floor Lights Scene". The second option is to make the main button on the keypad a controller for the "Foyer Lights" scene, and then move the "All Main Floor Lights" scene to a different button on the keypad. The third option would be to rewire the switches so one of the dimmers is actually controlling the load, and then remove the keypad from the "Foyer Lights" scene. I think this last option is probably the best, and it shouldn't be too difficult to do since there are already existing travellers going to the other junction boxes that are currently capped off.

I have a scene with three devices in it called "Foyer Lights". The scene includes a 6-button keypad that is attached to the load, and two dimmer switches. The two dimmers are controllers, and the keypad is a responder. The keypad is also a controller for an "All Main Floor Lights" scene that turns on the load it is connected to, as well as a bunch of other lights. Everything works fine, but I'm wondering if there is a way to make it so that the status lights on the keypad will not turn on or off when the "Foyer Lights" scene is controlled from either of the two dimmers. I only want those lights to reflect the status of the "All Main Floor Lights" scene. Is there an easy way to accomplish this, or do I need some sort of custom program?

That's exactly what I was looking for. Thanks! Man, I looked in every menu and sub-menu and just couldn't figure out what I was missing. I hadn't even noticed the little red ❌. Thanks so much!

I just sold my ISY994i on eBay and I want to reset it to factory defaults before I ship it. Also, how do I remove the device from my portal account? Thanks!

I wonder if this is something that can be fixed with a firmware update?

When I manually query the lock, either from the admin console, or the UD Mobile app, the status always updates correctly. The status also properly updates after the lock has been locked or unlocked remotely via the eisy. The problem only seems to occur when the lock is controlled manually. In this case, the status simply doesn't change regardless of what state you leave the lock in.

D'oh! I knew I must have been missing something obvious. Thanks!

I can't figure out how to add a forced device query to a program (i.e. if the door is open, then query the lock). Is this possible?

I hadn't thought about forcing a query. This could possibly be a workaround to my problem. I could write a program that queries the lock any time the door is opened. That, in conjunction with my original program, might just do the trick.

What locks did you upgrade to?

I'll give that a shot, but the communication seems to be fairly stable. I have a bunch of Z-Wave repeaters, and my locks are located pretty close to the ZMatter antenna. It's honestly not that big of a house.

This is the auto-lock program I was running at my old house: If I am unable to get the status updates from the lock to work, is there any way I can tweak this program so that it will still work reliably on the eisy?

I just set up a brand new eisy configuration from scratch in a new home. It is running the latest version of the firmware (5.7.0). Everything seems to be working great, including my two Z-Wave locks. The problem, however, is that the eisy is not receiving status updates from the locks. If I initiate a lock or unlock command from the eisy, the status will update, but if I lock or unlock the deadbolt manually, the status does not change. This is a problem because I have an auto-lock program that requires real-time status updates from the lock in order to function properly. I tried doing a network heal as well as a synchronize with interview. Neither of these things fixed the problem. At my old house, I was running a 994 with a 300 Z-Wave board and it worked perfectly with these same Schlage locks. Is there anything I can do to fix this issue? Here's a photo of my setup:

Thanks for the link! Since I'm starting from scratch and am not transferring any devices or nodes to the eisy, I'm assuming the only thing I need to migrate is my Portal license?

Today is the day! I'm ready to install my eisy and start programming it. Since I'm in a new home, I'll be completely starting over from scratch. I'm a little confused about the exact order to do things. For example, at what stage do I remove my 994 from my portal account and add my eisy to it?

I just ordered an eisy, as well as a serial kit to connect it to my PLM. I will be setting up a brand new installation at my new home. The PLM was previously paired with a 994 at my old home. What do I need to do to prepare the PLM for the new installation? Do I need to perform some type of factory reset?

Thanks for responses! I think I'm just going to bite the bullet and upgrade to the eisy. At least that way I know everything will be fully supported for the foreseeable future. I noticed on the eisy page on the UD store that it says, "Want a discount? Become a member!". What exactly does this mean? How much is the discount, and how do you become a member?

It's a 300, unfortunately.

I recently moved and would like to set up the 994 in my new home. I moved many of my Insteon and Z-Wave devices from my old house to my new one, plus, I installed some new devices. I was running 4.9 at my old house, but I'm thinking this may be a good opportunity to upgrade to 5.x. Before I do something rash, I have a few questions: 1) How do I factory reset the 994 so that I can start from scratch with a fresh install and re-add all my devices? 2) If I upgrade to 5.x, will I lose the ability to control my Z-Wave devices? I thought I read somewhere that this may be the case. 3) Since my 994 and PLM are both working perfectly, is there any compelling reason to upgrade to an eisy? I'd really hate to spend a lot of money if I don't have to. Thanks!

One thing I don't like about this is that it will throw the deadbolt even if the door is open. To get around this, I created a program that monitors the state of the door and only runs the autolock timer once the door has been closed.

My experience was the exact opposite. I had lots of communication issues with my Ventstar thermostats, but my 2441's have actually worked quite well.

Just checked, and it's working for me.