bpwwer

Hello Everyone, This is the support thread for PG3x v3.1.17 - v3.1.21

Hello all, We are very happy to introduce PG3x v3.1.22 for eisy. This is a minor update to 3.1.21. 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. Both PG3 and PG3x have the same feature set with the exception of a feature in PG3x that allows migration of node servers from PG3 to PG3x. For now, Polisy users should remain on PG3 and eisy users will use PG3x. This fixes a number of bugs in the original PG3x 3.1.16 release and adds the ability to migrate from Polisy/PG3. 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 may need to restart PG3x. From PG3x UI select System-> Restart Polyglot 3x. Once PG3x has restarted, reload /refresh the browser page. Migrating from Polisy/PG3 Make a PG3 backup on the Polisy. From the PG3 UI select System -> Backup/Restore -> Backup. This will download a backup file Restore the PG3 backup on eisy. From the PG3x UI select System -> Backup/Restore -> Migrate from PG3 backup. Select the Polisy PG3 backup file and when the button changes to "Restore" click it. Depending on how many node servers need to be migrated it can take a while. The UI should pop up messages showing the status as it migrates node servers. There are some limitations to the migration process. Only one IoX device can be migrated. If your Polisy was connected to more than one IoX device (say the local IoP and an i994), the migration process will only migrate one of these and it will use whichever one shows up first when it does it's database query. This will remove any previously installed node servers in PG3x and possibly overwrite them with a node server from the backup. You should start this process with no node servers installed. Any node servers on the Polisy that were installed from the "Local" store will fail to properly migrate (applies mostly to developers). All node servers will be left in the "Stopped" state. You will need to manually start each node server after the migration. Changelog for 3.1.22 - Rebuild package to work with Node version 19.5 Changelog for 3.1.21 - Don't loop over non-existent nodes when displaying node details in UI - Add ability to handle system upgrade messages and display a notice in the UI when the system is being upgraded. - quote password when sending to pg3.ops. Fixes issue with passwords containing special characters like '$$' - Try and trap network errors when verifying node servers installed on IoX. - Fix typo in log message. - Fix bug that caused dashboard to ignore "un-managed" node servers. Changelog for 3.1.20 - Fix minor bug in UI where we tried to use settings before they were set. - remove debugging messages. - Return status = 500 , and error if authentication crashes - Revamp verify node servers behavior. PG3x will now try to make the IoX match what is in it's database to better keep IoX and PG3x synced on what node servers are installed. - Fix IoX auto discover to not overwrite existing entry's username/password. - Change how the UI authenticates with the MQTT broker. This should resolve issues with logging and and bring back the ability to use multiple browsers to access PG3x at the same time. - Stop printing the mqtt frontend password in the log - Quote the user name so that it now works if the name has space characters. Changelog for 3.1.18 - Pass the correct structure to installProfile. Fixes profile files not being sent to IoX on node server install. - Allow 127.0.0.1 for IoX node config ip address. Stops PG3 from replacing the localhost IP with network IP on node server verification. Changelog for 3.1.17 - Change the IP address written to the IoX node server configuration to use 127.0.0.1. - Fix typo status should be stats in checkLicense. Caused licence check to fail for some purchased node servers. - Change ISY to IoX throughout the UI. - Always route reinstall through nsinfo, specifically fixes issues when re-installing via the purchases page. - add logging and pg3_install fixes to get permissions correct after install of node server. - fix typo in error message, puchase should be purchase. - Update database to indicate we've migrated to PG3x. - Add ability to migrate from PG3 backup. - Enable check for PG3 node server migration on start. - Add count of node servers re-installed to reinstallNS response. - Add ability to re-install all node servers via the System menu. - Handle alert and reinstallNS messages. - Add pg3x flag to global settings. - Don't update node name to 'undefined' - Remove "Running on Polisy" from footer. - Make node server verification errors more verbose. - Run update check every 12 hours. - Check for updates of PG3x. Support thread:

The node server is probably already running, just not connected to PG3. ps auxww | grep weatherstation.py and see if it shows up in the list. If so, then it needs to be killed before you can start it from PG3.

I'm surprised that you have it working given the number of bugs in PG3x. Looks like it's trying to contact those devices every 30 seconds or so. While it fills up the log with a bunch of useless messages, it shouldn't be impacting anything else. (it may slow down the node server response if it's waiting for one of those devices to timeout before it can respond/send a command to another device.

You can try doing a re-install by going into the node server store, selecting Kasa, click the install button and then select re-install into the same slot. That may help. You also may then encounter another error trying to start after that. Getting a node server to start with PG3x version 3.1.16 is unlikely right now.

While the version number is currently the same, eisy has PG3x vs. the PG3 on Policy. They have basically the same feature set which is why the version number is the same, but are very different internally. I struggled with the best way to version PG3x and decided that as long as the feature set remains synced so should the version. As documented elsewhere, PG3x has a number of known bugs that make it difficult (if not impossible) to get node servers running on it at this point. I suggest not even trying until 3.1.17 is release. My current ETA is early next week.

