Jump to content

Migration to ISY on Polisy: An attempt to collect, organize and share Simplified Directions.


dbwarner5

Recommended Posts

Posted
14 hours ago, Techman said:

Your link count is too low for the number of devices, especially if you have keypads with numerous nodes. It's possible that your restore file had issues. Did you do an ISY backup before you migrated over to the Polisy

Try removing power from the PLM and Polisy, then power up the PLM wait about 30 seconds then power up the Polisy.

 

Everything is now working correctly with the exception of one keypad (Should be able to figure it out). Seems that the fix was to restore and old ISY backup then run restore devices. I don't know if it made a different but before moving to the Polisy I had just upgraded to 5.3.4 so I reverted back to my last backup of 5.3.0. My PLM table when from 50 ish to approx. 300.

Thanks for the help! 

Posted
1 hour ago, RGKS said:

My PLM table when from 50 ish to approx. 300.

The important think to understand about link counting is that ANY Insteon traffic that occurs during the link count will destroy the link count.  The resulting count can be way too low or way too high.  In a system that's all switches it's easy to avoid other traffic... do the count will no one else is home and don't turn anything on or off.    In system's with battery devices... it's a bit more difficult... motion and heartbeats in particular.  

To verify that the link count is valid run the link count repeatedly until you've obtained the same number more than once.

  • Like 1
Posted
On 3/28/2022 at 9:46 AM, MrBill said:

The important think to understand about link counting is that ANY Insteon traffic that occurs during the link count will destroy the link count.  The resulting count can be way too low or way too high.  In a system that's all switches it's easy to avoid other traffic... do the count will no one else is home and don't turn anything on or off.    In system's with battery devices... it's a bit more difficult... motion and heartbeats in particular.  

To verify that the link count is valid run the link count repeatedly until you've obtained the same number more than once.

Thanks for clarifying the  PLM table count functionality. Everything is now working correctly. I still need to do a few checks and balances but the migration is successfully complete. Good to have a few issues once and while, helps to learn the system a bit more in-depth along the way!

  • Like 1
Posted (edited)

“ISY made me do it…”

 

I have been a long-time user (>10yr) of ISY. Along the way I added Z-Wave, 10 Node Servers, 800 hundred programs, (8) Alexa, and Polisy to the fold. I have had my Polisy since the beta-group release and during that time, it has hosted my 10 node servers without issue.

 

I installed IoP when it became available but was holding off migrating due to the need to manually migrate Z-Wave devices.

 

Up until last Monday, ISY (> 10-year-old) was running the main show. Sometime in the dark rainy night, ISY died with a flashing red error LED. I thought this was just a simple sd-card change time but after 3 sd-cards and a continued persistent flashing red LED I took it as a “sign” to move to ISY on Polisy.

 

Thanks to @dbwarner5 and many other members here for posting their tips, tricks, procedures, and advice. With these, my migration was absolutely uneventful. Insteon nodes, scenes, and programs all migrated without any issues. My only cost was the hour or two excluding and including all of the Z-wave nodes and fixing Z-wave scenes and program entries. This was also a good time to review some old programs.

 

I don’t have any objective evidence but can say that with IoP, my system seems much faster and response to events seems crisper. I especially like the speedy opening of the Admin Console. ? I am very happy that I took the plunge and upgraded to IoP.

 

Many of us have come to rely on our ISY home automation as an essential piece of modern life.  Thanks to UD technical team and the contributors to this forum for making such an easy and painless upgrade solution possible.

Edited by gviliunas
  • Like 5
Posted
3 hours ago, gviliunas said:

Thanks to @dbwarner5 and many other members here for posting their tips, tricks, procedures, and advice. With these, my migration was absolutely uneventful. Insteon nodes, scenes, and programs all migrated without any issues. My only cost was the hour or two excluding and including all of the Z-wave nodes and fixing Z-wave scenes and program entries. This was also a good time to review some old programs.

