oberkc

Are there any unusual LED indications on the front of the polisy?

I have both running. I don't remember any special tricks.

As far as I know, there are no colour changing bulbs that work "natively" with the ISY. Having said this, one could control hue bulbs with the ISY using the network module. Doing so required a bit more effort, but was not too bad once you get through the learning curve. Unfortunately, I am not sure one can add the network module anymore if the ISY is no longer supported.

I suspect the problem with adding fanlinc as a fan-category is that this approach does not keep other devices that are in scenes with the fanlinc (keypadlincs, for example) synced up. I would wager that this is the problem mrbill is trying to solve with programs.

Ever since upgrading to IoX5.6.0 and PG3 3.1.20, I get a regular occurrence that the PG3 becomes disconnected from the ISY. Power cycling temporarily solves the problem, but it returns the next day. I have initiated a ticket with UDI.

JTsao, did you ever find a solution? I recently upgraded to 5.6.0 (and PG3 version 3.1.20) and PG3 was disconnected from the ISY...PG3 could not find the ISY. I individually rebooted (software reboot) IoX and PG3, with no benefit. I power cycled the whole unit (Polisy, in my case) and this fixed it, only to have the problem return a couple of days later. I don't know if this is going to be a recurring theme or not.

If you are interested in node servers to integrate addition device types into your system, upgrading to the EISY is probably worthwhile. I am also a bit of a fan of upgrading on your own schedule, rather than waiting for a failure of the old ISY and suddenly having an "emergency" situation. On the other hand, the polyglot/node servers and ISY (or is it IoX?) is a bit more complicated and finicky from my experience. If you fear that the ISY has gotten beyond your abilities or interest, the EISY will not make things any easier.

Last I checked, the ISY IP address could be identified via admin console: Help>About. Also, since you mentioned the launcher, the current version of the launcher shows the IP address. I do not recall which launcher works with your ISY software version, however.

No, most certainly.

I don't recall with great confidence, but I can tell you I got them at Lowe's and they were likely the GE brand that they used to carry.

In retrospect, my migration (to polisy, not easy) went mostly well, though it was a bit of work. The only problem I continue to have is that z-wave motion and door sensor no longer work in my system. I had to replace them with Insteon.

Have you disabled program A?

This would be so. The fixtures require neutral to operate. Yes, you could tie them together, but that would be unnecessary. Hot and neutral would be at one of the fixture boxes. Yes, you could put in a keypad or switch at the current location, but you would need to repurpose the conductors coming into the switch box. This would be done at the applicable ceiling fixture box, and making one a hot and the other a neutral. I believe you could make this work with existing wiring.

I am interested in using some twinkly lights, but only if I can control via IoX. Does the PG3 node server work? Are there instructions anywhere? What is the capability of the node server (change scenes, colors, animations, on/off)?

Is it possible that your program conditions are such that something triggers the program, but it evaluates as false? If it were to do so during your 49-hour wait period, the program would halt and run the else path. The little red line by each program icon means nothing more than the fact that the last program execution was FALSE. Check the program summary page and see when these programs were last run and status.

I don't know that one method is better or more reliable than another. If you want to use use variables as a representative for each state of your alarm system, then there is probably no benefit to enabling or disabling programs. I have tended to avoid variables (for no particular reason that I can recall) when I can find other solutions. I would assign a keypad button for each state and use the status of the keypads as an indicator for current alarm state. I would put each button into "non-toggle (on)" mode, and create a scene containing all alarm buttons configured such that when you press one of the alarm buttons, the other alarm buttons would turn off. Given this, whichever button is ON at any given time is the current alarm condition. Whether this has any benefit over variables, I cannot say. Using button status as an indicator or current alarm state (assumed as off, home/asleep, home awake, away) , I would create a program folder for each state (except off) and enable/disable each folder based upon the condition of the keypad buttons. In each keypad folder add a program that accomplishes your desires (if certain sensors are trigger, activate alarm). Additionally, I would create a program, in no folder, alway enabled, that shuts the alarm off if the keypad button for the OFF alarm state is pressed. Before embarking too far on what methods you want to use, make sure you have defined your requirements for your alarm system. For example, do you want a delay between your button press and when your alarm system is activated? This may dictate a certain approach to how you do this. Are you going to change the state of your alarm system by some other method than physically pressing the keypad buttons (UD Mobile, Alexa, another program)? This may influence how you approach doing this.

