bpwwer

I can't really add much. I tried upgrading yesterday and same thing. I believe it is UDX that is hanging while doing the upgrade and it never finishes, leaving things in a state where IoX and PG3 don't work. My development system is currently in this state. I poked around a bit but I don't know how all of the upgrade process works and wasn't able to find any quick work-a-around.

I don't believe any of the UDI components were updated. Some of the packages were updated, but the underlying components themselves were not. (Although maybe UDX was changed slightly) For example package pg3x-3.1.22_3 is simply a new package build of pg3x version 3.1.22, there aren't any changes to PG3x. The problem with PG3x wasn't actually PG3x. It was/is a bug in the language PG3x is written in -- Node.js. A new version of Node.js was released and a bug in that is what caused PG3x to fail to start random node servers. The latest updates from UDI are supposed to force PG3 and PG3x to use the older version of Node.js that doesn't have the bug.

There isn't any functional difference between 3.1.16 and 3.1.17. One of the library components was upgraded so that PG3 would continue to work with other updates to the OS. The same for PG3x 3.1.21 and 3.1.22. I have not made a new release with feature/bug-fix additions for either PG3 or PG3x yet.

You need to reload the browser. The browser loads the UI components from PG3 and your browser is currently running the UI component for 6.0.63 which is not fully compatible with PG3 3.1.17. Simply reloading/refreshing the browser will cause it to load the updated UI components.

I believe there is a bug in PG3x that breaks automatic updates. It will be fixed in the next release.

Error querying station 77677 information: NOT FOUND I would guess that means there is no station ID 77677 in WeatherFlow servers.

I don't really know what triggers the device to be locally online vs. offline. But if it's not locally online, the node server can't discover it.

I don't know why. The status status should be 0 but it's not. There's a bug in the error message as it should show the reason the status is not 0, but it doesn't. I've fixed that in version 3.0.27 which I just pushed to the store. Update to 3.0.27 and restart it. The message "weatherflow:query_station_uom: Error querying station 77677 information:" should now show the reason it failed. The WeatherFlow API documents don't document what the various failures are or what they mean. So if the message isn't obvious, you'll have to contact WeatherFlow to get more details.

It is a setting in the MagicHome app. Somewhere under the device settings I believe.

I don't see anything wrong in the log file but it looks like you're using version 3.1.16 of PG3x. That version had a number of issues that have been resolved in later versions. The current version is 3.1.22 Normally, I'd suggest running "Upgrade Packages" from the admin console configuration tab to get get everything up to date, but there is an issue with the latest upgrade that is causing some people problems. By upgrading, you may just be trading one problem for a different one right now. At some point, you'll need to upgrade and sooner is probably better than later. The issue with the latest upgrade is that one or two node servers won't start. If you only have one node server installed, I don't know if that means it won't start or not. All reports have been from people with more than one installed.

Version 3.1.22 is simply a rebuild of the 3.1.21 to allow PG3x to work with the latest system update. No new features or bug fixes are included in this release.

PM me the PG3 log file (from PG3 UI menu Log -> Download Log. I'd need to see the log for the same day that you installed the node server. If that was yesterday, please re-install the node server and then download the log. To reinstall the node server go to Purchases and click the re-install button

@DennisCNo, I don't mind answering questions at all. The warning your seeing is normal under some circumstances. When the UI asks PG3x for a log, PG3x has to set up a process to watch the log file and send any new entries to the UI. When the UI switches away from viewing a log file, it sends a "stopLogging" messages to PG3x telling it to stop that watch process on the log file. There are cases where the UI might not send the "stopLogging" message so to make sure we don't leave watch processes running when we don't have to, we have the UI send that message at other times, just to be sure. In this case, it sent the "stopLogging" to be sure the process isn't running, before it attempts to start watching the log file. However, since it wasn't watching the logfile, PG3x traps the error (UI, you told me to stop watching something I'm not watching) and outputs the warning. There is no error in the log for node server not starting issue. The log will show a couple of messages indicating that the it's attempting to start the node server, but doesn't make it past a certain point. It's waiting for a response from the start service, but the service never responds. PG3x is written in such a way that this doesn't block anything else from happening so everything else should continue working normally. You just end up with one or two node servers in a waiting to start state.

