bpwwer

I started working on the node server and I reviewed the logs you posted above. What I think happened is that PG3 encountered a network error that it wasn't able to handle so it shutdown. When PG3 shutdown, it stopped (or attempted to stop) the node server. However, it looks like the node server didn't stop so that when PG3 restarted, it was unable to start the node server because it was already running. PG3. I've made a couple of changes to the node server to insure that it really does stop when PG3 tells it to. I should be able to release a new version tomorrow.

Yes, 3.1.17 will be the next PG3 version.

The PG3 bug is only effecting those messages displayed in the PG3 log. The check is wrong and then PG3 re-installs the node server config. Other than installing the config when it isn't needed, this doesn't effect anything else. It is fixed and will be available in the next release. Yes, you'll just need to do a upgrade packages to pick up the new release. It will probably be a few days from now. No, this fix won't effect ST-NuHeat. I'm planning to look into the node server this weekend. It needs to be updated to work on the eisy so I'll look into why it's stopping at the same time.

You're right. Fixed in version 2.0.8

The battery logic varies depending on the sensor. Some have 1 = OK, some have 0 = OK. When I wrote the node server I set up the battery definition based on whatever sensor I had available for testing. I'd need to go back and create another battery definition, then try to figure out which sensor needs to use which definition. I've resisted because I think Ambient's inconsistency in this area is bug. The CO2 battery field seems to be coming from the server data but without seeing the raw data from the server, I can't say anymore. Setting the log level to debug should output the raw data from the server in the log. CO2 battery comes from a field in the data called "batt_co2".

Use the "install dev packages" option in the admin console configuration tab and then try again. If you don't have an install dev packages option, you'll need to upgrade packages first.

Ahh, the node servers are running on PG3 but installed on the i994, correct? The verification check assumes that the node servers are supposed to be installed on the IoP running on the Polisy. It's a bug in PG3.

The 5 minute configuration update is either this PG3 instance fighting for control over those slots with something else or it isn't actually successful at updating the configuration. Every 5 minutes it queries the ISY/IoP for the node server configuration and verifies it against what it has in it's database. in this case, it's saying the user name value in the node server configuration is wrong, so it updates it to the correct username. The username field is set to the PG3 UUID/slot#. When I have 2 different versions of PG3 running, I've seen them do this, one changes, the other changes it back. That doesn't seem likely, but the way to check is to look at the configuration right after PG3 updates it. You may have to restart the admin console to get it to show the correct values. Look under Node Servers -> Configuration -> slot#. For NuHeat, it looks like a bug in the node server. It should only be shutting down if PG3 tells it to shutdown. Shutting down for any other reason is a bug. I'll take a look at it at some point. I just don't know when yet.

Once you migrate the licenses, it should be good.

No, unmanaged means it thinks something else is controlling the node servers in a specific slot. Migrating should have updated everything but it sounds like the IoX didn't get updated. You can do the migration again, it doesn't hurt to re-run it. The lack of license should prevent the node servers from running but they should be 'managed', not 'unmanaged'.

Ok, if I understand correctly, what you need to do is simply delete the PG2 node servers from the IoP, correct? My recommendation is to go through the 'unmanaged' node servers one by one and do the following: 1. From admin console Node Servers -> Configuration -> <slot> -> delete. This will delete the PG2 node server from the IoP. PG3 should then see that the slot is now free (may take a few minutes or log out of PG3 and log back in. 2. Install the PG3 node server into that slot. However, if you have scenes and programs configured for that node server, you may want to try and re-install the PG3 version instead. So skip step #1 and when installing the PG3 version, select the re-install option. It should install the PG3 version and if possible, it will attempt to keep the same nodes with the scenes and/or programs intact.

That implies that the username or password for the i994 as configured in PG2 is incorrect. (maybe it got reset somehow). Try re-entering them in PG2's ISY configuration and save. The reason you're getting the error and the node server's are being deleted is because PG2 can't communicate with the i994.

PG3x has more external system level dependencies than PG3. When doing an update, most of those dependencies are also shutdown and restarted. If any of the external dependencies don't restart, then PG3x won't start. We don't have a good way for users to check all the systems so for now, power cycling the eisy is probably the best way to reset everything.

If this is a new eisy, you should first update the system. Go to the Admin Console, select the Configuration tab and select the Upgrade Packages button. This can take some time depending on how much needs to be updated, it could take as long as 30 minutes. Also, PG3 uses a self-signed certificate so the browser will flag that as not secure and you have to explicitly trust it's certificate to get the page to load. I can't tell from your post what is happening. "This site cannot be reached" is typically because the PG3 isn't running, but I don't know where "client ID is not valid" is coming from. That could be related to the certificates.

Looks like Emporia changed the API slightly. I updated the node server and it should work now. Version 1.0.23

@RossI didn't write the node server, I believe @xKingdid. I converted it from a PG2 node server to PG3 node server.

It sound like the IoX service didn't start back up after the upgrade. PG3x needs to the IoX service to be running or it can't start. Can you start the admin console from the IoX finder?

No. @xKing just needs to fix the requirements file so it uses the working version of the library it needs.

@glarsenThe node servers that are written in node.js need to be updated to work with PG3x. I've updated ST-Inventory but haven't had time to update the others yet.

If you're using PG3x on eisy, there's a bug that's preventing it from restarting node servers on start up. It's been identified and resolved so the fix will be included in the next release.

The problem is that the node server didn't really stop when PG3 told it to. So it's still running. And because it's still running PG3 won't let you start it again. If you're familiar with Unix commands, you can ssh to the Polisy and kill off the running copy. Then use PG3 to start it. Otherwise, restarting PG3 should also kill it. If not, a reboot of the Polisy will for sure.

@garybixlerBased on that info, PG3x is trying to verify the node servers installed on the IoX, it does that every 5 minutes. While it was doing that, the IoX device refused the connection, causing the exception. I'll see if I can trap that exception since that shouldn't cause PG3x to shutdown. But since it's happening around the same time every day, is there something happening on the IoX at that time that would make it too busy to accept connections from PG3x?

The node server's not starting on restart is a bug. I'm looking into it. @garybixlerYour log shows that some type of network error occurred that PG3 was unable to handle, so it shutdown. it doesn't provide any information on what may have caused the error or what PG3 was trying to do when the error occurred. Was there anything in the log prior to the exception that may help? Is it happening at the same time every day?

That's the IoX's uuid '_' slot number so it would be specific to your setup. From the eisy's ssh command line you can do ls -l /var/polyglot/pg3/ns to see how each installed node server is represented.

It should be at 5 minute intervals, not 30 seconds. But I've seen it do something like this before where the timer doesn't wait for the specified time. I wasn't seeing it happen at 30 second intervals, but I'm going upgrade everything and check again.