Sorry. I misunderstood your intentions. I thought you were hoping to add all your Insteon and z-wave devices as a new install. Yes, eventually, I migrated everything over. I used my existing PLM and tried to follow the instructions on the wiki. In addition, I did a backup of my network resources and restored them from this backup. Insteon devices came over mostly 100%, if I recall. Most of my Zwave devices came over, but some did not. All required performing the "interview" process. Battery z-wave devices did not transfer for me. I tried excluding them and re-adding but they would not be recognized at all. Network resources worked from the backup. Email notifications came without problems. Variables transferred. Programs transferred fine, but any that included devices that did not transfer needed some manual intervention. Alexa integration transferred fine. I also had issues with node server transfers from the old system, but this was possibly errors on my part from experimenting with the node servers on the IoP prior to the migration. Again, I misunderstood your intentions. I wish I could say that z-wave import from a backup worked without issues for me, but I cannot say that. IIRC, once you import your backup the devices show up and, eventually, the process will initiate the interview process. Based on my experience, some devices will be fine, some will not respond to the interview request, and those that do respond will add the nodes that you may have already had but deleted. It took me more than a few hours to get everything working as before, once the migration was complete. Some of this time was spent replacing no-longer-working z-wave devices with Insteon counterparts or different makes and models of z-wave devices. From these, I had to add devices into scenes and programs. Based on your description of your z-wave devices, I suspect you are in for a lot of work. I agree with @DennisC: it might be best to wait a little longer in the hopes that Unfortunately, I only have done this one time, so my experience is limited and my memory failing.

I have a couple of keypad buttons throughout the house that enabl some zwave alarms to be triggered from door and window sensors. Mine is just “on” or “off”. If I wanted more than two modes, I would probably do this with multiple keypad buttons, one for each mode (off, home/asleep, home awake, away, etc…). I would probably then create a program for each of the alarm states, based upon what you want to happen for each of the states, and enable or disable each program based upon the status of each keypad button.

One can trigger an alexa routine from an ISY variable, for sure. Create an ISY program that sets a variable value as either 1 or 0, based upon the keypad button you want to use. Add the variable (as a sensor) to you alexa integratin though the portal. Once you have this new “sensor” in alexa, you can create a routine triggered by the sensor to execute a command to one of you other devices in alexa.

I had IoP running for quite some time before migrating. I had no PLM, no insteon, no zwave (though the zmatter board was installed). The only devices I had were the nodes from polyglot node servers. If you do not want to migrate your existing insteon and zwave devices, add a fresh PLM, exclude your zwave devices, factory reset your insteon devices, and add each fresh to your polisy.

Do these newly-added devices have an identifier (such as zyxxx) as part of he name? Is this identifier the same across multiple devices? If you right+click one of he devices, do you have a “group” option?

No way that I know of No, more than that. I believe you would need also to "exclude" each device. There are places in the wiki that may be of use. There may be more, but here are a few: https://wiki.universal-devices.com/index.php?title=Main_Page#Z-Wave_Plus™_for_ISY-994_Series https://wiki.universal-devices.com/index.php?title=Main_Page#Z-Wave_Quick_Start_Guide

I don't find identifying z-wave devices any more cumbersome than Insteon. Both are initially obscure numbers when initially added to the ISY. In both cases, I give them meaningful names right after I add them.

No effect? Are you sure? Will "switched on" not halt the WAIT state? Perhaps this is the difference that you are missing?

but...none of this matters if they don't provide the data to allow UD to support it.