I believe node 18.2.1 is the latest version on Polisy/eisy

I'm working on everything that's been reported. I'm hesitant to release something that still has known issues and I'm also waiting for a new eisy so I can test and debug the problem with purchases. I don't have a specific ETA for the release but I'm targeting early next week.

A small update. #1 is fixed and will be in the next release of PG3x #2 is fixed and will be in the next release of PG3x #3 no progress #4 appears to be resolved and should be fixed with the next release of UDX (this should solve some other minor issues with the same root cause) #5 is being debugged now #6 the first 2 parts are complete.

No, the license is tied to the hardware ID and that has to be changed in the portal based database that holds the license information. I don't know if it is part of the migration option in the portal or not at this point.

There isn't a migration path from Polisy to eisy yet. I'm working on it. Given the number of bugs in PG3x 3.1.16, I can't recommend even trying to use at all at this point.

There are a few bugs related to installing node servers. It may be possible to work around them, but it's a bit complicated. I am currently only able to test installation with my own node servers as my eisy has a bad hardware ID and can't be registered with the Portal (should be getting a new one soon). These are the bugs I'm aware of: 1) First installation will leave some of the node server files with the wrong owner/permissions. This causes the node server to fail to start. Using the re-install option should correct this. 2) When it tries to start the node server after doing the installation it will fail. It actually tries to start the node server before the installation is finished. After installation, stopping and then starting the node server may get the node server working. 3)??? Since I can only test with my own node servers which don't use the Portal or a license, it's possible there are bugs here that I won't see. Based on some of the forums posts I suspect there is in which case, it may not be possible to install any node servers. 4) backup doesn't work. Well it actually does work but it hits the same bug as #2 and PG3 is told the backup is done before it's even started. The backup does happen (it's sitting in /tmp on the eisy) but PG3 doesn't see it and send it on through the browser. 5) Migration is just not possible yet. There are three (four actually) things that need to happen to migrate node servers - First, PG3x needs to be able to read a PG3 backup. The backup file formats are different between the two. I have this bit already coded up. - Second PG3x needs to convert a PG3 node server to PG3x. How the node server is stored and controlled has changed. Again, this is coded. - Third, PG3x needs to move the node server to the local IoX. Restoring the PG3 backup in step 1 will keep the existing setup. So if the node server was installed to a Polisy IoP, then after the restore it will add the Polisy IoP to the database and expect the node server to be installed on that IoX device. I still have to write code. - Fourth the license needs to be migrated from Polisy to the eisy. This happens via the Portal and not something I control.

Thanks for the update. Maybe it was 5.5.0 that was the problem. My eisy is still on 5.4.5 as I haven't taken the time to update it, too busy trying resolve all the PG3x issues.

Since I can't see what you're actually seeing, I have to make assumptions about what is really happening. I thought I'd start fresh and see what happens. I reset PG3x to factory settings and opened the UI using a browser I don't normally use. This is what I get. Clicking the login takes me to the portal login screen. Logging into the portal brings me to the PG3x login screen. I enter the default credentials. That logs me in. The local IoX is connected (yes, it's still 5.4.5). Ignore the red status message, that's me trying and failing to detect when it hasn't actually connected, my current code displays that all the time regardless of the actual connection status. If I drop the the ISYs menu I'll see my local IoX configured and selected. If I reset PG3x again and restart it, this specific browser window will not change, but if I reload the page it will then show the the IoX as disconnected and no IoX will show up under the ISYs menu. However, it will show the status as Connected (which is wrong (sort of)). This is because the UI is still trying to connect to PG3x using the authentication info from the previous login which fails. To correct this, I need to logout and then login again to update the authentication info. This case sounds like what you initially described.

This is caused by a typo in a log message. It doesn't effect anything else. The log not being found is because the node server was unable to start. After re-installing you may also have to manually issue a "STOP" to the node server and then a "START" to get it going.

I'm not sure what's causing the problem with logging in. Is it reporting that authentication failed or just not doing anything at all? If it is showing an authentication error then the username/password isn't correct (or UDX isn't running). PG3x uses UDX to authenticate using the local IoX credentials. For the initial problem where it doesn't show the local IoX connected, that's likely because the browser has cached authentication information that is no longer correct and the UI isn't actually connected to PG3. Logging out and logging back in will refresh the login info and allow the UI to connect to PG3. So assuming you can get logged in again, it should connect and show the local IoX as connected. I'm currently trying to find a way for the UI to detect this case and let you know that you need to re-login.

Probably everyone. PG3x has a bug that's preventing backup from working.