Thanks for sharing. Your set up sounds a lot like mine and your experience is motivating me to make the jump. (I'd prefer to do it without my ISY dying though.)

  • Like 2
Posted (edited)

Hello All

I've read through all i could find, but the migration (restoration of backup) of my 994 to Polisy has resulted in my Amazon spoken missing from the Portal Amazon Tools.

The nodes are visible, just the spoken configuration is missing.

My polisy seems to have all the nodes from my previous isy.

Have updated preferred isy, updated ISY skill in alexa and still no luck.

Polisy seems to be working otherwise. One thing i have not been able to configure is the IP of the 994. These settings are greyed out on Polisy Admin Console.

 

If i need to rebuild I have exported the topo, but am uncertain which is the amazon spoken.

Also, I failed to make note of my Node server slots. Any way to recover this info?

 

Any suggestions would be much appreciated.

Edited by PB11
Posted (edited)

There is a new transfer setup function on a pulldown menu at one of the bottommost menus in ISY Portal.

It is best to set the IP of IoP in your router's DHCP reservation table.

Edited by larryllix
Posted
18 minutes ago, larryllix said:

There is a new transfer setup function on a pulldown menu at one of the bottommost menus in ISY Portal.

It is best to set the IP of IoP in your router's DHCP reservation table.

Thanks @larryllix. I did do this step but the spoken have not transfered. When I now go back, my polisy is not the migrate from option and my old 994i is the migrate to option so I'm not able to run it again.

 

Posted (edited)
2 hours ago, PB11 said:

Thanks @larryllix. I did do this step but the spoken have not transfered. When I now go back, my polisy is not the migrate from option and my old 994i is the migrate to option so I'm not able to run it again.

 

Sounds like a ticket request from super @Michel Kohanim before the data becomes lost.

or perhaps @bmercier would be able to help. He's the creator of this bridge over troubled waters.

Edited by larryllix
  • Thanks 1
Posted

Well I took it as a chance to clean house.

I used the alexa website to get the names of my previous devices and scenes and went through rebuilding them and cleaning Alexa up.

I will test over the next few days to see how things are working.

 

Now to Node server installation on the Polisy

  • Like 1
  • 2 weeks later...
Posted (edited)

Well this is not going well at all.  The only thing that went to plan was getting Insteon working.  The node servers are not working.  PG3 is totally messed up and PG2 only works from PG2 to ISY.  If I try to send a command from ISY to the node server, it says "busy" and then times out with an error.

PG3 won't accept me changing settings.  I try editing the ISY and it says "updateisyparameters invalid".  I tried adding it as a second, and that sort of works, but just has all kinds of issues.  

Nodelink has the same problem.  I can't send commands to it, it populates the admin console, but I can't send any commands to my DSC alarm without an error.

PG3 images below when I edit current isy

image.png.a5a6e6bc983eea98098f30046bd22091.png

image.thumb.png.eb4f1f15cf42e055933267c448729e88.png

 

 

 

image.png.3278ba085ffb0c268e12e78a722e91ca.png

 

UPdate; I have discovered the nodelink is getting commands from ISY, however, ISY doesn't think it is working.  ISY says busy and then gives an error, even though the command went through.  Other polyglot does not do anything.  Also tried restoring backup of pg3, and it doesn't do anything.  No nodes, no configuration.  The ISY setup page has no uuid and no way to enter a uuid.  Only if I add a second ISY can I get a uuid, but the nodes I installed aren't there.

 

UPdate:  OK, figured out some of the issues.  Upon moving to IoP, I moved polisy's IP address to the IP that used to be for my ISY.  This of course moved the node servers as well.  ISY however held onto the old IP address for polisy even though polisy from its side logged into ISY, ISY did not update that IP.  

However PG3 still is dead.

Edited by apostolakisl
  • 5 weeks later...
Posted (edited)

This was very helpful for me. Been working IoP with PG2 for several weeks and decided today to try to migrate from PG2 to PG3.  I have 8 Nodes and several that needed purchasing. 

Here's the problem I'm having:

- When going into PG3, the first thing that I need to do is add the ISY. But when I do, the Nodes come up on the dashboard all saying unmanaged and "no details". Expected since I haven't restored the PG2 backup.bin file yet. When I try to "Restore PG2 to xx:xx:xx:xx:xx" nothing changes and the existing slots remain inactive.

- The migration instructions say to purchase any node licenses prior to restoring. But when trying to install those nodes, it wants to put them in NEW node slots (starting at 9 for me) since the existing ones are already occupied. For example, my Ecobee is in slot 2, but when I purchase and try to install the Ecobee node, the only slots available start at slot 9. It won't allow me to put it in slot 2. And it doesn't allow me to delete the existing nodes in the dashboard.

- Trying to Restore the PG2 file before adding an ISY is impossible since the "Restore PG2 backup. to 00:00:00:00:00" option is not there until you actually add the ISY first.

It seems to me that I would have to delete all of the nodes in PG2 first, then restart Admin Console to remove them from the ISY, then go back into PG3 and restore the Nodes to their proper slots and HOPE that they will re-appear in Admin Console in their proper positions.

Am I missing something?

 

Edited by abartello
Posted (edited)

When you first install node servers they are unmanaged due to not connecting to the end devices. Once those parameters are setup and connected the NS will install the nodes into your IoP.

Edited by larryllix
Posted
9 hours ago, abartello said:

This was very helpful for me. Been working IoP with PG2 for several weeks and decided today to try to migrate from PG2 to PG3.  I have 8 Nodes and several that needed purchasing. 

Here's the problem I'm having:

- When going into PG3, the first thing that I need to do is add the ISY. But when I do, the Nodes come up on the dashboard all saying unmanaged and "no details". Expected since I haven't restored the PG2 backup.bin file yet. When I try to "Restore PG2 to xx:xx:xx:xx:xx" nothing changes and the existing slots remain inactive.

- The migration instructions say to purchase any node licenses prior to restoring. But when trying to install those nodes, it wants to put them in NEW node slots (starting at 9 for me) since the existing ones are already occupied. For example, my Ecobee is in slot 2, but when I purchase and try to install the Ecobee node, the only slots available start at slot 9. It won't allow me to put it in slot 2. And it doesn't allow me to delete the existing nodes in the dashboard.

- Trying to Restore the PG2 file before adding an ISY is impossible since the "Restore PG2 backup. to 00:00:00:00:00" option is not there until you actually add the ISY first.

It seems to me that I would have to delete all of the nodes in PG2 first, then restart Admin Console to remove them from the ISY, then go back into PG3 and restore the Nodes to their proper slots and HOPE that they will re-appear in Admin Console in their proper positions.

Am I missing something?

As mentioned in other threads, neither PG2 or PG3 were designed to allow migration so the process is not good.

"Unmanaged" means that some other instance of Polyglot installed and is managing those node servers. In your case, it's the PG2 instance that installed and is managing them.  

You don't need to do the install after purchasing the PG3 versions.  To restore from a PG2 backup you just need to have the license, you don't need, or even want the node servers to be installed before doing the restore.  The restore will do the installation.

If the restore from PG2 backup works, it will install the PG3 into the same slot and update the ISY so that it works with the PG3 version and not the PG2 version.  However, PG2 doesn't know this happened and still thinks it is managing those node servers as well.  Like I said above, PG2 was never designed to allow this and you're basically making PG3 steal the node server control from PG2.   From this point forward, you should not use PG2.

You can also use PG2 to delete the node server(s) first, then PG2 won't being trying to control the node server/ISY.  Once restored with PG3, it should work, but you may have to do some manual fixing as there's no guarantee that the PG3 is exactly like the PG2.  The PG3 configuration could be different and the nodes create by the PG3 version could be different.  It varies depending on the node server.

  • Like 1
Posted

Hello team - fantastic threads -

takes some doing and tech savvy, but I was mostly able to get my older Polisy to install PG3 (which seems to have brought IoP along for the ride) and was able to restore a backup of my isy to IoP.  I got Zwave to show on the menu too (it seems to needs  2 reboots of isy, which I do not see in the threads).

 

However, I am having issues with PG3 node servers - it looks a lot like abartello's issue - except I had already moved from PG2 to PG3 on my isy, before attempting a migration.  The results of that is that all of my nodes show as unmanaged under the IoP isy in PG3 Dashboard.  They all look normal in isy Dashboard.  Since PG3 is supposed to be able to handle 2 isys (or more), I tried selecting IoP and then restoring backup of PG3 from my isy to IoP.  Nothing changes from that.  Even stranger is that all the nodes show on my IoP, but they cannot connect to anything.  So, slots would start at 10 (I have 9 nodes filled on the isy).

 

How can I get PG3 to recognize 2 different ISYs?  Can I migrate PG3 to PG3?  If not, how can I get the ghost nodes on my IoP to go away to even install nodes fresh to IoP, even if there is ?  Do I have to delete them from isy?  But then isn't it as if it cannot handle 2 isys in PG3?

 

Any help greatly appreciated.

 

Posted

I know this is confusing, but again, nothing about how node servers were implemented in the past was designed to support migration of node servers. 

When a node server is installed, it is installed on both the Polyglot instance and on the ISY.  The ISY gets configured to point at the Polyglot instance and the Polyglot instance gets configured to point at the ISY.

Let me go through a simple example.  Here's the names I'll use to try and make it clear what I believe happened.
I

ISY994 - a 994 based ISY controller
ISYIOP - ISY controller running on a Polisy
POLISY - The Polisy controller
PG2    - Polyglot version 2 running on Polisy
PG3    - Polyglot version 3 running on Polisy
PG2NS1 - A node server from the PG2 node server store
PG3NS1 - The new version of the node server from the PG3 node server store

Originally, PG2NS1 was installed on ISY994 in slot #1.  The configuration of that slot points back to PG2 on the Polisy.  The PG2 database holds a reference that says PG2NS1 is installed on ISY994 in slot 1.

Looking at the PG3 dashboard when PG3 is configured for the ISY994, it will show PG2NS1 in slot #1 as "Unmanaged".  That means that while PG3 knows that something is installed in ISY994's slot 1, it has no reference in it's database for it and thus, can not manage it.

Now we migrate ISY994 -> ISYIOP.  

The configuration on ISYIOP for the node server in slot #1 is copied from what was in ISY994.  However, PG2 doesn't know that this happened.  PG2 is has the reference to ISY994.  Maybe the migration tool fixes the PG2 database entry as part of the migration, I don't know.  If the node server continues to work after the ISY994 is unplugged, it must.

Now you add ISYIOP to PG3.  Through the ISY menu you should be able to switch between the two ISY instances and the dashboard will show what is installed in the currently selected ISY.  

NOTE: Both ISY994 and ISYIOP have the same PG2NS1 installed in slot 1 (you copied the configuration from ISY994 when you migrated to ISYIOP).  So in PG3, the dashboard for each ISY should look the same.  PG3 still does not have a reference to PGNS1 in it's database so it remains "Unmanaged".

When you create a backup of PG3, you're not backing up the ISY(s). You're backing the PG3 database and the installed node servers.  At this point no node servers have been installed on PG3 so all you really did was backup the PG3 database and restore the PG3 database.  NOTE: the backup doesn't care which ISY is selected, it backs up everything.

I believe this is where you are now.  You have a couple of choices on how to proceed.

1) you can make a PG2 backup and attempt to restore that PG2 backup on PG3.   The PG2 backup will be of PG2NS1 and it's configuration from slot #1.   When restoring this on PG3, PG3 will look to see if PG3NS1 exists, and if it does, it will install it in slot one of which ever ISY is currently selected, overwriting the PG2 configuration that is already there.  The PG3 dashboard should then show the PG3NS1 installed in slot #1.  Switching PG3 to the other ISY will still show slot #1 as "Unmanaged" since you only restored the PG2 backup to the one ISY. 

