bpwwer

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?

I've never used the node server, but looking at it, I believe it should create nodes for your sensors shortly after you enter the username and password. It looks like it should have created a control node on startup and that node should have a "Discover" button. Clicking that will cause it to query for devices and create the nodes also. You do have to restart the admin console after installing the node server for the admin console to correctly display the nodes new nodes.

Yes, eventually (no current timeframe has been decided), PG3 will be deprecated. But for reference, I'm still doing almost all PG3 development on a Polisy with PG3. Then once I have it working on PG3, I move it to PG3x on eisy. PG3 on Polisy isn't going to suddenly disappear. Right now, it's only remote access to PG3x that doesn't and won't exist on PG3. There may be some node servers that depend on either the remote access framework or eisy specific hardware that work on a Polisy. Oh and PG3x will display update related notices like the admin console does. That's also something PG3 can't do. For people that are still using a i994 and have a Polisy, there's no good reason to try and migrate from i994 directly to PG3x. I'd first move to Polisy/PG3 and once that is stable, then you can think about migrating to PG3x.

I'm not sure what that link does. My assumption is that it sets a variable telling the Polisy that it should install PG3x instead of PG3 when doing updates. It should also remove PG3 and install PG3x. and then restart everthing. When PG3x first starts, it will check to see if it needs to migrate the database/node servers from PG3 to PG3x and will then proceed to do that. Depending on how many node servers are installed, this can take some time. It should send notices to the PG3x UI for each node server it migrates. Expect at least 30 seconds to 1 minute for each node server. If you interrupt this process you'll probably end up with some node servers migrated and some not so don't be in a rush, take your time. It also logs the migration progress in the PG3x log file so if something does go wrong, downloading the PG3x log and attaching that to any support request (ticket or forum/PM). I believe it does not try to start the node servers after it migrates them so they should all be in the disconnected state and you have to manually start each one. The migration should not effect any configuration or existing nodes. My testing involved migrating 30+ node servers multiple times (so yes, it takes quite a while to run) and I didn't see any issues, but I can't account for all the different environments and combinations of node servers. There's no easy way to go back to PG3. In theory, the variable can be cleared, PG3 can be re-installed and restored from a PG3 backup and it should work. There's probably some other stuff that PG3x did that will need to be cleaned up, but it should work. This hasn't been tested so for now, best to consider it a one-way migration. If you try https://polisy.local:8443/rest/pg3x.enable and it doesn't work, please submit a support ticket.

I would assume the username/password is the same as what you use to log into the admin console. We've been working to consolidate logins to use that everywhere, but we're not there yet. That is one difference between PG3x and PG3. PG3x uses the same username/password as the admin console, PG3 has it's own username/password database that's independent from everything else.

Currently the only "feature" difference between PG3 and PG3x is that PG3x is getting remote access support. We can't do remote access for PG3 which is one of the main reasons PG3x was developed. There are internal changes in PG3x that make the node servers more secure but that's not something that is user visible. There are no other plans for PG3x specific features other than those that are enabled because of the remote access framework. An example is that there is a Ring node server that will piggyback on the remote access framework and thus, will only run on PG3x. As mentioned above, Polisy is capable of running PG3x and there is a migration path available to switch. We can migrate from PG3 -> PG3x but we don't have an easy way to migrate back so make sure you make backups of everything before attempting to migrate PG3 -> PG3x.

Thanks! That's not how I thought they'd map.

I'm still curious if I'm missing something with the 1,2,3,4,all buttons. I'll have to add some additional logging to the node server to check that. Also, if you can check each of the other buttons and let me know which button mapped to which letter, I can update the node server to name them better.

You'll only be able to trigger on control, not status. You don't see something like this: The Test_Pico is a 3 button Pico remote. It might say "on" instead of "Button Pressed". I believe the Lutron app creates that representation internally based on how you've linked the devices in the app. The node server doesn't have that same ability. The app isn't really communicating with the remote commanding the remote to send a specific button press event to the bridge, it just knows that the button is linked to the shade so it it sends out the command to the shade directly when you press the virtual button. I don't know how Lutron tracks what is linked to a button press event. The unofficial information I have on the Lutron API doesn't document any way to get that information from the bridge (assuming it is actually stored in the bridge and not in the app or in the cloud).

@hart2hart I had no idea that's what the remote looked like. Support for it is in the node server but it's completely wrong based on what the remote actually looks like. Since it thinks it's supported, it won't dump any of the information it normally does for unsupported devices. Some general information about Lutron remotes (mostly Pico's). As I said, they are control devices. When you press a button on the remote, it sends a button press event with info about what button was pressed and then it sends a button release event when you release the button. The node server can detect the button press events and use that to trigger programs (and via a bit of a hack, scenes). The node created for the button isn't a simulated button. The node server cannot generate button press or button release events and send those to other devices. The Caseta API doesn't have any way to do that. That's why there's no "action" available in the node. I had assumed that the remote you have is similar to the other Pico remotes but it isn't. I suspect that when you press one of the number button (or all), it doesn't actually send out any events, just sets internal remote state. Then when you press the open/close/raise/lower or favorite button, it does send out an event. So that may be what the 5 nodes represent. There must be something different in the button pressed events depending on which number button was last pressed, but I don't know what that is. With Lutron (at with the Caseta smartbridge) you can only control devices directly. So if you want to control the shades from the node server, you'd use the shade nodes to do that. You can't have the node server tell the remote to control the shades. I think the only thing you might be able to do with the remote is something like this: If the remote open button is pressed, run a program to do something if the remote close button is pressed, run a different program You can experiment and see if you can create a program that triggers on one of the buttons. The way the node server configures the remote button nodes you should only have the option to trigger on button pressed. I'd like to know if this works. It probably maps A = Open, B = Close, C = favorite, D = Up/raise, E = Down/lower

I don't think I've seen any info on a 10 button remote. Which means it's not really supported in the node server. The log should detect the remote and dump some information about it. I'll need to see that info before I can add support for the remote. I'm curious as to what it was detected as. There's nothing in the node server that should create a node with a 'F' suffix. Yes, you can put the shades in a scene to control them all. I believe you can group the shades in the Caseta app to allow them all to respond to a single button. At least I somehow set my 2 up so that they only only remote that controls both. The node server doesn't do any polling so it doesn't matter what you set the poll values to.

Yes. The trial and the licensed node server are the same, except the trial expires after 30 days. I believe once you purchase the license, it replaces the trial license and the expiration is no longer checked. Worse case, you'd need to re-install but that won't delete any configuration you've done or any nodes already created.

Disconnected means it was unable to connect to the local (or configured) IoX. There are only a few different reasons it wouldn't be able to connect and viewing the log should reveal which. 1) the ISY software isn't running. In this case you also would not be able to start the admin console. The log would show a connection refused error. 2) The IP address is configured wrong. By default it's using the local address 127.0.0.1:8080 which is the local IoX. If you didn't change the configuration, then this should be correct. Again, you'll get a connection refused if it trying to connect at the wrong address. 3) The credentials are wrong. It starts with the default of admin/admin, but is supposed to update them if you log into PG3x with something different. The log will show 401 (authentication) errors in this case. You can update the credentials manually in PG3x via the ISYs -> Edit current ISY menu.

PM me the PG3x log file

An update on the bug. " a player drops and a topology change event occurs. If a topology change occurred which changes system.zones, but the group this thing was in did not get updated in a timely manner for some reason, then that is exactly the behavior you would expect." So there are two possible ways this bug could be triggered. A fix has been proposed. I'll keep monitoring it and update the node server as soon as a fix is available.