oberkc

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.

Fair enough. Of course, the instructions here were limited to z-wave migration. I was performing entire -994 > IoP migration.

Is not the thread you referenced the one we are in, and currently corresponding?

Thanks. I would have assumed something like that. I also assume what is now called "Backup" is what was formerly called "Full". Unfortunately, these are the types of details that cause me some loss of confidence. This wiki page has been recently quoted as the latest migration process, which includes updating to ISY 5.3.4 (step 1, which cannot be done with 300 series z-wave dongle). Things can go wrong when one gets careless with the details.

I am, after so many difficulties in recent times, getting the ambition to make the transition to IoP from the legacy -994. I am trying to follow the instructions on the wiki and want to be sure to be precise. In step three of the wiki is: Wiki step 3: "Backup your 994's Z-Wave dongle (Admin Console | Z-Wave | Utilities | Backup | Full)" Unfortunately, I see no "Utilities" option under Z-Wave, nor do I see a "Full" option. Yes, I am on 5.3.4. Is this a problem? Why do the instructions not match my admin panel options?

As far as I know, there is no direct access to “works with alexa” devices. Alexa devices do not show up in the ISY device listing, and status is not directly tracked. Having said this, one can trigger alexa routines via the ISY. My memory is a little vague on this, but some ISY devices can be added to alexa as “sensors”, as can ISY variables. Such “sensors” can be used as a trigger in alexa to force n lexa rotuine to activate. I use this method to control alexa announcements via ISY programs, but anything that can be done via an elexa routine cna be triggered via ISY including, I assume, controlling alexa-enabled devices.

Does it appear that your ISY is operating normally? Programs working? No funny lights on the ISY front panel? In my IoX launcher, the format for the URL is http://myISYaddress:myISYport/desc I am hopeful that you know your ISY address and port. Regardless, my IoX has alway found my ISY and polisy and I do not recall having to add them manually. There have been times when I had to reboot one or both, and times when it seemed that removing IoX and re-installing (including the clearing of the Java cache) was helpful. You might try this.

I may have missed it, but I saw no stated requirement for this to run on the "last" day of each month.

Yes, I think this is something you should do. IIRC, the additional of calendar variables was one of the big reasons I was excited to make the update to 5.X. Without it, your options are quite a bit more limited (and potentially more time consuming than making the software migration.

I assume that one is skilled enough to recognize the number of days in each month, and that some have 31, some have 30, one has 28 (and sometimes 29). I also assume that one recognizes that if one picks some number greater than 31, such a program will never trigger, that if one picks a number such as 29, 30, or 31, it will only trigger on some of the months. I would like to think that if one is trying to create computer programs using Boolean logic, that such person can figure the simpler parts out on their own.

I would be more inclined to create a variable to keep track of the day of month. Once each day (I do mine in the 3am cleanup program), run a program that includes a step: $dayofmonthvariable = [Current Day of Month] Create a program such as: if $dayofmonthvariale = some number then turn on Insteon module wait for some period of time turn of Insteon module else nothing The program, above, will work only for periods of time less than 24 hours. 24 hours after this program runs true, the day of month variable will change, become false, and halt any wait state.

I suppose you could test his theory by watching the program log while you execise the various keypad buttons. Does the program run twice, first true, then false?

Mine showed the migration option also on 5.5.2

I am waiting as well. I dont have an immediate need to move from the -994 at this point, so until that changes or I am more confident that the zwave migration path is less rocky, I will stay with the trusty ISY.

As suggested by @tazman, your next step would be to choose "migrate...." in the configuration tab. I have the Polisy, not the EISY, but I had the same experience and "dongle not responding" message. UD responded to my ticket with the same advice. Unfortunately, I understand that the migration process is still having growing pains so, if you plan to migrate in the future, my best guess is to hole off. If your intention is to start with a fresh z-wave installation, I would go ahead a choose the migrate option>>>use zwave dongle without migration. Unfortunately, I have not seen these instructions (regarding the migrate option) in the wiki, so I suspect this will be an ongoing issue.

I am wondering aloud whether the legacy ISY can be maintained, along with the EISY/Polisy, only for the IR capability. Of course one would have to create a communication path between the old and new (network module?). Unfortunately, I cannot offer any assistance in this matter other than to recall in the past that some were using multiple ISYs and could communicate between them.

I do not use programs for garage door status or control. All is done with scenes. What happened to your existing programs or scenes? A failure of a controller would not cause loss of any programs or scenes? How do you expect your system to operate? (What are your functional requirements?)

I don't know how long ago that the wiki reference was made. At one point, I don't think Alexa had room-sensitive commands...this is relatively recent. Before then, I assume that one could put a single Alexa , along with related devices, under separate accounts for each room. Alexa has evolved since then, and this workaround is no longer necessary.

I understand that, and have been waiting on, this is software that allows one to migrate an existing zwave network to the new zmatter system without having to go through the exclude/include process for every zwave device. I did not want spend all the time needed to recreate the zwave network. My existing system is working fine and I had no urgent need to migrate to IoP. For those of you willing to manually re-add all your z-wave devices to IoP (whether using zmatter or a dongle) I do not think that this announcement is any big deal. Or, perhaps this earlier software releases were "beta" and this one is actually z-wave certified.

Yes, one can migrate Insteon. I understand that zwave migration yet to be available but is coming soon. I should have been more specific.

I am using polisy with the legacy ISY-994. (I am waiting on the migration software to move the ISY capability over to the polisy). It works well. As Goose66 says, this will allow you to integrate additional devices into your ISY without the complications of using the network resources module. I use hue lights, roku, Sonos, and a few others. The ISY now can control such things.

Even if we don't get the migration software by the 9th, there are still better options, like golf and pickleball.