2) you can delete PG2NS1 from ISYIOP and then install PG3NS1 to slot #1 of ISYIOP.  If the PG3 version of the node server is the same as the PG2 version, it should re-create the same nodes and everything will work.  If it's not, you'll have to manually fix scenes and programs to use the PG3NS1 nodes instead of the PG2NS1 nodes.

To answer your last question, you can't migrate a PG3 node server from one ISY to another. 

PG3 can manage node servers installed on multiple ISY's (I.E. install/delete/start/stop).  But manage and migrate are two different things.

  • Like 1
  • Thanks 1
Posted

Thanks bpwwer - I think your explanation makes sense, but I may have been unclear on one point - while I do still have a couple of nodes in PG2, since they are not available in PG3, most of my nodes are PG3 for the ISY.  I am not concerned about the PG2 nodes for now, as they are not critical for my programs.  But 2 of the PG3 nodes are critical.  So, I would like to install the PG3 nodes on IoP that were on ISY.  When I restored the backup to IoP, it made it look like the nodes were installed on IoP, as they show up in the node server menu and in the device list.  However, the devices have no connections, probably for the reason you gave - the internals are still addressed to the original ISY.  

This leaves me in a bind - I think you are saying I need to remove the nodes from the ISY and that will then free up the slots on both the ISY and the IoP.  I cannot remove the nodes from the IoP, as they are unmanaged there, with no delete option.

