mikek

No PLM needed. The system is only Z-wave and Elk. I haven't done anything with the Elk node server yet.

Thank you.

I'm in the process of ISY --> EISY migration. Following instructions (https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Migrating_from_994_to_eisy). I have an old board, so can't migrate z-wave. That's no problem, I don't have many devices at all. So I'm trying to restore my programs. Did the ISY backup. Curious ... Where is the backup located? What is the name? At the restore step, instructions state: "If you are not migrating your Z-Wave network, Use (Admin Console | File | Restore ISY) to restore either your Eisy / Polisy backup or your ISY-994 backup" I don't see "Restore ISY" in my File menu. I do see "Restore Devices". Is that the correct option? When I click on that, I get a confirmation popup specifically about INSTEON. Also, my ISY firmware is v.5.0.11B. Is that okay, or do I need to update to 5.3.4 to successfully migrate programs? Or is that not even possible because of my board?

I did customize, especially thermostat for two stage HVAC and various light switches and dimmers. I just went through them all and documented configuration parameters. Not as painful as I had anticipated. Thanks for your help.

Thanks. That's what I'll do. Any ideas on how to document all my configuration parameters (other than going through every parameter for each device, one by one)?

Good tip. Done.

So I guess that means backups and screen shots and lots of notes. I only have about 10 devices, so in general it shouldn't be too bad. One concern is all my parameter configurations. Is there an easy way to compile a full list of those so I don't miss any?

Thanks, Geddy and DennisC. Confirmed that I have a 300 series board. So it seems that Z-Wave migration is not possible (please correct me if I'm wrong about this).

Thanks for the board photo. Very helpful.

Eisy Z-Wave migration instructions (from ISY-994) state "You must be using a 500 Series Board in the ISY-994." How do I determine which board I have?

Can someone post a photo of this combo? I'm replacing my 994 and just curious about real estate. The 994 is a tight fit already, and I'm wondering if I'll need to relocate things. I found the dimensions, but it would still be helpful to see it. Thanks.

Thanks, much appreciated!

Thanks. I looked at that Ecolink but can't find the user manual. The support tab on that page doesn't bring up any information. Any chance you can point me in the direction of some documentation?

Thanks for the reply. When you say "goes off", do you mean that it stops working/communicating or that the siren sounds? This would be a new device. Mainly looking for something for low volume notifications rather than a high volume siren, but the Aeotec seems to have enough options for that purpose. I don't really like the wall wart idea (I think I saw that the previous generation was a plug-in). In general, I'm not finding a lot of alternatives. Ecolink has one and I found a few other knock-offs, but the Aeotec seems to be the most popular.

Can anyone confirm compatibility of the Aeotec Siren 6 with the 994? Does anyone have experience with this device? Recommendations for an alternative?

? That did it! Thanks very much!

Yes, a low battery in a wireless sensor also reports as trouble. That's what I'm trying to accomplish with my notifications - a low battery alert. I already have my "violated" programs running and notifying as they should.

Thanks for your input. But I've already done that. According to Elk itself, status is trouble. According to ISY, status is trouble. According to alert, status is violated.

Since I'm just trying to see if this concept ("trouble" notification) works, I'm simply using the default subject (${alert.subject) and body (${alert.body}) for now. My programs and notifications work fine for a true "violated" status. But 'trouble" and "violated" are two unique statuses.

I originally posted this in the Elk board, but it seems like the problem is actually ISY related. What I want to do is receive an email alert when any of my Elk wireless zones report status as "trouble" (not "violated"). Simple code, looks like this (for one of the zones): If Elk Zone 'Office-WestWind' is Trouble Then Send Notification to 'Me' Else Wait 0 seconds However, instead of receiving a "trouble" alert I get this: Security Zone 'Office-WestWind' Violated Any ideas?

I have a HomeSeer Z-wave wall switch that I want to remove and replace with a different HomeSeer wall switch that has the multi-colored indicators. Is there an easy way to do this without messing up my configuration and programs? Is it possible to use the administrative console to simply point my old device configuration to the new switch? Thanks in advance.

apostolakisl - I think your option #2 is just what I need. Keeping the programs separate and triggering one or the other with a third program. Thanks! oberkc - There is nothing preventing the two programs from triggering simultaneously, but the likelihood is low enough where I wouldn't concern myself with it happening. Thanks for the idea about the added conditions. Yes, the secondary program does have a wait.

I have a Homeseer HS-WS200+ wall switch. Unlike the dimmer in the same series, the switch only has one indicator LED. This LED has several configuration parameters associated with it, and I use a program to set those parameters based on time of day, a motion detector and a timer. That all works well. I have another program that controls those same parameters (but configured differently) based on the status of a handful of door/window sensors. That also works well. Both programs end with setting the parameters back to my default status. I'm trying to figure out what to do when the conditions of both programs are met. I'd like to somehow define one program as primary and the other as secondary, and allow the primary to override the secondary. So if the primary program is triggered and active, ignore the secondary. And if the secondary is already active, and the primary is triggered, abort the secondary and enable the primary. I think I can accomplish this with nested conditions, but I was hoping to keep the two programs independent and simply tell the ISY which one takes precedence.

In a situation where two programs are giving conflicting instructions, is there a simple way to prioritize or define which takes precedence?

I'm also thinking that if the UDI is finding it, then I don't need another way to get it out of the Elk. Seems like I should be able to take advantage of what the ISY is seeing and reporting - I just don't know what that method should be. Anyone ever tried something like this?