Not having a log available is a good indication that the node server is crashing on startup. In most cases, this would be because it didn't get installed correctly or something it needs is missing. I'd suggest that you try re-installing the node server (node server store -> select YoLink -> click the install button -> select the re-install to existing slot option. If that doesn't allow it to start, download the PG3-log package and attach it here. Also, including the time of day when you did the re-install will help when looking at the log to narrow down what part of the lot to look at.

No, beyond just that increasing the log level results in more log info. If set to Critical, you'll probably see nothing, ever. I'm not sure if there are any messages at that level. If there are, it is very few. error and warning are just as they say. Error messages and/or warning messages only are output to the log. info are messages that report what PG3 is doing. This is the default and generally provides enough information to figure out what PG3 is doing at any given time. debug provides even more detail on what is happening. It tends to be used for things that might be nice to see when debugging but generate so much log output that it can make the log harder to read. db operations adds all the reads/writes to the PG3 database into the log. This generates a huge amount of log info and is only going to be useful when trying to track what is being read or written from/to the database. In general, there's no real reason to change from the default unless you're working with support and they request that you do so.

There isn't yet a migration process to migrate from a Polisy to an eisy. That feature is not yet in the PG3 version included with the eisy. The initial release was designed to be setup as a new system, not replace an existing system. The ability to restore a PG3 backup and migrate nodes/licenses is currently my highest priority. PG3 not recognizing the local IoX sounds like a bug. If it's not allowing you to add it, that probably means it is already in the database and you can't have duplicate entries in the database. It is just that the UI is not able to get that records from PG3.

No, I don't have any type of Davis system and these were written based on requirements and requests from others. Any updates would need to include documentation for those updates. I'm time limited right now so updates would be a pretty low priority. They weren't really meant to be used together, I didn't realize it would even make sense to use both. My understanding was that they were different API's for different Davis stations. I believe that's because it can report some data in either metric or imperial and other data in only imperial. The node server isn't doing any conversions. That would be a typo (or mistake) I start with an existing node server and modify it to work for another, in this case I started with the Open Weather Map node server and forgot to change that in the instructions.

The eisy creates self signed certificates and uses those to both authenticate and encrypt communication between the various software components on the box. Because most users have the box behind a router with no public IP address, it's very difficult to create certificates signed by an authoritative CA. If you tried to install your own certificates in place of the UDI self signed ones, you'd have make sure covered all the components or things would stop working. It's not impossible, but it's not documented nor is it currently supported by UDI.

The eisy is supposed to manage all of the certificates it needs internally. If you want the UI to access PG3 with https, you have to trust the UDI self-signed certificate. The alternative is to use http to access the UI which will then do so without any ssl encryption.

I believe a number of people have documented what they did to migrate from PG2 to PG3. At this point, most PG3 versions of the node servers have continued to get updated while the PG2 versions have not, I'd recommend just deleting the PG2 version and installing the PG3 version. You can try the PG3 re-install option but then you run the risk of the PG2 version causing issues later. When you configure PG3 with the ISY994 it should show all the PG2 node servers as unmanages (because PG2 is currently managing them). One-by-one. 1. document the configuration in PG2 (screen shot of config page, cut-n-paste values, write them down, whatever). Then delete the node server from PG2. 2. Within a few minutes, PG3 should then show that slot as empty. Install the PG3 version to the same slot and then using the configuration info you saved above, re-configure it. Your PG3 version is only one minor version out of date. 3.1.15 is stable and should be fine for now. When you're no longer using PG2, you should be able to an 'update packages' to update to the latest versions. No re-flashing necessary. I believe the only thing missing with IoP 5.4.5 is the ZMatter board support so you'll have to update the packages before you want to migrate your z-wave anyway. The main thing to finish is the getting PG2 migrated to PG3 before upgrading.

PG3 uses 1888, PG2 uses 1883. Different ports so they don't conflict with each other. mqctrl is a node name (or address). It is a node created by the node server. The log entry is just saying that when the node server started, it PG3 didn't find an existing node called mqctrl in it's database. This will always be the case when a node server first starts, none of it's nodes will be in the PG3 database. It's a warning mostly to the node server developer. We used to get the node server version from a file but now expect the node server to handle it internally. This node server is still getting the node server version from the file. Yes, the node server started correctly but then was unable to connect to a broker. It has nothing to do with the internal broker that PG3 is running. There needs to be another generic broker running somewhere that the node server can connect to. I'm not familiar with the mqtt-poly nod server so I'm mostly guessing that it needs a generic broker running. I know it won't work with the PG3 internal broker since that has authentication requirements that the node server won't know. I'm not sure about the PG2 internal broker and it's relationship with the mqtt-poly node server. The OS doesn't make difference but the version of PG3 might. The ability to restore PG2 backups on PG3 was somewhat supported with the initial PG3 production versions but because of the licensing requirements for PG3 node servers, it's probably not going to work for current PG3 production versions.