I would then need to reinstall the node servers on both ISY and IoP individually - which means I need to redo all  configurations manually on both.  I probably do not need to redo them on the original ISY for my situation, as once IoP is stable, I likely do not need it.  That said, right now, it is my hot backup of a known working configuration of my IoP migration experiment fails, so would really prefer to leave it intact and just switch the PLM when needed.

Another big downside of this approach is that all of the devices installed from the node servers that are in scenes or programs will disappear or go yellow respectively, as the device reference will be gone.  This means I also need to go in and reestablish the devices in scenes and the program conditions, statuses and actions that touch these devices.  The good news is that I have tried to abstract devices to one folder in my program stack and then use programs to access them - however, scenes are just broken and entries will disappear by this, so I need to document every scene that has a node device in it.

This is all doable, but quite painful, manual and painstaking.  And then I have a similar challenge with the Z-wave devices that also disappear from scenes and programs when migrating.

Further, my automation functionality is disrupted until I can make all the changes, as nodes and z-wave are embedded in logic along with Insteon devices.

I guess I need to leave a concentrated amount of time to fight through it, if this really the only answer, so I can make the transition in one fell swoop.  If there is any other method that is easier, would love to know before I go through with this.

And maybe this will be the last major transition until Wifi (and/or real Zigbee) gets turned on on the Polisy to talk to all the new devices supposedly coming out, so will get a break for a bit once I get through this.....

