bpwwer

In general you can't. But since the migration process is not great, it's not impossible to end up in that situration. You should be fine restoring from a PG2 backup. Just make sure you either delete the node servers from PG2 before doing the restore. The PG3 restore from PG2 backup can't clean up what's on PG2 after the restore.

There have been changes to the way node servers work since this node server was ported. The node server is not responsible for that status value, PG3 is. I've updated the node server so it should work correctly with the latest PG3 design.

It is slot dependent. So if there is a PG2 node server in slot that you are allowed to install and you have a different node server in PG3 slot 2. The restore will overwrite the existing node server in PG3. However, if there isn't any slot "overlap" between what's in the PG2 backup and what's currently installed on PG3, then none of the existing PG3 node servers would be effected.

Added this to the issues list for the node server so I've captured the request.

Try version 2.0.4, I made some changes that I think should fix that.

Seems like that used to work. I wonder if a new version of Python is now more strict about that sort of thing.

Have you installed PG3? I don't believe it is being installed by default yet so you have to manually install it using the instructions in the release announcements for PG3 before you can use it.

No command sent by the ISY to a node is synchronous. In this case, the ISY sends the backup command to the node server node. It does not wait for any response. The node server then queries every lighting type node for it's status. It does this one-by-one. How long it takes to complete will depend on how many devices you have and what else the ISY is busy doing. Polling is not used. It only does the queries when asked and same for the restore.

you can send it directly via a PM here. Ideally, just download the PG3 log and attach that to PM. Also, before you do that, can you verify what version of PG3 your are running?

I did the port of this node server from PG2 to PG3 so it's possible I broke something when I did the port. I don't use Google Calendars so I'm not sure I can thoroughly test it myself. I have no issues installing it. The error "Node server object missing uuid" is not in any of the PG3 code. It also doesn't make any sense because object names can't have spaces so there isn't any objects in PG3 named "Node server". I don't doubt that you're getting an error, but with that information I'm not able to do anything to debug it. PG3 logs showing when you try to install it would help.

I'm wondering what a node server for WOL would look like... Configuration could be via custom parameters: [host] : [mac address] [host2] : [mac address2] I would assume the goal would be to have a program action that sends the WOL packet to one of the configured devices. So would this create a node for each host and that node would have one command to send the WOL packet? Or would a single node with a dynamic parameter list for a send command be better? A node per host would be easier to implement, but that brings up the question @Michel Kohanim, what is the node limit for IOP? It could be a pretty simple node server, so what's it worth?

Yes, that sounds right. 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.

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.

That's strange. I'd like to understand better what happened the first time so that we can prevent that from happening to others in the future, but if you don't know, it's OK.

From the polyglot dashboard you can select the node server details and then the "Log" button. From there you can change the logging level. I believe it is set to Info by default. Changing to Error or Warning should reduce the amount of logging significantly.

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.

"Unmanaged" means that it was installed by a different instance of Polyglot. Only the instance that installed the node server can manage the node server. By your description, it sounds like you have two Polyglot installations (PG2 and PG3 maybe?) If that's not the case, you'll have to explain how you got your system into this state so we can figure out the next steps.

No idea, I don't know anything about this node server, sorry.

Yes, but it backs up all lighting type devices and restores all lighting type devices. You can't work with just a subset of devices. Although that would be a nice enhancement.

Yes, the free accounts do have limits, typically on the number of requests that can be made in a 24hr period. I don't remember what those limits are for the various services but I did try to set the default polling intervals to be high enough to not hit those limits. It is the poll intervals set in the node server that define how often it makes requests to the service. ISY programs won't trigger additional requests.

The instructions are referring to the PG3 custom parameters configuration, not ISY variables. You enter this in configuration section of node details for the node server on the PG3 user interface.

It should be in the store now.

PG3 (and PG2 actually) is really 2 separate components. There's the server component that interacts with the node servers and the ISYs and there's the frontend, or User Interface (UI) component that you interact with. The server component code runs on the Polisy in the background. The UI component runs in your Browser. In general, the versions should match. When a release it built, it updates the version number for both components. If they don't match, the most likely reason is because a new version was installed but the Polisy is still running the old version of the server component. The latest version of PG3 will tell you this and prompt you to restart PG3 to get the latest version installed on your Polisy running.

RA3 uses the Lutron LEAP protocol which is not publicly available. There are folks working to reverse engineer it. It really comes down to whether or not Lutron is willing to work with UDI or the reverse engineering efforts can provide a stable working library. RA3 does not require a licensed installed to install. Lutron makes the training classes available to anyone and once take, you are free to buy and install RA3 products. No, the Lutron processes/bridges can communicate over your local network via LEAP (or LIP) protocol. Their app has cloud dependencies, but node servers would not (at least the current ones for PG2 do not).

Ok,