oberkc

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?

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?

This program would, under certain circumstances, cause a "loop". For example, if your keypad link device is currently off, and you ask Alexa to turn it on (forcing an execution of the THEN action), the program would trigger itself and run again. I must admit I don't see the value of this program. Basically, it seems that it is saying "if a device is on, then turn it on, otherwise turn it off". I would handle this with a scene. Put all switches in the scene that you want to control the device. When you ask Alexa to turn on/off the device, create a routine that responds by turning on/off the scene.

Done

I had no programs or scenes with the original nodes. I did not have a need to migrate anything, so I did not (and, I am sure, it is too late). Lots of errors in the log. They continue every few seconds. See screen shot in attachment. Linked instructions say to "keep" 8080 port, but I have changed it to 8081. Also tried 8082. No change in status. Based on linked migration instructions, I ssh into polisy and tried the command: cd /var/polyglot/pg3/ns/uuid_n/config. I replaced UUID with that found in the ISY launcher and n=2 (slot for hue emulator. From that, I receive error "no such file or directory". I have double checked again the ISY host, port, user, and password. Host and port matches that found from the IoP admin console under "help>about". User and password match those that I use to login to IoP admin console (they are NOT admin/admin). Screen Shot 2023-02-01 at 1.23.21 PM.pdf Screen Shot 2023-02-01 at 1.18.42 PM.pdf Screen Shot 2023-02-01 at 1.50.50 PM.pdf

I have never been successful linking my Harmony Hub to the Hue Emulator on PG3/IoP (was working on PG2/ISY). I have decided to try again. Now, the Hue Emulator node on IoP admin console shows ISY connected as false. Additionally, none of my spokens show as nodes in the node server details>configuration table. Since last try, I have migrated all my system to IoP and the ISY no longer exists on my network. As best I can tell, ISY host/port/user/password are all correct in the node server configuration. I am not sure if this is relevant, but PG2 is still accessible, and still has hue emulator node server on it, but everything is showing disconnected. I am unable to delete any node server on PG2 (I presume because it is not connected to the ISY any longer). Suggestions?

S0, apparently.

I am not even sure how I would determine this. Suggestions?

I seem to be. When I manually unlocked it, the Amin panel changed status, then when manually locking it changed again. I have not done much more exhaustive testing than that, however.

I can't answer this question, but I can tell you that my BE469 added just fine. In fact, it came over from the ISY-994 backup files. The synch/interview process took care of the rest. Don't give up.

I have just migrated my system from the legacy ISY-994 to the polisy (not the EISY) but I understand EISY and Polisy are same in this regard. Zwave switches that could formerly act as scene controllers no longer do so. I submitted a ticket for this issue, and was told (loosely) that they are aware of the problem and that an update is coming that should help. Hopefully, we will have good z-wave capability soon.

I thought I would share a few highlights from my experience migration from ISY to Polisy. I have not had the smoothest experience lately with making updates to my system, and have been very hesitant to make this migration, but decided it was time to take the risk. I attempted to follow the instructions from the wiki, but found a few instances where the instructions could not be followed to the letter due to them directing to choose options from the admin console that did not exist in mine. Regardless, I believe I followed the intent of the instructions. My migration was using the existing PLM, from the ISY. Highlights from the process: - "most" of the Insteon devices came over. A few are missing (so far, I am missing a lamplinc and fanlinc, but am still sorting this out and may find more). Scenes that formerly contained the missing devices are no longer working from the admin console. Some controller devices within those scenes might still trigger the missing Insteon devices. Some don't. I assume that the links between Insteon devices remain, but the ISY link records no longer match. - zwave devices all came over but required the individual "sync and interview" process to work. Perhaps, if I had waited a day or three, this might have happed automatically, but I chose to force it on each individual device. All wired devices came through this, but sometimes with missing nodes or missing functionality (a z-wave switch that I could formerly use as a scene controller no longer worked as such...the ISY did not recognize a status change when the switch was manually toggled). I was unable to transfer any battery-operated z-wave device, with two exceptions: a door lock, and an alarm. No motion sensors. No door sensors. I was unable to force the door and motion sensors to respond to the interview request. I could exclude, then include them but, like the previously-mentioned switch, the ISY would not react to a status change when a door is opened or the motion señsor saw activity. This rendered those devices of no use. - Portal migration worked well. Alexa spokens, as best I can tell, all transitioned. - PG3 did not migrate properly. In this case, however, I am willing to assume this was a self-inflicted wound. Prior to the migration, I had PG3 working with the ISY, as well as with an unmigrated IoP. I cannot say (don't recall) that I had all node servers in the same slots, however. After I made the transition, the former nodes (I use Hue, Roku, Sonos, Harmony, and a few others) appeared in the admin console as before, but none worked. After attempting a few things, I ended up clearing PG3, clearing the node servers from the admin console, and re-adding to PG3. This also meant re-populating a few scenes and programs with the "new" nodes, but this is mostly working at this point. - most interesting to me: I have at least one case where I have an ISY scene connected to Alexa. This scene originally included several keypad buttons and two fanlincs. The scene is, I assume, typical for fan control. Button A = off. B = Low, C = medium, D = High. It has worked flawlessly since creation. Sometime between the time I last used it and now (I assume as the result of the migration), the fan scene ceased working. I can no longer control the fan from the KPL, nor can I control it from the admin console. Not only is one of the two fanlincs missing from the scene definition, it is completely missing from the device list. Despite all this, both fanlincs still respond to Alexa commands. I cannot even come up with a theory about how this is possible. - I thought I had successfully updated to 5.5.5 on IoP, prior to migration. After migration, however, the admin console for IoP shows 5.5.4. Did I imagine things? I guess I will never know for sure.

since AM is before PM, your time interval will never be true. I believe the "next day" option is still viable. Try: IfFrom 5:30:00 PMTo 5:30 AM (Next Day) <<<<<<AND Hallway Motion Sensor 1 is On Yes, these programs will run every time it is triggered by an event. The only question is whether it runs THEN or ELSE.

It also appears that, after migration to IoP, I cannot get any of my battery-operated zwave devices to respond to an interview. As an experiment, I successfully excluded one of the battery zwave devices (a door sensor, in this case) and added it back in. It was missing a node or two, and no longer had an On/Off status available on any of the nodes. Not much good. For now, I guess I will wait to see if anything happens over time. Perhaps there is an update that may address this some day.