Again, thanks for keeping this group informed and volunteering your insights.  This community is one of the many things that make this the best smart automation around.

Posted
Quote

When I restored the backup to IoP, it made it look like the nodes were installed on IoP, as they show up in the node server menu and in the device list.  However, the devices have no connections, probably for the reason you gave - the internals are still addressed to the original ISY. 

Yes, that sounds right.

Quote

Another big downside of this approach is that all of the devices installed from the node servers that are in scenes or programs will disappear or go yellow respectively, as the device reference will be gone.

Yes, they will lose the reference, but if you re-install the node server into the same slot, and it creates the same nodes with the same node addresses, that should "fix" most of those references. 

Also, you can remove node servers from the ISY/IOP directly using the Node Server -> Configure -> slot # -> delete button.  Use this to clean up any that don't have Polyglot instance managing them.

If a node server is being managed by a Polyglot instance and it gets removed from the ISY/IOP, the Polyglot delete should still delete it from the Polyglot database.    So even if that one-to-one link between Polyglot and ISY/IOP is broken, you should be able to clean it up without doing anything drastic.

  • Like 1
  • 5 weeks later...
Posted

Completed my migration to isy on polisy.  All went smoothly for insteon,  some minor problems with ISY on Polisy, pg2 and PG3 and port numbers (80, 8080, 443, 3000),  somehow missed the need for these setting in my preperation.   Setup with old ISY had no port numbers entered, reading default was 80.  Took me a while to realise I had to add 8080 to the ISY /polisy ip address in nodelink. Once I figured that out smooth sailing.   All zwave items reset and reinstalled and software updated.   Only have the zwave front door to finish.

  Thanks everyone for the instructions.

  • Like 3
  • 3 months later...
Posted

I bought my Polisy by pre order when it first came out.  Somewhere I read something about if the polisy is more than 2 years old it needs to be upgraded.  Can anyone explain this please?

Thanks

Posted (edited)

So the pre order ones are old enough to have to do those instructions?  I would imagine im capable of following instructions to do it but if I cant, what would tech support do?

Edited by Blackbird
Posted
30 minutes ago, Blackbird said:

So the pre order ones are old enough to have to do those instructions?  I would imagine im capable of following instructions to do it but if I cant, what would tech support do?

I think UDI offers paid services for those who needs help in regards to setting up their system. 

Posted
2 hours ago, lilyoyo1 said:

I think UDI offers paid services for those who needs help in regards to setting up their system. 

Ok thanks.  I'm sure I will be ok if I follow the instructions.  I'm guessing it's what all of you experienced guys did when you pre ordered 

  • Like 1
Guest
This topic is now closed to further replies.

  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

    • There are no registered users currently online
  • Forum Statistics

    • Total Topics
      37k
    • Total Posts
      371.4k
×
×
  • Create New...