bpwwer

Realize that currently, the PG3 backup/restore doesn't handle the fact that the IoX may also be changing so creating a backup of eisy and trying to restore to a Polisy (or another eisy) doesn't fully work. The backup/restore processes were written with the assumption that PG3 was pointing to a ISY994 and that if you replaced the Polisy, you'd still want to new Polisy to point to the same ISY994 (this was all done before IoP/IoX existed and hasn't been updated since). Fixing this is on the todo list.

Doing a restore will simply try to re-install all node servers so I wouldn't expect it to behave any different. Since it will re-install all node servers it's possible that it could cause this same issue with other node servers. So I'd say more risk of of making things worse instead of better.

If it is only one of many node servers then it is likely something happening with the node server. Node server will attempt to re-connect to PG3 automatically if the connection drops so you may not notice anything wrong, but this will now trigger notifications to UDMobile. In this case, you should see a "failed" notification followed by a 'connected" notification. If you are seeing notifications for all node servers at the same time, it is likely PG3 that has crashed. PG3 will automatically restart so again, you may not be seeing any other indication of a problem but when PG3 crashes, it will attempt to stop all node servers before restarting and both the stopping and restarting of the node servers will trigger the notifications. In this case you should see "disconnected" notifications followed by "connected" notifications. In either case, this is an indication that something is wrong. Node servers shouldn't randomly disconnect and PG3 shouldn't randomly crash. If you just don't care because things seem to be working fine, you can disable the notifications by going to the System -> Notifications page and disable PG3 notifications.

Yes, it is strange. I installed it here fine and then re-installed it and still fine. I've had another report of the same problem, different node server.

Yes, the missing file would be the problem. Try installing (re-install) it again.

@mbking I realized that hardware replacement would cause issues while answering your post so I added that to the issue list. If all node servers are disconnecting/reconnecting at once, that most likely means that PG3 restarted. There's another thread (I think the support thread) where this was reported by someone else. In their case it looks like the network connection between PG3 and the broker failed (reason unknown) which is a fatal error in PG3.

I believe one of the recent system updates does remove PG2 from the system. I don't know if @Michel Kohanim announced that or not. I had plans to include RIO support in my Russound PG3 node server but that hasn't made it on to my active tasks yet.

The PG3 (and PG3x) backup/restore process was never meant to migrate. Hence the need for a specific migrate from PG3 process. The backup/restore process assumes that the IoX (or really the ISY994) wouldn't change between a backup and restore as it was all developed when only ISY994 existed. I think the only way forward is to re-install each node server and re-configure them. You can re-install to the same slot over the unmanaged entries.

Yes, I've been monitoring it. There is a proposed fix, but the code base hasn't been changed since 2019 so I'm not real hopeful anyone will actually do something with it. I may have to fork the code and make the fix myself. That's something I can look at doing in a couple of weeks.

Like I said, there are only 2 cases where PG3 will tell a node server to shutdown. 1. Someone clicks the stop or restart buttons in the UI 2. PG3 shuts down. In your case it looks like PG3 shutdown: 5/26/2023, 13:59:57 [pg3] error: uncaughtException: read ECONNRESET Error: read ECONNRESET at TCP.onStreamRead (node:internal/stream_base_commons:217:20) 5/26/2023, 13:59:57 [pg3] error: uncaught ECONNRESET exception: Error: read ECONNRESET at TCP.onStreamRead (node:internal/stream_base_commons:217:20) 5/26/2023, 13:59:57 [pg3] info: Caught SIGTERM/SIGINT Shutting down. 5/26/2023, 13:59:57 [pg3] info: Stopping running NodeServers... That error indicates that the MQTT broker unexpectedly closed the network connection and since that connection is not supposed to close unless PG3 exits normally, PG3 simply aborts and restarts. As to why, I have no idea. The broker logs may have some information, but I've not found them to be very helpful in the past. Could also be something external disrupted the network (router reboot, etc.).

From the log it looks like your Sonos is refusing the connection attempt from the node server. After a few tries, the node server gives up and aborts. So it looks more like a Sonos problem than a node server problem.

