bpwwer

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.

Hello Everyone, This is the support thread for PG3x v3.1.25

Hello all, We are very happy to introduce PG3x v3.1.25 for eisy. The eisy is using a new version of Polyglot version three called PG3x. PG3x has infrastructure changes to make node servers (and PG3x) more secure. For now, Polisy users should remain on PG3 and eisy users will use PG3x. To upgrade PG3x: 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 should restart/reboot the eisy. Do this from the Admin Console, Configuration, Reboot. Once PG3x has restarted, reload /refresh the browser page. Changelog for 3.1.25 - Add debug logging for setClientState - Remove setClientState test message. - Fix stopLogging - typo in config.logStreams caused duplicate messages in UI log display - Fix working of update check failure message. - Change 'ISY' to 'IoX' - change ISY to IoX for installation target. - Do timestamp checking for setClientState - Rewrite the developer documentation. Lots of new content. - Disable node server auto-updates. Now displays "Update" button when new node server version is available. - Auto update install URL with submit to store changes. [developer tools] - Check for "null" devd entry - fix spelling of storeEntry - Delete debug messages

It doesn't really matter who/what installed the node servers. The flow looks like: - PG3 queries IoX for node servers installed on IoX - IoX returns the list. Based on the info, PG3 knows if it installed the node server or something else installed the node server - For all node servers not installed by this PG3, it creates an "Unmanaged" database entry to show that something is already installed in that slot. - PG3 queries IoX again for node servers installed on IoX - IoX returns an empty list This triggers the behavior. It doesn't matter who originally installed the node server, all that matters is that the list returned by the IoX previously had entries and now it has no entries. If the list had 10 entries and you remove one via PG2 or via admin console so that the list now has 9, PG3 will also remove that entry. If the list had 10 entries and you remove 9 of those either via PG2 or via admin console, then PG3 will remove those 9 entries. If the list had 10 entries and you remove all 10, then you've triggered this special case handling. Maybe this is a better way to explain it, if the number of node servers in the PG3 database > 0 and the IoX returns 0 node servers installed, PG3 assumes something has gone wrong and doesn't update it's database. This is because it can't "un-update" the database if the IoX returning 0 node servers was a temporary error.

Unmanaged means that whatever instance of PG3 you're running is not able to manage (start/stop/remove) those node servers because they were installed on something else. In general, removing them via the IoX admin console will remove the unmanaged entries from the PG3 database. With one exception. There is one case where PG3 won't remove the unamaged entries and that is when the IoX reports that no node servers are currently installed after previously reporting there were node server installed. From PG3's point of view. The IoX said it had node servers installed and now it says it has none. There are two reasons this could happen 1) You, the user purposely removed all the node servers from the IoX. 2) Something went wrong, the IoX has been factory reset and you are about to restore the IoX from a backup PG3 doesn't know which of those two cases caused the IoX to report no none servers installed. If it assumes it is #1 and it wasn't, then you'll end up in a bad state. If it assumes #2 and it wasn't you end up with the unmanaged entries which is annoying, but not fatal. So it assumes #2. So how can you force it to clear out those slots? Install a node server in an unused slot. Then IoX will report 1 node server is installed and it will assume the IoX configuration is valid and will update i'ts database to clear out the unmanaged entries.

No, it's not. The node server is only a MQTT client. There needs to be a broker running somewhere that it can connect to. The node server attempts to connect to a broker at 10.10.2.20:1884 but it never succeeds. I just looked at the node server code. When it connects to the broker, it outputs "Poly MQTT Connected, subscribing" to the log. That never shows up in your log. The configuration instructions point to this thread on the forum for more information on setting things up.

It is just information. When the node server is installed, it will install those Python modules too as they're needed for the node server to function. You don't need to do anything. Set the node server log level to debug and restart the node server. There will probably be information in there that will help understand what is happening.

The connection error indicates that it can't connect to the MQTT broker. Did you install/configure a MQTT broker for this? If so, what do the broker logs show?

Using 127.0.0.1 for the mqtt server means that nothing external to the eisy will be able to connect to it. You need the eisy's external IP address there. That's 10.10.2.20 right?