bpwwer

Yeah, that wasn't me that said to restore the PG3 backup, I would have liked to see a PG3x log after you tried starting a node server. I've done the PG3 -> PG3x migration on a Polisy a couple of times to test it, but that's the not same as having it run in the real world.

The status not showing up in programs is a bug. I can fix that. @Jimbo.Automates has nothing to do with this node server. It was written by @simplextech but he's no longer maintaining it, I am. Same for ST-Inventory. As I mentioned, the ST is set to true when the node server starts but there's nothing to ever set it false. Fixing this is a fair amount of work and right now it's not really a priority for me.

@JTsao based on your ticket, I don't think this is useful to you now, but might help someone else later. When PG3x migrates node servers from PG3, it leaves them in the disconnected state. You need to manually start the node servers after migration. You're post says you tried "rebooting, power cycling and restarting PG3x" and none of those steps will attempt to start the node servers when they've been previously stopped. PG3 and PG3x remember the last state of node servers. If you stop a node server, it won't be automatically restarted, you have to start it. In this case it's the migration process that stops all the node servers so they can be migrated, but it still relies on the user to start them back up.

Restart the admin console. You need to do that after installing any node server.

The status not showing up in programs is a bug. I can fix that. However, I don't think it ever changes as it looks to be hard coded to "True" in the node server. You can't use commands in the "if" part of a condition as these are things the IoX sends to the node server. They should be usable in the else/then portion to send the command on some trigger.

Great! Thanks for letting me know. It wasn't hard to add them, but you never know when you can't test.

I'm trying an experiment with this. I added support for both in version 1.0.9. I have no idea if this will work or not since I don't have any Sonos devices. So instead of replacing the existing 1.0.8 version, I added 1.0.9 as a second install option. I think you can simply re-install 1.0.9 over your existing 1.0.8 without having to get a new license, but I'm not sure. If it wants you to purchase it again, DON'T. I'll move it to the beta store. Since this does add new controls, you'll have to restart the admin console after re-installing and starting it to see those new controls.

Yes, you can run multiple copies of any node server. So in theory, you can run two copies each linked to a different smart bridge.

I have no idea what that means. The existing node server doesn't use either of those endpoints.

The node server can only link to one smart bridge.

Thanks @DennisC I meant to imply that I'd look into more, but I probably should have been more clear on that.

It won't automatically try update anymore. Each installed node server checks for updates when it is started and if it sees one available, it will display a notice and add an update button to the node server details page. Clicking the update button is a basically a shortcut to the purchases -> re-install page. It still should be doing global checks for updates every 8 hours same as it was before. It seemed to be working as intended when I tested it, but I only test with a small number of node servers (mostly my own since I can't make updates to other developer's node servers).

I don't see anything wrong. I did an update on my PG3 and it worked fine. I never had a pre 2.0 version installed on PG3x but re-installing seemed fine there. The only reason a re-install could fail is if there's a conflict between the version. That's one of the problems using git repositories to distribute node servers, if the git command fails, there's no way to automatically correct for that. Deleting the node server and then installing it should get the latest version unless something is really messed up in the current installation. Of course you do have to re-authenticate and re-configure if you do that. I have 2.0 installed but I can't get it to authenticate so maybe you don't want to update.

PM me the PG3x log package (Log menu, download log package). Then try going into the node server store, selecting the Holidays Google node server, click install, then click the re-install button and see if that works.

It's not a PG3 problem. It seems like something is really messed up w.r.t. the timezone info on the box. When write a simple program to display the time/date info I get: > console.log(date_ob.toTimeString()); 09:13:51 GMT-0900 (Pacific Standard Time) It should be Pacific Daylight Time which is GMT-0700. However Pacific Standard Time should be GMT-0800, so that's not right either. This appears to be a problem with the /etc/localtime file. It's not currently matching any existing timezone file. I'm guessing the timezone files were updated recently but the /etc/localtime file wasn't also updated to match. If I run sudo tzsetup -r it fixes the /etc/localtime to use one of the valid timezone files and then I get the right time in PG3 after restarting it.

Mine are off by -2 as well, I'm looking into it.

By default, addNode() won't change the name. But you can set the rename=True option to have it rename the node addNode(node, conn_status = None, rename = False) There's no node server differences between PG3x and PG3. You can continue to do your node server development on PG3 and they'll work the same on PG3x.

The changes were all in the server code, not the UI code. It mainly effects all the PG3 log messages.

Yes, It still only checks for the update when the node server is restarted. I'll see if I can make it check more often so you don't have to restart the node server. Thanks for pointing out the incorrect text. I'll get that fixed as well.

No, this topic is for Polisy PG3 version 3.1.20. The eisy 3.1.25 support topic is

fixed in 1.0.12 Thanks for reporting it!

Hello Everyone, This is the support thread for PG3 v3.1.20

Hello all, We are very happy to introduce PG3 v3.1.20 with bug fixes and new features, see changelog below. To upgrade PG3: In the Admin Console, click on Configuration, Upgrade Packages (note, this can take many minutes, depending on how long it's been since you last updated.). After the upgrade is complete you will need to restart PG3. From PG3 select System-> Restart Polyglot 3. Once PG3 has restarted, reload /refresh the browser page. Changelog for 3.1.20 - Fix wording of update check failure message. - Change 'ISY' to 'IoX' - change ISY to IoX for installation target. - Update developer documentation - Disable node server auto-update on restart. Add a manual update method for node servers.

First, please update PG3x. 3.1.25 is the latest version (just released yesterday). Version 3.1.23 had a bug that may prevent some node servers from installing. All 4 example node servers should install and run. The template node server was more a reference on how to use some of the udi_interface API's than a working node server. Node server debug relies almost exclusively on log files. PG3(x) outputs a lot of information so that it's pretty easy to follow what it is doing and where something goes wrong, when it does. While doing any node server development, it's not a bad idea to have a ssh session running that just runs 'tail -f /var/polyglot/pg3/pg3-current.log'. With PG3x, a lot of the node server control (add/remove/start/stop) is now external to PG3x and handled by UDX. That is all logged in /var/udx/logs/pg3_helper.log Once the node server is running, you'll want to track it's log file (/var/polygot/pg3/ns/<uuid_slot>/logs/debug.log) Both the node server's and PG3's logs are also available through the PG3 UI.

Power cycling seems to be the best way to reset the eisy. In theory, there should not be any difference between a reboot and power cycle. But based on all the reports here, a power cycle seems to fix things that a reboot dosen't.