Make sure those 5 devices are configured to allow local access.

As mentioned in at least one other response, this is a known issue with current work-around. It appears to be a bug in the IoX 5.5.5 release on eisy only.

Known issue with IoX 5.5.5 and PG3x, it's being worked on, but no work-around yet.

3 and 4 happen are what PG3x does to migrate the node servers over. The PG3x backup/restore screen has two options for restore: 1) Restore Backup 2) Migrate from PG3 Backup Using #1 won't do anything with a PG3 backup since the backup formats are different between PG3 and PG3x. Using #2 looks at each node server in the PG3 backup and one-by-one migrates to the PG3x, you should see status updates on the PG3x screen as this happens. It's not quick, as I was testing with 30 node servers or so, I would walk way and come back later since it can take a minute for each node server. When the migration is complete, the node servers should not be "unmanaged" state. It won't hurt anything to the do the migration again. It doesn't really care what the current state on PG3x is, it will start clean and migrate from the PG3 backup.

Those are instructions for migrating from a i994 to either Polisy or eisy. Not instructions for migrating from Polisy to eisy. while some the steps may be the same, it doesn't really cover the PG3 to PG3x migration steps I specified above.

What instructions did you follow? "Unmanaged" means that the node server config exists on the IoX but the config points to a different instance of PG3(x). If you simply restored a Polisy backup on the eisy, this would be the result. It would restore the Polisy's node server config so all the node server configs would be pointing back to the Polisy's PG3 and would still be considered managed by the Polisy's PG3 instance. To migrate the node servers, you need to backup PG3 on the Polisy and then use PG3x's migrate from PG3 backup button to migrate the PG3 backup and convert it to PG3x format and change the node server configs to point to PG3x.

While trying to track it down I was restarting my PG3x very frequently and it would tend to be the same node server that it would get stuck on for a while. Initially it was YoLink, then it switched to WeatherFlow, then it switched back to YoLink. So I'd say there's a 50/50 chance that restarting PG3x will result in the Elk node server not starting.

@DennisCThis looks like the same issue we've been trying to debug for the past couple of days. One (or two) node servers don't start and won't start manually with a "already starting" response. Last night I managed to track the issue to the service that PG3x uses to start node servers. PG3x calls the service to start the node server and .... nothing, crickets. the service never starts the node server and never responds back to PG3x so PG3x is sitting there waiting for it. It's seems to be somewhat random as which node server(s) are effected and it can change when PG3x is restarted. For some folks it's been the YoLink node server, for others the Elk, For me, it switches between YoLink and WeatherFlow. I don't have access to the source for that service so right now I'm waiting to here back from the person that does.

Very likely the upgrade wasn't finished.' With the eisy, there's no good way to know when it has finished and PG3x may start before some of the other services that it requires. In this case, it looks like the MQTT service wasn't initialized when ELK first tried to start. The latest update seems to be causing quite a bit of trouble.

There's another thread on this but this might be a better location for it. I just did an upgrade to upgrade my IoX from 5.5.4 to 5.5.5. My PG3x was already running the latest version so it didn't get upgraded. I have 7 node servers installed but not all are enabled. I hadn't really paid much attention to which were running and which weren't but now that I am, I am seeing this issue: After the upgrade/restart YoLink was not connected and I was able to reproduce the problem. Nothing looked wrong in the log. After restarting again, YoLink started fine but my WeatherFlow node server was now in this state, disconnected and already starting when trying to start.

Thanks! I'll take a log a the log. No log showing for the node server or no log available? Unfortunately, with PG3x those are no longer the same thing. With PG3x, it doesn't display the existing entries when you select log, it only shows new entries that happen after you select log. So the node server starting log entries may be in the log file, but not displayed, which is why I requested the log package for it.

I installed and did some testing with the Occupancy node server and I'm not seeing any issues. There is at least on support ticket open that sounds like it might be a similar issue. PG3x shouldn't have any interaction with the Occupancy node server other than to show an Unmanaged dashboard entry for it. I've verified that PG3x isn't attempting to delete or modify it in any way. When you say it disappears, where does it disappear from? From the admin consoles node server list? Or just from the PG3x's dashboard? or both? Is there something that triggers this? I.E. when you restart (IoX, PG3x, the eisy) or is it random?