It's not real clear what you're actually running. PG2, which runs on a RPi and on a UDI Polisy is no longer supported. However, it should continue to run. Most of the PG2 node server are also no longer supported. There is a WeatherFlow node server for PG2, but it may or may not work. Again, if the node servers continue to work, you're fine for now. PGC was discontinued and is no longer active, this includes all the node servers for it of which WeatherFlowPGC is one. PG3 and PG3x are the latest versions of Polyglot. These will only run on a Polisy or eisy controller from UDI. So you can't install it on a Raspberry Pi. PG2 node servers are not compatible with PG3(x) and many are no longer free. The transition from PG2 to PG3(x) has been happening over the past 2+ years.

@dbwarner5 stopping and starting the node server are supposed to generate notifications. On stop, it disconnects and on start it connects. Those are normal and correct. Stopping and starting node servers should not be happening often. In fact, the only way the node server can be stopped if if you stop it or PG3 shuts down. What I'm concerned about are "failed" notifications. Those mean the node server stopped communicating with PG3 which is something that should not ever happen and if it does, it's probably a bug somewhere.

Please verify in the node server logs that the node servers are actually disconnecting and reconnecting. You'll have to do this within the same day the notification was sent. In my case, the node server was disconnecting and reconnecting so the notification system was working as intended. Also, the node server was working as intended. When the connection dropped, it reconnected and the node server continued working without issue. The question is what's causing the connection to drop in the first place? In my case it appears to be caused by network packet corruption or possibly a bug in the low level networking code. In either case, not something I can fix.

You should update to the latest version of PG3 as this issue has been fixed. The (Re)Install button isn't really correct. It should be labeled "Update" and you can only update if you already have it installed. Instead, go to the Node Server Store, select the node node server from the list and then click the "Install" button to install.

I just submitted version 1.0.8 of the plug-in to the store. Go to the Node Server Store and click the Refresh Store button. Select the Caseta node server Click "Install" for the trial (I'm assuming you're running the trial) You should then have the option to re-install to the same slot, click on that and the node server will install the new version and restart the node server. The button press events for the configurable Pico buttons should now work.

I've been able to reproduce the issue and I'm working on a fix.

I suspect that's because the fail/reconnect happens within a couple of seconds. You may have said earlier, but are you running PG3 or PG3x? What does the node server log show at those times for a couple of them?

You should get a node created for each button on the Pico which it looks like you do from what you posted. You have Study_Pico - A, Study_Pico - B, Study_Pico - C, and Study_Pico - D right? Each of those should have an option to set what the button does like below. By default I believe button A sends an ON command, button B sends a BRIGHT command, button C sends a DIM command and button D sends an OFF command. But you can configure each button independently. For example with A configured to send ON and B configured to send OFF you could put these in a scene with an Insteon lamplinc and button A would then turn the lamplinc on and button B would turn it off. What you can't do is use a single button as a toggle (well maybe you can with a set of programs). Speaking of programs, you should also be able to trigger programs on the button press. Like below. Pico buttons are somewhat limited in that the only thing the bridge sends to the node server is the button pressed (and button released) events. They don't have any status. But this should be enough to do what you want. To summarize you have two options with Pico buttons 1. Use them as a scene controller where they send a command to the responders in the scene. 2. Use the button press event as a program trigger. If it isn't working as I described above, set the node server log level to debug, do the operation you're trying to make work, download the log package for the node server and PM it to me.

@Sparks PG3x uses a service on the system called UDX to do the authentication. That service is rejecting PG3x's request. That is not something that should be happening. So please to submit a ticket. There can be issues when that service is updated as part of a upgrade where it won't work properly until the system is rebooted, but as you've already tried that, this seems unrelated.

All of them or only specific node servers? What node servers do you have installed? My Roku node server seemed to do this. What's happening is that the mqtt connection drops, the node server then re-tries and successfully reconnects. So you see a fail notification and a connect notification. I was seeing this on only one of about a dozen node servers installed. I don't know why that one specific node server was having issues with the mqtt connection.

Critical - not used. Error - something failed that isn't expected to normally fail. Warning - something that may need to be reviewed. Info - messages that track execution. debug - more verbose execution tracking. db operations - log all database operations.

Looks like PG3x is not running. If PG3x was running it would connect fairly quickly, but then take a while to migrate node servers. the "Upgrade" process doesn't always result in things starting backup properly so a full system reboot or even power cycle is needed to get everything properly restarted. So if you've been waiting for 15 or 30 minutes with no change, power cycle.

The package has been updated. I believe all you need to do is run the "Upgrade Packages" again.

The package is missing a file that prevents PG3 from starting. We're working to get it updated.